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

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

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

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

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