软件测试的背景课件

第三章软件测试的实质主讲人：廖雪花《软件质量保证与测试》第三章软件测试的实质主讲人：廖雪花《软件质量保证与测试大纲3.1测试原则3.2测试术语定义3.3补充软件质量保证与测试区别与联系大纲3.1测试原则有真正完美的软件么？经过测试人员的努力，能够消除所有的软件缺陷么？如果做不到，我们该怎么办？有真正完美的软件么？3.1测试原则（特点）1、完全测试程序是不可能的左图是一个不超过100行的程序结构图，有大概100,000,000,000,000条可能的执行路径。以每秒执行1000个测试用例的速度计算，完成所有可能路径的测试大概需要3170年。白盒测试3.1测试原则（特点）1、完全测试程序是不可能的左图是一如果你打算测试下windows的计算器，只考虑整数的加法：x+yxyz在32位的计算机上运行，只考虑x，y是整数，不同的测试数据组合最大可能数目为：2的64方，以每秒执行1000个测试用例的速度计算，完成测试大概需要工作5亿年。黑盒测试如果你打算测试下windows的计算器，只考虑整数的加法无法进行完全测试的原因下面的各种情况，都可能导致问题的复杂化，或使软件留有隐患：输入量太大输出结果太多软件执行路径太多软件说明书本身就是主观的产物，可能不正确，也经常会变动。无法进行完全测试的原因下面的各种情况，都可能导致问题的复杂化无法进行完全测试的原因如果觉得某些测试条件是重复的、无必要的，或者为了节省空间，而将其剔除，那么采用的就是不完全测试。无法进行完全测试的原因如果觉得某些测试条件是重复的、无必要的2、软件测试是有风险的行为如果我们不去进行完全测试，必然会遗漏或放弃些什么，换句话说：我们是在冒险！我们究竟该怎么做才能将风险降低？关键思想：将数量巨大的可能测试减少到可以控制的范围，以及针对风险做出明智的选择，哪些测试不重要，哪些重要。缺陷数量测试量最优测试点测试费用漏掉的缺陷2、软件测试是有风险的行为如果我们不去进行完全测试，必然会遗2、软件测试是有风险的行为如果试图测试所有的情况，费用将大幅增加。软件缺陷漏掉的数量在到达某一点后没有显著变化。缺陷数量测试量最优测试点测试费用漏掉的缺陷关键任务：找到最优的测试量，使测试不多不少。2、软件测试是有风险的行为如果试图测试所有的情况，费用将大幅3、测试无法显示潜伏的软件缺陷测试不是为了证明软件是完善的，而是要尽量证明软件是有问题的！只能报告软件缺陷存在不能报告软件缺陷不存在3、测试无法显示潜伏的软件缺陷测试不是为了证明软件是完善的，4、找到的缺陷越多，说明软件缺陷越多软件缺陷就和生活中的害虫一样，发现一个，往往附近就可能会有一群！为什么会这样：程序员也有状态、心情不佳的时候人们总是习惯反复犯同样的错误缺陷往往是有关联的，一个错误往往导致更多的错误，而你可能只是发现了冰山的一角4、找到的缺陷越多，说明软件缺陷越多软件缺陷就和生活中的害虫5、杀虫剂现象：软件测试越多，免疫力越强难道软件也像生物一样能自动进化？其实指的是无论是项目组、程序员，还是测试人员，一般都有常规、固定的工作模式或习惯，容易产生盲点。回想一下螺旋模式，不断的重复改善：改变测试方法，改变测试重点5、杀虫剂现象：软件测试越多，免疫力越强难道软件也像生物一样6、并非所有的软件缺陷都需要修复即使测试中发现了问题，也并非所有缺陷都需要或能够得到修复没有足够的时间修复的风险不算真正的软件缺陷不值得修复到底是否进行修复，有时很难决断，从这个角度而言，我们是在冒险，有时后果很严重6、并非所有的软件缺陷都需要修复即使测试中发现了问题，也并非6、并非所有的软件缺陷都需要修复是否需要修复要归结为商业风险决策。决策过程通常由软件测试员、项目经理和程序员共同参与。他们站在各自的立场看待缺陷，对软件缺陷是否应该或不应该修复都有自己的观点和看法。后续章节将介绍如何报告软件缺陷，并使其他人知道。6、并非所有的软件缺陷都需要修复是否需要修复要归结为商业风险7、难以说清的软件缺陷没有人发现软件中存在的问题，该问题是缺陷吗？没有答案完美本身就没有固定的标准你脸上长个痣，有人觉得难看是缺陷，有人觉得那是美人痣。。。7、难以说清的软件缺陷没有人发现软件中存在的问题，该问题是缺（回顾）软件缺陷的定义产品说明书：是软件开发小组的一个协定。它对开发的产品进行定义，给出产品的细节、如何做、做什么、不能做什么。至少满足以下5个规则之一才称为软件缺陷：软件未实现产品说明书要求的功能。软件出现了产品说明书指明不应出现的错误。软件实现了产品说明书未提到的功能。软件未实现产品说明书虽未明确提及但应该实现的目标。软件难以理解、不易使用、运行缓慢或者从测试员的角度看最终用户会认为不好。（回顾）软件缺陷的定义产品说明书：是软件开发小组的一个协定。7、难以说清的软件缺陷尚未发现或未观察到的软件缺陷只能说是潜在缺陷。7、难以说清的软件缺陷尚未发现或未观察到的软件缺陷只能说是潜8、产品说明书不断变化，没有最终版本开发者的噩梦！软件测试人员必须要想到产品说明书可能改变。未曾计划测试的功能会增加，经过测试并报告软件缺陷的功能可能发生变化甚至被删除，这些都是有可能会发生的。8、产品说明书不断变化，没有最终版本9、软件测试员在产品小组中不受欢迎早点找出缺陷、控制情绪、不要总是报告坏消息10、软件测试是一项讲究条理的技术工作不再是随心所欲成为一个职业选择——需要训练和规范，而且有发展空间。9、软件测试员在产品小组中不受欢迎3.2软件测试的术语定义1、精确（precision）和准确（accuracy）不准确，不精确精确，不准确准确，不精确准确，精确3.2软件测试的术语定义1、精确（precision）和准1、精确（precision）和准确（accuracy）软件测试要精度还是准度很大程度上取决于产品是什么，最终取决于开发小组的目标。只有软件测试员清楚产品说明书，就可以量身定做测试程序来确认。1、精确（precision）和准确（accuracy）软件2、确认（verification）和验证（validation）确认：保证软件产品符合产品说明书的过程。验证：保证软件满足用户要求的过程。满足产品说明书未必满足实际需求哈勃太空望远镜的例子就是很典型的2、确认（verification）和验证（validati可靠性：软件运行稳定。质量：能够满足客户要求，包括价格、服务等。良好的可靠性并不代表良好的质量，可靠性仅仅是质量的一个方面。为了确保程序质量高而且可靠性强，软件测试员必须在整个产品开发过程中进行确认和验证。3、质量（quality）和可靠性（Reliability）可靠性：软件运行稳定。3、质量（quality）和可靠性（R4、测试（Testing）和

