问软件测试中“质量门”的概念

EN

只有当所有测试都通过时，测试套件才能通过。否则，这些测试就会变得毫无价值。什么是重要的失败，什么是可以忽略的失败？结果是所有的测试失败都会在一段时间后被忽略。坏的。

有一个例外:测试套件可能包含已知的失败测试，因为必要的功能尚未实现或bug尚未修复。这样的测试是有价值的，因为它们清楚地记录了一个bug。但是，因为它们的失败不会是一种倒退，所以它们的失败不应该使整个测试套件失败(相反，如果它们开始通过测试套件将表明您的测试套件与您的代码不同步)。理想情况下，您的测试框架有这样一个“TODO测试”的概念。

质量度量是另一回事。如果一个质量度量跨过了一个阈值，这就意味着某些事情可能已经成熟，但并不一定成熟到可以重构。但是，在该代码的上下文中，一些“违规行为”可能是可以的。只要某些代码区域可以被排除在特定的分析工具之外，在质量度量上设置门是可以的。显然，任何明确的排除都将是代码评审中的一个危险标志，并受到额外的审查，但对于异常情况，保持这样的逃生舱口打开是很重要的。

特别是，要求提高质量的想法，就像一件艺术品穿过释放管道一样，并不一定是好的。必要的质量增值从何而来？从开发人员那里改进代码，并重新提交一个新的仿制品进入管道。由于预先知道穿越整个管道所需的质量指标，因此提交任何没有这种质量的艺术品都是浪费时间。那你为什么要这么做？很可能，管道中的各个阶段为您的程序提供反馈，这在主版本发布之前是有用的。要获得这种反馈，您必须提交代码，即使您没有经过管道的意图。再一次，虚假的否定是不好的。这样的工作流不适合于管道模型，反馈应该是独立可用的。

这并不意味着你应该放弃优质浇口。但是，如果您的目标是100%的发布度量，那么当前的质量度量将成为项目的进度指标，就像技术债务的刻录图表一样。

在阿蒙的好答案中，我想补充一点：

...the测试本身就是质量之门。

它们是生产代码的门户，但是测试本身可以有自己的(潜在的)质量度量，包括：

• 是否在每个测试中克隆了常见的设置/拆卸代码？或者它是否位于测试套件所支持的任何安装/ClassInitialize/TestInitialize等方法中？
  • 如果被测试的代码没有充分利用契约，那么在必要时测试是否涵盖了可接受的参数范围？正在测试边缘值吗？空集合？空收藏品？等等，即使覆盖率很高，您也可能没有充分地使用代码。
  • 测试要花太长时间才能运行吗？
  • 他们跑了吗？还是有人用@Ignore标记了许多测试，使套件通过了测试？
  • 当然，覆盖率是否可以接受？

这些属性，当然还有更多的属性，都是您可以选择测量的关于测试套件本身的东西(有些测试套件是由SonarQube支持的)，以获得不仅测试，而且有效测试的信心。