对遗留项目开始自动化测试

为遗留应用程序编写自动化的回归测试总会是一项非常艰巨的任务。 我们所要面临的问题包括从哪里开始、对多少程序实行自动化测试、并且决定自动化的最佳策略等等。

Mark Levison 在敏捷软件测试新闻组中发布了一个帖子，Hubert Matthews 对此做出了回复，他所建议的方法是一种基于风险的方法。

你无法对一切都进行测试，所以你需要选择在哪里花费你的时间和金钱。对我来说，测试主要是关于信息和风险的，而不是要完全覆盖或者对所有功能完全测试的。

Hubert 提到了几点，它们有助于评估所要关注的领域。 他所提出的内容包括：

• 当前客户感觉质量最差的地方在哪？
• 功能的关键区域是什么（例如，是什么让他们创收）？
• 客户想要更多的特性，而不需要更高的质量吗？
• 对于他们的系统来说，最大的风险是什么？
• 如果客户想要对一项功能做出提升，那么会是什么呢？
• 探索式的手工测试会找到更重要的缺陷吗？

Rakesh Patel 在回应时提出 一种类似的方法，

1. 只需要对应用程序图形化界面的最重要操作进行自动化。很多应用程序都拥有 常用的操作，它们占所有情况的 80%。如果这些操作崩溃了， 那么你的业务就遇到麻烦了！！
2. 如果你可以绕过图形化界面， 而直接到达后端并测试业务功能，那么就一定要那么做。那意味着与图形化界面特定的整合测试只是要确保前端的数据能够到达后端。

Mark Fink 指出，在开始对遗留项目进行自动化测试之前，他喜欢先对项目有总体的印象，以识别出需要注意的特定区域。 他建议使用一系列工具，这些工具对于获得总体印象非常有用。与此类似，Nat 指出关键在于要为你所想要关注的区域创建端对端的测试。他建议，对于遗留系统，如果存在手动测试，那么经常是非常好的脚本，可以快速成为自动化测试的成果。

Ralph Bohnet 和 Gerard Meszaros 谈到了测试驱动移植，其中的一个结论是，对于任何遗留应用程序，如果想要移植成功的话，那么最重要的业务场景一定要有自动化的回归测试。

Lisa Crispin 同意在特定的情况下，你或许能够一下子对整个遗留应用程序进行自动化测试。对 Lisa 来说，起作用的是多种因素的组合。 其中的一些因素包括：

• 请客户对应用程序的关键部分按优先级排序
• 为每个部分编写手动的回归测试脚本
• 在每个 sprint 中估计时间，从而为那些部分编写 GUI 的冒烟测试
• 使用 CI 框架，至少每天执行一次测试套件
• 所有新的开发都应该有充分的测试

据 Lisa 所说，使用这种方法，他们能够在八个月的时间内对遗留应用程序编写充分的自动化测试。

因此，为整个遗留应用程序编写自动化的回归测试，是一项长远而且耗费时间的工作。我建议的方法是，为对业务重要的功能构建足够覆盖率的测试，然后逐渐围绕系统创建测试用具。

InfoQ 上的相关新闻： 针对缺少测试的应用程序的测试技术

查看英文原文： Starting Test Automation for a Legacy Project