第1个回答 2020-11-08
o 测试是不完全的(测试不完全)
很显然,由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素,哪怕是一个极其简单的程序,要想穷尽所有 逻辑路径,所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子,比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我 们将整个正整数域的数字进行一番测试的话,从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的,即便某一天我们能够穷尽该程序,只怕我们乃 至我们的子孙都早已作古了。为此作为软件测试,我们一般采用等价类和边界值分析等措施来进行实际的软件测试,寻找最小用例集合成为我们精简测试复杂性的一 条必经之道。
o 测试具有免疫性(软件缺陷免疫性)
软件缺陷与病毒一样具有可怕的“免疫性”,测试人员对其采用的测试越多,其免疫能力就越强,寻找更多软件缺陷就更加困难。由数学上的概率 论我们可以推出这一结论。假设一个50000行的程序中有500个软件缺陷并且这些软件错误分布时均匀的,则每100行可以找到一个软件缺陷。我们假设测 试人员用某种方法花在查找软件缺陷的精力为X小时/100行。照此推算,软件存在500个缺陷时,我们查找一个软件缺陷需要X小时,当软件只存在5个错误 时,我们每查找一个软件缺陷需要100X小时。实践证明,实际的测试过程比上面的假设更为苛刻,为此我们必须更换不同的测试方式和测试数据。该例子还说明 了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷,因此软件测试应该尽可能的多采用多种途径进行测试。
o 测试是“泛型概念”(全程测试)
软件测试不仅仅存在于程序编写完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话,需求阶段和设计阶段的缺陷产生的放大 效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷,记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证(自检)和设计验证(自检)也可以算作软件测试(建议称为:需求测试和设计测试)的一种。软件测试应该是一 个泛型概念,涵盖整个软件生命周期,这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估(信息系统审计和软件工程监理),即测试 本身也应当被测试,从而确保测试自身的可靠性和高效性。否则自身不正,难以服人。
另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件,软件测试是提高产品质量最直接、最快捷的手段,但决不是一个根本手段。
o 80-20原则
80%的软件缺陷常常生存在软件20%的空间里。这个原则告诉我们,如果你想使软件测试有效地话,记住常常光临其高危多发“地段”。在那 里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而 愚蠢的测试人员却仍在漫无目的地到处搜寻。
80-20原则的另外一种情况是,我们在系统分析、系统设计、系统实现阶段的复审,测试工作中能够发现和避免80%的软件缺陷,此后 的系统测试能够帮助我们找出剩余缺陷中的80%,最后的5%的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试 只能够保证尽可能多地发现软件缺陷,却无法保证能够发现所有的软件缺陷。
80-20原则还能反映到软件测试的自动化方面上来,实践证明80%的软件缺陷可以借助人工测试而发现,20%的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分,因此尚有5%左右的软件缺陷需要通过其他方式进行发现和修正。
o 为效益而测试
为什么我们要实施软件测试,是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件 测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价 值和意义。一般说来,在软件测试中我们应该尽量地保持软件测试简单性,切勿将软件测试过度复杂化。
o 缺陷的必然性
软件测试中,由于错误的关联性,并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的 软件缺陷。很多软件缺陷之间是相互矛盾的,一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何 况在缺陷的修复过程中,我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围,选择一个折 中的方案或是从非软件的因素(比如提升硬件性能)考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。
o 软件测试必须有预期结果
没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期 的结果,我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般,不少测试人员常常凭借自身的感觉去评判软件缺陷的发生,其结果往往是把似是而非的 东西作为正确的结果来判断,因此常常出现误测的现象。
o 软件测试的意义——事后分析
软件测试的目的单单是发现缺陷这么简单吗?如果是“是”的话,我敢保证,类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得 好,“不知道历史的人必然会重蹈覆辙”。没有对软件测试结果进行认真的分析,我们就无法了解缺陷发生的原因和应对措施,结果是我们不得不耗费的大量的人力 和物力来再次查找软件缺陷。