【发布时间】：2009-12-22 10:27:00
【问题描述】：
在我的项目中，我们正在建立持续集成环境，并且作为此过程的一部分，建议在 QA 测试周期内同时修复缺陷。
在将其发布到 QA 环境时，通常采用的流程是什么？这些修复程序是立即部署到 QA 环境中（在集成测试之后）还是累积到当前测试周期完成为止。
【问题讨论】：
【发布时间】：2009-12-22 10:27:00
【问题描述】：
给自己一个不断变化的目标真的很困难。我们倾向于在部署到 QA 之前批量修复——通常是关于每日 QA 部署。 QA 在早上的第一件事就是从隔夜构建中获取输出，如果一个真正严重的错误阻碍了大量测试，则“根据需要”。
CI 更像是一个基本的代码质量基准（例如，它构建、它通过单元/冒烟测试）- 不要觉得 QA 需要从 CI 中获取每个构建。
【讨论】：
在测试周期开始时，我倾向于只在存在已解决的阻塞错误时才采用新版本。这使我的团队可以避免新构建和意外回归造成的颠簸。发布的早期部分通常用于了解功能的实际实现方式以及产品是否满足最低验收标准。
在测试周期的中间，我更频繁地接受构建，以确保修复有尽可能多的曝光率，并尽快发现修复不当的错误。这通常每天进行，除非在我们运行长期压力或性能测试的环境中。
随着发布的临近，我对修复的 bug 施加了更多的控制（即：当前版本是分支的，并且我们有更严格的代码行策略），我将继续进行构建，仅当我们发现发布阻止 bug 时。目前，构建通常被称为 beta 或候选发布版本。
【讨论】：
在我理解正确的情况下，您是在问具有持续集成周期的项目中 QA 周期的持续时间是多少？
我们使用每日 QA 周期。如果夜间构建成功，则可以在第二天进行测试。
【讨论】：
在 CI 构建期间发现的错误需要由开发团队在发现后立即修复。而 QA 团队在其常规发布周期或补丁周期中接收常规构建，而不是通过 CI 构建问题。
由于 CI 构建自动测试发现了许多与 QA 和非 QA 相关的错误，因此它直接导致其他 QA 活动的性能负载过重。
一切都取决于公司的 QA 政策，有些人可能会或有些人可能不同意我的观点 :)
【讨论】：
nitzmahone 的回答是很好的建议，可以平衡您从 CI 系统获得的更频繁的构建与 QA 需要有一个已知的测试目标。
您可以利用持续集成在作为每个构建的一部分运行的单元/冒烟测试之上进行额外测试。以下是我做过的几件事：
【讨论】：
-
谢谢。我们的测试台不是完全自动化的，我们确实面临着每天回归每个构建的挑战
这些修复程序是立即部署到 QA 环境中（在集成测试之后）还是累积到当前测试周期完成。
这取决于。如果问题是阻塞并且不允许测试人员运行更多测试以完成整个测试计划（即完成他们的工作），那么显然需要立即发布修复程序。如果问题不是阻塞问题，那么最好将修复排队并使其在下一个版本中可用。但这需要大量的管理工作（记录问题、注释测试用例等）。
现在，如果 QA 在开发过程的早期进行（即，如果您没有使用非常有序的开发周期），如果测试人员与开发人员密切合作，那么最好在发现问题后立即修复它并甚至避免创建错误清单（大浪费）。
【讨论】：
-
谢谢。我们还试图在严格执行新版本和在已经测试的功能中发现新错误时获得惊喜之间取得平衡。我们还没有完全自动化 QA，因此新版本可能会撤销之前版本中成功通过的任何测试用例。
这取决于项目开发风格。假设你是敏捷团队。
- 有两个级别的测试，迭代期间的测试和迭代结束的测试
- CI 的目的是在迭代过程中发现并修复错误。测试类型侧重于单元、功能和故事的实现
- 您在此类敏捷团队中发现的错误应在发布到 QA 环境之前修复
- 应使用 QA 环境来执行回归和集成测试。此类测试的目的应该是发现回归和集成，而不是功能的功能
以上是一般方法。当然，它在很大程度上取决于您的软件和团队的性质
【讨论】：
这可以通过将 QA 团队划分为子团队（即内部团队和外部团队）来实现。内部 QA 的工作作为开发经理下的开发团队的一部分，外部 QA 执行正在开发的产品的测试。
内部 QA 团队负责产品的健全性测试。他们通过执行健全性流程来评估构建的基本运行状况检查。如果任何健全性流程失败或主要/新创建的模块崩溃，IQA 会将电子邮件发送给发布经理/开发经理以开发新的构建。一旦健全性流程通过，构建就可以准备好外部 QA 团队进行适当的处理测试。
每天计划构建，外部 QA 报告故障。内部 QA 负责与开发人员进行快速沟通和讨论。通过这种方式，可以通过将 QA-Dev 添加到开发团队中来提升整个流程并减少 QA-Dev 差距。
希望这能回答您的问题！干杯:)
【讨论】：