持续集成和QA

Question

在我的项目中，我们正在建立持续集成环境，并作为此过程的一部分，建议在QA测试周期内同步修复缺陷。

当涉及到将其发布到QA环境中时，通常的实践过程是什么？这些修复是立即部署到QA环境中(在集成测试之后)，还是累积到当前测试周期完成。

Answer 1

给自己一个不断移动的目标真的很难。我们倾向于在部署到QA之前批量修复-通常是关于每天的QA部署。QA在早上的第一件事就是获取通宵构建的输出，如果一个真正严重的bug阻碍了很多测试，那么QA就会“根据需要”获取输出。

CI是一个更基本的代码质量基准(例如，它构建，它通过单元/烟雾测试)-不要觉得QA需要从CI中获得每一个构建。

Answer 2

在测试周期的开始，我倾向于只在有阻塞bug被解决的情况下才进行新的构建。这使我的团队避免了新构建和意外回归造成的混乱。发布的早期部分通常用于了解功能是如何实际实现的，以及产品是否满足最小的验收标准集。

在测试周期的中间，我更多地接受构建，以确保修复尽可能多地公开，并尽快识别错误修复的bug。这通常是每天的，除非在我们运行长期压力或性能测试的环境中。

随着发布的临近，我对修复了哪些bug施加了更多的控制(例如:当前的发布是分支的，我们有更严格的代码行策略)，我将继续只在发现发布阻塞bug时进行构建。此时，构建通常被称为测试版或发布候选版本。

Answer 3

在我理解正确的情况下，您问的是具有持续集成周期的项目中QA周期的持续时间是多少？

我们使用每日QA周期。如果夜间构建成功，就可以在第二天进行测试。