测试框架升级

Question

由于许多漏洞的披露，我们不得不升级我们的核心框架，我们系统的很大一部分都依赖于这个框架。(在我们的例子中，它是4.3.16版本的Spring框架版本，但这只是一个例子，可能不太重要。)

我们修复了新版本中的一些向后兼容性问题。

(比如:在我们的项目中实现的接口中的新方法)

如何测试这是否没有引起任何问题？

我想知道我是否可以遵循任何方法，以确保它不会导致在运行时稍后检测到任何其他问题。

此外，这可能是任何库升级的共同关切。是否有任何应采取的做法或程序来消除这种关切？

Answer 1

你来测试。然后你再试一试。然后你再试一试。

这显然有点笼统，但这是答案。更详细的是：

• 确保单元测试通过(失败的单元测试应始终阻止构建)
• 确保您的集成测试通过。
• 确保您的自动化端到端测试通过。
• 你在系统上做了一些实验测试。出什么事了吗？
• 运行正式的回归测试计划。

在您的各种环境(开发、内部QA、UAT，无论您的流程涉及什么)中重复执行，直到您对更改有足够的信心为止。

最后，部署到生产中。

Answer 2

太多次我看到这个升级框架的过程：

1. 停止所有新特性的开发
2. 升级框架
3. 人工测试
4. 继续测试和修理
5. 继续测试和修理
6. 部署到生产前的环境中.继续测试和修复
7. 对每个环境重复
8. 部署到生产
9. 向你所信仰的任何神祷告
10. 继续测试和修理

第二步实际上应该是第三步，第一步应该是完全不必要的。如果你需要做第一步，那就是你做错了。

第一步应该从单元和自动测试覆盖开始。

我是敏捷团队的一员，这个团队不仅能够进行不兼容的框架升级，而且还可以对语言本身进行不兼容的升级。这是一个大型Rails应用程序升级到Ruby1.9。因此，基本上，我们所拥有的每个框架、库和依赖都被升级或替换了。

再过4周。在4种环境中，包括生产。我们还提供了4个主要的新功能。

这并不是说"Ruby更好！“相反，它证明了应用程序的单元数量和自动化测试覆盖范围。我们进行了1,200+单元测试，以及大约600个黄瓜测试。这也是一个紧密结合的团队与伟大的沟通证明。

因此，我修改的升级框架或软件基础结构主要部分的步骤列表如下：

1. 编写大量单元测试。必要时重构代码，以便为应用程序的核心逻辑编写单元测试。
2. 创建自动功能测试。不是所有的东西都可以用单元测试来测试，但是通过UI进行的完整的功能测试是次之的。写很多这些。
3. 重复步骤1和2。
4. 升级框架。
5. 让单元测试通过。
6. 让功能测试通过。
7. 跟踪你需要做的重大改变。向你的团队发送电子邮件，说明这些更改以及他们如何修复正在进行的工作。
8. 团队代码评审。让他们问问题。请详细回答。
9. 签入代码，并确保您的持续集成构建正在传递。
10. 协助队友进行合并和错误修复工作。
11. 部署到生产前环境进行手动测试。有一个手动测试计划已经到位。
12. 部署到下一个生产前环境，然后再进行一些测试。
13. 部署到生产部门。

这两种方法的关键区别在于，当你解决这些问题时。使用方法1，您在手动测试期间会遇到大多数问题。使用方法2，您在开发过程中会遇到它们，在那里它们更容易跟踪和修复。