软件质量保证与测试（慕课版）（第2版）-课件 第 1 章 绪论

软件质量保证与测试1.1

软件质量保证与测试的产生与发展第1章绪论SoftwareQualityAssuranceandTesting产生与发展的过程1957测试=调试

197219751980’198319731979软件测试是伴随着软件的产生而产生的。早期的软件规模小、复杂程度低，软件开发的过程相当随意，开发人员将软件测试等同于“调试”，常常由开发人员自己完成这部分工作。总体而言，跟软件测试相关的工作投入极少，测试工作介入也晚，常常是等到代码编写出来，产品已经基本完成时才进行测试。1957测试=调试

测试≠调试

197219751980’198319731979

直到1957年，软件测试才开始与调试区别开来，成为一种专门致力于发现软件缺陷的活动。

由于当时人们对软件测试的目的理解为“使自己确信产品能工作”，所以软件测试通常在程序代码编写之后进行。产生与发展的过程1957测试=调试

测试≠调试

197219751980’198319731979

当时也缺乏有效的测试方法，主要依靠“错误推测ErrorGuessing”来寻找软件中的缺陷。

因此，大量软件交付后，仍存在很多问题，软件产品的质量无法保证。产生与发展的过程第一次软件测试会议1957测试=调试

测试≠调试

197219751980’198319731979

1972年，软件测试领域的先驱BillHetzel（比尔黑则尔）博士在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的会议。产生与发展的过程第一类方法第一次软件测试会议1957测试=调试

测试≠调试

197219751980’198319731979产生与发展的过程

1973年，他首先给软件测试一个这样的定义：“就是建立一种信心，认为程序能够按预期的设想运行”。第一类方法第一次软件测试会议1957测试=调试

测试≠调试

197219751980’198319731979产生与发展的过程

核心观点：软件测试是试图验证软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的。

这是以正向思维方式，针对软件系统的所有功能点，逐个验证其正确性。被称为第一类方法。第一类方法第一次软件测试会议1957测试=调试

测试≠调试

19721975软件测试研究方向1980’198319731979产生与发展的过程

1975年约翰·古迪纳夫和苏珊·格哈特在IEEE上发表了“测试数据选择的原理”一文，软件测试才被确定为一种研究方向。

产生与发展的过程

第一类方法受到很多业界权威的质疑和挑战，代表人物是GlenfordJ.Myers（格伦福德·迈尔斯）。

1979年，他发表的代表性论著《软件测试艺术》可算是软件测试领域的第一本最重要的专著。软件测试第一类方法：验证软件是“工作的”产生与发展的过程软件测试第一类方法：验证软件是“工作的”

他认为测试不应该着眼于验证软件是工作的，而应该首先认为软件是有错误的，然后用逆向思维去发现软件中尽可能多的错误。

他还从人的心理学的角度论证，如果将“验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。产生与发展的过程

GlenfordJ.Myers（格伦福德·迈尔斯）于1979年提出了他对软件测试的定义：“测试是为发现错误而执行一个程序或者系统的过程”。Myers还给出了与测试相关的三个重要观点，那就是：1、测试是为了证明程序有错，而不是证明程序无错误；2、一个好的测试用例是在于它能发现至今未发现的错误；3、一个成功的测试是发现了至今未发现的错误的测试。第一类方法第一次软件测试会议1957测试=调试

测试≠调试

19721975软件测试研究方向1980’198319731979第二类方法产生与发展的过程

这就是软件测试的第二类方法，简单地说就是测试是验证软件是“不工作的”，或者说是有错误的。

Myers认为，一个成功的测试必须是发现Bug的测试，不然就没有价值。产生与发展的过程

到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成。软件测试定义发生了改变，测试不单纯是一个发现错误的过程。还有什么?质量测度!第一类方法“质量”的概念融入软件测试

第一次软件测试会议1957测试=调试

测试≠调试

19721975软件测试研究方向1980’198319731979第二类方法产生与发展的过程

