测试覆盖范围是否适合代码质量？

Question

如果我有一些具有80％测试覆盖率的代码（所有测试都通过），那么可以说它比没有测试覆盖的代码更高？

还是可以说它更可维护的是公平的？

Answer 1

从严格的意义上讲，在确定测试套件的质量之前，提出任何要求是不公平的。如果大多数测试相互琐碎或重复性，则通过100％的测试没有意义。

问题是： 在项目的历史中，是否有任何测试发现错误？ 测试的目的是查找错误。如果他们没有，他们将失败作为测试。他们可能只会给您带来错误的安全感，而不是提高代码质量。

为了改善测试设计，您可以使用（1）白盒技术，（2）黑盒技术和（3）突变测试。

（1）这里有一些适用于您的测试设计的好白盒技术。白盒测试是用特定源代码构建的。白盒测试的一个重要方面是代码覆盖：

• 每个功能都称为吗？ [功能覆盖范围
• 是否执行每个语句？ [声明覆盖范围 - 功能覆盖范围和声明覆盖范围非常基本，但总比没有好
• 每个决定（例如 if 或者 while），您是否有一项迫使其真实的测试，而其他测试则迫使它是错误的？ [决策范围
• 对于每个连词的条件（使用 &&）或析取（用途 ||），每个子表达是否具有真实/错误的测试？ [条件覆盖范围
• 循环覆盖范围：您是否有测试迫使0迭代，1个迭代，2次迭代？
• 是每个 break 从覆盖的循环中？

（2）当要求可用时使用黑框技术，但代码本身却没有。这些可以导致高质量的测试：

• 您的BlackBox测试是否涵盖了多个测试目标？您希望您的测试是“ fat”：它们不仅测试功能X，而且还测试Y和Z。不同功能的相互作用是查找错误的好方法。
• 您唯一不需要“脂肪”测试的情况是测试错误条件时。例如，测试无效的用户输入。如果您尝试实现多个无效的输入测试目标（例如，无效的邮政编码和无效的街道地址），则可能是掩盖另一个情况。
• 考虑输入类型，并为输入类型形成“等效类”。例如，如果您的代码测试查看三角形是否等边，则使用带有边的三角形的测试（1、1、1）可能会找到与测试数据（2、2、2）和（3、3、3）会发现。最好花时间思考其他类别的投入。例如，如果您的计划处理税收，则需要为每个税级进行测试。 [这称为等效分区。
• 特殊情况通常与缺陷有关。您的测试数据还应具有边界值，例如在等效任务的边缘上，上方或下方的边界值。例如，在测试排序算法时，您需要使用一个空数组，一个元素数组，一个带有两个元素的数组，然后是一个非常大的数组来测试。您不仅应该考虑边界案例，而且还应考虑输出。 [这是调用边界值分析。
• 另一种技术是“错误猜测”。如果您尝试一些特殊的组合，您是否有感觉？然后尝试一下！记住： 您的目标是找到错误，而不是确认程序有效. 。有些人有错误猜测的诀窍。

（3）最后，假设您已经对白盒覆盖范围进行了许多不错的测试，并应用了Blackbox技术。你还能做什么？是时候了 测试您的测试. 。您可以使用的一种技术是突变测试。

在突变测试下，您对程序进行修改，以期创建错误。突变可能是：

将一个变量的引用更改为另一个变量；插入ABS（）函数；改变比大于大；删除语句；用常数替换变量；删除一种压倒性方法；删除对超级方法的引用；更改参数顺序

在程序中的各个地方创建几十个突变体[该程序仍需要编译才能进行测试]。如果您的测试找不到这些错误，那么您现在需要编写一个可以在程序的突变版本中找到错误的测试。一旦测试找到该错误，您就杀死了突变体并可以尝试另一个。

---

附录: ：我忘了提到这个效果： 虫子倾向于群集. 。这意味着您在一个模块中发现的错误越多，您会发现更多错误的概率就越高。因此，如果您的测试失败了（也就是说，测试成功，因为目标是找到错误），不仅应该修复错误，而且还应使用该模块编写更多测试上面的技术。

只要您以稳定的速度找到错误，必须继续进行测试工作。只有当发现的新错误率下降时，如果您有信心，您对这一开发阶段做出了良好的测试工作。

Answer 2

从一个定义来看，这是更可维护的，因为任何打破变化更有可能被测试所捕获。

但是，代码通过单元测试的事实并不意味着它本质上具有更高的质量。该代码可能仍然以不相关的评论和不适当的数据结构的格式不佳，但仍然可以通过测试。

我知道我希望维护和扩展哪种代码。

Answer 3

绝对没有测试的代码可以是极高的，可读，美丽和高效的（或总垃圾），因此，不公平地说，具有80％测试覆盖的代码质量高于没有测试覆盖的代码。

可以公平地说，代码80％覆盖 好的 测试是 大概 可接受的质量， 大概 相对可维护。但这实际上几乎没有保证。

Answer 4

我称其为更可靠的。如果代码涵盖了很多测试，重构将变得非常容易。

公平地称其为更可维护的。

Answer 5

我会同意可维护的部分。迈克尔·菲瑟斯（Michael Feathers）最近发布了一段关于他的名为“可测试性和良好设计之间的深层协同作用“他讨论了这个主题。在谈话中，他说这种关系是一种方法，即设计精良的代码是可测试的，但是可测试的代码不一定是设计精良的。

值得注意的是，视频流在视频中不是很好，因此，如果您想完整观看，可能值得下载。

Answer 6

我一直在问自己这个问题已经有一段时间了，与“条件覆盖”有关。那么atollic.com的此页面怎么样 “为什么代码覆盖范围分析？”

从技术上讲，代码覆盖范围分析可以找到程序中未经测试案例涵盖的区域，从而使您可以创建涵盖程序中未经测试部分的其他测试。因此，重要的是要了解 代码覆盖范围可帮助您了解测试程序的质量，而不是代码本身的质量.

这在这里似乎很重要。如果您有一个测试案例集，该测试案例集可以达到一定级别的（代码或其他）覆盖范围，那么您很可能会使用一组详尽的输入值调用正在测试的代码！这不会告诉您有关正在测试的代码的太多（除非代码炸开或生成可检测的故障），但是会给您 对您的测试案例集有信心.

在一个有趣的地方 内心立方体 视图更改，测试代码现在正在通过测试的代码进行测试！

Answer 7

有很多方法可以保证程序可以执行您的意图，并确保修改不会带来意外效果。

测试是一个。避免数据突变是另一个。类型系统也是如此。或正式验证。

因此，尽管我同意测试通常是一件好事，但给定的测试百分比可能意义不大。我宁愿依靠没有测试的Haskell写的东西，而不是在经过良好测试的PHP库上