介绍
每个实行持续交付的项目，都有生产流水线的元素，如持续集成和自动化测试。这些测试是在不同层面进行的，从单元测试到冒烟测试再到功能测试。自动化功能测试的优点之一是可重复性和可预测的执行时间。出于这个原因，它应该作为软件质量的每一个构建之后的指标。功能测试自动化往往会成为一个瓶颈，所以你应该熟悉一下如何创建这样的测试的基本原则。
首先设计你的测试
测试集合可以比作盆景树。
最初的时候，我们照顾树根和树干。我们选择会成长的主要分支，我们每天都细心照料这棵树并等待它长出健康的叶子。
我们可以以类似的方式继续测试。
我们建一个将负责应用程序主要功能（例如：开启）的基类。
根据说明，我们先明确将被测试覆盖的应用程序的主要功能，然后每天我们在执行测试的时候都添加更多平行测试。
每一个支持测试（例如创建一个新的用户）的方法都需要与测试分离——让我们在单独的类里面来实现。
你应该在包括了应用程序主要功能的目录里保持类。
去建一个规定很多功能共有方法的抽象类是很好的做法。
如果你正在测试Web应用程序，就用页面对象设计模式。该模式里，一个类及其方法对应了单个页面的功能或一个大型网页里单个页面上的一个元素。
无需事事自动化
自动化花费很多，所以你应该主要测试应用程序的主要功能。
某些测试可以快速轻松地手动完成，且潜在脚本可能难以实现。
值得用到自动化的是那些繁琐的需要被重复很多次的，和那些需要大量数据验证的测试工作。
写短测试
在一个或多个测试失败的情况下，开发团队的任何成员都应该能够轻松地找到错误的原因。
出于这个原因，每个测试方法里应该最多有5个断言，并且每个方法都必须提供的测试操作的完整记录。
明智的做法是使用BDD（行为驱动开发）技术，但是当你没有用一个特定的测试框架时，你应该把接下来的测试步骤放在comments //given //when //then下。
创建独立测试
在测试类中的每个方法应该是一个独立的实体，而不是依赖于其他测试。我们应该能够在任何时间运行单个测试。否则，这样的测试用例集将来维护起来就会很贵——必须定期跟踪和更新测试之间的联系。
很多时候，测试需要一定的前提条件来满足。这些条件不应该用外部方法，应该在试验开始时运行。如果这些条件和测试类的所有方法一样，它们就可以被放在一开始进行的方法里（例如：在JUnit中被标记为@ BeforeClass）。
关注可读性
源代码应该是自我记录的，而写下以下几行代码的每个利益相关者应该明白测试在做什么，为什么它被这么写。尽量避免在源代码注释，因为它也必须被更新。这值得花比平常多一点的时间来命名方法，从而使你的代码更易读。
再看看行为驱动开发技术，每个测试方法都应以单词“应该”开始，而不是“测试”。
根据这一惯例，我们马上就可以明白一个特定的方法测试什么内容了，它在分析测试报告时特别有用。
测试必须要快
正如在本文开头所提到的，自动化功能测试应该是应用程序质量的一个指标。连续传递过程中的每一步都应指明最长持续时间；并且根据这个概念，开发团队应该尽快获得有关软件质量的反馈。自动化功能测试的持续时间应不超过几分钟。
对一个非常全面的测试集来说，有必要并行运行测试（经常在不同的机器上）。虚拟化在这里可能是非常有帮助的。
创建抗变测试
最常提及自动化功能测试的缺点是其对应用程序中变化的低抵抗性，尤其是在GUI中。
在Web应用程序中，测试应该能抵抗网站的内容的变化。测试应该只验证功能，这就使得它可以在不同的位置运行测试。这并不意味着我们不应该编写自动化测试来检查网页的内容。
如果你已经想创建这样的测试，你应该遵循DDT（数据驱动测试）技术。这意味着，检查内容是与源代码分离开的。
Web应用程序的页面布局变化非常频繁，这已经影响到了用户界面。
当你设计一个界面时，每个区段和每个页面你都应该有一个你可以用来测试的唯一标识符，即使一个网站的层次结构发生了变化。
自动化测试无法取代人类
功能自动化测试可以是项目中的主要测试技术，但绝不是唯一的一个。
自动化测试是可重复再生的，他们的覆盖范围总是相同的。
另一方面，虽然探索性测试是低再生的，但是它们能够覆盖自动化测试未触及的区域。
你还应该记住，自动化测试的“绿色”状态并不意味着你的应用程序是没有错误的。
这种情况往往会让测试员分心，而且有可能会影响测试的准确性。
最新内容请见作者的GitHub页：http://qaseven.github.io/