书名：软件测试技术基础教程（第2版）pdf/doc/txt格式电子书下载

推荐语：

作者：顾海花,雷雁,史海峰

出版社：电子工业出版社

出版时间：2015-03-01

书籍编号：30467954

ISBN：9787121239175

正文语种：中文

字数：171083

版次：2

所属分类：教材教辅-大学

版权信息

书名：软件测试技术基础教程（第2版）

作者：顾海花　雷雁　史海峰

ISBN：9787121239175

版权所有 · 侵权必究

前言

本书全面系统地介绍了软件测试基础理论及其应用技术，并介绍了软件测试的发展脉络及其与软件开发最新技术的结合和运用。本书旨在使读者可以很快地掌握软件测试的基础知识，引领读者进入软件测试这个新的领域，并了解软件测试的最新动态，对它有一个全面的认识。

本书重在培养读者软件测试工作的实践能力，适应软件企业的工作环境和业界标准，并与国际先进的软件开发理念和测试技术保持同步。通过本书的学习，读者应该了解并掌握软件产品质量保证的基本思想和科学体系，软件测试过程和策略，软件测试的方法、技术和工具的使用，为全面掌握软件技术和软件项目管理打下坚实的基础。

全书共分为两大部分。第1部分为软件测试基础理论，包括第1～7章，综合介绍了以下几个方面的内容：软件测试的定义、目标、原则和分类；软件开发过程和开发模式；软件测试技术前沿；白盒测试技术；黑盒测试技术；软件自动化测试；软件测试计划、文档及测试用例；面向对象的软件测试；Web网站测试。这部分内容论述浅显易懂，知识点全面实用，特别是在白盒、黑盒测试技术介绍中运用了大量的案例来进行阐述，并且介绍了软件领域中的新技术对软件测试提出的新要求。第2部分为软件测试工具实践，包括第8～10章，介绍了JUnit、LoadRunner、Quality Center等自动化测试工具的使用。

本书由顾海花担任主编，雷雁、史海峰担任副主编，王永安参与编写。其中第1、2、3、5章由顾海花编写，第4、8、9章由雷雁编写，第6、10章由史海峰编写，第7章由王永安编写，最后由顾海花负责统稿。同时，在本书的编写过程中，聂明院长给予了全力的支持和帮助，董志勇主任也提出了宝贵的意见，在此表示衷心的感谢！

参加本书编写的人员均为高职院校的教学骨干，并将多年积累的具有实用价值的经验、知识点和操作技巧等毫无保留地奉献给广大读者。为了方便教师教学，本书配有教学演示文稿供下载使用（下载网址：www.hxedu.com.cn）。

在本书编写过程中，参考和引用了大量专家学者的论著和研究资料，作者已经尽可能在参考文献中列出，谨在此向他们表示由衷的感谢。由于时间仓促和水平所限，书中难免存在一些不足之处，欢迎广大读者批评指正，联系信箱是guhh＠njcit.cn。

编者

第1部分 软件测试基础理论

第1章 软件测试基础知识

随着软件产业的日益发展，软件系统的规模和复杂性与日俱增，软件的生产成本和软件中存在的缺陷故障造成的损失也大大增加，甚至会带来灾难性的后果。软件产品不同于其他科技和生产领域的产品，它是人脑的高度智力化的体现，由于这一特殊性，软件与生俱来就有可能存在着缺陷。

在开发大型软件系统的漫长过程中，面对纷繁复杂的各种现实情况，人的主观认识和客观现实之间往往存在着差距，开发过程中各类人员之间的交流和配合也往往并不是尽善尽美的。

如果不能在软件正式投入运行之前发现并纠正这些错误，那么这些错误最终必然会在软件的实际运行过程中暴露出来。到那时，改正这些错误不仅要付出很大的代价，而且往往会造成无法弥补的损失。

软件的质量就是软件的生命，为了保证软件的质量，人们在长期的开发过程中积累了许多经验并形成了许多行之有效的方法。但是借助这些方法，我们只能尽量减少软件中的错误和不足，却不能完全避免所有的错误。

如何防止和减少这些可能存在的问题呢?答案是进行软件测试。测试是最有效的排除和防止软件缺陷与故障的手段，并由此促进了软件测试理论与技术实践的快速发展。新的测试理论、测试方法、测试技术手段在不断涌出，软件测试机构和组织也在迅速产生和发展，由此软件测试技术职业也同步完善和健全起来。