质量保证（QA:QualityAssurance）软件测试人员的职责是尽可能早的发现缺陷，并确保缺陷得以修复软件质量保证人员的职责是创建和执行改进软件开发过程，并防止软件缺陷发生的标准和方法。一个关注如何避免产生缺陷，侧重点是控制产品产生的过程，一个关注如何尽快发现缺陷，重点是产品本身。4、测试（Testing）和

质量保证（QA:Quality软件质量保证活动与测试的关系软件质量保证活动与测试的关系3.3补充软件质量保证与测试的关系3.3补充软件质量保证与测试的关系27软件质量有些软件开发者仍然相信软件质量是在编码之后才应该开始担心的事情。(这是荒谬的！)软件质量保证(SoftwareQualityAssurance，SQA)是一种应用于整个软件过程的保护性活动，它包括：一种质量管理方法，有效的软件工程技术（方法和工具）在整个软件过程中采用的正式技术复审一种多层次的测试策略对软件文档及其修改的控制保证软件遵从软件开发标准的规程度量和报告机制27软件质量有些软件开发者仍然相信软件质量是在编码之后才应该28质量概念我们应从以下几个方面考虑软件质量：软件结构方面功能与性能方面开发标准与文档方面28质量概念我们应从以下几个方面考虑软件质量：29软件质量概念IEEE关于软件质量的定义：软件质量是系统、部件或者过程满足规定需求的程度。系统、部件或者过程满足顾客或者用户需要或期望的程度。该定义相对客观，强调了产品（或服务）和客户/社会需求的一致性。ANSI关于软件质量的定义：按照ANSI（AmericanNationalStandardsInstitute，美国国家标准学会）在1983年的标准陈述，软件质量定义为“与软件产品满足规定的和隐含的需求的能力有关的特征和特性的全体”。具体包括软件产品中能满足用户给定需求的全部特性的集合，软件具有所期望的各种属性组合的程度，用户主观得出的软件是否满足其综合期望的程度，决定所用软件在使用中将满足其综合期望程度的软件合成特性29软件质量概念IEEE关于软件质量的定义：软件质量是30软件测试的定义1983年，IEEE在提出的软件测试文档标准（IEEEStandardForSoftwareTestDocument），即IEEE829-1983中对软件测试进行了准确的定义：软件测试是使用人工或自动手段来运行或测定某个系统的过程，检验它是否满足规定的需求或者弄清预期结果与实际结果之间的差别。IEEE在1990年颁布的软件工程标准术语集中沿用了这一概念，该概念非常明确的提出了软件测试以检验是否满足需求为目标。其次，G.J.Myers在其经典论著《软件测试的艺术》中对软件测试提出如下观点：测试是程序的执行过程，目的在于发现错误，一个好的测试用例可以发现至今尚未发现的错误，一个成功的测试能发现至今未发现的错误。30软件测试的定义1983年，IEEE在提出的软件测试文档标31软件测试方法1.静态方法和动态方法2.黑盒测试、白盒测试和灰盒测试3.基于软件开发阶段的测试方法需求测试单元测试集成测试性能测试压力测试容量测试配置测试回归测试安装测试安全性测试31软件测试方法1.静态方法和动态方法32软件测试自动化白盒测试工具功能测试工具负载压力测试工具测试管理工具32软件测试自动化白盒测试工具33软件缺陷的修复费用33软件缺陷的修复费用34软件质量保证体系软件质量保证（SoftwareQualityAssure，SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。SQA（软件质量保证）是CMM（软件能力成熟度）2级中的一个重要关键过程区域，它是贯穿于整个软件过程的第三方独立审查活动，在CMM的过程中充当重要角色。SQA的目的是向管理者提供对软件过程进行全面监控的手段，包括评审和审计软件产品和活动，验证它们是否符合相应的规程和标准，同时给项目管理者提供这些评审和审计的结果。满足SQA是达到CMM2级要求的重要步骤之一。34软件质量保证体系软件质量保证（SoftwareQua35能力成熟度模型（CMM）能力成熟度模型的历史和发展1987年，美国卡内基.梅隆大学软件研究所（SoftwareEngineeringInstitute，SEI）受美国国防部的委托，率先在软件行业从软件过程能力的角度提出了软件过程成熟度模型（CapabilityMaturityModel，CMM），随后在全世界推广实施的一种软件评估标准，用于评价软件承包能力并帮助其改善软件质量的方法。它主要用于软件开发过程和软件开发能力的评价和改进。它侧重于软件开发过程的管理及工程能力的提高与评估。CMM自1987年开始实施认证，现已成为软件业最权威的评估认证体系。CMM包括5个等级，共计18个过程域，52个目标，300多个关键实践。35能力成熟度模型（CMM）能力成熟度模型的历史和发展36能力成熟度模型的基本概念能力成熟度模型（CapabilityMaturityModelforSoftware，英文缩写为SW-CMM，简称CMM）CMM是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。它是在美国国防部的指导下，由软件开发团体和软件工程学院（SEI）及CarnegieMellon大学共同开发的。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。36能力成熟度模型的基本概念能力成熟度模型（Capabil37CMM的基本思想CMM的基本思想是基于已有60多年历史的产品质量原理。休哈特（WalterShewart）在30年代发表了统计质量控制原理，戴明（W.Edwards）和朱兰（JosephJuran）的关于质量的著作又进一步发展和论证了该原理。实际上，将质量原理变为成熟度框架的思想是克劳斯比（PhilipCrosby），他在著作《质量免费》（QualityisFree）中首先提出，他的质量管理成熟度网络描绘了采用质量实践时的5个进化阶段，而该框架后来又由IBM的拉迪斯（RomRadice）和他的同事们在汉弗莱（WattsHumphrey）指导下进一步改进以适应软件过程的需要。1986年，汉弗莱将此成熟框架带到了SEI并增加了成熟度等级的概念，将这些原理应用于软件开发，发展成为软件过程成熟度框架，形成了当前软件产业界正在使用的框架。37CMM的基本思想CMM的基本思想是基于已有60多年历史38实施CMM的必要性实施CMM是改进软件质量的有效方法:控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法软件工程和很多研究领域及实际问题有关，主要相关领域和因素有：需求工程（RequirementsEngineering）理论上，需求工程是应用已被证明的原理、技术和工具，帮助系统分析人员理解问题或描述产品的外在行为。软件复用（SoftwareReuse），定义为利用工程知识或方法，由一已存在的系统，来建造一新系统。这种技术，可改进软件产品质量和生产率。还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。38实施CMM的必要性实施CMM是改进软件质量的有效方法:CMMI补充：