人们将“质量”的概念融入其中，而且将测试作为软件质量保证的主要职能，包含软件质量评价的内容。第一类方法“质量”的概念融入软件测试

第一次软件测试会议1957测试=调试

测试≠调试

19721975软件测试研究方向1980’1983IEEE对软件测试的定义

19731979第二类方法产生与发展的过程

1983年IEEE提出的定义：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。第一类方法“质量”的概念融入软件测试

第一次软件测试会议1957测试=调试

测试≠调试

19721975软件测试研究方向1980’1983IEEE对软件测试的定义

软件质量保证与测试19731979第二类方法产生与发展的过程

软件测试总的来说是一种事后检查的方法，如果软件研发前期工作做得不好，完全依赖测试很难保障软件产品的质量，鉴于此，结合事先预防，过程监督和事后检查的软件质量保证就应运而生。产生与发展的过程类比：测试——>质量保证与测试

毕业时考一次——>日常督查与学期考试课堂提问第一类测试方法与第二类测试方法的本质区别体现在：执行测试的人员不同执行测试的时间不同执行测试的目的不同执行测试的效果不同为了全面保证软件质量调试软件测试(第一类方法)软件测试(第二类方法)软件质量保证与测试测试是为确信产品能工作测试是为了发现错误测试等同于“调试”观念变化的过程使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。软件测试软件质量保证软件质量保证是为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动，它贯穿于整个软件过程。基本概念软件质量保证活动（1）识别软件质量需求，并将其自顶向下分解为可以度量和控制的质量要素，为软件质量的定性分析和定量度量奠定基础；（2）研究并选用软件开发方法和工具；（3）对软件生存周期各阶段进行正式技术评审；（4）制定并实施软件测试策略和测试计划；（5）及时生成软件文档并进行其版本控制；（6）建立软件质量要素的度量机制；（7）处理不合格项，跟踪问题；（8）监控软件过程和产品质量；（9）记录SQA的各项活动，并生成各种SQA报告。软件质量保证与测试软件质量保证与测试质量保证人员开发人员测试人员检查评审测试......

软件测试是软件质量保证中重要的一项活动，但软件质量保证不仅仅包括软件测试，还包括检查、评审等其他很多活动。

软件质量保证也不仅仅只是测试人员的工作，它需要专职的软件质量保证人员，也需要软件开发人员参与相关工作。1.1

软件质量保证与测试的产生与发展本节内容就讲到这里，谢谢，再见！软件质量保证与测试1.2软件缺陷、软件错误、软件故障第1章绪论SoftwareQualityAssuranceandTestingGraceHopper

第一个Bug

软件缺陷（Defect），常常又被叫做Bug。Bug一词的原意是“臭虫”或“虫子”，这是怎么回事呢？

1945年9月9日，下午三点。美国海军编程员、编译器的发明者格蕾斯·哈珀（GraceHopper）哈珀正领着她的小组构造一个称为“马克二型”的计算机。第一个Bug

这还不是一个真正的电子计算机，它使用了大量的继电器，一种电子机械装置。

第二次世界大战还没有结束。

哈珀的小组夜以继日地工作。机房是一间第一次世界大战时建造的老建筑。那是一个炎热的夏天，房间没有空调，所有窗户都敞开散热。突然，马克二型死机了。第一个bug

技术人员试了很多办法，最后定位到第70号继电器出错。哈珀观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用摄子将蛾子夹出来，用透明胶布帖到工作日志中，并注明“第一个发现虫子的实例”。于是后来，bug一词成了计算机领域的专业术语，比喻那些系统中的缺陷或问题。

缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。软件缺陷的概念软件出现了产品说明书指明不会出现的错误软件未达到产品说明书的功能软件功能超出产品说明书指明范围软件未达到产品说明书虽未指出但应达到的目标软件难以理解、不易使用、运行速度缓慢，最终用户认为不好软件缺陷的外在表现软件缺陷的多种情况SoftS0t’软件产品要求