1.1 软件缺陷

1.1.1 软件缺陷案例分析

软件是由人编写开发的，是一种逻辑思维的产品，尽管现在软件开发者采取了一系列有效措施，不断地提高软件开发质量，但仍然无法完全避免软件（产品）会存在各种各样的缺陷。软件中存在的缺陷有时会造成相当严重的损失和灾难。

下面以4个软件缺陷的案例来说明。

（1）美国迪士尼公司的狮子王游戏软件缺陷

1994年秋天，美国迪士尼公司发布了一个面向儿童的多媒体游戏软件“狮子王动画故事书（The Lion King Animated Storybook）”。迪士尼公司为了打开儿童游戏市场，进行了大量促销宣传。结果，销售非常火爆，销售额非常可观，该游戏成为美国孩子们当年的“必买游戏”。然而好景不长，圣诞节过后，迪士尼公司的客户投诉电话便开始响个不停，愤怒的家长和玩不成游戏的孩子们对这款游戏软件的缺陷进行了大量的投诉。报纸和电视新闻进行了大量的报道。

后经调查证实，迪士尼公司在软件上市前没有将软件在市面上投入使用的许多不同类型的PC上进行广泛的测试，也就是说游戏软件对硬件的兼容性没有得到保证，造成了该软件只能在少数系统中正常工作，即在迪士尼程序员用来开发游戏的系统中可以正常运行，但在大多数公众使用的系统中却不能运行。该软件故障使迪士尼公司声誉大损，并且为了改正软件缺陷付出了沉重的代价。

（2）美国航天局火星登录探测器缺陷

1999年12月3日，美国航天局的火星极地登录者号探测器试图在火星表面着陆时突然失踪。事故评估委员会对这起事故进行了调查，认定出现故障的原因极可能是一个数据位被意外置位。而该问题本应该在内部测试时就被发现并予以解决。

从理论上看，着陆的过程是这样的：当探测器向火星表面降落时，它将打开降落伞减缓探测器的下降速度。降落伞打开几秒后，探测器的3条腿将迅速撑开，并锁定位置，准备着陆。当探测器离地面1 800 m时，它将丢弃降落伞，点燃着陆推进器，缓缓地降落到地面。

然而美国航天局为了节省研制经费，简化了确定何时关闭着陆推进器的装置。为了替代其他太空船上使用的贵重雷达，他们在探测器的脚部安装了一个廉价的触点开关，在计算机中设置一个数据位来控制触点开关关闭燃料。很简单，探测器的发动机需要一直点火工作，直到脚“着地”为止。

遗憾的是，故障评估委员会在测试中发现，许多情况下，当探测器的脚迅速撑开准备着陆时，机械振动也会触发着陆触点开关，设置致命的错误数据位。设想探测器开始着陆时，计算机极有可能关闭着陆推进器，这样火星极地登录者号探测器飞船下坠1 800 m之后冲向地面，撞成碎片。

结果是灾难性的，但背后的原因却很简单。登录探测器在发射前经过了多个小组测试，其中一个小组测试飞船的脚折叠过程，另一个小组测试此后的着陆过程。前一个小组不去注意着陆数据是否置位，因为这不是他们负责的范围；后一个小组总是在开始测试之前复位计算机，清除数据位。双方独立工作都做得很好，但没有在一起进行集成测试，使系统中的衔接问题隐藏起来，最终导致了灾难性事故的发生。

（3）北京奥运门票被迫暂停销售

2007年10月30日上午9点，北京奥运会门票面向境内公众的第二阶段预售正式启动。然而，为让更多的公众实现奥运梦想“先到先得，售完为止”的销售政策适得其反，公众纷纷抢在第一时间订票，致使票务官网压力激增，承受了超过自身设计容量8倍的流量，导致系统瘫痪。为此，北京奥组委票务中心对广大公众未能及时、便捷地实现奥运门票预订表示歉意，同时宣布奥运门票暂停销售5天。

为此次门票销售提供技术系统平台的是北京歌华特玛捷票务有限公司。该公司工作人员透露，此次票务官网设计的流量容量是每小时100万次，但瞬间承受了每小时800万次的流量压力，访问数量过大造成网络堵塞，技术系统应对不畅，造成很多申购者无法及时提交申请，所以系统在启动不久就出现了处理能力不足的问题。

