都讲自动化测试开发，当然要把开发自动化测试框架也当做一个项目来做。这时候，就需要考虑应该选择何种类型的自动化测试框架：数据驱动、关键字驱动、还是Junit ,TestNG ? 抑或直接利用现有的开源自动化测试框架，如Robot Framework 。无法讲这几种类型的框架，孰优孰劣，关键是认清项目实际，选择最适合的。讲一些题外话，就Java学习者而言，Junit3.x的源码是再好不过的教材了，JUnit框架运用到了大量的设计模式，反射机制。

在决定了选用何种自动化框架类型后，下面你需要抉择的就是：应该选择何种编程语言呢？编程语言的选择和开发者的技术背景有很大关系，一般都会选择自己熟悉的编程语言，但这也往往是个局限。另一方面，也受到SUT的影响。一般而言，很少见有选择C，C++作为自动化框架开发语言的，虽然这两种语言的执行效率要高，但开发效率要低一些。我们项目的自动化框架是Java语言编写的，关键字也是由Java实现的。关键字的实现选择Java，是由于SUT - 即Domino服务器提供的API是有Java ,C++。所以自然选择了Java。而自动化框架开发语言的选择，其实可以有别的选择，如脚本语言Python ,Perl。脚本语言Python，或Perl，作为超高级开发语言，解释执行的特性，在开发效率上可能会高一点。

下面就是关键字实现方式的选择了。关键字就相当于手动执行测试用例当中的一个步骤，比如现在的项目，即一个关键字就是修改产品的一个配置选项，也可以是发一封带有特定附件的邮件。就我们的产品而言，Domino提供的操作数据库的方式有三种，即DIIOP、Web Services和本地调用。刚开始选择的是DIIOP，这种方式实现起来比较简单，后来发现通过这种方式实现的自动化脚本，即包含十几个关键字脚本，其执行时间大概要35s – 40s。而Web Services的执行时间就要效率就要高得多，差不多一个自动化脚本的执行时间可以缩短10s, 但其实现需要分为服务器端Web Service的发布，和客户端的调用，通过这种方式实现，测试环境的部署也要复杂些。讲这些，主要是告诉我们，一开始就需要对这些做出评估，选择合适的方案，不然中途改变，影响是很大的。

自动化框架，说白了就是流程的封装啦。那么一个自动化框架应该包括哪些流程呢？来看看下面这两幅框架图吧。

第一幅图讲解了一套自动化测试是由自动化框架，自动化脚本，关键字组成的。第二幅图描述了自动化框架的流程：根据配置挑选要执行的测试用例，解析自动化执行脚本，将自动化执行脚本送给自动化执行引擎，生成Log文件，最后生成Report。

对比Robot Framework框架，这套简单的自动化框架有哪些地方可以提高呢？第一个，基于Test Suit的setup和teardown。一个自动化脚本的组成是这样的：清理、初始化测试环境(如，建立一些测试脚本需要用到的数据库)， 执行自动化脚本，生成执行结果，最后清空环境。这些步骤我们的自动化脚本中也实现的，但如果想在执行一批测试用例之前，做一些动作，执行完以后，在清空，我们用得方式就是把这些自动化脚本的名字在要执行的一批测试脚本之前，我们的脚本是按字母排序的，这样确保的。其实应该有更好的方式。第二个，自动化脚本中有关键字Fail了，是否还需要接着执行下面的关键字呢。我们框架式会继续执行，但Robot Framework做到了可配置，它是通过listern来实现的。可以好好学习下。

自动化框架、关键字的开发周期怎么安排，怎么预估effort ？ 项目自动化测试框架，自动化脚本开发也分成了两Iteration。 第一个迭代期间，完成自动化框架主要流程，完成主要关键字，构建SMOKE部分的自动化脚本。第二次迭代，进一步完善自动化框架，接着添加关键字，完成Regression部分自动化脚本。刚开始，effort的估计没有把握，因为有些关键字的实现可能比较困难，这时候需要及时sync风险。第二个阶段，effort的估计就有底了。

如何协同开发？自然是加入版本控制。现在的自动化框架用的版本控制是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 设计、框架开发、自动化脚本实现、各种规则制定、多方面协作等，所以需要把自动化测试开发当做项目来做哦！