在前一个测试子项目中的表现不错，而后我又被调入一个产品发布版本的回归测试子项目中去。相比之前的测试子项目（软件模块的功能测试），回归测试就很不一样了。回归测试所执行的，都是比较基础的测试用例，也是不管版本如何变迁也都不必要进行太多改动的测试用例。也正因为需要比较频繁地（每一个新的产品发布版本）执行这些测试用例，所以这些用例几乎都有相应的测试脚本，可以缩短测试执行时间，脚本就是利用之前我提到过的内部工具写成的。脚本语言本身可以抽取一些library出来，具有一定的模块化构造，可以减少一些重复的脚本代码，但是后来我从测试自动化（TA，Test Automation）的角度来看，依然是非常低级别（基础，非编译）的自动化实践。
相比之前跟着导师干活，这一次的工作就需要我自己独立进行，而且工作内容也增加了许多。包括要自己写测试计划，还要组织审核会议（Inspection Meeting），通过审核后的计划会在系统里被标示为“已批准”（Approved），这样我才可以根据这个计划以及测试用例开始执行测试。测试计划还是不难写，毕竟是回归测试嘛，把测试管理系统里以前别的版本的回归测试计划拿出来看一看，修改一些相关的字段，例如产品版本啊、执行人名称即可，大同小异。要随便弄弄蒙混过关倒是不难，依葫芦画瓢就行，难点是在于你是不是想弄明白这些回归测试的用例，毕竟这些用例都是别人写的，而且除了用例之外，还有测试脚本，万一两者之间有些互相冲突的信息，或者脚本报出的一些错误信息在用例中没有描述到，如何能够处理妥当，这需要执行人多花点心思，多消耗点脑细胞才行。
回归测试的另一个挑战在于，它涉及到的系统架构范围往往不止一个模块。之前在导师的带领下工作，只需要按照用例中所给出的信息，执行相应的命令即可。就算你不太明白命令中一些部分的参数该如何设计，在人机界面上执行这些命令时，它自己也能发现不合规的命令格式并且给出提示，要求你输入正确的值。只是执行、观察、发现错误、修改命令或参数、重新执行、记录结果，还是很轻松的。但如今由于要测试更多的模块、更广的范围，需要了解的命令也逐渐地多起来，在测试中发现一些异常现象后要查看日志、系统状态也需要执行一些命令，而这些命令并不在我负责测试的技术领域中，所以还得去找相关领域的测试同事、专家请教学习，或者不愿意求人的话就得自己找相关文档。在此，沟通以及查阅资料或者摸索的能力就非常重要了。
只是执行测试是相对简单而且有点枯燥的活，因为这些功能多数都是稳定的，不大会出错。于是我就把一些时间花在思考、理解这些测试用例和脚本上，正好回归测试的用例中总有一些是执行时间比较长的，我就利用这些时间去查阅资料、文档，理解测试用例的设计理念，以及研究多个测试用例之间的关系，看看是不是有漏测的功能。
在当时，我们的回归测试用例都是从现有的功能测试用例中直接筛选出来的，挑选的是其中比较基础的、通用的测试用例，是否容易实现脚本化也是考量的因素之一。因此，如果只是去看测试计划中的测试用例集，难以看到全貌，不知道为何要选择这些用例，也不知道这些用例之间有什么特别的联系，它们结合在一起是否有足够完整地覆盖了要测试的范围。因而，想要理解这些测试用例以及其关系，找到是否有漏测的功能，需要额外花一些功夫顺藤摸瓜地查看相关技术领域、模块的测试用例和以往的测试计划。看一看某个测试用例在它的模块里，是否还有其他的测试用例也在验证相似的功能，有什么区别，为何不选择其他的测试用例做回归测试，以及是否有一些应该测而没有测的功能（这需要研究功能需求规格说明书文档才行）。研究这些问题其实是蛮有意思的事，它能够帮助你更深刻地理解自己手中正在执行的测试用例，更能够分辨出在执行中你对哪些输出信息应该保持关注，而对其他一些信息则可以睁一只眼闭一只眼（因为有其他的测试用例会专门检查这一块的情况）。做到测试用例或者测试执行有重点、有针对性有着莫大的好处，专注能帮你过滤掉一些不必要关注的信息，延缓测试过程中的紧张感，也能够提高你对重点信息的关注度和敏感度，更容易发现问题。