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