代码合并前的功能分支测试？

Question

我是QA专业人员，为一个团队工作，该团队计划为开发人员创建特性分支，以实现独立的特性。我们曾争论过，是否每个特性分支上的测试应该由开发人员作为单元测试和开发测试的一部分来执行，还是应该由QA在分支代码合并之前在特性分支上执行黑匣子测试。通常遵循的行业标准是什么？

Answer 1

来自上下文驱动测试原则：

"The value of any practice depends on its context."

这方面没有“行业标准”，即使有99.9%的人同意采用一种或另一种做法，实践的价值仍然取决于你的背景。

话虽如此，在进行这一评估时，你可能会考虑到一些事情：

• 特性分支测试将产生更好的信息，越接近您的分支的状态，更改历史将在合并之后。

如果非快进合并和长期存在的分支是您的存储库中最常见的原因，那么您通过测试发现的信息在合并后更有可能无效。

为了缓解这种情况，对主服务器进行不断的重基和常量合并。

• 特性分支测试(早期测试)意味着增加了用于测试的构建和部署。如果您的构建和部署过程缓慢且容易出错，那么您将花费大量时间在测试准备上，而不是在产品开发上。
• 当通信是直接和诚实的时候，特征分支测试工作得更好。如果测试人员和开发人员之间的关系主要是通过文档和bug跟踪系统，以流水线的方式进行；而不是面对面或通过配对，那么测试活动可能会成为瓶颈，并会产生类似于第一点的情况。

如何知道哪一个更适合？创造实验。

计划你的目标是什么，提出指标来告诉你这些目标是如何实现的；

在时间盒或几个特性中进行实验；

收集指标；

在学习的基础上调整你的练习；

重复直到满意为止。

Answer 2

在作出这样的决定时，上述大多数答案都解释了“背景”的概念。

我想在计划测试特性分支时迭代测试策略：

1. 您不必在特性分支中进行回归测试
2. 您可以进行特性测试(测试新开发的特性)。
3. 健全性测试(基本功能运作良好)
4. 烟雾测试的关键功能可以工作。

在“理智”和“冒烟”中，尝试识别重叠的用例--这些用例将同时涵盖正常和冒烟的用例，例如:对于固件更新，您必须上传固件并更新固件。这里，上传功能(这是基本的)和固件更新(关键)都包括在内。

所以你不需要花太多的时间去弄清楚该做什么，在大多数情况下，吸烟测试也会包括精神错乱。

特性分支测试的

好处：

1. 它可以更灵活，并能提供更快的反馈。
2. 如果某个功能没有按预期工作，或者需要改进，您可以更早地与开发团队进行沟通。
3. 您可以更多地了解该特性，从而提高您的整体领域专长，这最终将有助于设计更好的测试方法。
4. 与软件整体相比，它在更注重特性的测试中有所帮助。这有助于找到更多的用例，否则您可能会错过。
5. 更多的开发-QA协作，白盒测试的机会，如果您与开发人员创建了一种礼节，开发人员将解释为什么构建失败了，代码块导致了错误。
6. 避免开发团队的特性重新工作和不必要的上下文切换，这反过来将有助于QA和Dev之间更顺畅的关系。

注意:即使它是特性分支或集成构建，开发团队也应该将其传递给QA，只需经过他们自己的基本测试。

Disadvantages:

1. 如果没有适当的沟通和工作量评估，那么这将是QA的更多工作量。您可能会在测试中失去效率，因为您可能会得到更少的时间来测试实际的集成构建。
2. 在所有测试级别上用测试来轰炸有限的QA资源就像运行超出其能力的引擎一样，并且不会花费时间来失败。

所以，看看你是否有足够的时间和资源去做这件事，那么这是一个学习和更精通你的领域的好机会。

如果你是一个负责处理这一切的QA，那么这是一个很大的不，你只会感到自己精疲力竭，感觉环境不那么支持和更有毒。

Answer 3

我写了软件工程栈交换中类似问题的回答。

没有“行业标准”。

在一个完美的世界里，我希望测试发生两次。测试的“第一关”在特性分支上。这使手动测试人员有机会创建他们的测试用例，确保它们都有意义，并且特性或更改被隔离地很好地覆盖。这一通过的主要目标不在于测试，而在于发现什么和如何测试。当然，它可以发现开发人员由于发现而忽略的问题。测试的“第二关”取决于您的发布过程。在有发布分支的急流中，第二次传递是在发布分支中完成的。不同的发布和分支流可能会在其他地方完成。开发人员领导的测试，无论是手动的还是自动化的，都将在开发过程中进行，在任何类型的代码评审期间都会进行，而且我希望它在第一次手动测试之前或与第一次手动测试并行进行。

然而，我们并不生活在一个完美的世界。手工测试是昂贵的，所以做两次是双倍的代价。因为第一个是试运行，测试人员更熟悉测试步骤和如何执行这些步骤，这可能比双倍的成本低一些。如果需要为遵守情况记录大量证据，也可能会更多。

有几条路要走。也许可以根据特性分支运行和构造“愉快路径”测试，并且发布过程可以包括更多的负面测试和探索性测试。根据正在开发的特性，可能有在发布过程中组合测试的方法，而这些方法在特性分支测试期间是不可行的。

这取决于组织评估不同选项的成本和风险，并选择对给定环境有意义的选项。