1.1 自动化框架的目的
对于自动化测试而言一个很明显的目的就是为了减少手工测试的重复工作的比例，提高测试的效率，让测试人员的有更多的时间去发掘深层次的问题；而自动化测试框架的目的，就是提高测试人员编写代码的效率，减少coding和调试的时间,所以以下是关于框架的主要目的：
- 提高编写测试代码的效率
- 提高测试代码的复用性
- 数据驱动,提高自动化测试的可覆盖率
- 将自动化测试融入到测试的过程中以便更好的满足越来越快的交付需求
- 不同环境通过简单的配置就可以运行同一套测试脚本
- 分而治之(separate concerns/divided and conquer)
- 接口测试
- UI端到端(End to End)集成
- ......
1.1.1 将自动化测试融入到测试过程中
在以上的几点目的中,将自动化测试融入的测试过程中有点看不见摸不着的感觉，所以专门来说明一下.
首先从一般的测试流程开始,一般的测试流程总是包括了一下几点:
- 了解需求
- 构建测试用例
- 执行测试(针对修改部分)
- 回归测试(针对可能影响的部分)
同时测试往往又是整个软件发布的最后一道程序,它强烈的依赖于开发的人员的进度.往往在快速迭代中，出现前期时间不紧张，后期时间非常紧张的状况,甚至出现只能通过加班来解决.那么如何解决呢？如何让自己的时间更好的利用和优化呢?
1.1.2 如果(What If)
为了解决上面提到的一些问题,倒是可以想想如果我们做到了什么，我们就可以来解决上面的问题,以下是我想到的一些如果:
- 构建测试用例的同时也可以开始构建自动化测试用例
- 开发人员开发时候,测试也可以构建自动化测试用例
- 当开发完成,自动化测试就可以运行进行常规的检查
- 自动化测试和手工测试可以并行的执行,各自检查不同的点
更加长远一点的问题是,测试是在交付的最底端,能不能找到一些方法或者框架性的东西,可以让上游的交付物件可以马上给自己用,而自己的产出又可以体现上游的需求来达到一个流水线交付的效果? There is no silver bullet.不过或许有呢......
1.1.3 就当这些可以实现的
做到以上一点,也许可以make tester's life easier. 有目标是好事,不过现实也是残酷的,达到这些如果是如此的不容易.不过假设以上的目标是正确的，那么就值得去尝试一步一步去接近.一下子造不出一个跑车,但是造辆自行车还是有可能的.
在了解了以上的一些情况之后,下面就讲一讲自动化框架的实现,以及这些实现是如何来解决我们提到的问题.