也谈自动化测试开发(2)

　　如何协同开发?自然是加入版本控制。现在的自动化框架用的版本控制是Git，这个比较火哦!多人协同开发，提交代码，肯定会有conflict。我们的做法是这样的，除了master分支，每个人在自己本地建个开发分支，每次提交代码前，先从Git Server上checkout最新代码到master分支，然后，在本地的开发分支和master分支merge，最后commit代码。

　　自动化脚本如何命名?我们的自动化脚本都是从手动测试用例挑选出来的，我们希望做到自动化脚本和手动脚本之间有个关联，但同时又要做到，只要看到这个自动化脚本的Title,就能知道这个自动化脚本的大概的测试意图。我们是这样做的，ModuleName_FilterName+ID， 这个ID便是手动测试用例的Define ID。

　　Keyword的粒度怎么把握?关键字相当于手动执行的一个执行步骤，我们是这样做的，首先Review手动执行的测试用例，抽取出通用的步骤，实现关键字。但如果关键字的粒度做得太细，那么关键字的数量会比较庞大，但粗了的话，关键字参数的形式就会比较复杂，对于构造自动化脚本的同事来说，就需要学习。这个粒度需要把握好，同时，对于自动化关键字参数，需要有详尽注释，使用格式范例。

　　自动化脚本中的变量如何维护?一般会把自动化脚本中的一些跟执行环境相关的参数以变量的形式抽取出来，存放在配置文件里，这样一来，在部署自动化测试环境的时候，就只需要修改这些跟环境相关的配置文件即可以。但这个配置文件会随着自动化测试用例的增加，而变得臃肿。

　　自动化脚本中运行结果如何判断?自动化测试脚本，如同手动执行测试用例一般，也有预期结果，实际结果的比对，如果两则不一致，则认为这个自动化脚本Fail。刚开始我们是这样做的，将预期结果一参数的形式传给一个关键字，这个关键字在后台会比较实际结果，如果不一致fail。刚开始也觉得没问题，后来发现，因为环境因素，一些预期结果是会发生变化的，这时候，我们必须修改自动化脚本。后来的做法是这样的，先dump出一份预期结果，存放在本地，执行自动化自动化脚本的时候，再Dump出一份实际结果，然后比对这二者。这样就避免了频繁改动自动化执行脚本了。

　　执行结果的容错性?如何确保执行结果是可靠的，在自动化关键字的实现过程中，会加入一些容错机制。举个简单的例子，发一封带特性附件的邮件，命中了一个策略。这时候，会在log数据库中产生一条记录。在实现自动化关键字的时候，可能会遇到这样的情况，当你去检查log数据库的时候，很有可能那条log记录还没生成好，这时候如果直接判断，自然会fail。我们是怎么提高容错性的呢?很简单的方法，就是加入了一定时间的延时，比如循环检查多少次，每次delay一秒等方法，这就带来了另一问题，在执行时间会延长。

　　及时获取RD帮助。在实现DLP功能时，发现程序重新载入配置会比较耗时，如果自动化脚本不能重新载入完成，就发邮件的话，是无法命中你的配置策略的。这时候，需要寻求RD帮助，他们在后台提供了hidden key。当enable这个hidden key后，重新载入完成后，程序会在console上打印出提示信息，这时候，我们的自动化脚本只需要去检查这些提示信息有没有生成，就可以判断是否重载完成，再发邮件。

　　在自动化测试开发，维护过程中，成本最大的是什么?觉得一方面是测试数据的维护。另一方是因为产品功能方面的变动引入的自动化脚本需要修改方面的成本。

　　自动化测试的应用场景?对于项目而言，最大的价值是什么?就我们项目而言，主要还是把手动测试用例变为自动化测试用例，也就是所谓的黑盒、功能性自动化实施。当初定位的时候，也是想做成自动化回归测试的，缩短回归测试时间，提高回归测试效率，确保代码优化、及新引进的代码不会影响旧有功能。也没指望自动化测试能发现手动测试发现不了的问题。理想的状态时这样的，自动化测试和CI系统集成，当出了一个新的build，自动化框架能够自动安装新build，执行自动化脚本，完了以后将执行结果通过邮件发布出来。

　　有没有方法把关键字的实现提前?而不是等到功能稳定后，再开始做自动化。看过Junit中的mock的概念，但具体怎么做，还不清楚，下阶段学习下!

　　现在看来，一套自动化测试的开发也涉及到：项目本身需求分析、hight-level 设计、框架开发、自动化脚本实现、各种规则制定、多方面协作等，所以需要把自动化测试开发当做项目来做哦!

原文转自：http://www.uml.org.cn/Test/201306283.asp