刚被派遣到诺基亚不久，确切地说是刚刚结束新员工入职培训的时候，小组长问我对测试自动化是否 感兴趣，我觉得好像蛮酷的，而且还可以被派到北京去参加两天的培训，英国人授课，何乐而不为呢。这个英国人是Mark Fewster，《Software Test Automation》的作者，这本书被认为是该领域的开山之作，详细地描述了测试自动化相关的所有细节、战略和战术。于是这样我加入了只有两个人的兼职测试自动化小组，之所以成立这个小组是因为在国外的其他研发中心使用测试自动化的效果非常好，所以要把它引入到杭州的研发中心。

　　我们很快接下第一个任务，将一些领域的回归测试用例实现为自动化脚本，以便节省回归测试所使用的时间和人力。产品线的测试自动化专家们已经做了一些工作，他们围绕着我们所使用的测试工具，使用其脚本语言封装出一个测试自动化框架。这个框架提供了若干库（Library），使用库所提供的函数可以快速地创建测试脚本，当有需要时我们也可以自己为库开发一些新的函数。当然，只是这一点还算不得是框架，它还规定了测试脚本要遵循的格式，以及要使用的日志功能，以便生成格式比较统一的测试结果记录和报告。甚至于它自己还有设计的测试脚本文件夹结构，通过一个特殊的INI文件及其内容来记录测试脚本的执行管理。运行这个测试自动化框架，可以看到相应测试脚本库下的所有测试脚本，并且可以配置要执行哪一些脚本。

　　跟随着这个测试框架的，还有一些相应的测试自动化理论知识。我们将测试全过程看做五个部分：前置条件检查；设置；执行；结果分析；清理及复原。所有的测试用例都是如此：首先，检查测试用例可以执行的前置条件是否已被满足，如果没有，则退出测试不执行，例如系统中存在某个被测板块；而后根据测试用例所需，将相关的资源或者环境设置到相应的状态，例如将被测板块设置到某个状态或是创建一些资源；而后是执行测试脚本，并且记录执行的结果，同时需要对结果进行分析，除了每一个测试步骤要检查之外，所有相关测试步骤执行完后也要检查整个测试的结果；后，在退出当前测试脚本的执行之前，它必须清理在设置阶段所改变或增加的资源及其状态，例如将被测板块恢复到测试开始前的状态，这一步非常必要，要做到执行或不执行当前测试脚本，留给后续测试脚本的被测系统环境都是一致的。不然的话，对于后续测试脚本来说，它们得到的测试环境将是不可预知的，运行脚本所得到的测试结果也是无法肯定的，如果脚本出错了需要调试也会难以定位问题的根源。

　　多个测试用例会组成一个测试集合，这个五个部分同样适用于测试集合层面：每一个测试集合都要检查该集合中所有测试用例都关注的前置条件；也要进行共同都需要的设置，例如创建某个文件，以供测试用例验证 该文件的各种操作是否正常；而后是执行测试集合，当然也包括对结果的分析以及生成报告；后在退出测试集合的执行前，将设置阶段所做的改变全部复位，以便后续测试集合得到当前测试集合相同的执行前环境。集合的集合，集合的集合的集合，循环往复，一直到整个产品线的所有测试用例集合，都适用这五个部分的模型。

　　在此过程中，我们的小组不断地发展壮大，当然，依然是兼职状态，吸纳的都是感兴趣的人，以及之前在回归测试工作组工作的人。于是我们开始面临一些技术之外的问题，也即如何确保大家所写出来的都是统一风格的测试脚本，都能够知道如何开发出符合框架要求的测试脚本，如何使用框架运行测试脚本以及对测试运行进行管理，等等。同样的，我们也需要考虑把测试的一些质量管理流程同样的引入到测试自动化的工作中来，例如如何对测试脚本的开发进行评审和修订，如何确保测试脚本的质量，如何确保每一个测试脚本自身都是一个原子操作，不会给后续的脚本留下烂摊子。

　　由于当时产品线整体正在将研发工作的主题转移到杭州研发中心，这个测试自动化框架的用户主题也将会变成杭州研发中心，于是管理层决定要在杭州寻找一个关键用户（Key User）来管理这个框架，负责它的维护工作以及持续地开发。对这个框架有着极高热情的我终得到了这个机会，于是我也有了机会和足够的时间可以去研究这个框架自身的设计原理。当然，框架本身也是用那个类C的脚本代码实现的，而且代码库也都是内部公开的，所以即使我不是关键用户，也可以学习它的设计原理，但是作为关键用户还需要协调和处理多人并行开发过程中的很多问题。于是我们开发出了一些相关文档和教程，帮助大家理解和使用这个框架，把它推广到测试自动化小组之外的其他测试团队，把普通的功能测试用例（不属于回归测试用例的集合）也纳入到这个框架之中，统一地管理起来。由于框架自身的模块化，功能测试脚本的开发人员可以省去许多重复函数代码的开发，而且也不用再靠自己去处理信息记录、结果分析和生成测试报告了。

　　人多了，有不同的想法和看法，测试自动化的人员也一样。测试自动化和开发的关系其实比它和测试的关系近多了，因为两者都涉及到代码。每个人写的脚本代码风格都不一样，所以我们也有自己的（测试脚本代码）编码规范和命名规则等等一系列的规定。而我们作为测试自动化小组，在审核会议上着重观察的则是测试脚本代码，而不是测试用例的逻辑，或是测试计划、报告之类的东西。

　　在此过程中，我们还要承担评估测试自动化工具、框架的工作，除了这个内部自己开发的框架，我们也同时有考虑其他的商用工具，不同的工具各有优势，例如有的工具集成了类似于实验室环境管理的功能。但终，在当时我们选择了内部开发出来的这个框架，因为大家对它更熟悉，推广使用它进行新脚本开发的成本相对更低，等等一些原因。

　　后来这些测试给我们一个新的测试自动化框架，由另一个产品线的测试专家们开发出来，也是围绕着公司的测试工具进行封装。但他们的实现思路主要是沿着如今流行的DSL路线前进，他们希望将那些所有测试用例都会用到的操作封装起来，作为一种无关具体实现技术（例如函数代码）的调用。使用这个框架的测试人员无需去查阅那个类C脚本语言，只需要使用这个框架所提供的操作即可。不过由于种种已记不得的原因，这个框架并未流行开来。