Web压力测试可以有效地测试一些Web服务器的运行状态和响应时间等，对于Web服务器的承受力测试是个非常好的手法。如果在网站建设时就进行压力测试，并考虑网站在访问量过大时如何保证网站的正常运行，就会增强网站的鲁棒性。

（4）诺基亚Series 40手机平台存在缺陷

2008年8月诺基亚承认该公司销售量超过1亿部的Series 40手机平台存在严重缺陷：旧版J2ME中的缺陷使黑客能够远程访问本应受到限制的手机功能；Series 40中的缺陷使黑客能够秘密地安装和激活应用软件。Series 40是一款非常普及的手机平台，主要用于诺基亚的低端手机。这些问题给数量众多的手机用户造成潜在的重大威胁。

从上述案例中可以看到软件缺陷就在我们身边，它普遍存在，并将对产品造成不同程度的危害，甚至对用户的使用产生灾难性的影响。

1.1.2 软件缺陷的定义

对于软件存在的各种问题，在软件工程或软件测试中都可以称为软件缺陷或软件故障。作为软件测试员，可能发现的缺陷大多数都不如上面所列举的实例那么明显，而软件测试员的任务就是要发现软件中所隐藏的错误，其中的一些简单而细微的错误，很难做到真正区分哪些是真正的错误，哪些不是，这对于软件测试员是一个最大的挑战。

软件缺陷即计算机系统或程序中存在的任何一种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷、瑕疵。缺陷会导致软件产品在某种程度上不能满足用户的需要。对于软件缺陷的精确定义，通常有以下5条描述：

① 软件未达到产品说明书要求的功能。

② 软件出现了产品说明书指明不会出现的错误。

③ 软件功能超出了产品说明书规定的功能。

④ 软件未实现产品说明书虽未明确指出但应该实现的目标。

⑤ 软件难以理解，不易使用，运行缓慢或者最终用户认为使用效果不好。

为了更好地理解上述5条描述，我们以计算器软件为例进行说明。

计算器的产品说明书声明它能够准确无误地进行加、减、乘、除运算。当你拿到计算器后，按下“+”键，结果什么反应也没有，根据第①条规则，这是一个缺陷。假如得到错误答案，根据第①条规则，这同样是一个缺陷。

若产品说明书声明计算器永远不会崩溃、锁死或者停止反应，当你任意敲键盘时，计算器停止接受输入，根据第②条规则，这是一个缺陷。

若用计算器进行测试，发现除了加、减、乘、除之外它还可以求平方根，说明书中从没提到这一功能，根据第③条规则，这是软件缺陷。软件实现了产品说明书未提到的功能。

若在测试计算器时，发现电池没电会导致计算不正确，但产品说明书未指出这个问题。根据第④条规则，这是个缺陷。

第⑤条规则是全面的。如果软件测试员发现某些地方不对劲，无论什么原因，都要认定为缺陷。如“=”键布置的位置极其不好按；在明亮光下显示屏难以看清。根据第⑤条规则，这些都是缺陷。

1.1.3 软件缺陷产生的原因

在软件开发的过程中，软件缺陷的产生是不可避免的。造成软件缺陷的原因有哪些?我们可以从软件本身、团队工作和技术问题等多个方面分析，将造成软件缺陷的原因归纳如下。

1.软件本身

◇ 文档错误、内容不正确或拼写错误。

◇ 数据考虑不周全引起强度或负载问题。

◇ 对边界考虑不够周全，漏掉某几个边界条件造成的错误。

◇ 对一些实时应用系统，保证精确的时间同步，否则容易引起时间上不协调、不一致性带来的问题。

◇ 没有考虑系统崩溃后在系统安全性、可靠性方面的隐患。

◇ 硬件或系统软件上存在的错误。

◇ 软件开发标准或过程上的错误。

2.团队工作

◇ 系统分析时对客户的需求不是十分清楚，或者和用户的沟通存在一些困难。

◇ 不同阶段的开发人员相互理解不一致，软件设计对需求分析结果的理解偏差，编程人员对系统设计规格说明书中某些内容重视不够，或存在着误解。

◇ 设计或编程上的一些假定或依赖性，没有得到充分沟通。

3.技术问题

◇ 算法错误。

◇ 语法错误。

◇ 计算的精度问题。

◇ 系统结构不合理，造成系统性能问题。

◇ 接口参数不匹配，导致模块集成出现问题。

