最近1直在学习测试方面的知识，也阅读了许多博客，通过这些博客也了解到了许多未曾接触过的关于测试方面的理
论和原则和1些常识性的东西，比如测试的不完全性，测试中的28定律，缺点的必定性等。这篇文章做下整理，
分享给大家。了解这些将对我们在进行软件测试时掌控软件测试尺度很有帮助。
☆测试的不完全性
很明显，由于软件需求的不完全性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是1个极
其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的1件事情。我们举1个简单的例
子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将全部正整数域的数字进行1番测试
的话，从其数目的无穷性我们即可证明是这样的测试在实际生活中是行不通的。为此作为软件测试，我们1般采取等
价类和边界值分析等措施来进行实际的软件测试，寻觅最小用例集合成为我们精简测试复杂性的1条必经之道。
☆测试具有免疫性(软件缺点免疫性)
软件缺点与病毒1样具有可怕的“ 免疫性 ” ，测试人员对其采取的测试越多，其免疫能力就越强，寻觅更多软件缺
陷就更加困难。由数学上的几率论我们可以推出这1结论。假定1个 50000行的程序中有 500 个软件缺点并且这些
软件毛病散布时均匀的，则每 100 行可以找到1个软件缺点。我们假定测试人员用某种方法花在查找软件缺点的精力
为 X小时 /100 行。照此推算，软件存在 500 个缺点时，我们查找1个软件缺点需要 X 小时，当软件只存在 5 个错
误时，我们每查找1个软件缺点需要 100X小时。实践证明，实际的测试进程比上面的假定更加刻薄，为此我们必须
更换不同的测试方式和测试数据。该例子还说明了在软件测试中采取单1的方法不能高效和完全的针对所有软件缺
陷，因此软件测试应当尽量的多采取多种途径进行测试。
☆测试是 “泛型概念 ” (要全程测试)
软件测试仅存在于程序完成以后？现在这个概念恐怕难以立足了。由于如果单纯的只将程序设计阶段后的阶段称之为
软件测试的话，需求阶段和设计阶段的缺点产生的放大效应会加大。这非常不利于保证软件质量。需求缺点、设计缺
陷也是软件缺点，记住“ 软件缺点具有生育能力 ”。软件测试应当逾越全部软件开发流程。需求验证(自检)和设计验
证(自检)也能够算作软件测试的1种。软件测试应当是1个泛型概念，涵盖全部软件生命周期，这样才能确保周期的
每一个阶段禁得起考验。同时测试本身也需要有第3者进行评估(信息系统审计和软件工程监理)，即测试本身也应当被
测试，从而确保测试本身的可靠性和高效性。否则本身不正，难以服人。
另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷
的手段，但决不是1个根本手段。
☆28定律
28定律，这里感觉非常亲切，原来28定律也能够用在测试里，80%的软件缺点常常生存在软件 20% 的空间里。
这个原则告知我们，如果你想使软件测试有效地话，记住常常光临其高危多发 “ 地段 ”。在那里发现软件缺点的可
能性会大的多。这1原则对软件测试人员提高测试效力及缺点发现率有侧重大的意义。聪明的测试人员会根据这个
原则很快找出较多的缺点而笨拙的测试人员却仍在漫无目的地到处搜索。
28定律的另外1种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80%
的软件缺点，尔后的系统测试能够帮助我们找出剩余缺点中的 80% ，最后的 5%的软件缺点可能只有在系统交付使
用后用户经过大范围、长时间使用后才会曝露出来。由于软件测试只能够保证尽量多地发现软件缺点，却没法保证
能够发现所有的软件缺点。
28定律还能反应到软件测试的自动化方面上来，实践证明 80%的软件缺点可以借助人工测试而发现， 20% 的软件
缺点可以借助自动化测试能够得以发现。由于这2者间具有交叉的部份，因此尚有5% 左右的软件缺点需要通过其他
方式进行发现和修正。
☆为效益而测试
为何我们要实行软件测试，是为了提高项目的质量效益终究以提高项目的整体效益。为此我们不难得出我们在实行
软件测试应当掌握的度。软件测试应当在软件测试本钱和软件质量效益二者间找到1个平衡点。这个平衡点就是我们
在实行软件测试时应当遵照的度。单方面的寻求都必定侵害软件测试存在的价值和意义。1般说来，在软件测试中我
们应当尽可能地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是：Keep it simple
but not too simple 。
☆缺点的必定性
软件测试中，由于毛病的关联性，其实不是所有的软件缺点都能够得以修复。某些软件缺点虽然能够得以修复但在修复
的进程中我们会难免引入新的软件缺点。很多软件缺点之间是相互矛盾的，1个矛盾的消失必定会引发另外1个矛盾
的产生。比如我们在解决通用性的缺点后常常会带来履行效力上的缺点。更何况在缺点的修复进程中，我们常常还会
受时间、本钱等方面的限制因此没法有效、完全地修复所有的软件缺点。因此评估软件缺点的重要度、影响范围，选
择1个折衷的方案或是从非软件的因素(比如提升硬件性能)斟酌软件缺点成为我们在面对软件缺点时1个必须直面的
事实。
这些常识性的理论原则我觉得非常有必要了解1下，由于这些都是先辈们经过无数次尝试总结出来的，站在伟人的肩
膀上能使我们少走1些弯路，关于测试的学习仍在继续！
参考： <http://www.ltesting.net/ceshi/ceshijishu/rjcsgcsrm/2013/1023/206738.html>