软件测试常识介绍.doc

: .
软件测试常识介绍
下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软 件测试时能够更好的把握软件测试的尺度。
1 测试是不完全的（测试不完全）
很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量 性及结果多样性等因素， 哪怕是一个极其简单的程序， 要想穷尽所有逻辑路径， 所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子， 比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将 整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这 样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我 们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和 边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测 试复杂性的一条必经之道。
2 测试具有免疫性（软件缺陷免疫性）
软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越 多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我 们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这 些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试 人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件 存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个 错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过 程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该 例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺 陷，因此软件测试应该尽可能的多采用多种途径进行测试。
3 测试是 “ 泛型概念 ” （全程测试）
我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后 的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效 应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷， 记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。 需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求 测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命 周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三 者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从 而确保测试自身的可靠性和高效性。否则自身不正，难以服人。
另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软 件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。
4 80-20 原则
80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想 使软件测试有效地话，记住常常光临其高危多发 “ 地段 ” 。在那里发现软 件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发 现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多