软件缺陷是由很多原因造成的，将诸多原因如规格说明书、系统设计结果、编程的代码等归类起来比较后发现，规格说明书是软件缺陷出现最多的地方，如图1-1所示。

图1-1 软件缺陷构成图

软件产品规格说明书为什么是软件缺陷存在最多的地方?主要原因有以下几种：

◇ 由于软件产品还没有设计、开发，完全靠想象去描述系统的实现结果，所以有些特性还不够清晰。

◇ 用户一般是非计算机专业人员，软件开发人员和用户的沟通存在较大困难，对要开发的产品功能理解不一致。

◇ 需求变化的不一致性。用户的需求总是在不断变化的，这些变化如果没有在产品规格说明书中得到正确的描述，容易引起前后文、上下文的矛盾。

◇ 对规格说明书不够重视，在规格说明书的设计和写作上投入的人力、时间不足。

◇ 没有在整个开发队伍中进行充分沟通，有时只有设计师或项目经理得到比较多的信息。

1.1.4 软件缺陷的修复费用

软件通常要靠有计划、有条理的开发过程来实现。从开始到计划、编程、测试，到公开使用的过程中，都有可能发现软件缺陷。软件缺陷造成的修复费用随着时间的推移呈指数级地增长。当早期编写产品说明书时发现并修复缺陷，费用可能只要 10 美元甚至更少。同样的缺陷如果直到软件编写完成开始测试时才发现，费用可能要100～1 000美元。如果是客户发现的，费用可能达到数千甚至数百万美元。图1-2所示为软件缺陷在不同阶段发现时错误修正后的费用情况。

图1-2 软件缺陷在不同阶段发现时错误修复的费用

以前面的迪士尼狮子王软件为例，它的问题的根本原因是软件无法在流行的家庭PC平台上运行。假如早在编写产品说明书时，有人已经研究过在普通家庭用什么型号的PC，并且明确指出软件需要在该种配置上设计和测试，付出的代价小得几乎可以忽略不计。如果没有这样做，可以补救的措施是，软件测试员去搜集家庭流行PC样机并在其上验证。他们会发现软件缺陷，但是修复费用要高得多，因为软件必须调试、修改、再测试。开发小组还应当把软件的初期版本分发给一小部分客户试用进行Beta测试，那些被挑选出来代表庞大市场的客户可能会发现问题。然而实际的情况却是这个缺陷被完全忽视，根本没有进行这方面的测试，直到成千上万的光盘被压制和销售出去。迪士尼公司最终支付了客户投诉电话费、产品召回、更换光盘，以及又一轮调试、修改和测试的费用，付出了昂贵的代价。如果严重的软件缺陷保留到了客户那里，就足以耗尽整个产品的利润。

1.2 软件测试

1.软件测试的定义

人们对于软件测试的目的可能会存在着这样的认识：软件测试是为了证明程序是正确的。实际上，这种认识是错误的。因为如果表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案，也不会主动去检测、排除程序中可能存在的一些隐患。显然，这样的测试对于发现程序中的错误，完善和提高软件的质量作用不大。事实上程序在实际运行中会遇到各种各样的问题，而这些问题可能是我们在设计软件时没有考虑到的，所以在设计测试方案时，就应该尽量让它能发现程序中的错误，从而在软件投入运行之前就将这些错误改正，最终把一个高质量的软件系统交给用户使用。

通常对软件测试的定义有如下描述：软件测试是为了发现程序中的错误而执行程序的过程。具体来说，它是根据软件开发各阶段的规格说明和程序的内部结构而精心设计出一批测试用例，并利用测试用例来运行程序，以发现程序错误的过程。

正确认识测试的目的是十分有必要的，只有这样，才能设计出最能暴露错误的测试方案。此外，应该认识到：测试只能证明程序中错误的存在，但不能证明程序中没有错误。因为即使经过了最严格的测试之后，仍然可能还有没被发现的错误存在于程序中，所以说测试只能查出程序中的错误，但不能证明程序没有错误。

测试是程序的执行过程，目的在于发现错误，而不是证明程序的正确性。一个好的测试用例在于可以发现还未曾发现的错误。一个成功的测试是发现了至今还没有发现的错误。

2.软件测试的原则

各种统计数据显示，软件开发过程中发现缺陷的时间越晚，修复它所花费的成本就越大，因此在需求分析阶段就应当有测试的介入。因为软件测试的对象不仅仅是程序编码，应当对软件开发过程中产生的所有产品都进行测试。这就像造房屋一样，我们只有对房屋设计蓝图进行仔细审查后，才能进行施工。

