在前一个测试子项目中的表现不错,而后我又被调入一个产品发布版本的回归测试子项目中去。相比之前的测试子项目(软件模块的功能测试),回归测试就很不一样了。回归测试所执行的,都是比较基础的测试用例,也是不管版本如何变迁也都不必要进行太多改动的测试用例。也正因为需要比较频繁地(每一个新的产品发布版本)执行这些测试用例,所以这些用例几乎都有相应的测试脚本,可以缩短测试执行时间,脚本就是利用之前我提到过的内部工具写成的。脚本语言本身可以抽取一些library出来,具有一定的模块化构造,可以减少一些重复的脚本代码,但是后来我从测试自动化(TA,Test Automation)的角度来看,依然是非常低级别(基础,非编译)的自动化实践。

相比之前跟着导师干活,这一次的工作就需要我自己独立进行,而且工作内容也增加了许多。包括要自己写测试计划,还要组织审核会议(Inspection Meeting),通过审核后的计划会在系统里被标示为“已批准”(Approved),这样我才可以根据这个计划以及测试用例开始执行测试。测试计划还是不难写,毕竟是回归测试嘛,把测试管理系统里以前别的版本的回归测试计划拿出来看一看,修改一些相关的字段,例如产品版本啊、执行人名称即可,大同小异。要随便弄弄蒙混过关倒是不难,依葫芦画瓢就行,难点是在于你是不是想弄明白这些回归测试的用例,毕竟这些用例都是别人写的,而且除了用例之外,还有测试脚本,万一两者之间有些互相冲突的信息,或者脚本报出的一些错误信息在用例中没有描述到,如何能够处理妥当,这需要执行人多花点心思,多消耗点脑细胞才行。

回归测试的另一个挑战在于,它涉及到的系统架构范围往往不止一个模块。之前在导师的带领下工作,只需要按照用例中所给出的信息,执行相应的命令即可。就算你不太明白命令中一些部分的参数该如何设计,在人机界面上执行这些命令时,它自己也能发现不合规的命令格式并且给出提示,要求你输入正确的值。只是执行、观察、发现错误、修改命令或参数、重新执行、记录结果,还是很轻松的。但如今由于要测试更多的模块、更广的范围,需要了解的命令也逐渐地多起来,在测试中发现一些异常现象后要查看日志、系统状态也需要执行一些命令,而这些命令并不在我负责测试的技术领域中,所以还得去找相关领域的测试同事、专家请教学习,或者不愿意求人的话就得自己找相关文档。在此,沟通以及查阅资料或者摸索的能力就非常重要了。

只是执行测试是相对简单而且有点枯燥的活,因为这些功能多数都是稳定的,不大会出错。于是我就把一些时间花在思考、理解这些测试用例和脚本上,正好回归测试的用例中总有一些是执行时间比较长的,我就利用这些时间去查阅资料、文档,理解测试用例的设计理念,以及研究多个测试用例之间的关系,看看是不是有漏测的功能。

在当时,我们的回归测试用例都是从现有的功能测试用例中直接筛选出来的,挑选的是其中比较基础的、通用的测试用例,是否容易实现脚本化也是考量的因素之一。因此,如果只是去看测试计划中的测试用例集,难以看到全貌,不知道为何要选择这些用例,也不知道这些用例之间有什么特别的联系,它们结合在一起是否有足够完整地覆盖了要测试的范围。因而,想要理解这些测试用例以及其关系,找到是否有漏测的功能,需要额外花一些功夫顺藤摸瓜地查看相关技术领域、模块的测试用例和以往的测试计划。看一看某个测试用例在它的模块里,是否还有其他的测试用例也在验证相似的功能,有什么区别,为何不选择其他的测试用例做回归测试,以及是否有一些应该测而没有测的功能(这需要研究功能需求规格说明书文档才行)。研究这些问题其实是蛮有意思的事,它能够帮助你更深刻地理解自己手中正在执行的测试用例,更能够分辨出在执行中你对哪些输出信息应该保持关注,而对其他一些信息则可以睁一只眼闭一只眼(因为有其他的测试用例会专门检查这一块的情况)。做到测试用例或者测试执行有重点、有针对性有着莫大的好处,专注能帮你过滤掉一些不必要关注的信息,延缓测试过程中的紧张感,也能够提高你对重点信息的关注度和敏感度,更容易发现问题。

查看更多“我的测试之旅”文章
1. 起点——作为软件开发人员
2. 转变——作为专职测试人员
3. 同期——加入测试自动化小组
4. 并行——自动化回归测试
5. 难点——功能改进的测试
6. 跳转——追逐新鲜事物的探险者
7. 启程——Scrum中的测试工作者
8. 困难——没有现成的测试工具
9. 行动——简化测试文档和流程
10. 贡献——开发项流程(Development Item Process)
11. 尝试——Scrum Master
12. 机遇——测试自动化培训师和教练
13. 转型——敏捷教练

敬请关注 《大测大悟——测试的敏捷之道》开放出版过程

联系方式:
- 新浪微博
- 谷歌邮箱 kaverjody @gmail.com
- LinkedIn