第一章
1. 软件的定义、分类
定义：软件是计算机系统中与硬件相互依存的另一部分，它是程序、数据及相关文档的集合。 分类：
程序：由程序设计语言所描述的、能为计算机所识别、理解和处理的语句序列。 数据：使程序能正常处理信息的数据和数据结构。
文档：一种数据媒体和其上所记录的数据，即记录软件开发活动和阶段性成果、理解软件所必需的阐述性资料。
2.IEEE 软件缺陷的定义
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题； 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
3. 软件缺陷产生的原因
（1）项目期限的压力（2）产品的复杂度（3）沟通不良
（4） 开发人员的疲劳、压力或受到干扰（5）缺乏足够的知识、技能和经验
（6）不了解客户的需求 （7）缺乏动力
4. 软件测试的定义：
IEEE 的定义 ：一个系统、构件或过程满足顾客或用户需求与期望的程度。
在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价 分析某个软件项以发现现存的和要求的条件之差别（即错误）并评价此软件项的特性 Crosby 的定义：一个系统、部分或过程满足规定需求的程度。
Pressman 的定义：软件质量是符合明确陈述的功能/性能需求、明确文档化了的开发标准和所有专业开发预期的隐含特性。
5. 软件质量的内容，各维度下软件质量标准
产品质量：产品质量是人们实践产物的属性和行为，是可以认识，可以科学地描述的。并且可以通过一些方法和人类活动，来改进质量.
质量模型: McCall 模型, Boehm 模型, ISO 9126 模型
过程质量:
软件能力成熟度模型 CMM ( Capability Maturity Model).
国际标准过程模型 ISO 9000
软件过程改进和能力决断SPICE ( Software Process Improvement and Capability
dEtermination)
6.MaCall 软件质量模型；应用 MaCall 模型分析软件质量
产品运行软件质量要素
产品修改软件质量要素
产品转移软件质量要素
7.MaCall 软件质量模型中软件质量维度；各个维度软件质量因子的定义
8. 软件质量管理的内容
软件质量管理就是确保软件具有较少缺陷，并达到软件系统既定目标。
软件质量管理有以下四种主要活动组成：
软件质量保证(Quality Assurance)建立起机构质量规程和标准的整体框架，这是生产高质量软件的保证。
软件质量规划(Quality Planning)从这个框架中选择适当的质量规程和标准，进行改写使之适应特定软件项目。
软件质量控制(Quality Control) 定义并设计软件过程，确保软件开发团队严格遵守项目质量规划和标准。
软件质量改进
9. 软件质量成本的定义、构成
定义：质量成本是为确保和保证满意的质量而发生的费用以及没有达到满意的质量所造成损失的总和，即包括保证费用和损失费用。
质量成本＝质量保证成本＋损失成本
质量保证成本：为保证满意的质量而发生的费用
损失成本：没有达到满意的质量所造成损失
质量成本＝质量预防成本＋评价成本＋失效成本
保证成本＝预防成本＋评价成本
预防成本：预防产生质量问题（软件缺陷）的费用，是企业的计划性支出，专门用来确保在软件产品交付和服务的各个环节不出现失误。
评价成本：是指在交付和服务环节上，为评定软件产品或服务是否符合质量要求而进行的试验、软件测试和质量评估等所必需的支出。
失效成本：分为内部的和外部的，如果在软件发布之前发现质量问题，而要求重做、修改和问题分析所带来的成本属内部失效成本，包括修正软件缺陷、回归测试等，以及因产品或服务不合要求导致的延误。
10. 软件质量标准的益处、分类（包括认证标准和评估标准）
益处：（1）有能力应用最高专业级别的软件开发与维护方法学和规程；
（2）开发组之间、尤其是开发与维护组之间更好的互相理解与协作；
（3）软件开发者和外部参与方之间更大的合作；
（4）基于采用著名开发与维护标准作为合同的一部分，使供货商和顾客之间能更好地互相理解与合作。
从内容和重点上我们可以把质量管理标准划分成：
认证标准
认证标准的范围是由认证的目的确定的，其目的在于：使软件开发机构能够证实其有能力确保软件产品或维护服务符合可接受的质量需求。这是通过一个外部的实体做出认证实现的； 用作顾客和供货商对供货商的质量管理系统评价一致性的基础。它可以通过由顾客实施的对供货商的质量管理系统的质量审计实现；
支持软件开发机构的工作，通过符合标准的需求来改进质量管理系统性能和增强顾客满意度。
评估标准
（1）用做软件开发与维护机构对其进行软件开发项目的能力的自我评估工具；
（2）用做改进开发与维护过程的工具，标准指出过程改进的方向；
（3）帮助采购机构确定潜在供货商的能力；
（4）通过罗列资格认证与培训计划课程，指导评估人员的培训。
认证标准的重点是外部的--支持供货商顾客关系，
而评估标准的重点是内部的，因为它关注的是软件过程改进。
11.ISO 9000-3 质量管理系统的基本原理
（1）顾客关注。机构依靠它们的顾客，所以应当理解当前的与未来的顾客需要；
（2）领导--建立并维护一个积极的内部环境中行使领导权，以实现机构的目标；
（3）人们的投入。人是机构之本，他们在各机构层次的全身心投入使得他们的能力能用于为机构谋益；
（4）过程方法--当把活动与资源作为过程管理的时候，就更有效地达到理想的结果；
（5）管理理的系统方法--把过程作为一个系统管理；
（6）持续改进--对全面性能正在进行的改进应当在机构的日程上优先；
（7）决策制定的实在方法。有效决策是建立在信息分析的基础上的；
（7）相互支持的供货商关系。一个机构和它的供货商是互相依赖时，相互支持的供货由关系增强双方创造增加值的能力。
12.ISO 9000-3 质量管理标准的认证过程；
（1）制订获得认证的活动计划 （2）建立机构SQA 系统
（3）接受认证审计 （4）维持ISO 认证的规程
13. 软件过程能力、软件过程成熟度、软件过程能力成熟度等级的定义
软件过程能力：描述开发组织或项目组遵循其软件过程能够实现预期结果的程度，它既可对整个软件开发组织而言，也可对一个软件项目而言。
软件过程成熟度：一个特定软件过程被明确且有效地定义、管理、测量和控制的程度。 软件能力成熟度等级：软件开发组织在走向成熟的途中几个具有明确定义的表示软件过程能力成熟度的平台。
14.CMM 的基本思想、作用、内容 （即软件过程成熟度等级的划分，各等级下软件过程的
特点）
思想：由于软件危机等问题是由我们管理软件过程的方法不当引起的，所以新软件技术的应用并不会自动提高软件的生产率和质量。
能力成熟度模型有助于软件开发机构建立一个有规律的、成熟的软件过程。改进的软件过程将开发出更高质量的软件，使更多的软件项目免受时间和经费超支之苦。
作用：指导软件机构通过确定当前的过程成熟度并识别出对过程改进起关键作用的问题，从而明确过程改进方向和策略。
通过集中开展过程改进的方向和策略相一致的过程改进活动，软件机构便能稳步而有效的改进其软件过程，使其软件过程能力得到循序渐进的提高。
对软件过程的改进，是在完成一个又一个小的改进基础上不断进行的渐进过程，而不是一蹴而就的彻底革命。
内容：CMM 把软件过程从无序到有序的进化过程分成5个阶段，并把这些阶段排列形成5个逐层提高的等级，如下图所示：
初始级：软件过程是无序的，有时甚至是混乱的，对软件过程几乎没有定义，软件项目成功与否取决于个人努力。
重复级：建立了基本的项目管理过程(过程模型) ，可跟踪成本、进度和质量特性。已经建立了必要的过程规范，能重复早先类似项目的实践经验成功完成新项目。
达到2级的一个目标是使项目管理过程稳定，从而使得软件机构能重复以前在成功项目中所进行过的软件项目工程实践。
处于第2级成熟度的软件机构的过程能力可以概括为：
软件项目的策划和跟踪是稳定的，已经为一个有纪律的管理过程提供了可重复以前成功实践的项目环境。软件项目工程活动处于项目管理体系有效控制之下，执行着基于以前项目准则且合乎现实的计划。
已定义级：已经定义了完整的软件过程，软件过程已文档化、标准化。所有项目均使用经批准的、文档化的标准软件过程来开发和维护软件。这一级别包含第2级的全部特征。
在第3级成熟度的软件机构中，有一个固定的过程小组从事软件过程工程活动。当需要时，过程小组可以利用过程模型进行过程例化活动，还可以推进软件机构的过程改进活动。 在该机构内实施了培训计划，能够保证全体项目负责人和开发人员具有完成承担的任务所要求的知识和技能。
处于第3级的软件机构的能力成熟度可以概括为：
无论是管理活动，还是工程活动都是稳定的。软件开发成本和进度以及产品的功能都受到控制，而且软件产品质量具有可追溯性。
以管理级：软件机构对软件过程、软件产品都建立了定量的质量目标，所有项目的重要过程活动都是可度量的。该机构收集了过程度量和产品度量的方法并加以运用，对软件过程和产品都有定量的理解与控制。
这一级包含了第3级的全部特征。
处于第4级的软件机构的能力成熟度可以概括为：
处于4级成熟度的软件机构，软件过程是可度量的，软件过程在可度量的范围内运行。 这一级的过程能力允许软件机构在定量的范围内预测过程和产品质量趋势，在发生偏离时可
以及时采取措施予以纠正，并且可以预期软件产品是高质量的。
优先级：处于5级的软件机构的能力成熟度可以概括为：
软件过程是可优化的。这一级别的软件机构能够持续不断的改进其过程能力，既对现行的过程实例不断改进和优化，又借助所采用的新技术、新方法来实现未来的过程改进。
第 2 章 软件度量
1. 软件度量、软件测量的定义
软件度量(Metrics)是指对软件产品、软件开发过程或者资源等对象的简单属性的定量描述。 软件测量(Measure)是对软件产品、软件开发过程和资源复杂属性的定量描述，它是简单属性度量值的函数，软件测量用于事后或实时状态, 如软件可靠性
2. 为什么需要软件度量？
任何工程化的工作都需要度量，软件工程也不例外
准确了解工程的实施情况
项目实施之前
辅助制定软件项目的计划
估算成本和工作量，以便制定计划
项目实施过程中
提供软件开发的可视性
跟踪和控制软件项目的开发
评估软件开发质量，进行质量控制
加强风险管理
项目实施之后
对项目的实施情况进行评估
为后续项目的积累经验数据
3. 软件度量的内容
三个方面
产品：各种文档和程序
过程：各种软件开发活动
资源：各种资源如人员、费用等
二个层次
内部属性
软件产品，过程和资源本身所具有属性，如软件产品的复杂度、程序长度等
易于度量
外部属性
软件产品，过程和资源与外部环境(用户、管理人员等) 间的关系如成本、效益、可靠性、可维护性等
难以度量，但由内部属性所决定
4. 软件度量的方法
面向规模的度量
面成功能的度量
项目成本和工作量估算
软件质量度量
5. 比较面向规模的度量和面向功能的度量
面向规模的度量：
优点：简单易行，自然直观
缺点：依赖于程序设计语言的表达能力和功能
软件开发初期很难估算出最终软件的代码行数
对精巧的软件项目不合适
只适合于过程式程序设计语言
面向功能的度量
优点：与程序设计语言无关, 在开发前就可以估算出软件项目的规模(事前)
不足：没有直接涉及算法的复杂度，不适合算法比较复杂的软件系统；
功能点计算主要靠经验公式，主观因素比较多
数据不好采集
6. 软件规模估算、工作量估算和成本估算之间的关系
软件项目成本和工作量估算极为重要
计算机系统中软件成本占总成本的比例很大
用户和项目管理人员对软件成本和工作量估算都很重视
软件项目成本估算比较困难
软件是逻辑产品，软件开发是一个逻辑思维的过程
涉及多方面因素
软件项目成本和工作量估算常用方法
参照和依据已完成项目的历史数据
将大项目分解为小项目
将项目按照软件生命周期分解
根据经验估算公式
上述方法可以同时、单独或者组合使用
7.McCall 软件质量度量体系：质量要素、质量要素的评价准则、软件质量度量
McCall 的软件质量度量模型
质量要素
定义了与软件质量相关联的一些要素
质量要素的评价准则
定义了能够对质量要素进行度量的一些准则
软件质量的度量
定义了如何基于对质量要素的定量描述对软件质量进行度量的方法
第 3 章 软件质量保证
软件质量保证的定义
一个有系统的、有计划的行动集合，它提供软件产品开发、维护过程符合已建立的技术需求、跟上计划安排和在预算限制之内进行管理上的需求充分信任所必需的。
软件质量保证体系结构（其中包含哪些 SQA 部件；各 SQA 部件之间的关系）
SQA 总是由一系列范围很宽的SQA 部件组成，这些部件都被用来挑战软件错误的
各种来源，并达到可接受的水平的软件质量。
SQA 的任务在质量保证任务领域中是独特的，这是由软件的特性决定的。
此外，进行软件开发与维护的环境直接影响SQA 部件。
项目前SQA 部件; 项目生命周期SQA 部件;SQA 基础设施部件; 软件质量管理部件; 标准化、认证和评估部件;SQA 组织部件
1项目前 SQA 部件——建议草案评审、合同草案评审、项目开发计划、软件质量计划等
不良合同总是让人讨厌的事情。从SQA 观点看，不良合同—其常见特征是不严格定
义的需求、不现实的预算和进度表—必然产生低质量的软件产品。
所以，对于SQA 来说，自然是从评审建议草案，再评审合同草案开始其预防性质量
保证措施。
项目前部件主要用于改进启动项目前的准备工作，包括建议草案评审和合同草案评
审。
2软件生存周期 SQA 部件——软件设计评审、专家观点、同行评审、软件测试、软件维护， 以及针对外部参与方的质量保证措施等
评审评审的主要内容是项目开发过程各阶段产生的各种文档。评审可以被划分为正式（设计）评审和同行评审
专家观点专家观点通过引进补充的外部能力到机构内部开发过程中来而支持质量评估工作。
软件测试的直接目标是正式批准模块或集成结构，以使下一个编程阶段可以开始或已完成的软件系统可以交付和安装。
软件维护部件通常，软件维护部件满足所有的质量需求，尤其是功能与进度安排需求以及预算限制。
外部参与方工作质量的保证分包商、顾客经常加入到软件项目开发中直接承包合同的开发者队伍中。项目越大、越复杂，就越可能需要外部参与方。应用于外部参与方大多数SQA 控制是在有关各方之间签署的合同中规定的。
3软件质量基础设施部件
主要的SQA 维护基础设施工具有：软件维护规程和工作条例；支持性软件质量手段；维护组的培训和认证；预防性和改正性措施；配置管理；软件维护文档和质量纪录。 4软件质量管理部件
改正性维护的主要管理性SQA 部件包括：性能控制—通过定期报告、定期员工会议和访问维护支持中心来实现；改正性维护的质量度量；改正性维护的质量费用。完善性维护和适应性维护的管理性工具主要应用于软件控制开发项目使用。
软件标准——认证标准和评估标准；常见的软件标准
软件质量保证组织部件
适用外部参与方使用的质量保证部件
分包商、顾客经常加入到软件项目开发中直接承包合同的开发者队伍中。项目越大、越复杂，就越可能需要外部参与方。
应用于外部参与方大多数SQA 控制是在有关各方之间签署的合同中规定的。
规程和工作条例之间的关系
专业开发与维护的SQA 规程必须符合机构的质量方针，也要符合国际或国家的SQA 标准。 规程和工作条例的具体关系如下:
为什么需要定义规程和工作条例
如果每个专业人员依靠自己的经验并以他知道的最佳方式完成他的任务不会更好些? 机构强迫我们只按照他们选择的方式完成任务有什么好处?
在大多数机构里经常听到员工们提出类似的问题。对这些问题的回答提示了要由规程和工作条例应对的挑战：应用机构积累的专门技能、经验和专长。
SQA 规程和工作条例的宗旨在于：以最有效、高效的方式执行任务、过程或活动，而不偏离质量需求；软件系统开发与维护所涉及人员之间的有效、高效的交流。执行的统一性、达到符合规程与工作条例，较少导致软件出错的错误理解。简化机构中各种实体执行的任务与活动之间的协调。较好的协调意味着较少的错误！
模板的定义、作用
在软件工程领域，模板指的是小组或机构创建的用于编辑报告和其他形式文档的格式。模板的应用对有些文档是必要的，而对其他文档是选择性的，还有一些情况，只需要使用模板的一部分，例如模板特定的章节或通用结构等。
对于开发组，使用模板可以:方便文档的编制过程，因为节省了详细构建报告结构所需的时间和精力。大多数机构许可从SQA 公共文件拷贝或者从机构的企业内部网下载模板，这样甚至可以不用键入新文档的目录。确保开发人员编制的文档更完善，因为文档中的所有主题都已经定义好了，并且被使用这此模板的大量专业人员反复评审过。不太可能发生诸如漏掉主题这样的常见错误。新组员的加入更容易，这是因为对模板熟悉。由于新成员已经在其他机构单位或小组工作过，他们从前面的工作中可能已经了解模板，而文档的标准结构是根据模板编制的，从而寻找信息变得简单得多。它同样可以使正在进行的文档编制工作顺利，不管编制了文档某些部分的那位小组成员是否已经离开。
方便文档评审，如果文档是基于一个合适的模板建立的，就不需要研究文档结构和确定其完备性。它同样简化已完成文档的评审工作，因为文档的结构是标准的，并且评审者熟悉评审的预期内容(章、节和附录) 。出于这种一致性．评审将会更彻底而又不那么费时。 对于软件维护组，使用模板可以：更容易找到执行维护任务所需的信息。
对于员工进行培训和认证，其目标是什么？
使新员工均掌握以足够的效率与有效性水平执行软件开发和维护任务所需的知识与技能； 这种培训有利于新小组成员的融入；通过传授风格、结构规程和工作条例，确保软件产品(文档和代码) 同机构标准相符；和同机构风格、结构规程及工作条例的符合性；传播SQA 规程的知识；确保关键软件开发和维护职位的候选者是有合适资格的。
培训和认证的实施过程
一个成功的培训和认证系统的实施要求常规的执行以下活动：确定每个职位的专业知识要求；确定专业培训和更新需要；计划专业培训项目；计划专业更新项目。确定需要认证的职位；计划认证过程；发布培训、更新、认证项目；跟踪已培训和已认证人员。所有这些活动组成一个综合的过程，在这个过程中，以前的活动和有关专业发展的反馈信息激励这样一个循环：持续培训、认证和对变化的质量要求的适应。培训和认证活动要满足新老雇员的需求。现行计划结果的全面跟踪以及留意专业的发展，是确保计划能够先进所必需的。 改正性措施和预防性措施的定义
改正性措施： 一个常规使用的反馈过程，包括质量不符合性信息收集、非常规源的识别和
分析以及改进的习惯做法与规程的建立和吸收，连同对它们约执行的控制和对它们的结果的测量。
预防性措施：一个常规使用的反馈过程，包括潜在质量问题信息的收集、偏离质量标准的识别与分析以及改进的习惯做法与规程的建立与吸收，连同对它们执行的控制和对它们的结果的测量。
软件配置、软件配置管理的定义
软件配置管理是一个负责应用(计算机化的或非计算机化的) 技术工具和管理规程、使之能够完成为维护SCI 和软件配置版本所需任务的SQA 部件。
软件配置管理的工作内容、作用
软件配置管理的任务:控制软件更改；发布SCI 和软件配置版本；提供SCM 信息服务；验证对SC 规程的符合性。
版本控制的定义
版本控制是软件配置管理的核心内容。
版本控制将各软件配置项纳入到配置库之中，为每一个配置项自动赋予版本标识，使得各软件配置项都根据既定的版本控制策略独立演化。
常见的软件配置管理工具
简单的版本配置工具，例如Microsoft Visual SourceSafe（VSS ）、Concurrent Version System（CVS ）等；项目级配置管理工具，适合中小型企业，例如PVCS 、MKS ；企业级配置管理工具，具有强大的版本控制和管理能力，适合中大型软件企业，包括CCC Harvest 、IBM Rational ClearCase等。
软件配置管理的过程
软件质量保证体系中的管理部件——项目进度控制、软件质量度量、软件质量费用、软件风险管理
项目进度控制的目标是：早期检测非常规事件，促进解决问题乡音的及时启动；进展控制以及成功和极端故障的积累信息，有利于改正性措施的启动。
进度控制的主要工具:风险管理活动的控制部件；项目进度安排控制部件；项目资源控制部件；项目预算控制部件
软件风险管理是指识别、评估并处置软件项目中的风险要素，通过有效的风险控制措施降低软件项目失败的风险。
软件风险管理过程
软件风险控制方法——风险避免、风险弱化、风险承担、风险转移
风险避免：通过变更计划消除使得风险的触发条件无法满足；
风险弱化：降低风险发生的概率；
风险承担：制定风险应急预案；
风险转移：将风险发生的结果连同应对责任转移给有承受能力的第三方。
软件质量度量的分类：按照软件生存周期规律划分；按照测量主题划分
第一种分类，依据软件系统的生命周期和其他阶段进行划分：过程度量（process metrics）, 与软件开发过程相关；产品度量（product metrics），与软件维护相关。
第二种分类，按照测量主题划分：质量; 进度表; 有效性（关于错误派错和维护服务）; 生产率 软件开发过程度量包括：软件过程质量度量、软件过程进度度量、软件过程生产率度量 软件质量保证组织的目标
第 4 章 软件测试概述
1. 软件缺陷的定义
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题； 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
2. 软件缺陷的分类：按照缺陷的软件制品划分；按照软件缺陷的严重程度划分； 按照软件制品划分
按照严重程度划分
3. 软件缺陷的生存周期（使用状态图表示）
在软件缺陷生存周期规律基础上，软件企业结企业的软件项目经验可以定义更精细粒度的软件缺陷生存周期模型。
4. 软件测试与软件调试之间的关系
5. 软件测试的定义、目的
定义：软件测试是为了尽快尽早地发现在软件产品中所存在的各种软件缺陷而展开的贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。 目的：以最少的时间和人力系统地找出软件中潜在的各种错误和缺陷。
如果我们成功地实施了测试，就能够发现软件中的错误。
6. 软件测试的原则
所有的测试都应可追溯到客户需求
应该在测试工作真正开始前的较长时间就进行测试计划
Pareto 原则：测试中发现的80%的错误可能来自于20%的程序代码
测试应从“小规模”开始，逐步转向“大规模”
穷举测试是不可能的
为了达到最有效的测试，应由独立的第三方来承担测试
其他原则
在设计测试用例时，应包括合理的输入条件和不合理的输入条件
严格执行测试计划，排除测试的随意性
应当对每一个测试结果做全面检查
妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便
检查程序是否做了应做的事仅是成功的一半，另一半是检查程序是否做了不该做的事 在规划测试时不要设想程序中不会查出错误
7. 软件测试的信息流
8. 软件测试执行的过程
（1）测试计划
定义软件测试的内容，确定测试的停止标准
明确测试方法与测试，定义并分配测试资源，等等
（2）测试设计
设计测试用例、测试数据
设计驱动模块、装模块
（3）测试开发
开发驱动模块、装模块以及测试脚本
（4）测试执行
执行不同层次的、多种类型的软件测试，包括单元测试、集成测试、确认测试、系统测试等。
（5）测试评估
评估测试计划的情形情况，评估测试人员的执行能力；
评估测试的有效性
分析软件缺陷数据，以提高测试回报率
9. 软件测试停止标准的定义
因为无法判定当前查出的缺陷是否是最后一个缺陷，所以决定什么时候停止程序测试就成了最困难的问题，但是测试最后一定要停止的
10. 常见的软件测试停止标准
（1）基于统计的测试停止标准
相对于一个理论上合理的和在试验中有效的统计模型来说，如果一个在按照概率的方法定义的环境中，1000个CPU 小时内不出错运行的概率大于0．995的话，那么我们就有95%的信心说，我们已经进行了足够的测试.
（2）使用指定的测试用例设计方法产生测试用例，运行这些测试用例均未发现错误（包括发现错误后已被纠正的情况），则测试可终止
11. 软件可靠性的定义
软件可靠性是指，在特定的环境下、在给定的时间内软件系统无故障运行的概率。
12. 软件测试与软件可靠性的关系
软件测试是提高软件可靠性的重要技术手段。
第 5 章 软件测试用例设计技术
软件测试用例的定义
测试用例是为了特定目的而设计的测试数据及相关测试规程的一个特定集合，即为有效发现软件缺陷的最小测试执行单元。
软件测试用例模板（模板中包含哪些数据项，分别介绍）
标识符:每一个测试用例应该有一个唯一的标识符号，它将作为所有和测试用例相关的文档、表格引用和参考的基本元素。
测试项:测试用例应该描述所需测试的项（内容）及其特征。
测试环境要求:测试环境要求用来表征该测试用例需要的测试环境。
输入标准:输入标准用来表征测试用的输入要求。
输出标准:标识按照指定的环境和输入标准得到的期望输出结果。
测试用例之间的关系:测试用例之间的关系用来表征测试用理之间的依赖关系。
测试用例的优先级
软件测试用例设计的考虑因素 :不可能实现穷举测试，所以编写测试用例过程中应尽量考虑有代表性、典型测试用例。这就要求测试用例设计时充分考虑如下基本因素：测试用例必须具有代表性、典型性。一个测试用例能基本覆盖一组或多组情形，这也是设计测试用例的初衷。测试用例要浓缩系统设计。测试用例既要考虑正确的输入，也需要考虑错误或异常的输入，以及促使这些错误、异常发生的条件。用户测试用例设计需要考虑用户实际使用场景； 用户测试用例是基于用户实际的可能场景，从用户角度模拟系统的输入，从而针对系统设计测试用例。用户测试用例不仅需要考虑用户实际的环境因素。
在本地化测试中需要尊重用户的所在国家、区域、风俗、语言等因素设计测试用例。重用同类型软件项目的测试用例；利用已有的Checklist ，例如《Java Inspection Checklist》，作为测试用例设计的基础；
软件测试用例设计技术——白盒测试，黑盒测试和灰盒测试
白盒测试的定义、目的、特点
白盒测试是一种测试用例设计方法; 盒子指的是被测试的软件; 白盒指的是盒子是可视的, 你清楚盒子内部的东西以及里面是如何运作的。
目的：白盒测试通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
特点：依据软件设计说明书进行测试；对程序内部细节的严密检验；针对特定条件设计测试用例；对软件的逻辑路径进行覆盖测试。
常见的白盒测试技术——控制流测试；数据流测试；编译测试等
控制流测试：语句覆盖；条件覆盖；路径覆盖……
数据流测试：定义覆盖；引用覆盖；定义--引用覆盖……
变异测试; 基本路径测试技术
黑盒测试的定义、目的、特点
黑盒测试又称功能测试、数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试。
目的：黑盒测试可以发现的软件缺陷：功能错误或遗漏; 界面错误; 数据结构或外部数据库访问错误; 性能错误; 初始化和终止错误。
特点：不考虑程序内部结构和内部特性；测试人员只需知道该程序输入和输出之间的关系或功能；设计测试用例的依据是需求规格说明书或用户手册。尤其适合于一些第三方软件测试，由于无法得到源程序，无法用其它方法进行测试。
常用的黑盒测试技术——边界值分析、 等价类划分、 基于决策表的测试、 基于因果图的测试、正交实验法等等
白盒测试技术和黑盒测试技术的比较
白盒测试只考虑测试软件产品, 它不保证完整的需求规格是否被满足。而黑盒测试只考虑测试需求规格, 它不保证实现的所有部分是否被测试到。黑盒测试会发现遗漏的缺陷, 指出规格的哪些部分没有被完成。而白盒测试会发现代理方面缺陷, 指出哪些实现部分是错误的。 白盒测试比黑盒测试成本要高得多。它需要在测试可被计划前产生源代码, 并且在确定合适的数据和决定软件是否正确方面需要花费更多的工作量。
一个白盒测试的失败会导致一次修改, 这需要所有的黑盒测试被重复执行并且重新决定白盒测试路径。黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。
白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。
白盒测试技术的优缺点
优点：迫使测试人员去仔细思考软件的实现; 可以检测代码中的每条分支和路径; 揭示隐藏在代码中的错误; 对代码的测试比较彻底; 最优化。
缺点：昂贵; 无法检测代码中遗漏的路径和数据敏感性错误; 不验证规格的正确性。 黑盒测试技术的优缺点
优点：对于较大的代码单元来说(子系统甚至系统级), 黑盒测试比白盒测试效率要高; 测试人员不需要了解实现的细节, 包括特定的编程语言; 测试人员和编码人员是彼此独立的; 从用户的视角进行测试, 很容易被理解和接受; 有助于暴露任何规格不一致或有歧义的问题; 测试用例可以在规格完成之后马上进行。
缺点：只有一小部分可能的输入被测试到, 要测试每个可能的输入流几乎是不可能的; 没有清晰的和简明的规格, 测试用例是很难设计的; 如果测试人员不被告知开发人员已经执行过的用例, 在测试数据上会存在不必要的重复; 会有很多程序路径没有被测试到; 不能直接针对特定程序段测试, 这些程序段可能很复杂(因此可能隐藏更多的问题); 大部分和研究相关的测试都是直接针对白盒测试的
第 6 章 白盒测试技术
1. 各种逻辑覆盖准则的定义——语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合
语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。这种覆盖又称为点覆盖，它使得程序中每个可执行语句都得到执行，但它是最弱的逻辑覆盖准，效果有限，必须与其它方法交互使用。
判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖。
条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。
判定/条件覆盖是既然判定条件不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖，就
自然会提出一种能同时满足两种覆盖标准的逻辑覆盖。
条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。
2. 覆盖、点覆盖、边覆盖、路径覆盖
点覆盖：如果连通图 G 的子图G ´是连通的，而且包含G 的所有节点，则称G ´是G 的点覆盖。与语句覆盖标准相同。
边覆盖：如果连通图 G 的子图G ´是连通的，而且包含G 的所有边，则称G ´是G 的边覆盖。通常与判定覆盖标准相同。
路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径。这是最强的覆盖准则。但在路径数目很大时，真正做到完全覆盖是很困难的，必须把覆盖路径数目压缩到一定限度。
3. 根据各种逻辑覆盖准测进行控制流测试，设计测试用例
测试步骤：
导出程序流程图的拓扑结构-流图
计算流图G 的环路复杂度V(G)
确定只包含独立路径的基本路径集
设计测试用例
第 7 章 黑盒测试技术
等价类划分的定义
等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。
等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。
使用等价类划分方法设计测试用例的过程
划分等价类（列出等价类表）和选取测试用例两步
有效等价类、无效等价类的定义
① 有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。 ② 无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。
等价类划分的启发式规则
（1）如果输入条件规定了取值范围，或值的个数，则可以划分成一个有效等价类和两个无效等价类。
（2）如果输入条件规定了输入值的集合，或者规定了“必须如何”的条件，则可划分成一个有效等价类和一个无效等价类。
（3）如果输入条件是一个布尔量，则可以划分成一个有效等价类和一个无效等价类。
（4）如果规定了输入数据的一组值，而且程序要对每个输入值分别处理，则可为每个输入值确立一个有效等价类，此外对这组值所有不允许的输入数据集合确立一个无效等价类。
（5）如果规定了输入数据的一组值，而且程序要对每个输入值分别处理，则可为每个输入值确立一个有效等价类，此外对这组值所有不允许的输入数据集合确立一个无效等价类。
（6）如果确知，已划分的等价类中各个元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类。
（7）等价类划分还应特别注意默认值、空值、NULL 、0、NONE 等的情形。
使用等价类划分方法设计测试用例，研究 PPT 中案例
（1）三角形问题-测试用例
（2）Pascal 语言
（3）次日问题
边界值的定义
边界值分析也是一种常用的黑盒测试方法，是对等价类划分方法的补充；
所谓边界值，是指相对于输入等价类和输出等价类而言，稍高于其最高值或稍低于最低值的一些特定情况。
使用边界值方法设计测试用例的过程
（1）确定边界
（2）选择测试用例
边界值分析的关键假设——单陷假设和多陷假设
（1）单缺陷假设认为失效极少是由两个或多个缺陷的同时发生引起的，在进行基本边界值分析获得测试用例的方法--使所有变量取正常值只使一个变量取极值；
（2）多缺陷假设则认为失效是由两个或多个缺陷导致的，边界值测试需同时考虑多个变量的取值情况。
边界值分析方法包括基本边界值测试和健壮性测试
基本边界值测试：如果有一个变量个数为n 的函数使除一个以外的所有变量取正常值使剩余的那个变量取最小值、略高于最小值、正常值、略低于最大值和最大值对每个变量都重复进行；
健壮性测试:健壮性测试是边界值分析的一种简单扩展。健壮性测试除了使用五个边界值分析取值，还要通过采用一个略超过最大值max+的取值以及一个略小于最小值min-的取值 应用边界值分析方法（即基本边界值测试和健壮性测试）设计测试用例 判定表的组成
条件桩（Condition Stub）、条件项（Condition Entity）动作桩（Action Stub）、动作项（Action Entity ）规则(rule)
应用基于判定表的测试技术设计测试用例
（1）确定规则个数；
（2）列出所有的条件桩和动作桩；
（3）填入条件项；
（4）填入动作桩和动作项，得到初始判定表；
（5）化简，合并相似规则；
（6）依据判定表，选择测试数据，设计测试用例。
第 8 章
软件测试执行的层次
（1）单元测试
（2）集成测试
（3）确认测试
（4）系统测试
典型的软件测试配置有哪些？
软件测试执行的过程
（1）制定测试计划：定义测试项目的阶段，以便于对项目进行适当的评估与控制，包括测试需求，测试策略，测试资源和测试进度。
（2）测试设计：设计测试用例及测试过程的阶段，它是验证测试需求被测试到的最有效的方法。
（3）测试实施：对测试设计阶段已被定义的测试进行创建或修正的阶段，如脚本、驱动、桩的实施。
（4）测试执行：对被测软件进行一系列的测试并记录日志结果的阶段。
（5）测试评估：分析测试结果并判断测试的标准是否被满足的阶段。
（6）缺陷跟踪：记录测试发现的问题，并且跟踪其修改的阶段。
软件测试计划的工作内容
测试用例设计，驱动模块、桩模块设计
测试实施工作包括编写测试脚本，实现驱动模块和桩模块
软件测试相关的角色，各角色的工作职责
（1）测试设计员
a. 制定和维护测试计划。
b. 设计测试用例及测试过程。
c. 评估测试，生成测试分析报告。
（2）测试人员
a. 执行集成测试和系统测试。
b. 记录测试结果。
（3）设计人员
a. 设计测试需要的驱动程序和稳定桩。
（4）编码人员
a. 编写测试驱动程序和稳定桩。
b. 执行单元测试。
单元测试的定义、工作内容
定义：单元测试针对程序模块，进行正确性检验的测试。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
工作内容：在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。
主要对模块的五个基本特性进行评价:错误处理、模块接口、局部数据结构、边界条件、 重要的执行路径；
驱动模块、桩模块的定义
驱动模块：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。
桩模块：用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。
为什说桩模块的设计成本比驱动模块的设计成本高？
驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，它需要一定的开发费用。 若驱动模块和桩模块比较简单，实际开销相对低些。
仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。
提高模块的内聚度可简化单元测试，如果每个模块只完成一个功能，所需测试用例数目将显著减少，模块中的错误也更容易发现。
常见的集成测试策略
（1）一次性集成方式
（2）增殖式集成方式
a. 自顶向下增值方式
b. 自底向上增值方式
c. 混合增值方式
比较自顶向下增值方式和自底向增值方式的集成测试策略的优缺点
自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能将是十分困难的。同时涉及复杂算法和真正输入／输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，导致过多的回归测试。 而自顶向下增殖方式的优点是能够较早地发现在主要控制方面的问题。
自底向上增殖方式的缺点是“程序一直未能做为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。
而自底向上增殖方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入／输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试。
确认测试、系统测试、α测试和β测试的定义
确认测试：确认测试又称有效性测试，它的任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
系统测试：所谓系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。
α测试：α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。这是在受控制的环境下进行的测试。
β测试:β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。 应用增殖式集成方式进行集成测试，要求集成测试过程描述
（1）以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代;
（2）依据所选的集成策略(深度优先或广度优先), 每次只替代一个桩模块;
（3）每集成一个模块立即测试一遍;
（4）只有每组测试完成后，才着手替换下一个桩模块;
（5）为避免引入新错误，须不断进行回归测试(即全部或部分地重复已做过的测试) 。
（6）从第二步开始，循环执行上述步骤, 直至整个程序结构构造完毕。
JUnit 单元测试的过程
1． Junit 三重唱
（1） TestCase 测试用例
用户定义的TestCase 必须扩展junit.framework.TestCase 类，它以testXXX 方法的形
式包含了一个或多个测试。一个测试用例把具有公共行为的测试归入一组。
（2） TestSuite 测试套装
一个测试套装可以把多个测试用例或测试套装封装为一组
（3） TestRunner 测试运行器
测试运行器用来运行测试套装，Junit 提供良种典型的测试运行器：
junit.swingui.TestRunner 和 junit.textui.TestRunner
2．JUnit 核心类
Assert 、Testresult 、Test 、TestListener 、TestCase 、TsetSuite 、BaseTestRunner
3.JUnit 单元测试的步骤
（1） 重载setUp()，封装测试环境初始化及测试数据准备；
（2） 设计测试方法，以testXXX 命名。
（3） 在测试方法中使用断言方法如assertEquals()，assertTrue()等。JUnit 中断言方法；
（4） 设计测试套件，或使用缺省的测试套件，调用TestRunner 执行测试脚本，生成
测试结果；
（5） 重载tearDown()析构测试环境，执行收尾动作；
理解 JUnit 测试框架，包括哪些核心类，每一个类的作用，特别是 TestCase、TestSuite 等概念
基于 JUnit 框架，设计测试脚本，对软件模块进行测试
第 9 章 软件测试自动化
手工测试的局限
（1）手工测试无法做到覆盖所有代码路径；简单的功能性测试用例在每一轮测试中都不能少，而且具有一定的机械性、重复性、工作量往往较大；
（2）许多与时序、死锁、资源冲突、多线程等有关的错误，通过手工测试很难捕捉到；
（3）进行系统负载、性能测试时，需要模拟大量数据或大量并发用户等各种应用场合时，很难通过手工测试来进行；
（4）进行系统可靠性测试时，需要模拟系统运行十年、几十年的业务量，以验证系统能否
稳定运行，这也是手工测试无法模拟的；
（5）如果有大量（几千）的测试用例，需要在短时间内（1天）完成，手工测试几乎不可能做到。
自动化测试的益处
（1）缩短软件开发测试周期，可以让产品更快投放市场；
（2）测试效率高，充分利用硬件资源；
（3）节省人力资源，降低测试成本；
（4) 增强测试的稳定性和可靠性；
（5）提高软件测试的准确度和精确度，增加软件信任度；
（6）软件测试工具使测试工作相对比较容易，且能产生更高质量的测试结果；
（7）手工不能做的事情，自动化测试能做，如负载、性能测试。
自动化测试的定义
自动化测试是指使用一种自动化测试工具来验证各种软件测试的需求，它包括测试活动的管理与实施、测试脚本的开发与执行。
软件测试自动化的基本原理和方法
软件测试自动化实现的基础是可以通过设计的特殊程序模拟测试人员对计算机的操作过程、操作行为，或者类似于编译系统那样对计算机程序进行检查。
软件测试自动化实现的原理和方法主要有：
直接对代码进行静态和动态分析
测试过程的捕获和回放
测试脚本技术
虚拟用户技术
测试管理技术
测试脚本的分类
（1）线性脚本——是录制手工执行的测试用例得到的脚本；
（2）结构化脚本——类似于结构化程序设计，具有各种逻辑结构（顺序、分支、循环），而且具有函数调用功能；
（3）共享脚本是指某个脚本可被多个测试用例使用，即脚本语言允许一个脚本调用另一个脚本。
（4）数据驱动脚本将测试输入存储在独立的数据文件中。
（5）关键字驱动脚本是数据驱动脚本的逻辑扩展
软件测试工具的作用
自动化测试工具的作用：
（1）确定系统最优的硬件配置。
（2）检查系统的可靠性。
（3）检查系统硬件和软件的升级情况。
（4）评估新产品。
软件测试自动化的局限
（1）不能取代手工测试
（2) 手工测试比自动测试发现的缺陷更多
（3）对测试质量的依赖性极大
（4）测试自动化不能提高有效性
（5）测试自动化可能会制约软件开发。
（6）工具本身并无想象力
自动化测试成熟度等级： 捕获和回放(级别 1)； 捕获、编辑和回放 （级别 2）；编程和回放 （级别 3）；数据驱动的测试（级别 4）；使用动词的测试自动化（级别 5）。 了解常见的软件测试工具
案例分析考点分布
1 理解 JUnit 单元测试框架
2 编写基于 JUnit 框架的软件测试脚本
3 控制流测试——满足各种逻辑覆盖准则
4 集成测试（要求给出测试过程）
（1）自顶向下深度优先集成测试策略
（2）自顶向下广度优先集成测试策略
（3）自底向集成测试策略
5 为企业建立 SQA 体系
6 软件质量与软件质量费用之间关系
7 MaCall 软件质量模型的应用，能识别出关联的软件质量因素
8 使用等价类划分方法、边界值分析法（包括基本边界值测试和健壮性测试）设计测试用例
9 ISO 9000-3 质量管理标准的认证过程
认证服务是由ISO 通过一个世界范围的认证服务网络组织的，这些服务由认可实体和认证实体授权的。
ISO 9000-3的认证如下：
（1）制订获得认证的活动计划
（2）建立机构SQA 系统
（3）接受认证审计
（4）维持ISO 认证的规程
第一章
1. 软件的定义、分类
定义：软件是计算机系统中与硬件相互依存的另一部分，它是程序、数据及相关文档的集合。 分类：
程序：由程序设计语言所描述的、能为计算机所识别、理解和处理的语句序列。 数据：使程序能正常处理信息的数据和数据结构。
文档：一种数据媒体和其上所记录的数据，即记录软件开发活动和阶段性成果、理解软件所必需的阐述性资料。
2.IEEE 软件缺陷的定义
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题； 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
3. 软件缺陷产生的原因
（1）项目期限的压力（2）产品的复杂度（3）沟通不良
（4） 开发人员的疲劳、压力或受到干扰（5）缺乏足够的知识、技能和经验
（6）不了解客户的需求 （7）缺乏动力
4. 软件测试的定义：
IEEE 的定义 ：一个系统、构件或过程满足顾客或用户需求与期望的程度。
在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价 分析某个软件项以发现现存的和要求的条件之差别（即错误）并评价此软件项的特性 Crosby 的定义：一个系统、部分或过程满足规定需求的程度。
Pressman 的定义：软件质量是符合明确陈述的功能/性能需求、明确文档化了的开发标准和所有专业开发预期的隐含特性。
5. 软件质量的内容，各维度下软件质量标准
产品质量：产品质量是人们实践产物的属性和行为，是可以认识，可以科学地描述的。并且可以通过一些方法和人类活动，来改进质量.
质量模型: McCall 模型, Boehm 模型, ISO 9126 模型
过程质量:
软件能力成熟度模型 CMM ( Capability Maturity Model).
国际标准过程模型 ISO 9000
软件过程改进和能力决断SPICE ( Software Process Improvement and Capability
dEtermination)
6.MaCall 软件质量模型；应用 MaCall 模型分析软件质量
产品运行软件质量要素
产品修改软件质量要素
产品转移软件质量要素
7.MaCall 软件质量模型中软件质量维度；各个维度软件质量因子的定义
8. 软件质量管理的内容
软件质量管理就是确保软件具有较少缺陷，并达到软件系统既定目标。
软件质量管理有以下四种主要活动组成：
软件质量保证(Quality Assurance)建立起机构质量规程和标准的整体框架，这是生产高质量软件的保证。
软件质量规划(Quality Planning)从这个框架中选择适当的质量规程和标准，进行改写使之适应特定软件项目。
软件质量控制(Quality Control) 定义并设计软件过程，确保软件开发团队严格遵守项目质量规划和标准。
软件质量改进
9. 软件质量成本的定义、构成
定义：质量成本是为确保和保证满意的质量而发生的费用以及没有达到满意的质量所造成损失的总和，即包括保证费用和损失费用。
质量成本＝质量保证成本＋损失成本
质量保证成本：为保证满意的质量而发生的费用
损失成本：没有达到满意的质量所造成损失
质量成本＝质量预防成本＋评价成本＋失效成本
保证成本＝预防成本＋评价成本
预防成本：预防产生质量问题（软件缺陷）的费用，是企业的计划性支出，专门用来确保在软件产品交付和服务的各个环节不出现失误。
评价成本：是指在交付和服务环节上，为评定软件产品或服务是否符合质量要求而进行的试验、软件测试和质量评估等所必需的支出。
失效成本：分为内部的和外部的，如果在软件发布之前发现质量问题，而要求重做、修改和问题分析所带来的成本属内部失效成本，包括修正软件缺陷、回归测试等，以及因产品或服务不合要求导致的延误。
10. 软件质量标准的益处、分类（包括认证标准和评估标准）
益处：（1）有能力应用最高专业级别的软件开发与维护方法学和规程；
（2）开发组之间、尤其是开发与维护组之间更好的互相理解与协作；
（3）软件开发者和外部参与方之间更大的合作；
（4）基于采用著名开发与维护标准作为合同的一部分，使供货商和顾客之间能更好地互相理解与合作。
从内容和重点上我们可以把质量管理标准划分成：
认证标准
认证标准的范围是由认证的目的确定的，其目的在于：使软件开发机构能够证实其有能力确保软件产品或维护服务符合可接受的质量需求。这是通过一个外部的实体做出认证实现的； 用作顾客和供货商对供货商的质量管理系统评价一致性的基础。它可以通过由顾客实施的对供货商的质量管理系统的质量审计实现；
支持软件开发机构的工作，通过符合标准的需求来改进质量管理系统性能和增强顾客满意度。
评估标准
（1）用做软件开发与维护机构对其进行软件开发项目的能力的自我评估工具；
（2）用做改进开发与维护过程的工具，标准指出过程改进的方向；
（3）帮助采购机构确定潜在供货商的能力；
（4）通过罗列资格认证与培训计划课程，指导评估人员的培训。
认证标准的重点是外部的--支持供货商顾客关系，
而评估标准的重点是内部的，因为它关注的是软件过程改进。
11.ISO 9000-3 质量管理系统的基本原理
（1）顾客关注。机构依靠它们的顾客，所以应当理解当前的与未来的顾客需要；
（2）领导--建立并维护一个积极的内部环境中行使领导权，以实现机构的目标；
（3）人们的投入。人是机构之本，他们在各机构层次的全身心投入使得他们的能力能用于为机构谋益；
（4）过程方法--当把活动与资源作为过程管理的时候，就更有效地达到理想的结果；
（5）管理理的系统方法--把过程作为一个系统管理；
（6）持续改进--对全面性能正在进行的改进应当在机构的日程上优先；
（7）决策制定的实在方法。有效决策是建立在信息分析的基础上的；
（7）相互支持的供货商关系。一个机构和它的供货商是互相依赖时，相互支持的供货由关系增强双方创造增加值的能力。
12.ISO 9000-3 质量管理标准的认证过程；
（1）制订获得认证的活动计划 （2）建立机构SQA 系统
（3）接受认证审计 （4）维持ISO 认证的规程
13. 软件过程能力、软件过程成熟度、软件过程能力成熟度等级的定义
软件过程能力：描述开发组织或项目组遵循其软件过程能够实现预期结果的程度，它既可对整个软件开发组织而言，也可对一个软件项目而言。
软件过程成熟度：一个特定软件过程被明确且有效地定义、管理、测量和控制的程度。 软件能力成熟度等级：软件开发组织在走向成熟的途中几个具有明确定义的表示软件过程能力成熟度的平台。
14.CMM 的基本思想、作用、内容 （即软件过程成熟度等级的划分，各等级下软件过程的
特点）
思想：由于软件危机等问题是由我们管理软件过程的方法不当引起的，所以新软件技术的应用并不会自动提高软件的生产率和质量。
能力成熟度模型有助于软件开发机构建立一个有规律的、成熟的软件过程。改进的软件过程将开发出更高质量的软件，使更多的软件项目免受时间和经费超支之苦。
作用：指导软件机构通过确定当前的过程成熟度并识别出对过程改进起关键作用的问题，从而明确过程改进方向和策略。
通过集中开展过程改进的方向和策略相一致的过程改进活动，软件机构便能稳步而有效的改进其软件过程，使其软件过程能力得到循序渐进的提高。
对软件过程的改进，是在完成一个又一个小的改进基础上不断进行的渐进过程，而不是一蹴而就的彻底革命。
内容：CMM 把软件过程从无序到有序的进化过程分成5个阶段，并把这些阶段排列形成5个逐层提高的等级，如下图所示：
初始级：软件过程是无序的，有时甚至是混乱的，对软件过程几乎没有定义，软件项目成功与否取决于个人努力。
重复级：建立了基本的项目管理过程(过程模型) ，可跟踪成本、进度和质量特性。已经建立了必要的过程规范，能重复早先类似项目的实践经验成功完成新项目。
达到2级的一个目标是使项目管理过程稳定，从而使得软件机构能重复以前在成功项目中所进行过的软件项目工程实践。
处于第2级成熟度的软件机构的过程能力可以概括为：
软件项目的策划和跟踪是稳定的，已经为一个有纪律的管理过程提供了可重复以前成功实践的项目环境。软件项目工程活动处于项目管理体系有效控制之下，执行着基于以前项目准则且合乎现实的计划。
已定义级：已经定义了完整的软件过程，软件过程已文档化、标准化。所有项目均使用经批准的、文档化的标准软件过程来开发和维护软件。这一级别包含第2级的全部特征。
在第3级成熟度的软件机构中，有一个固定的过程小组从事软件过程工程活动。当需要时，过程小组可以利用过程模型进行过程例化活动，还可以推进软件机构的过程改进活动。 在该机构内实施了培训计划，能够保证全体项目负责人和开发人员具有完成承担的任务所要求的知识和技能。
处于第3级的软件机构的能力成熟度可以概括为：
无论是管理活动，还是工程活动都是稳定的。软件开发成本和进度以及产品的功能都受到控制，而且软件产品质量具有可追溯性。
以管理级：软件机构对软件过程、软件产品都建立了定量的质量目标，所有项目的重要过程活动都是可度量的。该机构收集了过程度量和产品度量的方法并加以运用，对软件过程和产品都有定量的理解与控制。
这一级包含了第3级的全部特征。
处于第4级的软件机构的能力成熟度可以概括为：
处于4级成熟度的软件机构，软件过程是可度量的，软件过程在可度量的范围内运行。 这一级的过程能力允许软件机构在定量的范围内预测过程和产品质量趋势，在发生偏离时可
以及时采取措施予以纠正，并且可以预期软件产品是高质量的。
优先级：处于5级的软件机构的能力成熟度可以概括为：
软件过程是可优化的。这一级别的软件机构能够持续不断的改进其过程能力，既对现行的过程实例不断改进和优化，又借助所采用的新技术、新方法来实现未来的过程改进。
第 2 章 软件度量
1. 软件度量、软件测量的定义
软件度量(Metrics)是指对软件产品、软件开发过程或者资源等对象的简单属性的定量描述。 软件测量(Measure)是对软件产品、软件开发过程和资源复杂属性的定量描述，它是简单属性度量值的函数，软件测量用于事后或实时状态, 如软件可靠性
2. 为什么需要软件度量？
任何工程化的工作都需要度量，软件工程也不例外
准确了解工程的实施情况
项目实施之前
辅助制定软件项目的计划
估算成本和工作量，以便制定计划
项目实施过程中
提供软件开发的可视性
跟踪和控制软件项目的开发
评估软件开发质量，进行质量控制
加强风险管理
项目实施之后
对项目的实施情况进行评估
为后续项目的积累经验数据
3. 软件度量的内容
三个方面
产品：各种文档和程序
过程：各种软件开发活动
资源：各种资源如人员、费用等
二个层次
内部属性
软件产品，过程和资源本身所具有属性，如软件产品的复杂度、程序长度等
易于度量
外部属性
软件产品，过程和资源与外部环境(用户、管理人员等) 间的关系如成本、效益、可靠性、可维护性等
难以度量，但由内部属性所决定
4. 软件度量的方法
面向规模的度量
面成功能的度量
项目成本和工作量估算
软件质量度量
5. 比较面向规模的度量和面向功能的度量
面向规模的度量：
优点：简单易行，自然直观
缺点：依赖于程序设计语言的表达能力和功能
软件开发初期很难估算出最终软件的代码行数
对精巧的软件项目不合适
只适合于过程式程序设计语言
面向功能的度量
优点：与程序设计语言无关, 在开发前就可以估算出软件项目的规模(事前)
不足：没有直接涉及算法的复杂度，不适合算法比较复杂的软件系统；
功能点计算主要靠经验公式，主观因素比较多
数据不好采集
6. 软件规模估算、工作量估算和成本估算之间的关系
软件项目成本和工作量估算极为重要
计算机系统中软件成本占总成本的比例很大
用户和项目管理人员对软件成本和工作量估算都很重视
软件项目成本估算比较困难
软件是逻辑产品，软件开发是一个逻辑思维的过程
涉及多方面因素
软件项目成本和工作量估算常用方法
参照和依据已完成项目的历史数据
将大项目分解为小项目
将项目按照软件生命周期分解
根据经验估算公式
上述方法可以同时、单独或者组合使用
7.McCall 软件质量度量体系：质量要素、质量要素的评价准则、软件质量度量
McCall 的软件质量度量模型
质量要素
定义了与软件质量相关联的一些要素
质量要素的评价准则
定义了能够对质量要素进行度量的一些准则
软件质量的度量
定义了如何基于对质量要素的定量描述对软件质量进行度量的方法
第 3 章 软件质量保证
软件质量保证的定义
一个有系统的、有计划的行动集合，它提供软件产品开发、维护过程符合已建立的技术需求、跟上计划安排和在预算限制之内进行管理上的需求充分信任所必需的。
软件质量保证体系结构（其中包含哪些 SQA 部件；各 SQA 部件之间的关系）
SQA 总是由一系列范围很宽的SQA 部件组成，这些部件都被用来挑战软件错误的
各种来源，并达到可接受的水平的软件质量。
SQA 的任务在质量保证任务领域中是独特的，这是由软件的特性决定的。
此外，进行软件开发与维护的环境直接影响SQA 部件。
项目前SQA 部件; 项目生命周期SQA 部件;SQA 基础设施部件; 软件质量管理部件; 标准化、认证和评估部件;SQA 组织部件
1项目前 SQA 部件——建议草案评审、合同草案评审、项目开发计划、软件质量计划等
不良合同总是让人讨厌的事情。从SQA 观点看，不良合同—其常见特征是不严格定
义的需求、不现实的预算和进度表—必然产生低质量的软件产品。
所以，对于SQA 来说，自然是从评审建议草案，再评审合同草案开始其预防性质量
保证措施。
项目前部件主要用于改进启动项目前的准备工作，包括建议草案评审和合同草案评
审。
2软件生存周期 SQA 部件——软件设计评审、专家观点、同行评审、软件测试、软件维护， 以及针对外部参与方的质量保证措施等
评审评审的主要内容是项目开发过程各阶段产生的各种文档。评审可以被划分为正式（设计）评审和同行评审
专家观点专家观点通过引进补充的外部能力到机构内部开发过程中来而支持质量评估工作。
软件测试的直接目标是正式批准模块或集成结构，以使下一个编程阶段可以开始或已完成的软件系统可以交付和安装。
软件维护部件通常，软件维护部件满足所有的质量需求，尤其是功能与进度安排需求以及预算限制。
外部参与方工作质量的保证分包商、顾客经常加入到软件项目开发中直接承包合同的开发者队伍中。项目越大、越复杂，就越可能需要外部参与方。应用于外部参与方大多数SQA 控制是在有关各方之间签署的合同中规定的。
3软件质量基础设施部件
主要的SQA 维护基础设施工具有：软件维护规程和工作条例；支持性软件质量手段；维护组的培训和认证；预防性和改正性措施；配置管理；软件维护文档和质量纪录。 4软件质量管理部件
改正性维护的主要管理性SQA 部件包括：性能控制—通过定期报告、定期员工会议和访问维护支持中心来实现；改正性维护的质量度量；改正性维护的质量费用。完善性维护和适应性维护的管理性工具主要应用于软件控制开发项目使用。
软件标准——认证标准和评估标准；常见的软件标准
软件质量保证组织部件
适用外部参与方使用的质量保证部件
分包商、顾客经常加入到软件项目开发中直接承包合同的开发者队伍中。项目越大、越复杂，就越可能需要外部参与方。
应用于外部参与方大多数SQA 控制是在有关各方之间签署的合同中规定的。
规程和工作条例之间的关系
专业开发与维护的SQA 规程必须符合机构的质量方针，也要符合国际或国家的SQA 标准。 规程和工作条例的具体关系如下:
为什么需要定义规程和工作条例
如果每个专业人员依靠自己的经验并以他知道的最佳方式完成他的任务不会更好些? 机构强迫我们只按照他们选择的方式完成任务有什么好处?
在大多数机构里经常听到员工们提出类似的问题。对这些问题的回答提示了要由规程和工作条例应对的挑战：应用机构积累的专门技能、经验和专长。
SQA 规程和工作条例的宗旨在于：以最有效、高效的方式执行任务、过程或活动，而不偏离质量需求；软件系统开发与维护所涉及人员之间的有效、高效的交流。执行的统一性、达到符合规程与工作条例，较少导致软件出错的错误理解。简化机构中各种实体执行的任务与活动之间的协调。较好的协调意味着较少的错误！
模板的定义、作用
在软件工程领域，模板指的是小组或机构创建的用于编辑报告和其他形式文档的格式。模板的应用对有些文档是必要的，而对其他文档是选择性的，还有一些情况，只需要使用模板的一部分，例如模板特定的章节或通用结构等。
对于开发组，使用模板可以:方便文档的编制过程，因为节省了详细构建报告结构所需的时间和精力。大多数机构许可从SQA 公共文件拷贝或者从机构的企业内部网下载模板，这样甚至可以不用键入新文档的目录。确保开发人员编制的文档更完善，因为文档中的所有主题都已经定义好了，并且被使用这此模板的大量专业人员反复评审过。不太可能发生诸如漏掉主题这样的常见错误。新组员的加入更容易，这是因为对模板熟悉。由于新成员已经在其他机构单位或小组工作过，他们从前面的工作中可能已经了解模板，而文档的标准结构是根据模板编制的，从而寻找信息变得简单得多。它同样可以使正在进行的文档编制工作顺利，不管编制了文档某些部分的那位小组成员是否已经离开。
方便文档评审，如果文档是基于一个合适的模板建立的，就不需要研究文档结构和确定其完备性。它同样简化已完成文档的评审工作，因为文档的结构是标准的，并且评审者熟悉评审的预期内容(章、节和附录) 。出于这种一致性．评审将会更彻底而又不那么费时。 对于软件维护组，使用模板可以：更容易找到执行维护任务所需的信息。
对于员工进行培训和认证，其目标是什么？
使新员工均掌握以足够的效率与有效性水平执行软件开发和维护任务所需的知识与技能； 这种培训有利于新小组成员的融入；通过传授风格、结构规程和工作条例，确保软件产品(文档和代码) 同机构标准相符；和同机构风格、结构规程及工作条例的符合性；传播SQA 规程的知识；确保关键软件开发和维护职位的候选者是有合适资格的。
培训和认证的实施过程
一个成功的培训和认证系统的实施要求常规的执行以下活动：确定每个职位的专业知识要求；确定专业培训和更新需要；计划专业培训项目；计划专业更新项目。确定需要认证的职位；计划认证过程；发布培训、更新、认证项目；跟踪已培训和已认证人员。所有这些活动组成一个综合的过程，在这个过程中，以前的活动和有关专业发展的反馈信息激励这样一个循环：持续培训、认证和对变化的质量要求的适应。培训和认证活动要满足新老雇员的需求。现行计划结果的全面跟踪以及留意专业的发展，是确保计划能够先进所必需的。 改正性措施和预防性措施的定义
改正性措施： 一个常规使用的反馈过程，包括质量不符合性信息收集、非常规源的识别和
分析以及改进的习惯做法与规程的建立和吸收，连同对它们约执行的控制和对它们的结果的测量。
预防性措施：一个常规使用的反馈过程，包括潜在质量问题信息的收集、偏离质量标准的识别与分析以及改进的习惯做法与规程的建立与吸收，连同对它们执行的控制和对它们的结果的测量。
软件配置、软件配置管理的定义
软件配置管理是一个负责应用(计算机化的或非计算机化的) 技术工具和管理规程、使之能够完成为维护SCI 和软件配置版本所需任务的SQA 部件。
软件配置管理的工作内容、作用
软件配置管理的任务:控制软件更改；发布SCI 和软件配置版本；提供SCM 信息服务；验证对SC 规程的符合性。
版本控制的定义
版本控制是软件配置管理的核心内容。
版本控制将各软件配置项纳入到配置库之中，为每一个配置项自动赋予版本标识，使得各软件配置项都根据既定的版本控制策略独立演化。
常见的软件配置管理工具
简单的版本配置工具，例如Microsoft Visual SourceSafe（VSS ）、Concurrent Version System（CVS ）等；项目级配置管理工具，适合中小型企业，例如PVCS 、MKS ；企业级配置管理工具，具有强大的版本控制和管理能力，适合中大型软件企业，包括CCC Harvest 、IBM Rational ClearCase等。
软件配置管理的过程
软件质量保证体系中的管理部件——项目进度控制、软件质量度量、软件质量费用、软件风险管理
项目进度控制的目标是：早期检测非常规事件，促进解决问题乡音的及时启动；进展控制以及成功和极端故障的积累信息，有利于改正性措施的启动。
进度控制的主要工具:风险管理活动的控制部件；项目进度安排控制部件；项目资源控制部件；项目预算控制部件
软件风险管理是指识别、评估并处置软件项目中的风险要素，通过有效的风险控制措施降低软件项目失败的风险。
软件风险管理过程
软件风险控制方法——风险避免、风险弱化、风险承担、风险转移
风险避免：通过变更计划消除使得风险的触发条件无法满足；
风险弱化：降低风险发生的概率；
风险承担：制定风险应急预案；
风险转移：将风险发生的结果连同应对责任转移给有承受能力的第三方。
软件质量度量的分类：按照软件生存周期规律划分；按照测量主题划分
第一种分类，依据软件系统的生命周期和其他阶段进行划分：过程度量（process metrics）, 与软件开发过程相关；产品度量（product metrics），与软件维护相关。
第二种分类，按照测量主题划分：质量; 进度表; 有效性（关于错误派错和维护服务）; 生产率 软件开发过程度量包括：软件过程质量度量、软件过程进度度量、软件过程生产率度量 软件质量保证组织的目标
第 4 章 软件测试概述
1. 软件缺陷的定义
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题； 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
2. 软件缺陷的分类：按照缺陷的软件制品划分；按照软件缺陷的严重程度划分； 按照软件制品划分
按照严重程度划分
3. 软件缺陷的生存周期（使用状态图表示）
在软件缺陷生存周期规律基础上，软件企业结企业的软件项目经验可以定义更精细粒度的软件缺陷生存周期模型。
4. 软件测试与软件调试之间的关系
5. 软件测试的定义、目的
定义：软件测试是为了尽快尽早地发现在软件产品中所存在的各种软件缺陷而展开的贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。 目的：以最少的时间和人力系统地找出软件中潜在的各种错误和缺陷。
如果我们成功地实施了测试，就能够发现软件中的错误。
6. 软件测试的原则
所有的测试都应可追溯到客户需求
应该在测试工作真正开始前的较长时间就进行测试计划
Pareto 原则：测试中发现的80%的错误可能来自于20%的程序代码
测试应从“小规模”开始，逐步转向“大规模”
穷举测试是不可能的
为了达到最有效的测试，应由独立的第三方来承担测试
其他原则
在设计测试用例时，应包括合理的输入条件和不合理的输入条件
严格执行测试计划，排除测试的随意性
应当对每一个测试结果做全面检查
妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便
检查程序是否做了应做的事仅是成功的一半，另一半是检查程序是否做了不该做的事 在规划测试时不要设想程序中不会查出错误
7. 软件测试的信息流
8. 软件测试执行的过程
（1）测试计划
定义软件测试的内容，确定测试的停止标准
明确测试方法与测试，定义并分配测试资源，等等
（2）测试设计
设计测试用例、测试数据
设计驱动模块、装模块
（3）测试开发
开发驱动模块、装模块以及测试脚本
（4）测试执行
执行不同层次的、多种类型的软件测试，包括单元测试、集成测试、确认测试、系统测试等。
（5）测试评估
评估测试计划的情形情况，评估测试人员的执行能力；
评估测试的有效性
分析软件缺陷数据，以提高测试回报率
9. 软件测试停止标准的定义
因为无法判定当前查出的缺陷是否是最后一个缺陷，所以决定什么时候停止程序测试就成了最困难的问题，但是测试最后一定要停止的
10. 常见的软件测试停止标准
（1）基于统计的测试停止标准
相对于一个理论上合理的和在试验中有效的统计模型来说，如果一个在按照概率的方法定义的环境中，1000个CPU 小时内不出错运行的概率大于0．995的话，那么我们就有95%的信心说，我们已经进行了足够的测试.
（2）使用指定的测试用例设计方法产生测试用例，运行这些测试用例均未发现错误（包括发现错误后已被纠正的情况），则测试可终止
11. 软件可靠性的定义
软件可靠性是指，在特定的环境下、在给定的时间内软件系统无故障运行的概率。
12. 软件测试与软件可靠性的关系
软件测试是提高软件可靠性的重要技术手段。
第 5 章 软件测试用例设计技术
软件测试用例的定义
测试用例是为了特定目的而设计的测试数据及相关测试规程的一个特定集合，即为有效发现软件缺陷的最小测试执行单元。
软件测试用例模板（模板中包含哪些数据项，分别介绍）
标识符:每一个测试用例应该有一个唯一的标识符号，它将作为所有和测试用例相关的文档、表格引用和参考的基本元素。
测试项:测试用例应该描述所需测试的项（内容）及其特征。
测试环境要求:测试环境要求用来表征该测试用例需要的测试环境。
输入标准:输入标准用来表征测试用的输入要求。
输出标准:标识按照指定的环境和输入标准得到的期望输出结果。
测试用例之间的关系:测试用例之间的关系用来表征测试用理之间的依赖关系。
测试用例的优先级
软件测试用例设计的考虑因素 :不可能实现穷举测试，所以编写测试用例过程中应尽量考虑有代表性、典型测试用例。这就要求测试用例设计时充分考虑如下基本因素：测试用例必须具有代表性、典型性。一个测试用例能基本覆盖一组或多组情形，这也是设计测试用例的初衷。测试用例要浓缩系统设计。测试用例既要考虑正确的输入，也需要考虑错误或异常的输入，以及促使这些错误、异常发生的条件。用户测试用例设计需要考虑用户实际使用场景； 用户测试用例是基于用户实际的可能场景，从用户角度模拟系统的输入，从而针对系统设计测试用例。用户测试用例不仅需要考虑用户实际的环境因素。
在本地化测试中需要尊重用户的所在国家、区域、风俗、语言等因素设计测试用例。重用同类型软件项目的测试用例；利用已有的Checklist ，例如《Java Inspection Checklist》，作为测试用例设计的基础；
软件测试用例设计技术——白盒测试，黑盒测试和灰盒测试
白盒测试的定义、目的、特点
白盒测试是一种测试用例设计方法; 盒子指的是被测试的软件; 白盒指的是盒子是可视的, 你清楚盒子内部的东西以及里面是如何运作的。
目的：白盒测试通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
特点：依据软件设计说明书进行测试；对程序内部细节的严密检验；针对特定条件设计测试用例；对软件的逻辑路径进行覆盖测试。
常见的白盒测试技术——控制流测试；数据流测试；编译测试等
控制流测试：语句覆盖；条件覆盖；路径覆盖……
数据流测试：定义覆盖；引用覆盖；定义--引用覆盖……
变异测试; 基本路径测试技术
黑盒测试的定义、目的、特点
黑盒测试又称功能测试、数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试。
目的：黑盒测试可以发现的软件缺陷：功能错误或遗漏; 界面错误; 数据结构或外部数据库访问错误; 性能错误; 初始化和终止错误。
特点：不考虑程序内部结构和内部特性；测试人员只需知道该程序输入和输出之间的关系或功能；设计测试用例的依据是需求规格说明书或用户手册。尤其适合于一些第三方软件测试，由于无法得到源程序，无法用其它方法进行测试。
常用的黑盒测试技术——边界值分析、 等价类划分、 基于决策表的测试、 基于因果图的测试、正交实验法等等
白盒测试技术和黑盒测试技术的比较
白盒测试只考虑测试软件产品, 它不保证完整的需求规格是否被满足。而黑盒测试只考虑测试需求规格, 它不保证实现的所有部分是否被测试到。黑盒测试会发现遗漏的缺陷, 指出规格的哪些部分没有被完成。而白盒测试会发现代理方面缺陷, 指出哪些实现部分是错误的。 白盒测试比黑盒测试成本要高得多。它需要在测试可被计划前产生源代码, 并且在确定合适的数据和决定软件是否正确方面需要花费更多的工作量。
一个白盒测试的失败会导致一次修改, 这需要所有的黑盒测试被重复执行并且重新决定白盒测试路径。黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。
白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。
白盒测试技术的优缺点
优点：迫使测试人员去仔细思考软件的实现; 可以检测代码中的每条分支和路径; 揭示隐藏在代码中的错误; 对代码的测试比较彻底; 最优化。
缺点：昂贵; 无法检测代码中遗漏的路径和数据敏感性错误; 不验证规格的正确性。 黑盒测试技术的优缺点
优点：对于较大的代码单元来说(子系统甚至系统级), 黑盒测试比白盒测试效率要高; 测试人员不需要了解实现的细节, 包括特定的编程语言; 测试人员和编码人员是彼此独立的; 从用户的视角进行测试, 很容易被理解和接受; 有助于暴露任何规格不一致或有歧义的问题; 测试用例可以在规格完成之后马上进行。
缺点：只有一小部分可能的输入被测试到, 要测试每个可能的输入流几乎是不可能的; 没有清晰的和简明的规格, 测试用例是很难设计的; 如果测试人员不被告知开发人员已经执行过的用例, 在测试数据上会存在不必要的重复; 会有很多程序路径没有被测试到; 不能直接针对特定程序段测试, 这些程序段可能很复杂(因此可能隐藏更多的问题); 大部分和研究相关的测试都是直接针对白盒测试的
第 6 章 白盒测试技术
1. 各种逻辑覆盖准则的定义——语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合
语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。这种覆盖又称为点覆盖，它使得程序中每个可执行语句都得到执行，但它是最弱的逻辑覆盖准，效果有限，必须与其它方法交互使用。
判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖。
条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。
判定/条件覆盖是既然判定条件不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖，就
自然会提出一种能同时满足两种覆盖标准的逻辑覆盖。
条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。
2. 覆盖、点覆盖、边覆盖、路径覆盖
点覆盖：如果连通图 G 的子图G ´是连通的，而且包含G 的所有节点，则称G ´是G 的点覆盖。与语句覆盖标准相同。
边覆盖：如果连通图 G 的子图G ´是连通的，而且包含G 的所有边，则称G ´是G 的边覆盖。通常与判定覆盖标准相同。
路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径。这是最强的覆盖准则。但在路径数目很大时，真正做到完全覆盖是很困难的，必须把覆盖路径数目压缩到一定限度。
3. 根据各种逻辑覆盖准测进行控制流测试，设计测试用例
测试步骤：
导出程序流程图的拓扑结构-流图
计算流图G 的环路复杂度V(G)
确定只包含独立路径的基本路径集
设计测试用例
第 7 章 黑盒测试技术
等价类划分的定义
等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。
等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。
使用等价类划分方法设计测试用例的过程
划分等价类（列出等价类表）和选取测试用例两步
有效等价类、无效等价类的定义
① 有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。 ② 无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。
等价类划分的启发式规则
（1）如果输入条件规定了取值范围，或值的个数，则可以划分成一个有效等价类和两个无效等价类。
（2）如果输入条件规定了输入值的集合，或者规定了“必须如何”的条件，则可划分成一个有效等价类和一个无效等价类。
（3）如果输入条件是一个布尔量，则可以划分成一个有效等价类和一个无效等价类。
（4）如果规定了输入数据的一组值，而且程序要对每个输入值分别处理，则可为每个输入值确立一个有效等价类，此外对这组值所有不允许的输入数据集合确立一个无效等价类。
（5）如果规定了输入数据的一组值，而且程序要对每个输入值分别处理，则可为每个输入值确立一个有效等价类，此外对这组值所有不允许的输入数据集合确立一个无效等价类。
（6）如果确知，已划分的等价类中各个元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类。
（7）等价类划分还应特别注意默认值、空值、NULL 、0、NONE 等的情形。
使用等价类划分方法设计测试用例，研究 PPT 中案例
（1）三角形问题-测试用例
（2）Pascal 语言
（3）次日问题
边界值的定义
边界值分析也是一种常用的黑盒测试方法，是对等价类划分方法的补充；
所谓边界值，是指相对于输入等价类和输出等价类而言，稍高于其最高值或稍低于最低值的一些特定情况。
使用边界值方法设计测试用例的过程
（1）确定边界
（2）选择测试用例
边界值分析的关键假设——单陷假设和多陷假设
（1）单缺陷假设认为失效极少是由两个或多个缺陷的同时发生引起的，在进行基本边界值分析获得测试用例的方法--使所有变量取正常值只使一个变量取极值；
（2）多缺陷假设则认为失效是由两个或多个缺陷导致的，边界值测试需同时考虑多个变量的取值情况。
边界值分析方法包括基本边界值测试和健壮性测试
基本边界值测试：如果有一个变量个数为n 的函数使除一个以外的所有变量取正常值使剩余的那个变量取最小值、略高于最小值、正常值、略低于最大值和最大值对每个变量都重复进行；
健壮性测试:健壮性测试是边界值分析的一种简单扩展。健壮性测试除了使用五个边界值分析取值，还要通过采用一个略超过最大值max+的取值以及一个略小于最小值min-的取值 应用边界值分析方法（即基本边界值测试和健壮性测试）设计测试用例 判定表的组成
条件桩（Condition Stub）、条件项（Condition Entity）动作桩（Action Stub）、动作项（Action Entity ）规则(rule)
应用基于判定表的测试技术设计测试用例
（1）确定规则个数；
（2）列出所有的条件桩和动作桩；
（3）填入条件项；
（4）填入动作桩和动作项，得到初始判定表；
（5）化简，合并相似规则；
（6）依据判定表，选择测试数据，设计测试用例。
第 8 章
软件测试执行的层次
（1）单元测试
（2）集成测试
（3）确认测试
（4）系统测试
典型的软件测试配置有哪些？
软件测试执行的过程
（1）制定测试计划：定义测试项目的阶段，以便于对项目进行适当的评估与控制，包括测试需求，测试策略，测试资源和测试进度。
（2）测试设计：设计测试用例及测试过程的阶段，它是验证测试需求被测试到的最有效的方法。
（3）测试实施：对测试设计阶段已被定义的测试进行创建或修正的阶段，如脚本、驱动、桩的实施。
（4）测试执行：对被测软件进行一系列的测试并记录日志结果的阶段。
（5）测试评估：分析测试结果并判断测试的标准是否被满足的阶段。
（6）缺陷跟踪：记录测试发现的问题，并且跟踪其修改的阶段。
软件测试计划的工作内容
测试用例设计，驱动模块、桩模块设计
测试实施工作包括编写测试脚本，实现驱动模块和桩模块
软件测试相关的角色，各角色的工作职责
（1）测试设计员
a. 制定和维护测试计划。
b. 设计测试用例及测试过程。
c. 评估测试，生成测试分析报告。
（2）测试人员
a. 执行集成测试和系统测试。
b. 记录测试结果。
（3）设计人员
a. 设计测试需要的驱动程序和稳定桩。
（4）编码人员
a. 编写测试驱动程序和稳定桩。
b. 执行单元测试。
单元测试的定义、工作内容
定义：单元测试针对程序模块，进行正确性检验的测试。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
工作内容：在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。
主要对模块的五个基本特性进行评价:错误处理、模块接口、局部数据结构、边界条件、 重要的执行路径；
驱动模块、桩模块的定义
驱动模块：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。
桩模块：用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。
为什说桩模块的设计成本比驱动模块的设计成本高？
驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，它需要一定的开发费用。 若驱动模块和桩模块比较简单，实际开销相对低些。
仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。
提高模块的内聚度可简化单元测试，如果每个模块只完成一个功能，所需测试用例数目将显著减少，模块中的错误也更容易发现。
常见的集成测试策略
（1）一次性集成方式
（2）增殖式集成方式
a. 自顶向下增值方式
b. 自底向上增值方式
c. 混合增值方式
比较自顶向下增值方式和自底向增值方式的集成测试策略的优缺点
自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能将是十分困难的。同时涉及复杂算法和真正输入／输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，导致过多的回归测试。 而自顶向下增殖方式的优点是能够较早地发现在主要控制方面的问题。
自底向上增殖方式的缺点是“程序一直未能做为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。
而自底向上增殖方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入／输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试。
确认测试、系统测试、α测试和β测试的定义
确认测试：确认测试又称有效性测试，它的任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
系统测试：所谓系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。
α测试：α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。这是在受控制的环境下进行的测试。
β测试:β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。 应用增殖式集成方式进行集成测试，要求集成测试过程描述
（1）以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代;
（2）依据所选的集成策略(深度优先或广度优先), 每次只替代一个桩模块;
（3）每集成一个模块立即测试一遍;
（4）只有每组测试完成后，才着手替换下一个桩模块;
（5）为避免引入新错误，须不断进行回归测试(即全部或部分地重复已做过的测试) 。
（6）从第二步开始，循环执行上述步骤, 直至整个程序结构构造完毕。
JUnit 单元测试的过程
1． Junit 三重唱
（1） TestCase 测试用例
用户定义的TestCase 必须扩展junit.framework.TestCase 类，它以testXXX 方法的形
式包含了一个或多个测试。一个测试用例把具有公共行为的测试归入一组。
（2） TestSuite 测试套装
一个测试套装可以把多个测试用例或测试套装封装为一组
（3） TestRunner 测试运行器
测试运行器用来运行测试套装，Junit 提供良种典型的测试运行器：
junit.swingui.TestRunner 和 junit.textui.TestRunner
2．JUnit 核心类
Assert 、Testresult 、Test 、TestListener 、TestCase 、TsetSuite 、BaseTestRunner
3.JUnit 单元测试的步骤
（1） 重载setUp()，封装测试环境初始化及测试数据准备；
（2） 设计测试方法，以testXXX 命名。
（3） 在测试方法中使用断言方法如assertEquals()，assertTrue()等。JUnit 中断言方法；
（4） 设计测试套件，或使用缺省的测试套件，调用TestRunner 执行测试脚本，生成
测试结果；
（5） 重载tearDown()析构测试环境，执行收尾动作；
理解 JUnit 测试框架，包括哪些核心类，每一个类的作用，特别是 TestCase、TestSuite 等概念
基于 JUnit 框架，设计测试脚本，对软件模块进行测试
第 9 章 软件测试自动化
手工测试的局限
（1）手工测试无法做到覆盖所有代码路径；简单的功能性测试用例在每一轮测试中都不能少，而且具有一定的机械性、重复性、工作量往往较大；
（2）许多与时序、死锁、资源冲突、多线程等有关的错误，通过手工测试很难捕捉到；
（3）进行系统负载、性能测试时，需要模拟大量数据或大量并发用户等各种应用场合时，很难通过手工测试来进行；
（4）进行系统可靠性测试时，需要模拟系统运行十年、几十年的业务量，以验证系统能否
稳定运行，这也是手工测试无法模拟的；
（5）如果有大量（几千）的测试用例，需要在短时间内（1天）完成，手工测试几乎不可能做到。
自动化测试的益处
（1）缩短软件开发测试周期，可以让产品更快投放市场；
（2）测试效率高，充分利用硬件资源；
（3）节省人力资源，降低测试成本；
（4) 增强测试的稳定性和可靠性；
（5）提高软件测试的准确度和精确度，增加软件信任度；
（6）软件测试工具使测试工作相对比较容易，且能产生更高质量的测试结果；
（7）手工不能做的事情，自动化测试能做，如负载、性能测试。
自动化测试的定义
自动化测试是指使用一种自动化测试工具来验证各种软件测试的需求，它包括测试活动的管理与实施、测试脚本的开发与执行。
软件测试自动化的基本原理和方法
软件测试自动化实现的基础是可以通过设计的特殊程序模拟测试人员对计算机的操作过程、操作行为，或者类似于编译系统那样对计算机程序进行检查。
软件测试自动化实现的原理和方法主要有：
直接对代码进行静态和动态分析
测试过程的捕获和回放
测试脚本技术
虚拟用户技术
测试管理技术
测试脚本的分类
（1）线性脚本——是录制手工执行的测试用例得到的脚本；
（2）结构化脚本——类似于结构化程序设计，具有各种逻辑结构（顺序、分支、循环），而且具有函数调用功能；
（3）共享脚本是指某个脚本可被多个测试用例使用，即脚本语言允许一个脚本调用另一个脚本。
（4）数据驱动脚本将测试输入存储在独立的数据文件中。
（5）关键字驱动脚本是数据驱动脚本的逻辑扩展
软件测试工具的作用
自动化测试工具的作用：
（1）确定系统最优的硬件配置。
（2）检查系统的可靠性。
（3）检查系统硬件和软件的升级情况。
（4）评估新产品。
软件测试自动化的局限
（1）不能取代手工测试
（2) 手工测试比自动测试发现的缺陷更多
（3）对测试质量的依赖性极大
（4）测试自动化不能提高有效性
（5）测试自动化可能会制约软件开发。
（6）工具本身并无想象力
自动化测试成熟度等级： 捕获和回放(级别 1)； 捕获、编辑和回放 （级别 2）；编程和回放 （级别 3）；数据驱动的测试（级别 4）；使用动词的测试自动化（级别 5）。 了解常见的软件测试工具
案例分析考点分布
1 理解 JUnit 单元测试框架
2 编写基于 JUnit 框架的软件测试脚本
3 控制流测试——满足各种逻辑覆盖准则
4 集成测试（要求给出测试过程）
（1）自顶向下深度优先集成测试策略
（2）自顶向下广度优先集成测试策略
（3）自底向集成测试策略
5 为企业建立 SQA 体系
6 软件质量与软件质量费用之间关系
7 MaCall 软件质量模型的应用，能识别出关联的软件质量因素
8 使用等价类划分方法、边界值分析法（包括基本边界值测试和健壮性测试）设计测试用例
9 ISO 9000-3 质量管理标准的认证过程
认证服务是由ISO 通过一个世界范围的认证服务网络组织的，这些服务由认可实体和认证实体授权的。
ISO 9000-3的认证如下：
（1）制订获得认证的活动计划
（2）建立机构SQA 系统
（3）接受认证审计
（4）维持ISO 认证的规程