发布用于系统测试的软件时，在不添加新功能的情况下修复错误是否正确？

这个问题是给有经验的测试人员或测试主管的。这是来自软件项目的场景：

假设开发团队已完成10个功能的第一次迭代，并将其发布到系统测试中。测试团队为这10个功能创建了测试用例，并估计需要5天的测试时间。开发团队当然不能闲置5天，他们开始为下一次迭代创建10个新功能。在这段时间内，测试团队发现了缺陷并提出了一些错误。这些bug的优先级很高，其中一些必须在下一次迭代之前修复。问题是，在修复所有这些错误之前，他们不会接受具有任何新功能或对现有功能进行更改的新版本。测试团队说，如果我们还引入了新功能以及错误修复，这就是我们如何保证测试的稳定版本。他们也不能在每次迭代中对所有测试用例进行回归测试。

这意味着开发团队必须创建一个代码分支专门用于错误修复，并创建另一个分支以继续开发。特别是在重构和体系结构更改方面，存在更多的合并开销。

如果这是通用的测试原理，您是否可以同意。测试团队的关注是否有效？您在项目中实践中遇到过此问题吗？

我要说的是，每个新功能的发布都应该在一个单独的分支上。这样可以使开发和发布脱钩。

您向最终用户发布的产品如何在此过程中起作用？您的系统测试团队应较少关注开发时间表，而应专注于客户发布时间表。

在开发持续进行的过程中尝试正式测试新功能毫无意义，因为您的下10个功能很有可能会触及相同的功能，并要求它们再次测试这些功能。

他们可以继续在开发过程中非正式地测试临时内部版本，并充实他们的测试设计（希望能捕捉到这些新功能中的大多数错误），但是在开发结束时他们将需要一段额外的时间来对新功能和回归进行正式测试。测试。

当他们估计需要测试5天来测试10个新功能时，他们应该考虑的是，在开发周期结束时（向客户发布），他们需要5天的时间来验证新功能（并且可能需要更多时间进行迭代）如果发现错误）。在此期间，可以将客户版本分支出来进行测试，并且可以在下一个版本中继续开发新功能。

我们使用混合方法。对于客户发布，我们绝对有自己的分支，仅用于严重的错误修复。

继续在多个软件版本上进行定期开发。例如，假设最新的稳定发行版是2.0。所有有风险的功能将添加到3.0分支。只有错误修复才能进入2.0分支。专门的质量检查小组只能在稳定的分支机构进行测试。客户发布当然是从另一个基于2.0的分支机构完成的。诸如下一代平台开发之类的长期运行功能将在4.0甚至3.0中完成。

所有这些在纸上看起来都不错。但是，如果客户需要特定功能，则必须将其自身添加到2.0分支中，因为3.0不够稳定，无法发布给客户。这意味着质量检查团队将不得不重新运行整个回归套件。

我们要做的一件事是对每个回归测试用例进行代码覆盖。仅运行那些受功能代码更改影响的回归测试用例。当然，对于客户版本，将运行完整回归套件。

这实际上取决于新功能与需要修复错误的部分的紧密程度。例如，如果您将新的拖放功能添加到UI的一小部分，则“不应”影响与用户加载的文件的解析有关的错误。

话虽如此，测试人员想要测试“ Ceteris paribus”（所有“其他”条件相同）的修补程序是可以理解的（不一定合理）。

发行方式和最终用户的期望可能还存在其他一些问题。例如，您可能只需要在错误修复+测试和另外一项新功能+测试的迭代之后发布，因为用户只有在有新功能时才希望重新安装或升级。有些人可能要求尽快将修复程序作为最高优先级。

您可以通过合并合并两个团队来解决此（常见）问题。

开发团队中的测试人员，随着功能的产生进行测试，可以帮助大多数团队提高输出质量。

我建议你阅读从这个优秀的博客帖子的Henrik Kniberg解释考班。您会在Scrum流程中找到许多想法（Henrik Kniberg还是一本免费的书）。

他还在自己的博客上写了一篇出色的看板VS Scrum文章。

请享用。

测试团队肯定有一个有效的担忧，但是我会质疑每个版本都需要进行多次测试迭代。为什么要对用户从未见过的代码版本进行全面测试？

