1、第三章 软件测试的实质主讲人：主讲人：廖雪花廖雪花软件质量保证与测试大 纲3.1 测试原则测试原则3.2 测试术语定义测试术语定义3.3 补充软件质量保证与测试区别与联系补充软件质量保证与测试区别与联系有真正完美的软件么？有真正完美的软件么？经过测试人员的努力，能够消除所有经过测试人员的努力，能够消除所有的软件缺陷么？的软件缺陷么？如果做不到，我们该怎么办？如果做不到，我们该怎么办？3.1 测试原则（特点）1、完全测试程序是不可能的、完全测试程序是不可能的左图是一个不超过100行的程序结构图，有大概100,000,000,000,000 条可能的执行路径。以每秒执行1000个测试用例的速度计算
2、，完成所有可能路径的测试大概需要3170 年。白盒测试白盒测试如果你打算测试下 windows 的计算器，只考虑整数的加法：x+yxyz在在3232位的计算机上运行，位的计算机上运行，只考虑只考虑x x，y y是整数，不同是整数，不同的测试数据组合最大可能的测试数据组合最大可能数目为：数目为：2 2的的6464方，以每方，以每秒执行秒执行10001000个测试用例个测试用例的速度计算，完成测试大的速度计算，完成测试大概需要工作概需要工作5 5亿年。亿年。黑盒测试黑盒测试无法进行完全测试的原因下面的各种情况，都可能导致问题的复杂下面的各种情况，都可能导致问题的复杂化，或使软件留有隐患：化，或使软
3、件留有隐患：输入量太大输入量太大输出结果太多输出结果太多软件执行路径太多软件执行路径太多软件说明书本身就是主观的产物，可能不软件说明书本身就是主观的产物，可能不正确，也经常会变动。正确，也经常会变动。无法进行完全测试的原因如果觉得某些测试条件是重复的、无必要如果觉得某些测试条件是重复的、无必要的，或者为了节省空间，而将其剔除，那的，或者为了节省空间，而将其剔除，那么采用的就是不完全测试。么采用的就是不完全测试。2、软件测试是有风险的行为如果我们不去进行完全测试，必然会遗漏或放弃些什么如果我们不去进行完全测试，必然会遗漏或放弃些什么，换句话说：，换句话说：我们是在冒险！我们是在冒险！我们究竟该怎
4、么做才能将风险降低？我们究竟该怎么做才能将风险降低？关键思想：将数量巨大关键思想：将数量巨大的可能测试减少到可以的可能测试减少到可以控制的范围，以及针对控制的范围，以及针对风险做出明智的选择，风险做出明智的选择，哪些测试不重要，哪些哪些测试不重要，哪些重要。重要。缺陷数量缺陷数量测试量测试量最优测试点最优测试点测试费用测试费用漏掉的缺陷漏掉的缺陷2、软件测试是有风险的行为如果试图测试所有的情况，费用将大幅增加。如果试图测试所有的情况，费用将大幅增加。软件缺陷漏掉的数量在到达某一点后没有显著变化。软件缺陷漏掉的数量在到达某一点后没有显著变化。缺陷数量缺陷数量测试量测试量最优测试点最优测试点测试费
5、用测试费用漏掉的缺陷漏掉的缺陷关键任务：找到最优的关键任务：找到最优的测试量，使测试不多不测试量，使测试不多不少。少。3、测试无法显示潜伏的软件缺陷p测试不是为了证明软件是完善的，而是要测试不是为了证明软件是完善的，而是要尽量证明软件是有问题的！尽量证明软件是有问题的！n只能报告软件缺陷存在只能报告软件缺陷存在n不能报告软件缺陷不存在不能报告软件缺陷不存在4、找到的缺陷越多，说明软件缺陷越多软件缺陷就和生活中的害虫一样，发现一软件缺陷就和生活中的害虫一样，发现一个，往往附近就可能会有一群！个，往往附近就可能会有一群！为什么会这样：为什么会这样：n程序员也有状态、心情不佳的时候程序员也有状态、心
6、情不佳的时候n人们总是习惯反复犯同样的错误人们总是习惯反复犯同样的错误n缺陷往往是有关联的，一个错误往往导致缺陷往往是有关联的，一个错误往往导致更多的错误，而你可能只是发现了冰山的更多的错误，而你可能只是发现了冰山的一角一角5、杀虫剂现象：软件测试越多，免疫力越强难道软件也像生物一样能自动进化？难道软件也像生物一样能自动进化？其实指的是无论是项目组、程序员，还是其实指的是无论是项目组、程序员，还是测试人员，一般都有常规、固定的工作模测试人员，一般都有常规、固定的工作模式或习惯，容易产生盲点。式或习惯，容易产生盲点。回想一下螺旋模式，不断的重复回想一下螺旋模式，不断的重复改善：改变测试方法，改变
7、测试重点改善：改变测试方法，改变测试重点6、并非所有的软件缺陷都需要修复p即使测试中发现了问题，也并非所有缺陷都需要或能够即使测试中发现了问题，也并非所有缺陷都需要或能够得到修复得到修复 没有足够的时间没有足够的时间 修复的风险修复的风险 不算真正的软件缺陷不算真正的软件缺陷 不值得修复不值得修复p到底是否进行修复，有时很难决断，从这个角度而言，到底是否进行修复，有时很难决断，从这个角度而言，我们是在冒险，有时后果很严重我们是在冒险，有时后果很严重6、并非所有的软件缺陷都需要修复p是否需要修复要归结为商业风险决策。是否需要修复要归结为商业风险决策。p决策过程通常由软件测试员、项目经理和程序员共
8、同参决策过程通常由软件测试员、项目经理和程序员共同参与。与。他们站在各自的立场看待缺陷，对软件缺陷是否应他们站在各自的立场看待缺陷，对软件缺陷是否应该或不应该修复都有自己的观点和看法。后续章节将介该或不应该修复都有自己的观点和看法。后续章节将介绍如何报告软件缺陷，并使其他人知道。绍如何报告软件缺陷，并使其他人知道。7、难以说清的软件缺陷没有人发现软件中存在的问题，该问题是没有人发现软件中存在的问题，该问题是缺陷吗？缺陷吗？没有答案没有答案完美本身就没有固定的标准完美本身就没有固定的标准你脸上长个痣，有人觉得难看是缺陷，有你脸上长个痣，有人觉得难看是缺陷，有人觉得那是美人痣。人觉得那是美人痣。（
9、回顾）软件缺陷的定义产品说明书：是软件开发小组的一个协定。它对开发的产品说明书：是软件开发小组的一个协定。它对开发的产品进行定义，给出产品的细节、如何做、做什么、不产品进行定义，给出产品的细节、如何做、做什么、不能做什么。能做什么。至少满足以下至少满足以下5个规则之一才称为软件缺陷：个规则之一才称为软件缺陷：软件未实现产品说明书要求的功能。软件未实现产品说明书要求的功能。软件出现了产品说明书指明不应出现的错误。软件出现了产品说明书指明不应出现的错误。软件实现了产品说明书未提到的功能。软件实现了产品说明书未提到的功能。软件未实现产品说明书虽未明确提及但应该实现的目标。软件未实现产品说明书虽未明确
10、提及但应该实现的目标。软件难以理解、不易使用、运行缓慢或者从测试员的角软件难以理解、不易使用、运行缓慢或者从测试员的角度看最终用户会认为不好。度看最终用户会认为不好。7、难以说清的软件缺陷尚未发现或未观察到的软件缺陷只能说是尚未发现或未观察到的软件缺陷只能说是潜在缺陷。潜在缺陷。8、产品说明书不断变化，没有最终版本、产品说明书不断变化，没有最终版本n开发者的噩梦！开发者的噩梦！软件测试人员必须要想到产品说明书可软件测试人员必须要想到产品说明书可能改变。未曾计划测试的功能会增加，经过能改变。未曾计划测试的功能会增加，经过测试并报告软件缺陷的功能可能发生变化甚测试并报告软件缺陷的功能可能发生变化甚
11、至被删除，这些都是有可能会发生的。至被删除，这些都是有可能会发生的。9、软件测试员在产品小组中不受欢迎、软件测试员在产品小组中不受欢迎 早点找出缺陷、控制情绪、不要总是报告坏早点找出缺陷、控制情绪、不要总是报告坏消息消息10、软件测试是一项讲究条理的技术工作、软件测试是一项讲究条理的技术工作n不再是随心所欲不再是随心所欲n成为一个职业选择成为一个职业选择需要训练和规范，而需要训练和规范，而且有发展空间。且有发展空间。3.2 软件测试的术语定义1、精确（、精确（precision）和准确（）和准确（accuracy）不准确，不精确不准确，不精确精确，不准确精确，不准确准确，不精确准确，不精确准确
12、，精确准确，精确1、精确（、精确（precision）和准确（）和准确（accuracy）软件测试要精度还是准度很大程度上取决软件测试要精度还是准度很大程度上取决于产品是什么，最终取决于开发小组的目于产品是什么，最终取决于开发小组的目标。标。只有软件测试员清楚产品说明书，就可以只有软件测试员清楚产品说明书，就可以量身定做测试程序来确认。量身定做测试程序来确认。2、确认（verification）和验证（validation）确认：保证软件产品符合产品说明书的过程。确认：保证软件产品符合产品说明书的过程。验证：保证软件满足用户要求的过程。验证：保证软件满足用户要求的过程。满足产品说明书未必满足实
13、际需求满足产品说明书未必满足实际需求哈勃太空望远镜的例子就是很典型的哈勃太空望远镜的例子就是很典型的可靠性：软件运行稳定。可靠性：软件运行稳定。质量：能够满足客户要求，包括价格、服务等。质量：能够满足客户要求，包括价格、服务等。良好的可靠性并不代表良好的质量，可靠性仅仅是质量的良好的可靠性并不代表良好的质量，可靠性仅仅是质量的一个方面。一个方面。为了确保程序质量高而且可靠为了确保程序质量高而且可靠 性强，软件测试员必须在整性强，软件测试员必须在整个产品开发过程中进行确认和验证。个产品开发过程中进行确认和验证。3、质量（quality）和可靠性（Reliability）4、测试（Testing）
14、和质量保证（QA:Quality Assurance）软件测试人员的职责是尽可能早的发现缺陷，并确保缺软件测试人员的职责是尽可能早的发现缺陷，并确保缺陷得以修复陷得以修复软件质量保证人员的职责是创建和执行改进软件开发过软件质量保证人员的职责是创建和执行改进软件开发过程，并防止软件缺陷发生的标准和方法。程，并防止软件缺陷发生的标准和方法。一个关注如何避免产生缺陷，侧重点是控制产品产生的一个关注如何避免产生缺陷，侧重点是控制产品产生的过程过程，一个关注如何尽快发现缺陷，重点是，一个关注如何尽快发现缺陷，重点是产品本身产品本身。软件质量保证活动与测试的关系 单元测试单元测试 开发方法学 配置管理 验
15、证技术 评 审 正确性验证正确性验证 性能调试性能调试 集成测试集成测试 系统测试系统测试 原子事务 模块冗余性 质量保证质量保证 检检 错错 避免错误避免错误 测测 试试 调调 试试 容容 错错 3.3 补充软件质量保证与测试的关系27软件质量有些软件开发者仍然相信软件质量是在编码之后才应该开始有些软件开发者仍然相信软件质量是在编码之后才应该开始担心的事情。担心的事情。(这是荒谬的！这是荒谬的！)软件质量保证软件质量保证(Software Quality Assurance，SQA)是一种是一种应用于整个软件过程的保护性活动，它包括：应用于整个软件过程的保护性活动，它包括：一种质量管理方法，
16、一种质量管理方法，有效的软件工程技术（方法和工具）有效的软件工程技术（方法和工具）在整个软件过程中采用的正式技术复审在整个软件过程中采用的正式技术复审 一种多层次的测试策略一种多层次的测试策略 对软件文档及其修改的控制对软件文档及其修改的控制 保证软件遵从软件开发标准的规程保证软件遵从软件开发标准的规程 度量和报告机制度量和报告机制28质量概念我们应从以下几个方面考虑软件质量：我们应从以下几个方面考虑软件质量：软件结构方面软件结构方面 功能与性能方面功能与性能方面 开发标准与文档方面开发标准与文档方面29软件质量概念IEEE关于软件质量的定义：软件质量是关于软件质量的定义：软件质量是 系统、部
17、件或者过程系统、部件或者过程满足规定需求的程度满足规定需求的程度。系统、部件或者过程系统、部件或者过程满足顾客或者用户需要或期望的程度满足顾客或者用户需要或期望的程度。该定义相对客观，强调了产品（或服务）和客户该定义相对客观，强调了产品（或服务）和客户/社会需求的一社会需求的一致性。致性。ANSI关于软件质量的定义：按照关于软件质量的定义：按照ANSI（American National Standards Institute，美国国家标准学会）在，美国国家标准学会）在1983年的标准陈年的标准陈述，软件质量定义为述，软件质量定义为“与软件产品满足规定的和隐含的需求的与软件产品满足规定的和隐含
18、的需求的能力有关的特征和特性的全体能力有关的特征和特性的全体”。具体包括。具体包括 软件产品中软件产品中能满足用户给定需求的全部特性的集合能满足用户给定需求的全部特性的集合，软件软件具有所期望的各种属性组合的程度具有所期望的各种属性组合的程度，用户主观得出用户主观得出的的软件是否满足其综合期望的程度，软件是否满足其综合期望的程度，决定所用软件在使用中将满足其综合期望程度的决定所用软件在使用中将满足其综合期望程度的软件合成特性软件合成特性30软件测试的定义1983年，年，IEEE在提出的软件测试文档标准（在提出的软件测试文档标准（IEEE Standard For Software Test D
19、ocument），即），即IEEE 829-1983中对软件测试进中对软件测试进行了准确的定义：行了准确的定义：软件测试是使用人工或自动手段来运行或测定某个系统的过程，检验它软件测试是使用人工或自动手段来运行或测定某个系统的过程，检验它是否满足规定的需求或者弄清预期结果与实际结果之间的差别。是否满足规定的需求或者弄清预期结果与实际结果之间的差别。IEEE在在1990年颁布的软件工程标准术语集中沿用了这一概念，该年颁布的软件工程标准术语集中沿用了这一概念，该概念非常明确的提出了软件测试以检验是否满足需求为目标。概念非常明确的提出了软件测试以检验是否满足需求为目标。其次，其次，G.J.Myers在
20、其经典论著在其经典论著软件测试的艺术软件测试的艺术中对软件测中对软件测试提出如下观点：试提出如下观点：测试是程序的执行过程，测试是程序的执行过程，目的目的在于在于发现错误发现错误，一个一个好的测试用例好的测试用例可以发现至今尚未发现的错误，可以发现至今尚未发现的错误，一个一个成功的测试成功的测试能发现至今未发现的错误。能发现至今未发现的错误。31软件测试方法1.静态方法和动态方法静态方法和动态方法2.黑盒测试、白盒测试和灰盒测试黑盒测试、白盒测试和灰盒测试3.基于软件开发阶段的测试方法基于软件开发阶段的测试方法 需求测试需求测试 单元测试单元测试 集成测试集成测试 性能测试性能测试 压力测试压
21、力测试 容量测试容量测试 配置测试配置测试 回归测试回归测试 安装测试安装测试 安全性测试安全性测试32软件测试自动化白盒测试工具白盒测试工具功能测试工具功能测试工具负载压力测试工具负载压力测试工具测试管理工具测试管理工具33软件缺陷的修复费用34软件质量保证体系 软件质量保证（软件质量保证（Software Quality Assure，SQA）是建立一套有）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。和方法能够正确地被所有项目所采用。软件质量保证的目的是使软软件质量保证的目
22、的是使软件过程对于管理人员来说是可见的。件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。这些将使软件项目满足机构方针的要求。SQA（软件质量保证）是（软件质量保证）是CMM（软件能力成熟度）（软件能力成熟度）2级中的一个重级中的一个重要关键过程区域，它是贯穿于整个软件过程的第三方独立审查活动要关键过程区域，它是贯穿于整个软件过程的第三方独立审
23、查活动，在，在CMM的过程中充当重要角色。的过程中充当重要角色。SQA的目的是向管理者提供对软件过程进行全面监控的手段，包括的目的是向管理者提供对软件过程进行全面监控的手段，包括评审和审计软件产品和活动，验证它们是否符合相应的规程和标准评审和审计软件产品和活动，验证它们是否符合相应的规程和标准，同时给项目管理者提供这些评审和审计的结果。，同时给项目管理者提供这些评审和审计的结果。满足满足SQA是达到是达到CMM2级要求的重要步骤之一。级要求的重要步骤之一。35能力成熟度模型（CMM）能力成熟度模型的历史和发展能力成熟度模型的历史和发展 1987年，美国卡内基年，美国卡内基.梅隆大学软件研究所（
24、梅隆大学软件研究所（Software Engineering Institute，SEI）受美国国防部的委托，率先在）受美国国防部的委托，率先在软件行业从软件过程能力的角度提出了软件过程成熟度模型软件行业从软件过程能力的角度提出了软件过程成熟度模型（Capability Maturity Model，CMM），随后在全世界推广），随后在全世界推广实施的一种软件评估标准，用于评价软件承包能力并帮助其实施的一种软件评估标准，用于评价软件承包能力并帮助其改善软件质量的方法。改善软件质量的方法。它主要用于软件开发过程和软件开发能力的评价和改进。它主要用于软件开发过程和软件开发能力的评价和改进。它侧重于
25、软件开发过程的管理及工程能力的提高与评估。它侧重于软件开发过程的管理及工程能力的提高与评估。CMM自自1987年开始实施认证，现已成为软件业最权威的评估年开始实施认证，现已成为软件业最权威的评估认证体系。认证体系。CMM包括包括5个等级，共计个等级，共计18个过程域，个过程域，52个目标，个目标，300多个关多个关键实践。键实践。36能力成熟度模型的基本概念 能力成熟度模型（能力成熟度模型（Capability Maturity Model for Software，英文缩写为，英文缩写为SW-CMM，简称，简称CMM）CMM是是对于软件组织在定义、实施、度量、控制和改善其软件对于软件组织在定
26、义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。过程的实践中各个发展阶段的描述。它是在美国国防部的指导下，由软件开发团体和软件工它是在美国国防部的指导下，由软件开发团体和软件工程学院（程学院（SEI）及）及Carnegie Mellon大学共同开发的。大学共同开发的。CMM的核心是把软件开发视为一个过程，并根据这一原的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。科学化、标准化、使企业能够更好地实现商业目标。37CMM的基本思想 CMM的基本
27、思想是基于已有的基本思想是基于已有60多年历史的产品质量原理。多年历史的产品质量原理。休哈特（休哈特（Walter Shewart）在）在30年代发表了统计质量控制原年代发表了统计质量控制原理，戴明（理，戴明（W.Edwards）和朱兰（）和朱兰（Joseph Juran）的关于）的关于质量的著作又进一步发展和论证了该原理。质量的著作又进一步发展和论证了该原理。实际上，将质量原理变为成熟度框架的思想是克劳斯比（实际上，将质量原理变为成熟度框架的思想是克劳斯比（Philip Crosby），他在著作），他在著作质量免费质量免费（Quality is Free）中首先提出，他的质量管理成熟度网络描
28、绘了采用质量实）中首先提出，他的质量管理成熟度网络描绘了采用质量实践时的践时的5个进化阶段，而该框架后来又由个进化阶段，而该框架后来又由IBM的拉迪斯（的拉迪斯（Rom Radice）和他的同事们在汉弗莱（）和他的同事们在汉弗莱（Watts Humphrey）指导下进一步改进以适应软件过程的需要。）指导下进一步改进以适应软件过程的需要。1986年，汉弗莱将此成熟框架带到了年，汉弗莱将此成熟框架带到了SEI并增加了成熟度等并增加了成熟度等级的概念，将这些原理应用于软件开发，发展成为软件过程级的概念，将这些原理应用于软件开发，发展成为软件过程成熟度框架，形成了当前软件产业界正在使用的框架。成熟度框
29、架，形成了当前软件产业界正在使用的框架。38实施CMM的必要性 实施实施CMM是改进软件质量的有效方法是改进软件质量的有效方法:控制软件生产过程控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合、提高软件生产者组织性和软件生产者个人能力的有效合理的方法软件工程和很多研究领域及实际问题有关，主要理的方法软件工程和很多研究领域及实际问题有关，主要相关领域和因素有：相关领域和因素有：需求工程（需求工程（Requirements Engineering）理论上，需求工程是应用已被证明的原理、技术和工具，理论上，需求工程是应用已被证明的原理、技术和工具，帮助系统分析人员理解问题或描述产品
30、的外在行为。帮助系统分析人员理解问题或描述产品的外在行为。软件复用（软件复用（Software Reuse），定义为利用工程知识或方），定义为利用工程知识或方法，由一已存在的系统，来建造一新系统。这种技术，可法，由一已存在的系统，来建造一新系统。这种技术，可改进软件产品质量和生产率。改进软件产品质量和生产率。还有软件检查、软件计量、软件可靠性、软件可维修性、软还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。件工具评估和选择等。uCMMI补充：补充：CMMI CMMI是英文是英文Capacity Maturity Model IntegratedCapacity Matu
31、rity Model Integrated（能力成熟度集成模型）的简称，（能力成熟度集成模型）的简称，CMMICMMI是是CMMCMM模型的最新版模型的最新版本。资料显示，运用本。资料显示，运用CMMICMMI模型管理的项目，不仅降低了项目模型管理的项目，不仅降低了项目的成本，而且提高了项目的质量与按期完成率。因此，美国的成本，而且提高了项目的质量与按期完成率。因此，美国在国防工程项目中全面地推广在国防工程项目中全面地推广CMMICMMI模型，规定在国防工程项模型，规定在国防工程项目的招标中，达到目的招标中，达到CMMICMMI一定等级的公司才有参加竞标的资格。一定等级的公司才有参加竞标的资格
32、。该模型包括了该模型包括了连续模型连续模型和和阶段模型阶段模型这两种表示方法，一个组这两种表示方法，一个组织根据自己的过程改进要求可以自由选择合适的表示方法来织根据自己的过程改进要求可以自由选择合适的表示方法来使用。使用。uCMMI补充：补充：CMMI CMMI有两种不同的实施方法，其级别表示不同的内容。有两种不同的实施方法，其级别表示不同的内容。（1 1）连续式）连续式，主要是衡量一个企业的项目能力。企业在接，主要是衡量一个企业的项目能力。企业在接受评估时可以选择自己希望评估的项目来进行评估。因为是受评估时可以选择自己希望评估的项目来进行评估。因为是企业自己挑选项目，其评估通过的可能性就较大
33、一点。但是，企业自己挑选项目，其评估通过的可能性就较大一点。但是，它反映的内容也比较窄一点。它仅仅表示企业在该项目或类它反映的内容也比较窄一点。它仅仅表示企业在该项目或类似项目的实施能力达到了某一等级。似项目的实施能力达到了某一等级。uCMMI补充：补充：（2）阶段式。它主要是衡量一个企业的成熟度，亦即企业在项目实施上的综合实力。就是说处于某一阶段的企业，做大部分项目都要到达某一要求。一般地讲，一个企业要想在阶段性评估中得到三级，其企业内部的大部分项目要达到三级，小部分项目可以在二级，但绝不能够只有一级。阶段性实施方法的难度要大一些。说明：CMMI目前已成为许多大型软件业者用于改善组织内部软件
34、工程所采行的软件评估标准，CMMI也陆续应用于系统工程及软件采购方面，成为国际间通用的一种软件生产程序标准。有专家预测，在未来的几年内，CMMI将成为ISO9000之后的又一个国际标准。uCMMI补充：补充：实施CMMI的意义 很多人认为，实施CMMI的意义在于项目工程走向世界，可以在西方国家接到订单。实际上，更为重要的意义则是，CMMI的实施能够提高我国企业的管理水平，降低企业的成本。事实表明，企业实施CMMI技术的投入都会得到丰厚的回报。据SEI统计，用于软件项目上的CMMI的投资，其回报率在5:1到8:1之间。由此可见，为什么这么多的企业纷纷实施CMMI项目管理技术。uCMMI补充：补充
35、：CMMI级别 CMMI一级，完成级。一级，完成级。在完成级水平上，企业对项目的目标与要做的努力很在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。的依赖性。uCMMI补充：补充：CMMI级别 CMMI二级，管理级。二级，管理级。在管理级水平上，企业在项目实施上能够遵守既定的在管理级水平上，企
36、业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并联合上人员有相应的培训，对整个流程有监测与控制，并联合上级单位对项目与流程进行审查。级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列管理程序。企业在二级水平上体现了对项目的一系列管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。性，保证了企业的所有项目实施都会得到成功。uCMMI补充：补充：CMMI级别 CM
37、MI三级，明确（定义）级。三级，明确（定义）级。在定义级水平上，企业不仅能够对项目的实施有一整在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化。这样，企业不仅能够在同类的项目上成流程予以制度化。这样，企业不仅能够在同类的项目上成功地实施功地实施CMMI，也能在不同类的项目上成功地实施。，也能在不同类的项目上成功地实施。uCMMI补充：补充：CMMI级别 CMMI四级，量化管理级。四级，
38、量化管理级。在在量化管理级水平上，企业的项目管理不仅形成了一量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。通过量化技术来实现种制度，而且要实现数字化的管理。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上流程的稳定性，实现管理的精度，降低项目实施在质量上的波动的波动。uCMMI补充：补充：CMMI级别 CMMI五级，优化级。五级，优化级。在在优化级水平上，企业的项目管理达到了最高的境界。优化级水平上，企业的项目管理达到了最高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够
39、充分利用信息资料，对企业在项目实施的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化运用新技术，实现流程的优化。说明：说明：由上述的由上述的5 5个级别我们可以看出，每一个级别都是更个级别我们可以看出，每一个级别都是更高一级的基石。要上高层台阶必须首先踏上较低一层台阶。高一级的基石。要上高层台阶必须首先踏上较低一层台阶。48软件评审的内容管理评审管理评审技术评审技术评审文档评审文档评审过程评审过程评审49评审的方法和技术特别检查（特别检查（Ad hoc review）
40、轮查（轮查（Pass Around）走查（走查（Walkthrough）团队评审（团队评审（Group Review）检视（检视（Inspection）50检视、团队评审和走查异同点比较表 角色/职责检视团队评审走查主持者主持者评审组长评审组长评审组长或作者评审组长或作者作者作者材料陈述者材料陈述者评审者评审者评审组长评审组长作者作者记录员记录员是是是是可能可能专门的评审角色专门的评审角色是是是是否否检查表检查表是是是是否否问题跟踪和分析问题跟踪和分析是是可能可能否否产品评估产品评估是是是是否否计划计划有有有有是是准备准备有有有有无无会议会议有有有有有有修正修正有有有有有有确认确认有有有有无无
41、51评审的技术 缺陷检查表缺陷检查表规则集规则集评审工具的使用评审工具的使用 Gerrit Jupiter SourceMonitor从不同角度理解产品从不同角度理解产品场景分析技术场景分析技术本章小结掌握测试原则、测试术语的定义掌握测试原则、测试术语的定义了解软件质量保证与测试的关系了解软件质量保证与测试的关系到目前为止，关于过程的所有内容已经讲完了。到目前为止，关于过程的所有内容已经讲完了。下一章将进入新的部分，介绍软件测试的基本下一章将进入新的部分，介绍软件测试的基本技术。技术。作业：查资料，回答以下问题假定无法完全测试某一程序，在决定是否应该停止测试假定无法完全测试某一程序，在决定是否应该停止测试时要考虑哪些问题？时要考虑哪些问题？有没有质量很高但可靠性很差的产品？请举例。有没有质量很高但可靠性很差的产品？请举例。为什么不可能完全测试程序？为什么不可能完全测试程序？假如周一测试软件的某一功能，每小时发现一个新的软假如周一测试软件的某一功能，每小时发现一个新的软件缺陷，你认为周二将会以什么样的频率发现软件缺陷？件缺陷，你认为周二将会以什么样的频率发现软件缺陷？