CMMI是英文CapacityMaturityModelIntegrated（能力成熟度集成模型）的简称，CMMI是CMM模型的最新版本。资料显示，运用CMMI模型管理的项目，不仅降低了项目的成本，而且提高了项目的质量与按期完成率。因此，美国在国防工程项目中全面地推广CMMI模型，规定在国防工程项目的招标中，达到CMMI一定等级的公司才有参加竞标的资格。该模型包括了连续模型和阶段模型这两种表示方法，一个组织根据自己的过程改进要求可以自由选择合适的表示方法来使用。CMMI补充：CMMI是英文CapacityCMMI补充：

CMMI有两种不同的实施方法，其级别表示不同的内容。（1）连续式，主要是衡量一个企业的项目能力。企业在接受评估时可以选择自己希望评估的项目来进行评估。因为是企业自己挑选项目，其评估通过的可能性就较大一点。但是，它反映的内容也比较窄一点。它仅仅表示企业在该项目或类似项目的实施能力达到了某一等级。CMMI补充：CMMI有两种不同的实施方法，其级别表示不CMMI补充：

（2）阶段式。它主要是衡量一个企业的成熟度，亦即企业在项目实施上的综合实力。就是说处于某一阶段的企业，做大部分项目都要到达某一要求。一般地讲，一个企业要想在阶段性评估中得到三级，其企业内部的大部分项目要达到三级，小部分项目可以在二级，但绝不能够只有一级。阶段性实施方法的难度要大一些。说明：CMMI目前已成为许多大型软件业者用于改善组织内部软件工程所采行的软件评估标准，CMMI也陆续应用于系统工程及软件采购方面，成为国际间通用的一种软件生产程序标准。有专家预测，在未来的几年内，CMMI将成为ISO9000之后的又一个国际标准。CMMI补充：（2）阶段式。它主要是衡量一个企业的成熟度，亦CMMI补充：实施CMMI的意义

