如何处理几乎在软件验证结束时引入的错误修复？

Question

一点背景： - 我正在测试嵌入式系统的固件。它涉及调用某些固件功能并检查硬件外围设备提供的输入/输出。

1. 我开始测试版本A并执行了85％的测试用例。

   • 然后，我发现开发人员发布了版本B，版本C和版本D.每个版本都有很小的变化。
   • 我认为B和C的变化对我没有影响。
   • 仅在D版中重新测试了一个测试用例。

2. 我在版本A中发现了几个错误，开发人员现在修复了它们并发布了版本E.

3. 因此，我在A版本中测试了大约90％的测试用例，在D版本上测试了4％，在版本E上测试了6％。

4. 我的问题是，我可以发布什么固件版本？版本A，因为这是我测试的最大块？或者我可以说最后一个发布的版本E？

5. 我半自动化了测试用例的固件交互，但是，我必须手动测量电信号。最重要的是，运行这些测试用例需要时间。

6. 运行测试的适当嵌入式系统的可用性是另一个问题。没有多少人分享它们。

7. 我是否应该咬紧牙关并以某种方式再次运行版本E的所有测试用例？

非常感谢，

Answer 1

我相信你担心的是由于回归而导致的变化。因此，良好的做法是至少在发布3-4周之前关闭开发，并彻底彻底地测试您的最新版本。在这个阶段，你应该非常挑剔采取新的修复。如果您对新引入的更改可能影响的区域100％有信心并且您有一些自动化方法来测试这些区域，则只选择新的更改。

因此，如果您在发布之前有时间，请确保端到端测试最新版本（E）。如果没有，并且您不确定必须影响的新变更区域，那么您应该使用您测试最多的版本（A）

Answer 2

有这么多版本和测试无法覆盖它们

  

我在A版中测试了大约90％的测试用例，在D版上测试了4％，在版本E上测试了6％

建议您的Delivery管道可以使用更多的工作量。在每个版本上运行回归和E2E套件非常重要。因为此时这是不可能的

  

我可以发布什么固件版本？版本A，因为这是我测试的最大块？或者我可以说最后一个发布的版本E？

您是否有信心发布尚未经过测试的内容？如果不是 - 为您的客户/用户提供最稳定的客户/用户 - version A。拥有新版本（B，C，D）和修复（version E）并不意味着您必须立即将它们部署在Prod服务器上。我知道上市时间是一个因素，但质量也是如此。一旦您通过了测试版本A，您就可以Retest版本E和  发布完全覆盖的固件版本A。

我的建议是开始使用Risk-based testing，并尝试避免在版本准备好QA之后创建新的测试。没有必要等到最后一分钟。开发自动化测试也有SDLC

当版本可用于测试时，您只能留下实施 - 下一阶段。如果手头有很好的要求，甚至只是最后的调整。另一个有用的做法是在部署新版本后执行Smoke suite。一些智能回归可以用作运行良好的代码分析，并链接应该针对代码更改运行的测试。使用run tests in parallel可以大大改善您的Delivery管道，并使您能够跟上常用版本。