如果测试人员试图将定义的版本发布给客户，而不期望新功能，则他们的要求是合理，合理的，您应该弯腰交付。

如果这只是为了在正常的开发阶段协助他们的“过程”，并确保错误列表不会失控，而没有造成任何问题，请询问测试负责人是否可以放宽此限制，直到我们离发布点越来越近。

考虑将您的源代码管理系统更改为分布式产品。这将使发布这样的版本变得更加容易。

“如果这是通用的测试原则，您是否可以同意。

Yes

测试团队的关注是否有效

Yes

您在项目中实践中遇到过这个问题吗？”

Yes

：

and Yes Merging is the downside of it 

您没有问这是谁的责任，但这是配置管理器的责任。此流策略应在他的CMP中。否则开除他/她。我认为Pierre 303的回应也非常好，但是当然在技术上（例如，考虑Siebel版本...）和组织上都可以。

问题是，如果他们在分支上测试错误，则一旦合并回去，它们仍然需要重新测试，然后在主干上进行回归测试（除非他们非常信任很少有好的测试者）。这不仅为开发人员带来更多工作，还为测试人员带来更多工作。

这里没有正确的答案，但您应该考虑以下几点：

• 这些错误版本（没有新功能）可能会交给用户吗？如果是这样，那么是的，必须对其进行分支和测试，并且每个人都需要接受它作为开销。

• 是否有可能将新功能划分为新功能，使其存在于应用程序的完全独立区域中，而不是以前处理过的块？如果是这样，则为您提供了选择-测试人员可以对应用程序的错误进行重新测试并进行回归测试。这不是理想的选择，但这是一种折衷方案，可能会起作用，并为他们提供一些他们想要的东西。

• 将它们分支为一个发行版实际上需要多少工作？通常这很痛苦，但是实际的工作量通常并不那么好。显然，您需要他们来确认这不仅对他们来说还需要更多工作（请参阅我说的第一句话），但我已经看到了使该工作成功的地方。

• 有没有更好的方法来使用版本控制？ 诸如Mercurial（请参阅http://hginit.com/-很好）之类的东西或另一个分布式版本控制系统以不同的方式分支和合并，可能使您解决问题。 确实，请看一下它，因为我认为这可能是您问题的答案。

但是，祝你好运，这很痛苦。最重要的是，最好的前进方式将非常取决于您的公司，产品和情况，因此请确保您考虑到这一点，不要只是从货架上拿东西，而是相信您必须100％遵守。

如果您描述的错误是实际缺陷而不是设计优化，那么是的，您应该在开始开发新功能之前真正尝试修复它们。

如果您在已知错误的基础上构建新功能，那么您将创建一个纸牌屋。您可能会开发脆弱的，不可预测的软件。根据错误代码与您的新功能之间的隔离级别，这些错误也可能会影响您的新功能。如果是这样，您如何知道新功能是否正常运行？

如果首先修复错误，那么您将为所添加的任何新功能奠定更坚实的基础。

当然，有时候外力会迫使您违背更好的判断力。尝试帮助决策者做出明智的决定，使他们知道任何一种行动方案的后果（即，未解决的缺陷与错过的功能交付日期）并允许他们做出判断。有时出于法律和财务上的原因，有必要采取行动，尽管这不是可取的。

在添加新功能之前，请务必尝试修复错误！

在我工作的地方，我们处理这种情况，即每个预期的生产版本都有其自己的分支。例如，假设一秒钟将在6月底发布一个版本，7月底将发布另一个版本。6月的发行版将拥有自己的分支，所有功能都将添加到该分支并发送给质量检查。此时，我们将从7月的发行版开始，从6月的分支开始。当质量检查人员发现错误后，我们会在6月的分支机构中对其进行修复，并将这些修补程序推送至质量检查部门后，它们便会合并到7月的发行分支中。确实会增加一些开销来处理这些合并，但是通常合并是相当轻松的。您有时会不知所措，这很痛苦，但这只会在进行批量更改时才会发生，而这些更改在质量检查周期内不应该发生（但是，超过我喜欢的承认）。但是有了一套很好的测试（单元和集成），代码覆盖率以及所有其他TDD流行语，风险就会有所减轻。为了提供帮助，我们通常需要一个人来处理每个项目的合并。