软件测试的目标是想以最少的时间和人力找出软件中潜在的各种错误和缺陷。如果成功地实施了测试，就能够发现软件中的错误。

根据这样的测试目的，软件测试的原则应该是：

◇ 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。软件项目一启动，软件测试也就开始了，而不是等程序写完，才开始进行测试。

◇ 测试用例应包括测试输入数据和与之对应的预期输出结果这两部分。只有对测试输入数据给出预期的输出结果，才会有一个检验实测结果的基准，而不会把一个似是而非的错误结果当成正确结果。

◇ 程序员应避免检查自己的程序。如果由别人来测试程序员编写的程序，可能会更客观、更有效、更容易取得成功。

◇ 设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

合理的输入条件是指能验证程序正确的输入条件，而不合理的输入条件是指异常的、临界的、可能引起问题变异的输入条件。因此，软件系统处理非法命令的能力也必须在测试时受到检验。用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发现更多的错误。

◇ 充分注意测试中的群集现象。对发现错误较多的程序段，应进行更深入的测试。

◇ 严格执行测试计划，排除测试的随意性。对于测试计划，要明确规定，不要随意解释。

◇ 应当对每一个测试结果做全面检查。这是一条最明显的原则，但常常被忽视。必须对预期的输出结果明确定义，对实测的结果仔细分析检查，抓住关键，暴露错误。

妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。

1.3 软件测试的复杂性与经济性分析

人们通常认为软件工程中程序的开发是一个复杂而困难的过程，需要投入大量的人力、物力和时间，而测试程序则比较容易，不需要花费太多的精力，并且通过测试可以找到所有的软件故障。这其实是人们对软件开发过程理解上的一个误区。在实际的软件开发过程中，软件测试作为现代软件开发工业的一个非常重要的组成部分，正扮演着越来越重要的角色。随着软件规模的不断扩大，如何在有限的条件下对被开发的软件进行有效的测试已经成为软件工程中一个非常关键的课题。

1.3.1 软件测试的复杂性

软件测试是一项细致并且需要具备高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。针对下面几个问题的分析充分说明了软件测试的复杂性。

1.不可能对程序实现完全测试

完全测试是不现实的，在实际的软件测试工作中，由于测试的数量极其巨大，不论采用什么方法，都不可能进行完全的测试。所谓完全的测试，就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。穷举测试会引起以下几种问题：

◇ 测试所需要的输入量太大。

◇ 测试的输出结果太多。

◇ 软件执行路径太多。

◇ 软件的规格说明书存在主观性，没有一个客观的标准，从不同的角度来评判，软件缺陷的标准是不同的。

由于以上问题的存在，使得在大多数的软件测试过程中，穷举测试几乎是不可能的。以Windows 系统中最简单的计算器程序为例，假如要对它进行穷举测试，首先进行加法的测试，那就要输入1+0=，1+1=，1+2=，…，计算器能处理的数字是32位，所以要一直输入到1+99 999…99 999（共32个9）=。接下来，继续输入2+0=，2+1=，2+2=，…，直到输入2+99 999…99 999（共32个9）=。依次类推，加法的输入还在继续……

在软件的使用过程中，人们不仅要进行合法的输入，若出现某些意外情况，可能还要发生种种不合法的输入。所以测试人员既要测试所有合法的输入，还要对那些不合法但是可能的输入进行测试。比如，在测试加法计算时输入：1+a，jpkl+o9，jsfw+16，…，这样的测试情况可能出现无穷多个。

按照上述思路一个一个的测试，单是合法输入就接近无穷多个，使得在理论上根本无法进行穷举测试。在实际的使用过程中，测试人员还要考虑到包括随机出现的各种突发情况，比如用户不小心撞到键盘引起某个误操作。Glenford J.Myers在1979年描述了一个只包含loop循环和if语句的简单程序，可以使用不同的语言将其写成20行左右的代码，但是这样简短的语句却有着十万亿条路径。面对这样一个庞大的数字，即便是一个有经验的优秀的软件测试员也需要十亿年才能完成全部测试，而且在实际应用中，此类程序是非常有可能出现的。

E.W.Dijkstra的一句名言对测试的不彻底性作了很好的注解：“程序测试只能证明错误的存在，但不能证明错误的不存在”。由于穷举测试工作量太大，实践上行不通，这就注定了一切实际测试都是不彻底的，也就不能够保证被测试程序在理论上不存在遗留的错误。

