51Testing软件测试论坛

标题: 去年10月写的一篇文章：测试的趣味与自动化改进 [打印本页]

作者: cmsbai 时间: 2005-5-27 15:28
标题: 去年10月写的一篇文章：测试的趣味与自动化改进
测试的趣味与自动化改进
看到这个题目很多从事测试工作的人会很吃惊，测试难道会有趣味（开什么国际玩笑，向这个哗众取宠的家伙丢鸡蛋），大家先把文章看完，别忙丢鸡蛋。
我毕业已经三个月了，而我接触测试工作已经有半年的时间了，在从事测试工作的半年时间里，我大部分时间是为测试而测试，特别是刚开始接触测试工作时，只是想尽快的完成测试，所做的思考仅仅限于程序的哪些运行点我还没有跑，然后是重复无聊透顶的案例执行操作，而很少花时间思考我应该走一个怎样的测试过程，我怎么把测试的效率提高，甚至把测试有趣化。当我逐步熟悉了测试工作之后，特别是正式毕业回到公司，我体会到了大部分测试人员所痛苦的：测试的确是无聊透顶的工作。当你拿着自己书写的案例或是别人给你的案例做第一遍执行的时候，就已经有无聊的感觉，更何况你还要重复执行第N遍（俺是学数学的，相信大家也都知道N的意味），这样的日子会逐渐瓦解一个测试人员对他工作的热情度，甚至使他讨厌这项工作，最终离开这项工作。为什么会这样子呢，因为他感觉他的工作没有了乐趣，而重复性的工作是最根本的原因。我们这么才能摆脱这种无聊的境地（可不是工作哦），开发工作的乐趣呢，我的答案就是自动化测试的引进（也许大家有更好的方法，欢迎能告知我）。
关于自动化测试的文章，大家都能通过google搜索到一大堆（其中肯定又有一堆比我的认识深刻正确），我要讲的是我的实际体会。自动化测试的引进是一个逐步的过程，它不是通过购买大量的设备与软件就能立即实现的（当然有了必要的设备与软件实现将更加容易），而是通过我们在实际测试工作中运用我们的大脑（人脑虽然没有电脑听话，但是比电脑聪明，哈哈），怎么运用我们的大脑，当然不是用我们的大脑去执行测试案例了，我们要用我们的大脑思考我们怎样改进测试过程，哪部分可以自动化进行（所有的测试都可以实现自动化在人工智能没有成熟之前是彻彻底底的谬论），然后当然是实施了。刚才说到我们做不到完全的自动化测试，同时我还要强调自动化测试是一个逐步的过程，象软件开发一样，我们把测试过程的很多小部分实现了自动化，然后就可以把它们关联整和到一块。
自动化测试过程的引入以及改进可能有一些难度，它需要一些脚本功底和编程功底，正是有些难度才使测试变的有些趣味（特别是对喜欢挑战性工作的人来说），同时即使我们的功底很差，也没有关系，我想我们都是可以学习的。用脚本或程序实现测试过程的自动化这个选择取决于我们自己的偏好、测试环境以及允许改进的时间等等，对于不太懂编程或测试过程简单或时间比较少的情况，我建议用脚本实现比较好。如果你非常精通编程（认为编程完成这项工作对你来说是小菜一碟，同时花费不了多少时间），你可以采取编程实现。为了更加清晰一些，我认为它们有以下对比结果：
脚本比程序有以下优点：
一、脚本实现不需要多少编程知识，技术难度比较小。
二、脚本实现花费的时间要远远小于编程实现花费的时间。
同时呢程序比脚本又有以下优点：
一、程序实现能把自动过程实现的比较彻底。
二、程序实现自动化的范围比脚本实现的范围要广。
为了让大家更好的认同我的观点，同时体验一下自动化引入带来的乐趣，我举个例子：有一段时间我在测试一个监控模块，需要做大量模拟用户的操作来测试这个模块会不会有异常，特别是要模拟用户浏览常用网页的操作，做了两次之后，感觉太烦琐且极度无聊，老是在那儿打开网页，然后关闭（大家可以想象一下无聊程度）。于是呢我花了10分钟写了一个批处理脚本，在脚本中利用shell调用IE打开我要浏览的所有网站，感觉不错，不用老用鼠标双击IE然后输入地址了，节省了不少时间，很有成就感，同时明显的提高了效率。但是这样测试了几次，又感觉测试有些烦琐，虽然不用频繁点击鼠标了，也不用输入网址了，但是还要我频繁的按ALT+F4来关闭打开的窗口，而且还要我蹲在测试机前，重复做几次的确又会厌烦的，但是用批处理恐怕实现不了关闭我打开的IE窗口（至少是我目前不知道怎么能用批处理来实现）。于是我就考虑只好用程序实现了，同时呢用程序实现的话也不是特别难，于是我花了2天的工作空余时间利用VC写了一段小程序，主要就是利用CreateProcess打开IE浏览特别的几个门户网站，然后利用EnumWindows以及EnumChildWindows枚举所有的窗口,找到CreateProcess中打开的IE窗口，关闭掉。呵呵，就这么简单，以后我每天做的工作就是升级监控模块，然后运行我的测试程序，过半个小时再去看一下结果。这样为自己节省了大量的时间，同时在更短的时间内还能更好的保证测试质量，最重要的是没有那么烦琐无聊了。哈哈！
讲到以上的程序实现，还有一个小插曲：改造的初期我是想把测试过程完全自动化实现，其中包括接受其他机器发送来的命令并解析，自动替换升级数据，自动卸载和加载监控模块，打开IE浏览网站以及关闭IE窗口，甚至包括自动重启机器，花费大量时间写了监听并解析其他机器发送来的命令这个模块之后发现没有什么价值，自动替换升级数据实现太过复杂，同时自动重启机器后再进入所需系统仍然需要人工选择（测试机安装了多套系统，且包括LINUX系统），后来就只利用上了打开IE浏览网站以及关闭IE窗口部分。这个插曲只是想说明我们在改造测试自动化的过程中不要太理想化，要想到我们改进的测试的用户是我们自己（没有广泛的用户群），没有必要花大量的时间规划我们的改进计划以及完美我们的自动化测试，因此我们要做的是利用短的时间来提高我们的测试效率，使我们的测试变的有趣味，用我们工作时间的很小部分完成这样的工作。
啊哈，看到我们的经过我们改造的测试过程效率越来越高，同时还省确了大量的需要我们进行重复无聊的操作，是不是很有趣！同时呢，进行自动化测试的改进不只是有趣，而且可以更好的保障软件的质量，因为自动化测试可以走一些手工几乎无法实现的测试案例，这个无法实现不是真的无法实现，是根据现有人力物力以及我们的忍耐度不可能做到的案例，什么案例会是这样呢，可能不太好想象，还是举个实际事例吧：有一个待测程序，它可以压缩PE文件（类似于大家熟悉的UPX）和解压经过其压缩的PE文件，同时呢有三个压缩参数，每个参数项有10个可选参数，现在交给我测试（同时开发人员告诉我全部功能都已经实现，就是可以在各种参数组合条件下压缩没有经过这个程序压缩的PE文件），怎么测？难道我要手工输入参数一个个压缩搜集的PE样本文件，只是参数组合就有1000个，更何况我不能只拿一个样本文件来测试吧，同时我也不可能只做一遍（开发没有错误是不可能的，改正10个错误不出现其他错误的程序员我还没有遇到过呢）。看来我只能走其他的测试过程了，3个参数项用3个数组来保存，然后让他们组合成1000个组合，把每个组合传递给被测程序，让被测程序慢慢去压缩我搜集的10000个不同PE文件去吧，我又可以到www.PLmm.com去看MM了，哈哈。
公司开饭了，呵呵，饿了，今天就写到这儿了，俺要跟大家说声“byebye“，吃饭去了。

------------------------------------------cmsbai@msn.com
www.pakport.net

[ Last edited by cmsbai on 2005-5-27 at 15:31 ]

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)