持续集成和QA
在我的项目中，我们正在建立持续集成环境，并且作为此过程的一部分，建议在QA测试周期中同时修复缺陷。持续集成和QA
将它发布到质量保证环境时，通常采用的流程是什么？这些修补程序是否立即部署到质量保证环境中（集成测试后），还是累积到当前测试周期完成？
给自己一个不断移动的目标是非常困难的。在部署到QA之前，我们倾向于批量修复 - 通常每日部署QA。 QA在早上第一件事情时就会获得输出，如果一个真正关键的错误阻碍了大量测试，那么QA就会“按需要”。
CI更多的是一个基本的代码质量基准（例如，它构建，它通过单元/烟雾测试） - 不需要QA需要从CI中获取每个构建。
在我理解正确的情况下，您问的是具有持续积分周期的项目中QA周期的持续时间是多少？
我们使用日常QA周期。如果成功的话，夜间测试可以在第二天进行测试。
nitzmahone的答案是平衡您从CI系统获得的更频繁的构建，QA需要拥有已知的测试目标。
您可以利用持续集成在作为每个版本的一部分运行的单元/烟雾测试之上获得额外的测试。这里有几件事情我做：
立即部署到QA环境（集成测试后），这些修补程序或者是他们累积，直到目前的测试周期的完成。
这取决于。如果问题是阻止并且不允许测试人员运行更多测试，为了完成整个测试计划（即完成他们的工作），那么显然需要立即发布修复程序。如果问题不是阻塞问题，那么排队修复并在下一个版本中提供它可能更可取。但是这需要大量的管理工作（记录问题，注释测试用例等）。
现在，如果QA在开发过程中很早发生（即，如果您没有使用非常连续的开发周期），如果测试人员正在与开发人员密切合作，那么一旦发现问题就可以解决问题，甚至避免创建一个错误清单（大量浪费）。
谢谢。我们还试图在采取新构建时僵化和当我们在已经测试的功能中发现新bug时获得惊喜。我们没有完全自动化的QA，所以新的构建可能会撤消在以前的构建中成功通过的任何测试用例。 – user236747 2010-01-01 09:26:15
在测试周期开始时我倾向于如果有阻止被解决的bug只需要新版本。这可以让我的团队避免新建和惊喜回归造成的冲击。发布的早期部分通常用于了解功能是如何实际实现的，以及产品是否符合最低限度的接受标准。
在测试周期的中间，我更频繁地接受构建，以确保修复尽可能多地曝光，并尽快识别错误修复的错误。除了我们正在进行长期压力测试或性能测试的环境以外，这通常是每日一次。
随着发布版本的临近，我对哪些bug进行了更多控制（例如：当前版本是分支的，我们有更严格的代码行策略），我们将继续构建版本，因为我们发现版本阻止的bug 。目前，构建通常被称为测试版或候选版。
这取决于项目开发风格。假设你是敏捷团队。
- 有迭代
- CI的目的是发现和迭代过程中修正错误迭代结束，并在测试中，测试的两个层次。测试类型集中在单元，功能和故事实施上
- 您在此类敏捷团队中发现的错误应该在发布到质量保证环境之前得到修复
- QA环境应该用于执行回归和集成测试。这种测试的目的应该是寻找回归和整合而不是功能功能
以上是一般的做法，偏离当然，这在很大程度上取决于你的软件和团队的性质CI过程中发现
错误开发团队尽快发现它们需要修复。质量保证团队在定期发布周期或补丁周期期间收到常规版本，而非CI构建问题。
由于CI建设汽车测试吸引了众多QA和非QA相关的错误，所以直接导致对其他QA活动表现沉重的负担。
所有取决于公司QA政策，有些人可能还是有些人可能不与我的观点一致:)
这可以通过将QA团队为子团队即内部和外部来完成。内部质量保证部门作为开发团队的一部分负责开发经理和外部质量保证部门的工作，对正在开发的产品进行测试。
内部QA团队负责product.They的健全测试评估通过执行健全流动构建的基本健康检查。如果任何理智流程失败或者主要/新创建的模块崩溃，IQA会将电子邮件路由到发布经理/开发经理以开发新的构建。一旦理智流程通过，构建已准备好由外部QA团队负责测试。
构建计划每天的基础上，故障是由外部质量检查的报告。内部质量检查人员在那里进行理智流动，并与开发人员进行快速沟通和讨论。通过这种方式，可以提升整个过程，并通过将其添加到开发团队中来降低QA-Dev差距。
希望这回答你的问题！欢呼:)
谢谢。我们的测试平台并不是完全自动化的，我们确实遇到了每一次构建日渐衰退的挑战 – user236747 2010-01-01 09:27:04