很多人认为，实施CMMI的意义在于项目工程走向世界，可以在西方国家接到订单。实际上，更为重要的意义则是，CMMI的实施能够提高我国企业的管理水平，降低企业的成本。事实表明，企业实施CMMI技术的投入都会得到丰厚的回报。据SEI统计，用于软件项目上的CMMI的投资，其回报率在5:1到8:1之间。

由此可见，为什么这么多的企业纷纷实施CMMI项目管理技术。CMMI补充：实施CMMI的意义很多人认为，CMMI补充：CMMI级别

CMMI一级，完成级。在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。CMMI补充：CMMI级别CMMI一级，完成级。CMMI补充：CMMI级别

CMMI二级，管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并联合上级单位对项目与流程进行审查。

企业在二级水平上体现了对项目的一系列管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。CMMI补充：CMMI级别CMMI二级，管理级。CMMI补充：CMMI级别

CMMI三级，明确（定义）级。在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化。这样，企业不仅能够在同类的项目上成功地实施CMMI，也能在不同类的项目上成功地实施。CMMI补充：CMMI级别CMMI三级，明确（定义）级。CMMI补充：CMMI级别

CMMI四级，量化管理级。在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。CMMI补充：CMMI级别CMMI四级，量化管理级。CMMI补充：CMMI级别

CMMI五级，优化级。在优化级水平上，企业的项目管理达到了最高的境界