有关执行时间

　　执行测试集合里的所有用例需要花多少时间是个关键问题。如果自动化测试需要执行很长时间，那么它不再为我们增加价值，因为预期的反馈已经不再迅速（尤其对于敏捷项目中小的迭代）。另外，这些正在执行的测试集合会被停掉，因为等待它执行完是件痛苦的事。采用并行，类似infrastructure的产品，或者书中的其他方法--只要能使测试跑的快，你就可以维持一个快速的反馈循环。

　　另外，可为每个测试用例标上标签并选择性的执行所从事的功能模块。能够选择性执行可以节省很多执行时间，尤其对于测试集合相当的大并且执行完整个集合在特定情况下没有实际意义的场景。

　　保持测试用例状态为绿色

　　将测试集合里的所有用例标成绿色（例如，执行成功的）。有时候，你可能知道某些用例会因为一些已知的原因失败，也许是部分系统不可用或者在修复中的问题推迟一段时间上线。在这种情况下，你可以把这部分用例标成已知失败的用例，让测试框架忽略或者跳过它们。这样做可区分构建中未知的和已知的失败，新增的失败用例可立即被发现。

　　一旦用例状态变成红色，自觉地优先将它变成绿色（例如，通过修复测试用例或者修复代码）。越早定位到失败测试，越容易更正他们--特别是刚刚签入代码改动导致用例失败的情况。同样要重视那些看似永远不会失败的用例集合，因为有自动化测试在会给人一种很安全的错觉。某种情况下，如果加入的测试用例很脆弱经常失败，又让人觉得不安全。这两种情况，团队都应该做一些调查研究。

　　通过测试这些测试代码来查找出问题是值得推荐的，它可以建立自动化测试可靠的自信。同样，使用data fuzzing是个不错的选择，这样，你不用在每次测试执行中用同一套数据。有助于产生更健壮和有意义的测试。

　　清晰的报告

　　花一些时间在测试框架中实现报告功能。用简洁且精确的方式来报告失败和错误，这样研究人员可快速地定位到哪里出错。报告要绝对简单，如果有时间精力的话图表化更好。

　　对所有人可见

　　最后也最重要的是，让过程简单，且所有的相关人员可操作和看到执行结果。在网上记录测试执行历史和趋势，如果可能的话，把它挂到代码质量分析工具如Sonar上。让大家从各自的角度去看结果。尽量让添加和更新测试简单，大家一起参与进来把测试做的更好。

　　总的说来，我们认为有效的，应该格外重视的测试自动化方法包括：

　　● 在项目的开始从小做起，迭代地在每个完成的冲刺中构建测试集合。

　　● 建立测试自动化订单，作为优先级任务清单。这有助于集中精力在当前任务，同时不忽视长期目标。好好研究可选测试工具的用途，不要舍不得花费一到两个冲刺的时间去熟悉它们。

　　● 保持测试脚本和数据较少的依赖，有助于日后有需要更换测试工具时轻松应对。

　　● 产出有意义的测试，在向自动化测试集合添加用例的时候，适当地考虑可维护性和执行时间。

　　● 尽快地想尽办法让整个团队使用已迁入到build/CI system的安全保障。

　　● 产出有意义的测试并且确保它们不会给人安全的假象。

　　● 努力地快速解决失败用例，让测试执行时间尽可能的短。

　　● 最后也最重要的是，适当地添加直观的报告机制，让团队所有人能看到测试结果和历史趋势。这有助于每个人都参与进来监督开发的进展和健康度，并做出有根据的决定。

　　总结

　　在这篇文章中，我分享了在最近项目中实施测试自动化所学到的经验教训。其中所列的测试自动化方法绝对是完整的。它们是我在一个很棒的团队实施测试自动化时收集到的宝贵经验集合。

　　要铭记的是，软件测试自动化让电脑一遍遍地快速执行回归测试集合，验证功能点，发挥其最大的价值。团队中的成员被释放出来做更擅长的事，运用其认知技能在流行前沿探索式测试系统。

　　如果你赞同文章中所提倡的测试方法并投入自动化测试，你也可以每天在类似线上的测试环境下，构建，集成，测试和发布同线上一样高质量的产品应用。