回归测试和部署策略

Question

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

我之所以问这个问题，是因为如果90%的应用程序没有变化，使用敏捷方法每月部署更改会存在很多浪费（和风险）。我的意思是，框架可能会在一个月内发生变化，也可能会有一些应用程序发生变化。由于框架发生了变化，所有应用程序都必须进行回归测试。比如，如果有10个应用程序在一年内根本没有变化，那么这10个应用程序每个月都要进行回归测试，即使它们没有任何功能更改或热修复。他们之所以要被测试，只是因为业务每月都在推出更新。

而涉及到的风险...如果部署了一个关键任务的应用程序，需要几周时间和多个部门进行测试，那么期望不断进行回归测试这个应用程序是否现实呢？

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

这些应用程序共享同一个数据库，因此需要进行持续测试。我知道TDD和自动化测试，但目前还没有实现。

有什么建议吗？

- Bob Horn

Answer 1

框架的设计理念是它应该是“缓慢移动的代码”。您不应该像支持的应用程序一样频繁更改框架。尝试将框架放在较慢的开发周期上：可能每三到六个月发布一次版本。

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

敏捷并不意味着对所有内容进行无限制的更改。您的架构师可以设定框架的边界，并防止人们轻易地调整它，以获得可能是应用程序快捷方式的东西。这可能需要几次迭代才能稳定下来，但之后应该会更加稳定。

- John Deters

Answer 2

我认为如果没有（单元）测试覆盖，就不能称之为敏捷方法。敏捷的关键原则之一是具有强大的单元测试，为频繁重构和新功能开发提供安全保障。在你的情况下存在很大的风险。每个月部署二十到三十个应用程序，当它们中的大多数不会为用户增加任何新的业务价值，并且没有进行测试时，我认为这不是一个好主意。虽然我坚信敏捷，但您不能仅选择其中方便的部分。

如果业务应用程序没有改变，我不会发布它，只是为了在新框架中编译。想象一下，每个.NET应用程序都需要在框架更改时重新发布。阅读你的问题，我想知道是否通用数据库驱动了这种需求。如果您的框架隔离了模式，并且发现需要在模式更改时重建应用程序，则首先需要解决该问题。查看Scott Ambler的《重构数据库》获取一些提示。

另外，集成测试和单元测试之间存在很大差异。您的回归测试是集成测试。在那个层面上自动化非常困难。我认为测试领域正在发生的突破都是关于编写高度可测试的代码，使单元测试越来越多地涵盖代码基础。

- Rob

Answer 3

这里有一些我能想到的建议： 1. 将框架分解成独立的部分，这样更改一个部分只需要运行少量的测试用例。 2. 使用测试用例优先级技术。也就是说，仅通过某种策略选择的应用程序的测试池中重新运行一小部分测试用例。通常，附加分支和ART的性能比其他方法更好。它们需要知道每个测试用例的分支覆盖信息。 3. 减少对框架的更新频率。如果应用程序不需要更改，则可以使用旧版本的框架。因此，我想这些应用程序可以每三个月更新一次框架。

- zhy2002

Answer 4

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

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

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

我发现将项目分为三个不同的代码流很有帮助；开发、QA和生产。开发阶段对所有更改都是开放的，QA阶段锁定功能，生产阶段则锁定代码（尽管它也有一定程度的锁定）。如果你每月发布到生产环境，你可能希望在发布前至少一个月从开发代码中分支出一个QA构建。然后你花一个月时间接受测试新的更改并回归测试其他所有可以的东西。你可能需要在发布前大约一周完成更改的测试，这样应用程序就可以进行分阶段部署，并且你可以多次进行试运行安装。你不会有时间回归测试所有内容，所以要准备好发布补丁到生产环境的策略。别忘了将这些补丁合并回QA和开发代码流中。

自动化回归测试理论上是一件非常好的事情；但实际上，你最终会花更多的时间来更新测试代码，而不是手动运行测试脚本。此外，你可以用一个真正优秀的测试脚本开发人员的价格雇佣两三个测试人员。悲哀但却是事实。

- sarme