实际软件

SoftS0t’1错误软件缺陷的多种情况软件产品要求

实际软件

SoftS0t’2缺少1错误软件产品要求

实际软件

软件缺陷的多种情况SoftS0t’2缺少1错误3多余软件产品要求

实际软件

软件缺陷的多种情况SoftS0t’2缺少1错误3多余4未指出但应有软件产品要求

实际软件

软件缺陷的多种情况SoftS0t’2缺少1错误3多余4未指出但应有5用户不满意！软件产品要求

实际软件

软件缺陷的多种情况课堂提问：下列那种不属于软件缺陷：A.银行POS机在用户取款时翻倍吐钱，取100，吐200B.计算机病毒发作，屏幕出现熊猫烧香画面C.网上售票软件反应迟钝，用户难以正常买票D.某软件在进行修改升级之后，原来正常的功能现在出错了软件缺陷的多种情况软件缺陷产生的原因软件自身的特点团队合作设计和实现问题管理问题

软件缺陷的产生，主要是由软件产品的特点和开发过程决定的。那么造成软件缺陷的主要原因有哪些？下面从软件自身的特点、团队工作和技术问题等角度来分析软件缺陷产生的原因。软件缺陷产生的原因软件自身的特点1.软件本身的实际需求不清晰，导致设计目标偏离实际需求，从而引起功能或产品特征上的缺陷。案例：某网上售票系统，一开始把系统的同时在线购票用户数量定位在十万数量级，但在实际应用中，同时在线购票用户数量可能会达到百万甚至千万数量级，这样就会引起负载或强度问题。系统过载会导致性能下降，而如果负载超过其强度极限，则可能会彻底瘫痪或崩溃。软件缺陷产生的原因软件自身的特点2.系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。如庞大的ERP系统，数字化校园系统等。3.对一些实时应用，需要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调、不一致所带来的问题。软件缺陷产生的原因软件自身的特点4.系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题。案例：手机APP；美国迪斯尼公司狮子王游戏软件兼容性问题软件缺陷产生的原因软件自身的特点5.由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。例如：网银。软件缺陷产生的原因团队合作1.系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。2.不同阶段的开发人员相互理解不一致。例如，软件设计人员对需求分析的理解有偏差，编程人员对系统设计规格说明书某些内容重视不够，或存在误解。3.对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。4.项目组成员技术水平参差不齐，新员工较多，或培训不够等原因也容易引起问题。软件缺陷产生的原因设计和实现问题1.系统结构设计不合理、算法选择不科学，造成系统性能低下。2.没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。3.对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。软件缺陷产生的原因设计和实现问题4.算法错误：在给定条件下没能给出正确或准确的结果。5.语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，只能在测试运行时发现。6.计算和精度问题：计算的结果没有满足所需要的精度。7.接口参数传递不匹配，导致模块集成出现问题。软件缺陷产生的原因管理问题1.缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试、等时间，遗留的缺陷会比较多。2.开发流程不够完善和规范，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。例如对需求变化、设计更改、代码修正等因素缺乏严格规范的管理机制，导致开发过程难以稳步推进。软件缺陷产生的原因管理问题3.开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误。4.文档不完善，风险估计不足等PIE模型

在试图发现软件缺陷的而执行软件的动态测试工作中有一些复杂而有趣的现象。假设某一个程序中有一个存在缺陷的代码行，在该软件的某次执行中，这个存在缺陷的代码行并不一定会被执行到；就算是这个存在缺陷的代码行被执行到了，只要没有达到某个特定的条件，程序也并不会出错；只有执行错误代码，达到某个特定的条件，程序的错误状态表现出来后被感知，才能发现程序中的缺陷。几个相关概念

软件测试中的PIE模型可以区分这些不同的现象，并明确了这些现象的转化条件。先来明确几个概念。缺陷Fault：

指静态存在于程序中的错误代码行。错误Error：