2.杀虫剂现象

软件中存在的故障现象与发现的故障数量成正比。1990年，BorisBeizer在其编著的“Software Testing Techniques”（第二版）中提到了“杀虫剂怪事”一词，同一种测试工具或方法用于测试同一类软件越多，则被测试软件对测试的免疫力就越强。这与农药杀虫是一样的，老用一种农药，则害虫就有了免疫力，农药就失去了作用。

在现实当中，往往是发现了一个故障以后，很可能会接二连三地发现更多的软件故障。有这样一个现象值得我们去重视：47%的软件故障（是由用户发现的）是与系统中的4%的程序模块有关。因此，经测试后的程序中隐藏的故障数目与该程序中发现的故障数目成正比。

产生杀虫剂现象的可能原因是由于开发过程中各种各样的主客观因素，再加上不可预见的突发性事件，软件测试员采用同一种测试方法或者工具不可能检测出所有的缺陷。为了克服被测试软件的免疫力，软件测试员必须不断编写新的测试程序，对程序的各个部分进行不断测试，以避免被测试软件对单一的测试程序具有免疫力而使软件缺陷不被发现。

因此，根据经验，我们应当对故障集中的程序模块进行重点测试，越是问题多的模块，越是要花更多的时间和代价来测试，以此会达到更好的测试效果。

3.软件测试的代价

穷举测试的不可行性使得大多数软件在进行测试的时候只能采取非穷举测试。如果一个软件不能做到穷举测试，这就意味着它是有风险的。

软件中有些缺陷必须经过特定的路径才会被测试发现，不使用穷举测试是很难发现的，这些故障很有可能在使用时被用户发现。如果程序中隐藏的故障在软件投入市场时才被发现，则修复代价就会非常高。这就会产生一个矛盾：软件测试员不能做到完全的测试，不完全测试又不能证明软件的百分之百的可靠。那么如何在这两者的矛盾中找到一个相对的平衡点呢?

我们可以从图1-3所示的最优测试量示意图得到答案，当软件缺陷降低到某一数值后，随着测试量的不断上升软件缺陷并没有明显地下降。这是软件测试工作中需要注意的重要问题。如何把测试数据量巨大的软件测试减少到可以控制的范围，以及如何针对风险做出最明智的选择是软件测试人员必须把握的关键问题。

图1-3 最优测试量

图1-3所示的最优测试量示意图说明了软件故障缺陷数量和测试工作量之间的关系，随着测试工作量的增加，测试成本将呈几何数级上升，而软件缺陷数量降低到某一数值之后将没有明显的变化，最优测量值就是这两条曲线的交点。如何找到最优测试点，掌握好测试工作量是至关重要的。一位有经验的软件管理人员在谈到软件测试时曾这样说过：“不充分的测试是愚蠢的，而过度的测试是一种罪孽”。测试不足意味着让用户承担隐藏错误带来的危险，过度测试则会浪费许多宝贵的资源。

对于软件测试数据量巨大的问题没有十全十美的解决办法，采取最优测试量只是在两者中的一种妥协。然而糟糕的是矛盾还不止于此，在当今竞争激烈的市场里，争取时间可能是制胜的关键，这本身就使软件的开发与测试出现矛盾。使情况更加复杂的是，当一种新的技术或者新的标准出现时，可能人们会对软件是否十全十美并不在意了。在这种情况下，要进行多长时间的测试就更是一个值得商榷的问题。

4.不能修复所有的软件故障

在软件测试中还有一个严峻的现实：即使花再多的时间和代价，也不能够使所有的软件故障都得到修复。但这并不能说明测试就是失败的，在实际操作过程中，测试人员要进行正确的判断，合理的取舍，根据风险分析来决定哪些故障需要修复，哪些故障可以不修复，即并不是所有的软件缺陷都需要被修复。

当确定是软件缺陷时，若出现以下情况，软件缺陷就不需要被修复。

◇ 不会引起大的问题。为了防止整个系统由于局部修复而出现某些问题，在特殊情况下，不常出现的小问题可以暂时忽略。

◇ 修复所冒的风险太大。由于软件本身各个模块之间有着千丝万缕的联系，使得单一修复某一段代码可能会产生更多的大量未知故障，所以在某些情况下不修复反而是最保险的做法。

◇

....