在敏捷项目中实施自动化测试之我见

作者 Rajneesh Namta 译者 李琼 发布于 2012年4月18日

 

实施Scrum开发过程充满着挑战—尤其对于从零开始做产品的团队来说。在每个增量冲刺中，你不仅要新增功能，还要确保已实现的功能依然可用。这时，拥有一个可覆盖系统测试和集成测试的自动化框架,可为团队增添不少火力。它不仅能为回归测试增添一层保障，还能释放出珍贵的开发和测试人员时间,让他们花更多的精力在擅长的领域。

在这篇文章中，我想分享我们团队在最近项目中成功应用的一些自动化测试方法--事实证明，这些成果是一项巨大的资产。付出的努力将会在未来得到很多的回报。现在，我们每天能在类似线上的测试环境下，构建，集成，测试和发布同线上一样高质量的产品应用。通过相互分享好的和坏的经验，我们学到新的知识并且加以实践，把事情做得更好。

我们团队很高兴看到应用自动化测试方法所收获的这些成果。采用这些方法能让我们持续地在每个冲刺中轻松添加新的功能，同时，把我们从多轮回归测试中解救出来去寻找和修复重要的问题。

下面是我们学到的一些实战经验，如果你正开始着手在项目中增加自动化测试，这些经验应该可以让你少走弯路。

从小做起

生成自动化测试的过程类似于生产被测软件。这涉及到大量的设计，编码和测试它本身是否正常工作。因此，同应用一样，自动化测试最好是增量开发的—在几轮冲刺中陆续地向自动化框架添加新的测试和功能。需要明确的是，我们的目的不是在一开始就产生完美得能做任何事情的测试框架，它不可能达到。 从事测试同生产软件一样，是有价值的。它们能让人建立自信和看到令人激动的进展。即使再小的成功也能让大家快速地进入状态—特别是当测试自动化方案已经运行并且证明是对团队有价值的时候。

测试自动化订单

为你的项目维护一份测试自动化订单，在订单中列出所有的自动化任务和已识别的改进需求。如果每个冲刺你从订单中认领几项并实现，不久就会看到一个新的自动化回归测试集合成型。有时候，测试自动化订单的用户故事可能需要开发人员专职来实施，为推进自动化测试，需要向产品负责人提出人员需求。但如果团队成员都推崇质量，让产品负责人看到这些用户故事的价值不是难事。

一个测试自动化订单可以包含如下有先后优先级的项：

• 参数化测试执行环境
• 持续地集成
• 提升报告机制
• 在通知邮件中提供附上错误日志的选项
• 为流程场景收集性能报告
• 为重要测试用例的并发执行增加验证性测试

工具只是手段不是最终目的

测试自动化所用的工具和框架不是投入测试时间的真实目的。如果你眼光长远的话，真正的目的是通过快速的反馈来支持新一轮的开发。它可以让各方知晓项目的最新状态，由此，利益相关者可以做出有根据的决定。既然工具和框架只是实现更多的一种途径，就不要沉迷在新工具上而忽视了最终的目的。

测试数据和脚本独立于所选的自动化测试工具也尤为重要。写死在脚本里的测试数据，系统配置和对象很难维护。从长期看来，如果项目碰到意外问题，频繁地与测试数据交互会让中途更换测试工具成为一件困难的事。

设计有意义的测试而不是什么都自动化

测试方案最重要的部分是测试。很多团队花大量的时间和精力在开发功能齐全的框架上而忽视了有意义的测试。不要让框架代码比测试代码更重要。开发一流的框架理念是诱人的但是要避免这个陷阱。投入测试自动化的真正价值在于它产生的测试，因此要集中精力在有意义的测试本身。

另外，不要因为自动化而自动化。在添加新的测试之前适当的考虑可维护性和执行时间。每个加入到自动化测试集合的测试，都成为了产品基线的一部分，也需要同其他基线一样维护—在整个应用的生命周期中。添加复杂和难维护的测试，最终结果是减慢组内反馈循环，这个应当避免。

让自动化测试远离你本地机器

如果你正在为项目编写自动化测试，而且只在你本地机器上运行。那么这个测试基本没有价值。团队中的每个成员应该享受到自动化产生的安全保障。要达到这个目的，你必须让自动化测试远离你本地机器。

团队所有成员应该能够访问自动化测试集合并且点击按钮就能执行。如果某个成员想要在提交大量改动之前或之后执行测试集合，他应该能够执行并且不麻烦地得到结果。理想状态下，自动化测试集合最好架设在外部服务上，作为构建过程或者持续集成环境的一部分来运行。有频率地订制测试集合执行（如在每次迁入或者至少每日）并标上执行状态。适时地制定通知机制来通知有关人员最新的执行状态。

有关执行时间

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

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

保持测试用例状态为绿色

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

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

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

清晰的报告

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

对所有人可见

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

总结

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

• 在项目的开始从小做起，迭代地在每个完成的冲刺中构建测试集合。
• 建立测试自动化订单，作为优先级任务清单。这有助于集中精力在当前任务，同时不忽视长期目标。好好研究可选测试工具的用途，不要舍不得花费一到两个冲刺的时间去熟悉它们。
• 保持测试脚本和数据较少的依赖，有助于日后有需要更换测试工具时轻松应对。
• 产出有意义的测试，在向自动化测试集合添加用例的时候，适当地考虑可维护性和执行时间。
• 尽快地想尽办法让整个团队使用已迁入到build/CI system的安全保障。
• 产出有意义的测试并且确保它们不会给人安全的假象。
• 努力地快速解决失败用例，让测试执行时间尽可能的短。
• 最后也最重要的是，适当地添加直观的报告机制，让团队所有人能看到测试结果和历史趋势。这有助于每个人都参与进来监督开发的进展和健康度，并做出有根据的决定。