全国咨询热线：136-9172-9932
分析了回归测试的原因及其类型后，我们可以开始制定一个有效的回归测试策略。在设计回归测试策略时，团队依赖于两个因素：
1.产品的本质。这是一个关键因素，让我们能选择合适的回归测试策略，以及周到的回归测试计划。例如，测试一个登录页面和测试综合专业门户的方法有很大的不同。登陆页面的回归测试主要针对用户界面和可用性方面的测试用例，而对于门户网站来说，会考虑到更多安全性、性能、兼容性等方面的测试用例。
2.产品的规模。大、中、小型的产品要采用不同的回归测试方法。对于小型产品而言，单轮的手工回归测试可能就足够了;而对于具有丰富功能的大中型产品，通常手工和自动两种回归测试都要采用。
如果考虑到这些因素，测试团队就可以选择到合适的回归测试方式和方法。
回归测试方法
回归测试遵循两种实现方法：手工和自动。
手工回归
无论采用何种方法论(瀑布、敏捷和其他)，手工回归测试是对产品进行回归测试的基本方法。回归测试套件包含了应用程序最近发生变更及其相关部分的测试案例。这种类型的测试总是先于自动化测试，在某些情况下比后者更有效。例如，想要测试与应用程序发生变更部分相关的功能，通过编写自动化测试脚本是不可能做到的。
手工回归测试，在产品交付过程的早期阶段是有效的。我们开发的一个产品，比如iOS图像处理应用程序，手动回归测试可以帮助检测出影响应用程序用户体验的多个错误。手工回归测试发现该应用无法正确地生成图像，当用户改变屏幕方向时会发生崩溃。
尽管如此，测试团队仍然试图采用自动化的回归测试，因为手工回归测试的主要问题是费时、费力。对于复杂的产品，手工运行回归测试套件，不可避免地影响了测试工程师的注意力和效率。因此，在这种情况下，团队更喜欢借助自动化。
自动回归
一个大中型项目(时长六个月或更久)，当项目处于稳定阶段(预期的业务逻辑和用户界面已不会发生重大变化)，自动化回归测试是典型的方法。有了全面的回归测试规划，自动化降低了测试团队花费在繁琐、重复任务上的精力，省下时间去参与那些需要人工介入的测试，比如探索性和用户体验测试。
然而，现今的团队往往在早期阶段就开始自动化回归测试。它适用于敏捷开发，团队至少每周部署一个产品，没有时间准备手动回归测试。通过与整个团队(利益相关者、管理者、业务分析师等)沟通并研究用例文档，测试人员可以了解利益相关者的需求、产品业务逻辑以及测试的预期结果。在项目早期，自动化的主要任务是选择测试框架，它应该提供简单的脚本和低成本的测试维护。创建的基础架构可以重用于未来的产品，并能加速测试自动化。
在某些情况下，自动化可以帮助检测手动回归测试未发现的错误。最能说明问题的例子，是那些随机出现的错误。当我们测试上面描述的图像处理应用程序时，自动化超时有助于检测出一些随机错误。如果一个脚本发生超时，它会自动被标记为失败。结果是，同一个脚本一次又一次地运行，直到通过，这样就可以发现出现在某个确定位置的随机错误。
