testing - 回归测试和部署策略

Question

我想要一些关于部署策略的建议。如果开发团队创建了一个广泛的框架，并且许多 (20-30) 应用程序使用它，并且企业希望应用程序至少每 30 天更新一次，那么最佳部署策略是什么？

我问的原因是，如果 90% 的应用程序没有更改，那么使用每月部署更改的敏捷方法似乎有很多浪费（和风险）。我的意思是框架可以在一个月内改变，一些应用程序也可以。由于框架发生了变化，所有应用程序都应该进行回归测试。例如，如果有 10 个应用程序在一年中根本没有变化，那么这 10 个应用程序每个月都会进行回归测试，当时它们没有任何功能更改或热修复。必须对它们进行测试，仅仅是因为企业每个月都在滚动更新。

以及所涉及的风险……如果部署了一个关键任务应用程序，这需要几周时间，并且需要多个部门进行测试，那么期望必须不断地对该应用程序进行回归测试是否现实？

一种选择是使任何框架更新向后兼容。虽然这意味着应用程序不需要更改其代码，但它们仍然需要进行测试，因为底层框架发生了变化。而且涉及的风险很大；一个不断变化的框架（并部署这个框架）意味着任务关键型应用程序永远不能长时间享受相同的代码库。

这些应用程序共享相同的数据库，因此需要不断测试。我知道 TDD 和自动化测试，但目前还不存在。

有什么建议吗？

Answer 1

框架背后的想法是它应该是“缓慢移动的代码”。您不应该像它支持的应用程序那样频繁地更改框架。尝试以较慢的开发周期获取框架：也许不超过每三或六个月发布一次。

我的猜测是，您仍在制定此框架中的一些架构决策。如果您认为框架更改确实需要如此动态，请找出框架的哪些部分经常更改，并尝试将这些部分重构为需要它们的应用程序。

敏捷并不一定意味着对一切进行无限的改变。您的架构师可以对框架的构成设置界限，并阻止人们轻易地对其进行调整以获得可能的应用程序快捷方式。可能需要几次迭代才能让它稳定下来，但在那之后它应该会更稳定。

Answer 2

除非您有（单元）测试覆盖率，否则我不会将其称为敏捷方法。敏捷的关键原则之一是您拥有强大的单元测试，为频繁的重构和新功能开发提供安全网。你的场景有很多风险。每月部署 20 到 30 个应用程序，其中 1) 大多数应用程序不会为其用户增加任何新的业务价值；2) 在我的书中，没有适当的测试不符合一个好主意。我是敏捷的坚定信徒。但是你不能只挑它方便的部分。

如果业务应用程序没有改变，我不会发布它只是为了在新框架中编译。想象一下，每次框架更改时，每个 .NET 应用程序都需要重新发布。阅读您的问题，我想知道公共数据库是否正在推动对此的需求。如果您的框架正在隔离架构，并且您发现每当架构更改时都需要重新构建应用程序，那么您需要首先解决该问题。查看Scott Ambler 的Refactoring Databases以获得一些技巧。

另外，集成测试和单元测试之间存在很大差异。您的回归测试是集成测试。在那个级别上实现自动化是非常困难的。我认为测试中发生的突破都是关于编写高度可测试的代码，使单元测试越来越多的代码库成为可能。

Answer 3

以下是我能想到的一些技巧： 1. 将框架分解成独立的部分，这样改变一个部分只需要运行一小部分测试用例。2. 采用测试用例优先级技术。也就是说，您只重新运行由某些策略选择的应用程序的一小部分测试池。附加分支和 ART 通常比其他分支具有更好的性能。他们需要知道每个测试用例的分支覆盖信息。3. 减少更新框架的频率。如果应用程序不需要更改，则意味着可以不更改它。所以我想这些应用程序使用旧版本的框架是可以的。您可以每 3 个月更新一次这些应用程序的框架。

Answer 4

回归测试是一种生活方式。您需要在发布之前对每个应用程序进行回归测试。但是，由于时间和金钱通常不是无限的，因此您应该将测试重点放在变化最大的领域。识别这些区域的一种快速而肮脏的方法是计算给定业务区域中更改的代码行数；说“会计”或“用户管理”。这些应该首先与您确定为“关键任务”的任何区域一起进行最多测试。

现在我知道更改的代码行不一定是衡量更改的最佳方法。如果您有明确定义的变更请求，实际上最好通过查看变更请求的数量和复杂性来评估这些热点。但并不是每个人都有这种奢侈。

当您谈论对框架进行更改时，您可能不需要测试所有使用它的代码。如果您正在谈论对 DAL 之类的更改，那么无论如何，这基本上等于所有内容。您只需要测试足够大的代码示例，就可以合理地确信更改是可靠的。同样，从“关键任务”区域和受影响最严重的区域开始。

我发现将项目分成 3 个不同的代码流很有帮助；开发、质量保证和生产。开发对所有更改都是开放的，QA 是功能锁定的，而生产是代码锁定的（好吧，无论如何都要锁定）。如果您按月发布到生产环境，您可能希望在发布前至少 1 个月从开发代码中分支一个 QA 构建。然后你花那个月验收测试新的变化和回归测试你可以做的一切。您可能需要在发布前一周左右完成对更改的测试，以便应用程序可以暂存，并且您可以空运行安装几次。您不会对所有内容都进行回归测试，因此请准备好将补丁发布到生产环境的策略。大学教师'

自动化回归测试将是一件非常棒的事情。理论上。在实践中，您最终会花费更多时间来更新测试代码，而不是手动运行测试脚本。此外，您可以以一个非常优秀的测试脚本开发人员的价格雇佣两到三只测试猴子。悲伤但真实。