软件测试过程中，需要注意的常识性问题
5星 · 超过95%的资源 需积分: 16 184 浏览量
2009-04-26
18:24:41
上传
评论 1
收藏 30KB DOC 举报 
软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的
经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未
发现的隐藏的软件缺陷。
生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认
为软件缺陷（ Software Bug ）的具体含义包括下面几个因素：
•软件未达到客户需求的功能和性能；
•软件超出客户需求的范围；
•软件出现客户需求不能容忍的错误；
•软件的使用未能符合客户的习惯和工作环境。
考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合规范 ，
未能在特定的条件（资金、范围等）达到最佳等。可惜的是，我们中的很多人更倾向于把
软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。
在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时
在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完
美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让
步，对软件测试是有百益而无一弊的。
下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软件测试
时能够更好的把握软件测试的尺度。
•测试是不完全的（测试不完全）
很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多
样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证
所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约
数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，
从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们
能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般
采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简
测试复杂性的一条必经之道。
•测试具有免疫性（软件缺陷免疫性）
软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力
就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设
一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100
行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小
时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，
当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的
测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子
还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测
试应该尽可能的多采用多种途径进行测试。
•测试是 “ 泛型概念 ” （全程测试）
我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之
为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证
软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测
试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测
试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个
软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者
评论3
最新资源