Test Automation

2013-08-05

works

测试自动化是每个敏捷团队必须坚持的实践。

1. Why Test Automation

在敏捷开发中的迭代有两层含义。第一，迭代是交付式的，仅仅开发工作的完成是不够的，迭代结束时需要交付可工作的软件，从而能够部署上线并取得反馈。第二，迭代是增量式的。随着开发过程的进行，系统完成的功能点逐渐增多，每个迭代交付的内容除了本次迭代开发完成的工作，还需要包括以前所有迭代交付的内容。这也就意味着，每次迭代的测试不止要保证本次迭代增加的新内容得到验证，同时以前迭代交付的内容也必须得到验证，也即通过回归测试保证以前交付的历史功能不受到影响。

然，回归测试的工作量随着开发完成功能点的增多，往往是成指数级增长。用传统的人工测试方式已经不能够满足当下快速开发及交付的节奏，所以要想保证项目成功的交付，就必须进行测试自动化。

{:height=”300px” width=”400px”}

2. What’s Test Automation

测试自动化是将传统的简单重复的手工测试由计算机系统来承担并自动完成，其目的是持续的、及时的获得对产品质量的快速反馈。测试自动化包括测试环境的准备、被测对象的自动安装、测试过程的自动执行、测试结果的自动处理以及测试报告的自动生成等。

测试自动化可以适用于一切能够自动化的测试场景，包括那些机械的、重复的以及不依赖主观判断的测试，比如

单元测试
基于数据的服务间集成测试
回归测试
基于大数据的压力测试、
基于时间持续执行的性能测试

测试自动化大大提升了测试的效率，有助于减少手工测试过程中人为出现的错误，同时测试人员可以有时间参与到其它更有价值的测试活动，比如探索性测试。

3. A Good Automated Test

一个好的自动化测试必须要满足以下几个要素：

3.1 Valueable

敏捷以价值为导向，我们的测试自动化也是一样，需要衡量投入产出比。

做任何事请都是有成本的，包括构建自动化测试环境、脚本和编写测试，同时这些一旦产生，马上会进入维护期，产生维护成本。所以很多时候我们都可以问一下，“这么做值不值？”。比如，如果用很大的成本(80)去自动化一个测试，而只得到很少的受益(2)，那么我们就需要权衡是否一定自动化。另外，需求变动频繁的模块，自动化测试需随着需求的变动而变动，投入大而产出低，更应谨慎的选择。

3.2 Fast

测试自动化的目的是能够获得对产品质量的快速反馈。如果自动化测试的执行花费了很长时间，那么它不再为我们带来价值，而是我们持续交付的障碍，这种测试可能被停掉，可能被扔到一个没人注意的角落，其实也就相当于被停掉。如果这些测试是必须的，那么一定要让它跑的快。

3.3 Idempotent

一个好的测试应该是等幂的，能够重复的被执行，稳定的得到同一个验证结果。当测试失败的时候能够快速的重现，从而发现问题所在。一个好的测试应该与环境无关的，与基础数据无关的。一个显示依赖于基础数据的测试明显增加了测试维护成本，当测试失败时，首先需要检测基础数据是否正确。

3.4 Stable

测试结果应该是稳定。在同一运行环境中应得到同样的结果，一个不稳定的测试对项目是具有伤害性的，它不能保证它的反馈的正确性，同时经常阻碍持续集成，久而久之这种测试有就等于没有，它对产品质量的保护已经起不到预期的作用。

3.5 Simple/Appropriate Test

简单，选择合适的测试粒度与组合，以及组成合适的测试。

1.  合适的测试粒度与组合

一般，软件开发团队中测试活动包括单元测试，集成测试，Smoke测试，回归测试等。理想状态下，每一项测试的覆盖率达到100%，然，并不是所有的用例都能够被很容易的自动化，并且能够快速稳定的运行。就如马丁在测试金字塔一文中提到的项目中底层单元测试应多于依赖GUI的高层端到端测试。底层单元测试运行速度快，稳定，能够更快的定位问题；而端到端的测试往往相对脆弱、编写成本高，而且运行耗时。

2. 并不是所有的东西都能够自动化。

手工测试不能被完全取代。统计结果表明，自动测试只能发现15-30%的缺陷，而手工测试可以发现70-85%的缺陷。所以自动化测试不适合软件的新功能测试，而适合那些简单重复性的测试，比如回归测试，可以保证对已经测试过部分进行测试的准确性和客观性。

4. Summary

测试自动化带来的好处是显而易见的，然而在构建自动化测试的时候应根据项目的实际情况进行决策，不能一味的追求测试覆盖率，而导致构建和维护成本的明显上升，运行一个小时的集成测试显然是项目测试策略的一个很大的坏味道。