块测试
决策测试
条件测试
基础路径测试
代码复杂度分析
一些测试技术比如边界值分析、以及结对测试（pairwise），可以有效地帮助我们在尽量少增
加风险的同时，减少所需测试用例的数目。然而常见的问题在于产品缺陷，并不是平均分布
在代码里的。在一些典型的软件项目里，总有些组件比其他组件存在更多的缺陷。
二八定律同样适合于代码。20%的代码中存在有80%的bug。
很多人都相信 Pareto 定律 28 （80/20 法则）也同样适用于软件项
目。在一般应用上，Pareto 定律认为在很多度量标准下 80%的结果源自 20%的原因。如果应
用在软件领域，Pareto 定律可以解读为，80%的用户使用仅仅 20%的功能，80%的缺陷存在
于 20%的产品中，或者说 80%的运行时间耗费在 20%的代码上。一方面，基于风险的测试方
法是尝试归类出哪部分产品组件拥有更普及的用户场景，从而投入更多的测试力量；另一面
则是这种方法的风险性，它依赖于对测试重点的精确选择从而忽略了一个事实，还是有用户
会去使用那些 20%以外的功能和代码。
别碰它
我曾经在视窗95开发组进行 络组件的测试工作。在测试过的一个组件里，
我们会偶尔发现微小缺陷，而在极少情况下， Beta 版的用户也会 告同
一个组件的问题。幸运的是，所有这些缺陷都是小问题，因为都被解决为
“无需修复”，意即这个缺陷在本产品发布中将不会修复，或者在将来的
任何发布中也不会。其实如此解决组件缺陷是出于这样一个“简单”原因：
当初开发此代码的开发员已经离开公司了，而现在我们“不敢碰”这些代
码。这些代码过于困难和复杂，以至于没有一个独立开发人员愿意承担惹
出一大堆新缺陷的风险去修复它。
所幸这个组件在之后的微软视窗操作系统中被彻底重写了，但是我时常仍
然听到一些因为没人敢碰而放弃修复的故事。
阿伦 ?培智
回路复杂度
市场上有免费的计算回路的软件
面向对象的度量
某一个特定的类和有多少类被某一个特定的类调用。例如，如果一个类包含的方法被其他 5
个类调用而且这些方法也调用了其他 10 个类，那么它的扇入就是 5，扇出就是 10。这些度
量值作为可维护性度量常常是非常有效的，同时也表明了需要额外的测试的区域。例如，如
果一个类被很多类调用（很高的扇入度），那么很有可能在这个类中任何代码的改动都会导
致在其中一个调用类中产生新的漏洞
如果一个对象多次被调用，那么应该对该调用对象进行重点测试。
代码改动量
这两种情况都需要进行再次修复，或者是针对原有的问题，或者是针对新发现的问题。通常，
这种情况还会反复发生。当代码非常复杂时，往往会需要进行多次的反复才能修正所有已知
的缺陷，并且确保没有新的故障发生。（然而从概率上而言，该段代码的代码改动指标将会
非常高，这也就意味着其中还可能存在更多的缺陷）
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！