指执行错误代码后导致的内部错误状态。此时若无适当措施(容错)加以及时处理，便产生软件失败。失败Failure：

指错误状态传播到软件外部被外部感知。错误缺陷失败外部内部缺陷Fault、错误Error和失败FailurePIE模型

PIE模型告诉我们，就算一个程序中有缺陷，但要通过动态测试观察到这一缺陷的外部表现，还需要三个必要的条件：1、程序执行路径必须通过错误的代码（Execution-执行）;2、在执行错误代码的时候必须符合某个或者某些特定条件，从而触发出错误的中间状态（Infection-感染）；3、错误的中间状态必须传播到最后输出，使得观测到输出结果与预期结果不一致（Propagation-传播）。缺陷错误符合特定条件的输入执行存在缺陷的代码行失败ExecutionInfectionPropagationPIE模型程序PIE模型对某个软件进行软件测试时：包含缺陷Fault的代码可能没有被执行到；测试执行到了包含缺陷Fault的代码，但由于不满足特定的输入条件，不一定会产生错误的中间状态error；产生了错误的中间状态，但没有传播到最后输出，我们从外部没有发现问题。以上情况都会导致测试工作不充分，发现不了软件中存在的缺陷！类比：体检PIE模型：代码示例publicstaticvoidMY_AVG(int[]numbers){intlength=numbers.length;doubleV_avg,V_sum;V_avg=0.0; V_sum=0.0; for(inti=1;i<length;i++){V_sum+=numbers[i];}if(length!=0){V_avg=V_sum/(double)length;} System.out.println("V_avg:"+V_avg);}代码有问题吗？PIE模型：示例publicstaticvoidMY_AVG(int[]numbers){intlength=numbers.length;doubleV_avg,V_sum;V_avg=0.0; V_sum=0.0; for(inti=1;i<length;i++)//缺陷Fault{V_sum+=numbers[i];}if(length!=0){V_avg=V_sum/(double)length;} System.out.println("V_avg:"+V_avg);}情况1：没有对MY_AVG的调用，缺陷代码没有被执行到。publicstaticvoidMY_AVG(int[]numbers){intlength=numbers.length;doubleV_avg,V_sum;V_avg=0.0; V_sum=0.0; for(inti=1;i<length;i++){V_sum+=numbers[i];}if(length!=0){V_avg=V_sum/(double)length;} System.out.println("V_avg:"+V_avg);}PIE模型：示例publicstaticvoidMY_AVG(int[]numbers){intlength=numbers.length;doubleV_avg,V_sum;V_avg=0.0; V_sum=0.0; for(inti=1;i<length;i++){V_sum+=numbers[i];}if(length!=0){V_avg=V_sum/(double)length;} System.out.println("V_avg:"+V_avg);}PIE模型：示例情况2：numbers[]={}，此时虽然执行到了包含缺陷Fault的代码行，但不会产生错误Error。publicstaticvoidMY_AVG(int[]numbers){intlength=numbers.length;doubleV_avg,V_sum;V_avg=0.0; V_sum=0.0; for(inti=1;i<length;i++){V_sum+=numbers[i];}if(length!=0){V_avg=V_sum/(double)length;} System.out.println("V_avg:"+V_avg);}PIE模型：示例情况3：numbers[]={0,2,4}，输出结果为2，预期正确结果也为2，有Error(逻辑上第一个数没有加进去)，但观察不到Failure。publicstaticvoidMY_AVG(int[]numbers){intlength=numbers.length;doubleV_avg,V_sum;V_avg=0.0; V_sum=0.0; for(inti=1;i<length;i++){V_sum+=numbers[i];}if(length!=0){V_avg=V_sum/(double)length;} System.out.println("V_avg:"+V_avg);}PIE模型：示例情况4：numbers[]={3,4,5}，输出结果为3，预期正确结果为4，有Error，也发生了Failure。//测试的四种情况//情况1：未调用MY_AVGpublicstaticvoidmain(String[]args){//情况2：

int

numbers[]={};//情况3：intnumbers[]={0,2,4};//情况4：intnumbers[]={3,4,5}; MY_AVG(numbers); }PIE模型：示例错误ErrorPIE模型剖析缺陷Fault程序未发现错误情况1情况2失败Failure缺陷Fault程序未发现错误××情况3失败Failure缺陷Fault程序未发现错误×情况4失败Failure缺陷Fault程序发现错误错误Error错误Error不看源代码，通过执行软件，能够发现的问题只有PIE模型中外部层面的软件失败Failure，也就是表现出来的问题。程序中处于内部静态层次的缺陷Fault，和内部中间状态层次的错误Error，是难以通过执行软件来直接检测出来的。PIE模型缺陷Fault失败Failure测试设计测试设计要做的重要工作之一，就是如何恰当的设计测试数据，使得可能存在的软件缺陷Fault，通过程序执行都尽可能的产生失败Failure并被外部观察到。测试设计本节内容就讲到这里，谢谢，再见！1.2软件缺陷、软件错误、软件故障软件质量保证与测试1.3软件质量保证与测试的意义、原则和挑战第1章绪论SoftwareQualityAssuranceandTesting65软件数量越来越多

以App为例，工业和信息化部公布2018年我国市场上监测到的App数量净增42万款，总量达到449万款。软件规模越来越大KB→MB→GB

航天飞机控制软件有4000万行代码，空间站控制软件有10亿行代码。

软件发展的特点和软件质量保证与测试的关系缺陷与代码量正相关！软件复杂度越来越高，使得缺陷产生的概率增大196219972016软件发展的特点和软件质量保证与测试的关系67软件应用越来越广泛和深入，而新研发的软件往往缺陷较多软件发展的特点和软件质量保证与测试的关系社会对软件的质量要求越来越高68

软件在事关国计民生的重要领域的应用，使得社会对软件的质量要求越来越高，软件的质量风险越来越大。软件发展的特点和软件质量保证与测试的关系软件质量保证与测试的重要性事关国计民生的重要软件，没有严格的质量控制，不经过充分测试，就投入使用，可能造成恶性事故！

软件质量保证与软件测试已成为一项专业化要求越来越高的工作，需要采用专门的方法和技术，需要借助各种专业化的工具，需要专业人才甚至是专家来承担。软件缺陷导致的事故案例1.

美国爱国者导弹防御系统失效。2.

美国航天局火星登陆事故3.致命的辐射治疗仪1.爱国者导弹防御系统失效海湾战争中，1991年2月25日，一枚伊拉克飞毛腿导弹击中了沙特阿拉伯载赫蓝的一个军营，炸死了美国陆军的28名士兵，美国的爱国者导弹防御系统未能拦截。政府调查指出，拦截失败归咎于导弹控制软件系统中的一个时钟误差。软件缺陷导致的事故案例2.美国航天局火星登陆事故

1992年2月3日，美国航天局的火星极地登陆飞船在试图登陆火星表面时逆向推进器意外关闭，飞船坠毁。

这一事故的后果非常严重，损失巨大，而起因却是控制软件设计中的缺陷。事后分析测试发现，当飞船的支撑腿迅速打开准备着陆时，机械震动很容易触发着地触电开关，关闭登陆逆向推进器。软件缺陷导致的事故案例3.致命的辐射治疗仪

20世纪80年代中期，Therac-25放射治疗仪在美国和加拿大发生了多次医疗事故，5名患者治疗后死亡，其余患者则受到了超剂量辐射被严重灼伤。

Therac-25放射治疗仪的事故是由操作失误、软件缺陷和系统设计共同造成的。软件缺陷导致的事故案例软件质量保证与测试的意义及早发现问题、解决问题，降低返工和修复缺陷的成本防止事故，降低失效成本保证软件产品达到一定的质量标准对软件质量进行客观评价提高软件产品质量、满足用户需求软件质量保证与测试的意义软件质量成本=预防成本+评估成本+失败成本制定质量保证计划

制

定

质

量

标

准

组

织

人

员

培

训……

评审

测试……

修复缺陷

赔偿损失……$改正一个错误的相对成本需求分析设计编码系统测试实际使用1倍3-6倍10倍15-40倍30-70倍40-1000倍开发测试需求分析概要设计程序编码案例详细设计5行文字3页设计文档20页设计文档5000行程序代码改正一个错误的相对成本学习软件质量保证与测试并不是只有将来专门从事软件质量保证与测试工作的人员，才需要学习软件质量保证与测试。所有参与软件项目的人都应当树立软件质量保证与测试的理念。开发人员也必须学习和掌握软件质量保证与测试的基本知识、方法、技术和工具。一般而言软件开发人员需要对自己所开发的软件完成基本的测试，只有懂测试的开发人员才能开发出高质量的软件，软件质量保证与测试的理念、知识和能力是对软件开发工程师的一项基本要求。软件质量保证与测试要贯穿于整个软件生存期软件质量保证与测试要预防为主，发现为辅软件质量保证与测试需要客观性软件质量保证与测试需要独立性软件质量保证与测试的最终标准都应追溯到用户需求软件质量保证与测试应妥善保存一切过程文档软件质量保证与测试的基本原则穷尽测试是不可能的，应当进行测试设计，选择测试数据。设计测试用例时，应该考虑各种情况，包括异常情况。应当把尽早和不断的测试作为座右铭。对测试发现的错误结果一定要有一个确认的过程。测试规格要求应追溯到用户需求。应充分注意问题群集现象。制定并严格执行测试计划，排除测试的随意性。通过测试的软件并不意味着没有任何缺陷。测试必须考虑成本和效益，测试需要适时终止。保存一切测试过程文档。软件测试的技术原则穷尽测试是不可能的有一个软件，输入两个数：A、B，输出：C=A+B如果要把所有可能的输入都测试一次，则：每个数的取值个数：232(按照32位2进制数来估算)A+B所有可能的情况：232x232=264约等于1020如果某台计算机完成一次加法运算需要1纳秒的时间，总共需要约3000年。不对软件做充分的测试是不负责任，而过度的测试也是一种严重浪费！软件测试的技术原则软件缺陷与测试成本曲线未发现的缺陷数测试成本测试不充分过度测试测试的程度软件质量保证与预测由专人负责，与开发人员无关高水平程序员编写的程序无需测试

测试是为了表明软件已正确地实现了用户的要求

测试通过的软件一定是没有缺陷的软件质量保证与测试浪费资源，拖累进度，没有必要关于软件质量保证与测试的一些错误认识软件质量保证与测试面临的挑战软件质量保证理念还没有深入人心理想状态：所有软件研发人员都把软件质量保证当成是一种自觉的约束(mentaldiscipline)实际情况：重产品轻质量；重开发轻测试；赶进度降成本。

软件测试技术发展滞后软件测试技术的发展也很快，但是其发展速度仍落后于软件开发技术的发展速度。软件质量保证与测试面临的挑战如何保证重要、关键软件不出问题这是一个挑战对于实时系统来说，缺乏有效的测试手段信息系统的安全性如何进行有效的测试与评估，是世界性的难题新的软件应用对软件质量保证与测试提出了新的挑战软件质量保证与测试面临的挑战软件的规模越来越大，产生的测试任务越来越繁重软件变得越来越复杂，质量保证难度在增大，如何进行充分而有效的测试成为了难题面向对象的测试技术才刚刚起步分布式系统整体性能还不能进行很好的测试请同学们通过自主拓展学习和深入思考，提出自己认为的软件测试面临的挑战！课外学习任务

搜集和整理软件缺陷、软件失败实例做成PPT，准备5分钟的交流演讲。本节内容就讲到这里，谢谢，再见！1.3软件质量保证与测试的意义、原则和挑战软件质量保证与测试1.4

质量意识、社会责任和工匠精神第1章绪论SoftwareQualityAssuranceandTesting一、质量意识

树立质量意识，控制软件过程，保证软件质量，提高用户对软件的满意度，对一个软件项目而言十分重要。1.质量意识强2.软件过程严3.软件质量好4.用户满意度高5.市场份额大6.产品收入多7.资金持续投入良性循环一、质量意识

反之，如果软件项目团队质量意识薄弱，研发的软件缺陷很多，则可能导致整个软件项目陷入泥潭，甚至以失败而告终。美国IBM公司1963年开始开发IBM360机的操作系统，这一系统共约有100万条指令，花费了5000人∙年，经费数亿美元，但软件缺陷多达2000个以上，系统根本无法正常运行。

项目负责人Brooks事后总结他在组织开发过程中的沉痛教训时说“…正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难……”。一、质量意识

软件项目质量成本的预防成本、评估成本和失败成本三个组成部分中，预防成本的总体变化范围较小。树立质量意识，科学合理的增加预防成本，可以较好的保证和提高软件质量，防止过高的评估成本，避免巨额的失败成本，从而能够在整体上降低软件质量成本。

预防成本+评估成本+失败成本=软件质量成本$合理增加防止过高避免过高整体上可降低一、质量意识

软件质量保证与测试相关工作人员要树立起牢固的质量意识，把质量意识、质量标准、和质量控制措施，落实到每一项具体工作中去，提高软件质量，降低总体质量成本，提升产品效益。二、社会责任

软件缺陷可能导致事故，造成人身安全和财产损失。尤其是那些事关国计民生的重要软件，没有严格的质量控制，不经过充分测试就投入使用，可能造成恶性事故，危害社会！1996年6月4日，欧洲阿丽亚娜5型火箭发射爆炸。研制费用为70亿美元，研制时间1985－1996年，参研人员约1万人。与阿丽亚娜5型火箭一同化为灰烬的还有4颗卫星。这是世界航天史上一大悲剧。二、社会责任

阿丽亚娜5型火箭延用了阿丽亚娜4型火箭初始定位软件，但这两种型号的火箭情况有所不同，阿丽亚娜5型火箭起飞加速度=21.5g，阿丽亚娜4型火箭起飞加速度=11.4g。

阿丽亚娜5型火箭加速度值在系统中产生上溢出，以加速度为参数的速度、位置均计算错误，导致惯性导航系统对火箭控制失效，控制程序只得进入异常处理模块，引爆自毁。二、社会责任

在软件质量保证与测试工作中，应当具有社会责任感，从以下几个方面肩负起自己的社会责任。(1)对自己承担的软件质量保证相关工作负责，以专业水平和技术能力服务社会、报效国家。(2)对自己的软件测试工作负责，让测试通过的软件质量过关、安全可靠，而不是遗留下类似于定时炸弹的软件缺陷和漏洞。(3)不利用自身的专业知识、技术能力，为制作病毒木马、入侵他人电脑、窃取机密信息等活动提供技术支持。(4)发现重大软件漏洞及时向我们国家的有关部门报告，维护公共利益和国家安全。三、工匠精神

一些软件项目测试任务十分复杂和繁重，需要精心设计大量的测试用例，重复执行这些测试用例，准确记录测试过程，耐心细致分析测试结果，来查找可能存在的软件缺陷。这样的测试任务，要求测试人员具有工匠精神，能够敬业、精益、专注，并能够在实践中创新，解决各种软件测试中的具体问题。三、工匠精神

据北京智能车联产业创新中心发布的2019年北京市自动驾驶路测报告，2019年各企业共有73辆无人驾驶汽车在进行测试，测试总里程达88.66万公里，其中百度的Apollo测试车达到52辆，测试总行驶里程75.4万公里。

这份报告是继美国加州车辆管理局发布《2019年自动驾驶脱离报告》之后出炉，也显示了在自动驾驶领域，中美两国的你追我赶。在国内大量自动驾驶测试数据的背后，可以看到测