软件测试期末复习

软件测试期末复习

第1章 软件质量和测试的背景

1. 软件特征与软件工程
   • 软件的定义 ：IEEE 定义为计算机程序、规程以及可能的相关文档和运行计算机系统需要的数据。
   • 软件与硬件的区别 ：软件是逻辑产品，具有不同的失效曲线，不会像硬件一样有磨损。
   • 软件工程的定义 ：Fritz Bauer 和 IEEE 给出的定义，强调系统化、规范、可度量的方法应用于软件的开发、运行和维护。
   • 软件工程的视图 ：分为定义阶段（做什么）、开发阶段（如何做）、维护阶段（改变），以及贯穿其中的保护性活动。
2. 软件范型的转变 ：如雅虎公司 “开放、免费、盈利” 的规则对软件范型的影响。
3. 软件质量
   • 软件质量保证（SQA） ：是应用于整个软件过程的保护性活动，包括质量管理方法、软件工程技术、正式技术复审等。
   • 质量概念 ：从软件结构、功能与性能、开发标准与文档等方面考虑。
   • 质量运动 ：全面质量管理的 4 个步骤，前两步关注过程，第三步关注用户，第四步关注市场用途。
   • 软件质量概念 ：IEEE 和 ANSI 的定义，强调满足需求和期望的程度。
   • 软件质量的特征 ：功能性、可靠性、易使用性、效率、可维护性、可移植性。
4. 软件质量保证与测试的关系 ：质量保证重在防止缺陷出现，测试重在寻找缺陷，二者结合才能得到好的软件。
5. 软件测试与可靠性概述
   • 软件测试的意义 ：通过案例说明软件缺陷可能导致的严重后果。
   • 软件测试的定义 ：IEEE 的定义强调检验是否满足需求，Myers 的观点强调发现错误。
   • 软件测试方法 ：包括静态与动态方法、黑盒测试、白盒测试、灰盒测试，以及基于开发阶段的多种测试方法。
   • 软件测试自动化 ：涉及白盒测试工具、功能测试工具等不同类型。
   • 软件缺陷的修复费用 ：随着发现时间的推迟，修复费用呈上升趋势。
6. 软件质量保证与测试人才的特点
   • 现代软件研发对软件人才的需求 ：包括专业基础、创新能力、主人翁精神、团队精神等。
   • 软件测试员应具备的素质 ：如探索精神、故障排除能力、创造性、追求完美、准确判断等。
   • 软件测试的工作岗位 ：从入门级测试员到高级顾问等不同级别及其职责。

第2章 软件质量工程体系

1. 软件质量控制的基本方法
   • 基本概念 ：软件质量控制是开发组织使用的程序和方法，以最低代价获得客户满意产品，并持续改善开发过程。
   • 目标问题度量法 ：通过规定目标、引出问题、度量映射等步骤，收集数据并改善质量目标。
   • 风险管理法 ：包括风险识别、评估、排序、控制等环节，采用不同风险控制方法应对风险。
2. 软件质量控制模型和技术
   • 模型 ：如基于 PDCA 的全面统计质量控制（TSQC）模型。
   • 模型参数 ：包括产品、过程、资源。
   • 实施过程 ：在预开发、开发、维护阶段实施软件质量控制。
   • 技术 ：涵盖预防性和检测性特征的技术，如因果分析、配置管理、独立确认与验证等，不同技术对质量控制参数有不同影响。
3. 软件质量保证体系
   • 软件质量保证（SQA） ：建立有计划、系统的方法，保证标准等被正确采用，使软件过程对管理人员可见。
   • 能力成熟度模型（CMM） ：SEI 开发的用于评价软件承包能力并改善软件质量的方法，包括 5 个等级、18 个过程域等，SQA 是 CMM2 级的重要关键过程区域。
   • 软件质量保证的内容 ：贯穿软件生产、开发、基线系统、市场发布、研究分析、测试、计划、设计、原型、支持、交付等各个环节。

第3章 软件质量度量和配置管理

1. 软件度量的基础概念
   • 度量的定义 ：包括名词和动词两种形式，名词是赋予软件过程或产品属性的数值或类别，动词是实施度量的过程；测量是按照尺度给软件实体属性赋值的过程，强调量化过程性；度量（Metric）是已定义的测量方法和尺度；指标（Indicator）是用于评价或预测其他度量的度量。
   • 软件度量的重要性 ：可度量性是学科成熟的标志，它使软件开发更专业、标准和科学，有助于管理层更好地管理软件过程，通过度量可以增加理解、管理软件项目、指导软件过程改善。
2. 软件质量度量
   • 软件质量要素 ：CMM定义软件质量为符合特定需求和用户要求或期望的程度。
   • 影响软件质量的因素 ：软件质量是人、过程和技术的函数，即 Q = {M, P, T}。
   • 质量保证模型 ：包括 McCall 模型、Boehm 模型、FURPS 模型、ISO9126 标准。这些模型从不同维度对软件质量特性进行描述和分类，如 McCall 模型强调正确性、可靠性、效率等，ISO9126 从功能性、可靠性、可用性等方面进行规范。
   • 缺陷排除效率（DRE） ：定义为 DRE = E / (E + D)，其中 E 为软件交付前发现的错误数，D 为交付后发现的缺陷数，用于衡量质量保证及控制活动的过滤能力。
3. 软件过程度量
   • 概念 ：是对软件过程进行度量的定义、方法、活动和结果的集合，包括选择和定义度量、制定度量计划等一系列完整步骤。
   • 常见问题 ：如度量太多或太少、度量对象或属性不正确、定义不精确、数据未利用、解释错误、自动化工具欠缺等。
   • 基于目标的软件过程度量方法（GQM 模型） ：是一种层次状结构，从目标出发，细化为问题，再选择数据项等，通过不断分解和细化来实现对软件过程的有效度量。
4. 软件配置管理
   • 目标 ：贯穿整个软件生命周期，建立和维护项目产品的完整性，确保被选择的项目产品得到识别、控制且可获取，已识别出的项目产品的更改得到控制等。
   • 角色职责 ：涉及项目经理、配置控制委员会、配置管理员、系统集成员、开发人员等，各角色在配置管理过程中承担不同职责。
   • 过程描述 ：包括项目计划阶段和项目开发维护阶段，项目计划阶段要确定里程碑和开发策略、制定配置管理计划等，项目开发维护阶段主要由配置管理员完成管理和维护工作。
   • 关键活动 ：如配置项识别、工作空间管理、版本控制、变更控制、配置审计、状态报告等，用于有效管理软件配置。
   • 常用工具 ：如 Visual SourceSafe（VSS）、Concurrent Version System（CVS）、PVCS、MKS、CCC Harvest、ClearCase 等，不同级别的工具适用于不同类型和规模的项目。

第4章 软件可靠性度量和测试

1. 软件可靠性基础
   • 定义 ：1983 年美国 IEEE 计算机学会定义为在规定的条件下，在规定的时间内，软件不引起系统失效的概率，该概率是系统输入和系统使用、软件中存在的错误的函数。
   • 软件可靠性与硬件可靠性的区别 ：硬件有老化损耗现象，失效是物理故障，有浴盆曲线现象；软件没有磨损，不存在浴盆曲线现象，其可靠性更多地决定于人，且软件的冗余不能提高可靠性等。
   • 影响软件可靠性的因素 ：主要包括需求分析定义错误、设计错误、编码错误、测试错误、文档错误等软件差错。
   • 软件的差错、故障和失效 ：异常是偏离期望的状态，缺陷是不符合使用要求或与技术规格说明不一致的状态，差错有多种含义，故障是程序中不正确的步骤等，失效是程序运行的外部结果与要求不一致。
2. 可靠性模型及其评价标准
   • 软件可靠性模型 ：用于预计或估算软件的可靠性，将复杂系统的可靠性逐级分解为简单系统的可靠性。模型众多，如 Musa 模型、Shooman 模型、Goel - Okumoto 模型、威布尔模型等，不同模型适用于不同阶段和假设条件。
   • 模型分类 ：根据时间域、类别、型式、种类、族等特征进行分类，如有限故障类和无限故障类模型等。
   • 可靠性度量 ：常见的软件差错包括非法转移、误转移等，故障模型可建立在系统不同级别上，级别越低，处理代价越低，但覆盖故障越少。
   • 模型建立 ：通过对所选模型关联参数的统计来确定失效情况等，对经费估算、资源计划等很重要，但由于软件特性等因素，建立完全满足要求的模型困难且难以验证。
   • 模型统一 ：极大似然估计、最小二乘法、Bayes 分析方法等是模型参数估计和分析的有效手段。
   • 软件可靠性模型评价准则 ：包括模型拟合性、预计有效性、偏差、偏差趋势、噪声等。
3. 软件可靠性测试和评估
   • 软件可靠性评测 ：运用统计技术对软件可靠性测试和系统运行期间采集的软件失效数据进行处理并评估软件可靠性的过程，其目的是测量和验证软件的可靠性，是对软件测试过程的一种完善，有助于软件产品本身的可靠性增长。
   • 软件可靠性测试的具体实施过程 ：包括测试过程模型、测试目的、测试准备和执行等内容。
4. 提高软件可靠性的方法和技术
   • 建立以可靠性为核心的质量标准 ：在软件项目规划和需求分析阶段建立包括可靠性在内的质量标准，通过一定指标指定标准基线，同时要确定划分各开发过程的质量度量，如需求分析、设计结果、测试结果、验收结果等的质量度量。
   • 选择开发方法 ：不同的软件开发方法对软件的可靠性有重要影响，如 Parnas 方法等。
   • 软件重用 ：包括开发过程重用、软件构件重用、知识重用等方面，可提高软件的可靠性和开发效率。
   • 使用开发管理工具 ：如 PVCS 软件开发管理工具，可规范开发过程、缩短开发周期、减少成本等，对提高软件可靠性、保证质量有很大作用。
   • 加强测试 ：测试规范包括测试设计规范、测试用例规范、测试规程规范等，测试方法多种多样，如走查、机器测试、程序证明、模拟测试、设计审查等，通过这些测试可以查找、定位、改正和消除错误，实现软件可靠性增长。
   • 容错设计 ：提高可靠性的技术分为避免故障和容忍故障两类，避免故障的技术有算法模型化、模拟模型化、正确性证明等，容忍故障的技术有冗余技术、容错技术、自适应技术等。
5. 软件可靠性研究的主要问题
   • 包括观点、方法和工具问题，软件可靠性模型问题，软件可靠性模型的应用问题，数据问题，软件测试用例的自动生成问题，硬 - 软件混合系统可靠性问题等。

第5章 软件质量标准

1. 软件质量标准概述
   • 标准的层次 ：软件质量标准分为国际标准、国家标准、行业标准、企业标准和项目规范五个级别。这些标准是从不同范围和层次对软件质量进行规范和约束。
   • 国际标准 ：由国际机构制定和公布，如ISO，其标准具有广泛代表性和权威性，如ISO10012:1995质量手册编写指南等。
   • 国家标准 ：由政府或国家级机构制定或批准，适用于本国范围，如中国的GB、美国的ANSI、FIPS、英国的BS、德国的DIN、日本的JIS等。
   • 行业标准 ：由行业机构、学术团体或国防机构制定，适用于特定业务领域，如我国的GJB军用标准、美国国防部标准等。
   • 企业规范 ：大型企业或公司为满足自身软件工程工作需要而制定的标准，如IBM公司的“程序设计开发指南”。
   • 项目规范 ：为特定科研生产项目制定的操作规范，目标明确，专用性较强，若能成功指导项目运行，也有可能发展为行业规范。
2. ISO9001和9000-3在软件中的应用
   • ISO9000族标准核心 ：包括ISO9000：2005《质量管理体系—基础和术语》、ISO9001：2008《质量管理体系—要求》、ISO9004：2009《质量管理体系—业绩改进指南》、ISO9011：2011《质量和环境管理体系审核指南》。
   • ISO9001：2008的要求 ：涵盖管理职责、质量系统、合同复审、设计控制、文档和数据控制、对客户提供产品控制、产品标识和可跟踪性、过程控制、审查和测试、审查、度量和测试设备的控制、审查和测试状态、对不符合标准产品的控制、改正和预防行为、处理、存储、包装、保存和交付、质量记录的控制、内部质量审计、培训、服务、统计技术、采购等20条需求，这些需求为组织建立质量管理体系提供了全面的指导。
3. 能力成熟模型CMM&CMMI
   • CMM的本质与目的 ：是软件管理工程的一部分，用于描述软件组织在定义、实现、度量、控制和改善软件过程中的各个发展阶段，通过5个不断进化的层次评定软件生产的历史与现状，帮助组织提升软件过程能力和成熟度。
   • CMM的5个成熟度等级 ：
     • 初始级 ：软件过程混乱无序，项目成功依赖个人才能和经验，管理方式属于反应式。
     • 可重复级 ：建立了基本的项目管理来跟踪进度、费用和功能特征，能利用以前类似项目的经验取得成功。
     • 已定义级 ：软件管理和过程文档化、标准化，形成组织的标准软件过程，所有软件开发都使用该标准过程。
     • 已管理级 ：收集软件过程和产品质量的详细度量，对软件过程和产品质量有定量的理解和控制。
     • 优化级 ：通过量化反馈和新技术促进过程不断改进，保持优化的机构，进行缺陷预防、过程变更和技术变更管理。
   • CMM关键域 ：每个成熟度等级都定义了对应的关键域，这些关键域是实现该成熟度等级所需解决的主要问题和关键活动的集合。例如，初始级的关键域包括项目管理、项目策划、配置管理、软件质量保证等。
   • PSP和TSP ：
     • PSP（个体软件过程） ：是一个自我持续改进过程，提供软件开发表格、指南和规程的结构化框架，帮助软件工程师做出准确的计划、改善产品质量、建立度量基准、确定过程改变对能力的影响。
     • TSP（团队软件过程） ：指导项目组成员有效规划和管理项目开发任务，实施集体管理与自己管理相结合的原则，旨在以最少的时间和预计费用生产高质量软件产品，实施需满足一定条件，如高层主管支持、项目组成员经过PSP培训等。
   • CMMI ：是CMM模型的最新版本，一种综合性模型，解决了早期CMM模型存在的问题，如不能集中不同过程改进的能力、重复的培训和改进活动、不同模型对相同事物说法不一致等。
   • CMM中的质量框架 ：软件质量保证（SQA）是CMM可重复级中的关键过程域之一，在CMMI中升级为管理级中的过程与产品质量保证过程（PPQA）。其目的是提供对流程和相关工作产品的客观洞察，通过评审和审计验证软件产品和活动是否符合适用的规程和标准，并向相关人员提供结果。
4. IEEE软件工程标准
   • IEEE 730:2001 ：规定了软件质量保证计划的结构与内容，包括目的、参考文档、管理、文档、标准、实践、约定和度量、软件评审等方面。
   • IEEE/EIA Std 12207——软件生命周期过程 ：
     • 主要过程 ：包括获取过程、供应过程、开发过程、运行过程，供各主要当事方在参与或完成软件产品开发、运行或维护时使用。
     • 支持过程 ：包括文档编制过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审核过程、问题解决过程，支持其他过程以帮助软件项目获得成功及良好的产品质量。
   • IEEE Std 1012——验证与确认 ：
     • 验证 ：评价系统或组件的过程，判断给定阶段的产品是否满足该阶段开始时施加的条件，是一种普通的测试活动，要求验证每个开发阶段是否符合先前阶段定义的需求，经过合理组织的项目应包含验证和确认计划（VVP）。
     • 确认 ：开发过程中对系统或组件进行评价的过程，以确认它是否满足规定的需求，通常用测试来完成这项任务，确认计划是必须的。
   • IEEE Std 1028——评审 ：规定了管理评审、技术评审、审查、走查、审计等不同类型评审的目的、参与人等，用于查出并标识软件产品的反常，验证软件产品是否满足规格说明等要求。
5. 其他质量标准
   • ISO/IEC 15504-2:2003软件过程评估标准 ：用于对软件过程进行评估，帮助组织了解和改进其软件过程能力。
   • Tick IT ：帮助软件企业建立与其业务过程相关的质量体系，满足ISO 9001的要求，由TickIT办公室进行管理，其审核员项目提供相关培训和支持。
6. 小结
   • 标准体系结构和内容 ：介绍了软件行业的标准体系结构，从通用标准的概念、层次等方面展开，侧重于软件质量标准的介绍。
   • CMM的重要性 ：CMM为软件过程改进提供了一个框架，将软件过程成熟度分为5个等级，定义了每个等级的主要问题和关键域，组织内部人员的积极参与和创造性活动对CMM的成功实施至关重要，同时个体软件过程和团体软件过程也应运而生以补充和支持CMM的实施。

第6章 软件评审

1. 软件评审的必要性
   • 提高项目生产率：早期发现错误，减少返工和测试时间。
   • 改善软件质量：通过评审过程，提升软件整体质量。
   • 知识共享：让开发团队成员更熟悉产品和开发过程。
   • 标志阶段完成：标志着软件开发的一个阶段的完成。
   • 提高软件可维护性：产生和利用有用文档，增加对软件的理解。
2. 软件评审的角色和职能
   • 评审组长（Moderator）：负责组织和协调评审活动。
   • 宣读员（Reader）：在评审会议上宣读相关内容。
   • 记录员（Recorder）：记录评审过程中的问题和讨论内容。
   • 作者（Author）：准备被评审的内容，参与讨论并负责后续修改。
   • 评审员（Reviewer、Inspector）：对被评审内容进行审查，提出问题和建议。
3. 评审的内容
   • 管理评审 ：由最高管理者进行，评价管理体系的适宜性、充分性和有效性，输入包括内、外审评审结果、顾客信息反馈等，输出为《管理评审报告》。
   • 技术评审 ：目的是发现软件在功能、逻辑、实现上的错误，验证软件符合需求规格等，输出技术评审报告。
   • 文档评审 ：对需求文档、设计文档、代码、测试文档等进行评审。
   • 过程评审 ：评估质量保证流程，处理不符合问题，总结和共享经验。
4. 评审的方法和技术
   • 评审的方法包括特别检查、轮查、走查、团队评审、检视等。
   • 评审的技术有缺陷检查表、规则集、评审工具（如Gerrit、Jupiter、SourceMonitor）、从不同角度理解产品、场景分析技术等。
5. 评审会议流程
   • 准备评审会议 ：评审组长发出通知，选择评审材料，打包分发材料，安排活动进程。
   • 召开评审会议 ：进行评审预备、成员介绍、演示或说明、沟通、记录等，遵循相关原则。
   • 跟踪和分析评审结果 ：跟踪有条件接受和不接受的缺陷，分析评审的有效性、效率和成本。
6. 小结
   • 软件评审的重要性：在软件生存期的每个阶段都可能引入缺陷，通过评审可以提前发现并纠正缺陷，避免其传播到后续阶段。
   • 代码审查：发现代码中的bug，考察代码的易维护性和可扩展性，提出修改建议，确保代码质量。

第7章 软件全面质量管理

1. 全面质量管理概述
   • 质量控制理论的发展阶段 ：质量控制理论的发展可以概括为五个阶段，确定质量的主体包括产品质量、工作质量、设计质量和制造质量。
   • 全面质量管理的功能益处 ：如缩短总运转周期、降低成本、提高生产率、追求企业利益和成功、使顾客完全满意、获取利润等。
   • 全面质量管理的含义 ：强调关注顾客、精确度量、持续不断地改进、向员工授权，以及改进组织中每项工作的质量。
   • 全面质量管理与竞争优势 ：包括拓宽管理跨度、增进组织纵向交流、减少劳动分工、促进跨职能团队合作等内容。
   • 相关问题探讨 ：如戴明循环、面向社会大网络的全面质量管理、全面质量管理的系统思考等。
   • 全面质量管理与 ISO9000 的对比 ：两者的相同和不同之处。
   • 全面质量管理与统计技术 ：统计技术在质量管理中的应用，如显著性检验、实验设计、方差分析与回归分析、控制图、统计抽样等。
2. 6σ 项目管理
   • 6σ 管理法简介 ：6σ 的由来及在各行业的发展。
   • 6σ 管理法与零缺陷 ：零缺陷的概念及发展历程。
   • 6σ 管理的特征 ：以顾客为关注焦点、提高顾客满意度和降低资源成本、注重数据和事实、以项目为驱动等。
   • 6σ 管理的优点 ：提升企业管理能力、节约运营成本、增加顾客价值等。
   • DPMO 与 6σ 的关系 ：不同 σ 值对应的正品率和 DPMO 值，体现 6σ 管理的核心特征。
   • 6σ 管理的人员组织结构 ：包括 6σ 管理委员会、执行负责人、黑带、黑带大师、绿带等。
   • 6σ 与其它管理工具的比较 ：与全面质量管理、企业流程再造的对比。
3. 质量功能展开设计
   • 质量功能展开的概念 ：将顾客需求转变成质量特性并展开质量设计的方法。
   • 质量功能展开分解模型 ：从顾客需求出发，经过产品规划、零部件规划、工艺规划、生产规划等阶段，形成瀑布式的分解过程。
   • 质量屋的构成 ：包括 WHATS 输入项矩阵、HOWS 矩阵、相关关系矩阵等。
   • 质量功能展开的特点 ：以满足顾客需求为出发点、继承和延伸传统设计技术方法、质量屋是基础工具、减少产品设计过程的盲目性等。
4. DFSS 流程及主要设计工具
   • DMAIC 与 DFSS 简介 ：DMAIC 是业务流程改进的五步循环改进法，包括定义、评估、分析、改进、控制。
   • DFSS 的重要性及其内涵 ：强调质量保证措施应集中在设计过程上，基于预防性思想、并行质量工程思想和以顾客为关注焦点。
   • DFSS 与 DMAIC 的区别 ：DMAIC 侧重于对现有流程的改进，而 DFSS 更注重产品或流程的初始设计。
   • DFSS 流程及主要设计工具 ：包括构建并行工作团队、定义可开发产品和过程需求、需求分析等流程，主要设计工具有 QFD、FMEA、新 QC 七种工具等。
   • DFSS 的集成框架 ：从选择并确定项目到最终评审等一系列步骤，涉及多种工具和方法的应用。
   • 6σ 实施中的注意问题 ：如模仿机械、缺乏质量文化、专业培训不足、基础管理薄弱、项目实施规划不合理等。
   • DFSS 的发展方向 ：支持 DFSS 的软件工具平台开发、管理问题研究、顾客需求转换、概念设计中的解耦合设计、稳健性设计技术研究等。
5. 小结
   • 全面质量管理的定义 ：是企业所有部门、组织和人员以产品质量为核心，结合专业技术、管理技术和数理统计技术，建立质量保证体系，控制生产过程中的质量影响因素，提供优质产品。
   • 6σ 管理法的核心 ：是一种统计评估法，追求零缺陷生产，关注产品、服务质量以及过程改进，提高顾客满意度和忠诚度。

第9章 软件测试

1. 软件测试的目的和原则
   • 目的 ：通过运行程序发现错误，建立高可靠性的软件系统，是软件质量保证的重要手段。
   • 原则 ：尽早和不断地进行测试；不默认程序无错误；设计测试用例时给出预期结果；测试工作应由独立的人员或团队承担；对合理和不合理的输入数据都进行测试；重点测试错误群集的程序区段；检查程序功能是否多余；避免穷举测试；长期完整保留测试用例和文件。
2. 软件测试种类
   • 单元测试 ：对软件中的基本单位进行测试，内容包括接口测试、局部数据结构测试、重要执行路径测试、错误处理测试、边界条件测试，方法有驱动模块和桩模块，技术包括静态测试、白盒测试、状态转换测试、功能测试和非功能测试。
   • 集成测试 ：将模块组合在一起进行测试，内容包括测试模块间的接口和相互作用，方法有非增量式和增量式集成测试（自顶向下、自底向上），技术包括对集成后的模块进行功能和性能测试。
   • 系统测试 ：对整个软件系统进行测试，内容包括功能测试、性能测试、强度测试、可靠性测试、恢复测试、安装测试、安全性测试、配置测试、可用性测试、兼容性测试、网站测试等。
   • 验收测试 ：决定软件是否满足验收标准并交付给用户，内容包括测试软件是否满足用户需求，技术包括α测试和β测试。
   • 回归测试 ：在软件修改后进行测试，确保修改后的软件仍然正确，测试策略包括维护测试用例库和选择回归测试包，测试过程涉及重新运行测试用例，技术包括选择性回归测试和完整回归测试。
3. 软件测试与软件开发的关系
   • 软件测试贯穿于整个软件开发生命周期 ：软件开发的每个阶段都可能引入错误，测试应从需求分析阶段开始，贯穿整个生命周期。
   • 生命周期测试与 V 模型 ：V 模型描述了软件开发过程与测试过程的关系，强调测试活动与开发活动的对应关系。
4. 软件测试的现状
   • 软件测试从早期的与调试等同，发展到如今其重要性和规范性不断提高，测试方式从手工向自动化转变，测试人员需求增加且素质提高，测试服务体系初步形成。
5. 测试工具选择
   • 测试工具可以帮助提高测试效率和质量，包括白盒测试工具、黑盒测试工具、测试设计和开发工具、测试执行和评估工具、测试管理工具等，在选择工具时要考虑功能（如报表功能、集成能力、兼容性）和成本等因素。

第10章 黑盒测试

1. 黑盒测试的基本概念
   • 黑盒测试是一种软件测试技术，它不考虑程序的内部结构，只根据软件的功能规格说明来设计测试用例，试图发现功能错误或遗漏、界面错误、数据结构或外部数据库访问错误、性能错误、初始化和终止错误等。
2. 等价类划分
   • 划分等价类 ：将输入域划分为有效等价类和无效等价类，有效等价类是合理的输入数据集合，无效等价类是不符合需求规格说明书的输入数据集合。
   • 划分等价类的方法 ：根据输入条件的不同情况，如取值范围、集合、布尔量、一组值、规则、处理方式等，确定相应的等价类。
   • 设计测试用例 ：从划分出的等价类中，按编号唯一性、覆盖有效等价类、覆盖无效等价类等原则设计测试用例。
3. 边界值分析法
   • 边界条件 ：程序在处理边界值时容易出现错误，因此需要特别关注输入条件的边界情况。
   • 边界值的选择方法 ：包括取刚达到和超越范围边界值、取最大和最小个数及相邻值、考虑输出条件的边界、处理有序集合的首尾元素、考虑内部数据结构边界等。
4. 因果图法
   • 因果图设计方法 ：分析程序规格说明中的原因和结果，用因果图表示它们之间的关系，并标明约束条件，然后将因果图转换成判定表，最后根据判定表设计测试用例。
   • 因果图的基本图形符号 ：包括恒等、非、或、与等。
   • 因果图的约束符号 ：有互斥、包含、唯一、要求、屏蔽等。
5. 功能图法
   • 功能图设计方法 ：用功能图形象地表示程序的功能说明，功能图模型由状态迁移图和逻辑功能模型构成，通过生成局部测试用例、测试路径和合成测试用例来进行测试用例设计。
   • 功能图法生成测试用例 ：包括生成局部测试用例、测试路径生成、测试用例合成等步骤。
6. 黑盒测试方法的比较与选择
   • 综合策略 ：通常先进行等价类划分，再结合边界值分析，必要时用错误推测法补充测试用例，对照程序逻辑检查覆盖程度，对于输入条件组合情况可选用因果图法、判定表驱动法、正交试验法、功能图法等。
7. 黑盒测试工具介绍
   • 介绍了一些常用的黑盒测试工具，如 WinRunner、LoadRunner、QuickTest Pro 等，这些工具有助于提高黑盒测试的效率和效果。
8. 小结
   • 总结了黑盒测试的常用方法，包括等价类划分法、边界值分析法、因果图法、功能图分析法等，并强调了这些方法的实践性和相互之间的比较与选择。

第11章 白盒测试

1. 白盒测试的概述
   • 白盒测试的目的 ：检查程序模块的所有独立执行路径、逻辑判定的两种情况、循环的边界和运行界限内的执行、内部数据结构的有效性等。
   • 白盒测试的实施步骤 ：包括测试计划、设计、执行和总结四个阶段，分别进行测试进度制定、测试用例设计、测试结果获取及错误分析解决等工作。
2. 控制流测试
   • 程序结构 ：程序主要由顺序、分支、循环三种结构组成。
   • 语句覆盖 ：设计测试用例使程序中每个可执行语句至少执行一次。优点是直观，缺点是无法测试隐藏条件和隐式分支。
   • 判定覆盖（分支覆盖） ：确保每个判断的取真分支和取假分支至少经历一次。优点是测试能力比语句覆盖强，缺点是忽略条件组合。
   • 条件覆盖 ：保证每个判断中每个条件的可能取值至少满足一次。但覆盖条件的测试用例不一定覆盖分支。
   • 判定 - 条件覆盖 ：要求每个条件的所有可能取值至少出现一次，且每个判断本身的判定结果也至少出现一次。但可能忽略路径覆盖问题。
   • 路径覆盖 ：设计足够多的测试用例覆盖程序中所有可能的路径。优点是覆盖率高，缺点是工作量大且无法保证程序正确性。
   • 几种常用逻辑覆盖的比较 ：从语句覆盖、判定覆盖、条件覆盖、判定 - 条件覆盖、路径覆盖等方面比较各自的优缺点和覆盖能力。
   • 循环测试 ：对循环结构进行测试，确保循环的边界和运行界限内的正确执行。
3. 基本路径测试
   • 程序的控制流图 ：用节点和控制流线表示程序的控制结构，便于分析和测试。
   • 程序结构的要求 ：程序代码不应包含转向不存在的标号、无用的语句标号、无法到达的语句、不能到达退出程序的语句等。
   • 举例分析 ：通过具体示例说明如何画出控制流图、计算圈复杂度、导出和准备测试用例。
4. 程序插装 / 程序变异测试
   • 程序插装 ：在程序中设置断点或打印输出语句，了解程序的动态特性，辅助调试和测试。
   • 程序变异测试 ：通过生成程序的变异体，判断测试集是否能找出变异体的错误，从而评估源程序的正确程度。
5. 白盒测试工具
   • C++Test ：介绍其单元测试功能、主要特性等，如在不需要执行程序的情况下识别运行时缺陷、自动化代码分析以增强兼容性等。
   • JUnit ：说明其特点、使用好处、测试编写原则、特征及使用方法，其核心类和接口包括 Test、TestCase、TestSuite、TestResult 等。
6. 软件缺陷分析
   • 简介 ：对软件缺陷进行分析，了解其类别、级别、产生原因和构成等。
   • 软件缺陷的类别 ：按不同标准可分为功能缺陷、系统缺陷、加工缺陷、数据缺陷、代码缺陷等。
   • 软件缺陷的级别和状态 ：如微小的、一般的、严重的、致命的，以及激活状态、已修正状态、关闭状态等。
   • 软件缺陷产生的原因 ：包括软件本身、团队工作、技术问题、项目管理问题等。
   • 软件缺陷的构成 ：详细阐述功能缺陷、系统缺陷、加工缺陷、数据缺陷、代码缺陷等的具体内容。
7. 小结
   • 白盒测试的重要性 ：白盒测试允许观察程序内部，与黑盒测试互补，完整测试软件不可或缺。
   • 本章内容总结 ：涵盖了白盒测试的基本概念、技术、工具及软件缺陷分析等内容，强调了白盒测试在软件质量保证中的作用。

第12章 基于缺陷模式的软件测试

1. 概述
   • 软件缺陷的不可避免性与代价 ：软件开发中缺陷不可避免，发现越晚修复成本越高，如编码测试阶段未发现的缺陷，到系统测试时修复成本大幅上升。
   • 相关定义 ：
     • 软件错误 ：软件生存期内的不希望或不可接受的人为错误，导致软件缺陷产生。
     • 软件缺陷 ：软件中存在的不希望或不可接受的偏差，运行于特定条件时被激活引发软件故障。
     • 软件故障 ：软件运行时出现的不希望或不可接受的内部状态。
     • 软件失效 ：软件运行时产生的不希望或不可接受的外部行为结果。
   • 软件缺陷的产生原因 ：包括程序编写错误、未按规定编写、软件复杂性、开发人员态度、沟通问题、需求频繁变更、进度压力、管理失误等。
   • 减少缺陷的关键因素 ：早期发现问题成本低，有效的审核和人员专业性训练可显著减少缺陷。
   • 软件缺陷的特征 ：在瀑布模型开发过程中，缺陷会积累和放大。
2. 软件缺陷属性
   • 缺陷标识 ：唯一标识每个缺陷的符号。
   • 缺陷类型 ：如功能缺陷、用户界面缺陷、文档缺陷等。
   • 缺陷严重程度 ：对软件产品影响程度的划分，如 Critical、Major、Minor 等。
   • 缺陷优先级 ：修复缺陷的紧急程度，如立即解决、正常排队、不急等。
   • 缺陷状态 ：缺陷在修复过程中的情况，如已提交、打开、拒绝、已解决、已关闭等。
   • 缺陷起源 ：缺陷首次被检测到的阶段。
   • 缺陷来源 ：引起缺陷的起因。
   • 缺陷根源 ：发生错误的根本因素。
3. 软件缺陷的严重性和优先级
   • 严重性和优先级的关系 ：严重性反映缺陷对软件质量的破坏程度，优先级表示修复顺序。
   • 处理常见错误 ：避免夸大或掩盖缺陷严重程度和优先级。
   • 严重性和优先级的表示和确定 ：根据缺陷对功能、性能的影响程度及修复难度等确定。
4. 软件缺陷管理和 CMM 的关系
   • 初始级的缺陷管理 ：无章可循，项目交货期不可预测，测试成本高。
   • 可重复级的缺陷管理 ：项目制定自身缺陷管理过程，记录和监控缺陷。
   • 已定义级的缺陷管理 ：组织级缺陷管理过程，项目根据组织级过程定制自身过程。
   • 定量管理级的缺陷管理 ：通过量化数据管理缺陷。
   • 持续优化级的缺陷管理 ：持续改进缺陷管理过程。
5. 报告软件缺陷
   • 基本原则 ：准确报告缺陷，提供清晰准确的描述、再现步骤、完整信息等。
   • 有效描述规则 ：单一准确、可以再现、完整统一、短小简练、特定条件、补充完善、不做评价。
   • IEEE 软件缺陷报告模板 ：包括软件缺陷报告标识符、总结、描述等详细内容。
6. 软件缺陷管理
   • 缺陷管理目标 ：跟踪管理各阶段发现的缺陷，确保处理达到标准，收集数据支持决策。
   • 人员职责 ：明确项目经理、项目测试负责人、测试人员、开发人员、质量保证人员等的职责。
   • 缺陷生命周期 ：缺陷从发现到关闭的状态变化过程。
   • 缺陷管理系统 ：用于管理缺陷整个生命周期的工具，提供多种功能，如 Bugzilla、ClearQuest 等。
7. 软件缺陷分析
   • 缺陷分析方法 ：如缺陷趋势图、分布图、处理统计表。
   • 缺陷分析指标 ：缺陷发现率、潜伏期、密度、清除率等。
8. 小结
   • 强调软件缺陷管理的重要性，指出其在国内的研究和应用相对较少，具有广阔的发展前景。

第13章 集成测试

1. 概述
   • 集成测试的定义 ：在单元测试基础上，将多个模块组合在一起测试，检查接口正确性，是单元测试的扩展，不能保证满足用户需求，需结合系统测试。
   • 与单元测试和系统测试的区别 ：单元测试关注模块内部及部分接口，集成测试关注穿越接口的数据；系统测试涉及整个软件系统及硬件等，从用户角度评价。
   • 集成测试的主要任务 ：检查模块组装后的接口数据丢失、子功能组合、相互影响、全局数据结构、误差累积等问题。
   • 集成测试的层次与原则 ：包括层次划分和原则，如所有公共接口要测试、关键模块充分测试、按层次进行、考虑质量成本进度、尽早开始并与总体设计为基础、充分沟通、修改接口再测、记录执行结果等。
2. 集成测试策略
   • 非渐增式集成 ：先分散测试后集中集成测试。
   • 渐增式集成 ：自顶向下和自底向上两种方式，各有优缺点。
   • 其他集成测试策略 ：三明治集成、核心系统先行集成、高频集成等。
   • 几种集成测试实施方案的比较 ：非增量式、自顶向下、自底向上、三明治、核心系统先行等方案在测试用例规模、驱动和桩模块工作量、缺陷定位等方面各有特点。
3. 集成测试用例设计
   • 从系统运行、正向测试、逆向测试、特殊需求、高覆盖率、模块接口依赖关系等角度设计用例。
4. 集成测试的过程
   • 计划阶段 ：完成集成测试计划，制定策略。
   • 设计实现阶段 ：建立测试环境，完成设计开发。
   • 执行评估阶段 ：执行用例，记录评估结果。
5. 面向对象的集成测试
   • 对象交互 ：介绍对象间请求操作及类接口方式，如公共操作命名类型、返回值类型、创建实例、引用实例等，以及汇集类测试和协作类测试。
   • 步骤 ：选定检测类、确定覆盖标准、利用结构关系图确定关联、构造测试用例。
   • 常用测试技术 ：抽样测试、正交阵列测试等。
6. 小结
   • 集成测试是关键环节，最好由开发人员完成，集成测试策略围绕接口覆盖和集成树路径设计，灵活选择策略。

第14章 系统测试

1. 概述
   • 定义 ：对通过集成测试的软件系统，与硬件、外设、支撑软件等组合进行测试，验证是否满足需求。
   • 流程 ：在完成产品需求和系统设计文档后，系统测试小组可提前制定计划和设计用例，提高效率。
   • 目标 ：确保活动按计划、验证产品与需求符合、建立缺陷记录跟踪库、及时通知相关小组和个人。
   • 方针 ：指定测试工程师负责、向相关领导报告、遵循文档化标准过程、建立缺陷库、定期评估汇报。
   • 原则 ：寻找外部输入层测试空间、测试异常空间、计划阶段定好测试形式、认识系统测试难度高。
2. 系统测试主要方法
   • 性能测试 ：关注时间性能（响应时间）和空间性能（系统资源消耗），目标是判断系统是否满足性能需求、表现性能。
   • 强度测试 ：模拟实际软硬件环境和用户使用过程的系统负荷，长时间或超负荷运行测试软件，检查系统最高负载能力。
   • 安全性测试 ：考虑系统对无效参数、指令的处理，配置数据保存恢复、导出导入，密码登录处理，安全性功能有效性等问题。
   • 兼容性测试 ：明确软件兼容的操作系统、浏览器、应用软件等，考虑向前向后兼容、不同版本兼容性，依据标准规范进行数据共享兼容性测试。
   • 恢复测试 ：关注潜在灾难和系统失效后果，系统保护和恢复过程对错误的反应，恢复过程正确性。
   • 用户图形界面测试 ：遵循规范化、灵活性、正确性、直观性、舒适性、实用性、一致性、帮助、独特性、多窗口应用与系统资源等规则。
   • 安装测试 ：目标包括安装程序正确运行、程序安装正确、安装后能运行、完善性安装后仍能正确运行。
   • 可靠性测试 ：以改善软件可靠性为目的，测试平均无故障时间、故障停机时间等指标，可借助软件可靠性模型评估。
   • 配置测试 ：在各种硬件和软件平台及不同设置下检查软件操作，保证软件在设计和连接的硬件上正常工作。
   • 可用性测试 ：关注符合标准规范、直观性、一致性、灵活性、舒适性、正确性、实用性等。
   • 文档资料测试 ：测试文档内容及其对软件整体质量的影响，注意文档开发与软件开发的不同。
   • 网站测试 ：包括文字、链接、图形、表单、动态内容、数据库、服务器性能和加载、安全性等测试。
3. 系统测试工具及其应用
   • 分类 ：负载压力测试工具（LoadRunner、QALoad、E-Test Suite、JMeter、ACT）、功能测试工具（WinRunner、QARun、IBM Rational Robot、SilkTest）、白盒测试工具（Logiscope、JUnit、Cunit、IBM Rational Purify）、测试管理工具（TestDirector、TestManager）。
   • 常见测试工具 ：介绍各种工具的特点和用途。
4. 小结
   • 系统测试是产品交付前最后一个测试环节，重要性高，目的是保证交付的软件满足用户需求，测试用例应在实际用户环境下执行。

第15章 测试管理

1. 测试的过程及组织
   • 测试过程 ：包括代码会审、单元测试、集成测试、验收测试等阶段，以保证测试质量。
   • 测试方法的应用 ：集成测试及后续阶段一般采用黑盒方法，策略包括边值分析法、等价分类法、猜测法、因果图法等；单元测试结合白盒法和黑盒法。
   • 测试的人员组织 ：明确不同角色在测试过程中的职责，如需求分析规格说明、设计评审、程序测试等。
   • 软件测试文件 ：包括测试文件的类型、使用目的（如验证需求正确性、检验测试资源等）和编制要求。
2. 建立软件测试管理体系
   • 建立体系 ：明确测试员和程序员的关系，测试管理体系应涵盖软件产品的监视和测量、产品设计和开发的验证等方面。
   • 项目组织结构设计与选择 ：理解项目组织的概念、设置原则（如目的性、高效精干、一体化组织原则）以及不同类型（如工作队式、部门控制式等）。
   • 测试管理者的工作原则 ：如雇用合适员工、定期一对一谈话、重视结果等。
3. 测试文档的撰写
   • 重要性 ：好的软件文档能提高易用性、可靠性和降低支持费用。
   • 测试计划 ：内容包括概要、目标和发布标准、测试领域、方法描述、进度表、资源、配置范围、工具等。
   • 测试规范 ：包括背景信息、测试特性、功能考虑、测试考虑、假定等。
   • 测试案例和测试报告 ：开发测试案例需依据规范，在运行过程中不断补充；测试报告应包含必要信息。
   • 软件缺陷报告 ：应涵盖缺陷名称、软件版本、优先级与严重性、测试步骤、后果、预计结果等。
4. 调试的技巧
   • 调试过程 ：包括自动化测试过程的计划、设计、开发、执行、维护等步骤。
   • 心理因素 ：调试能力受个人先天因素影响，且调试工作易让人沮丧，需克服心理障碍。
   • 调试方法 ：如蛮力法、回溯、原因排除法等，以及调试时需要考虑的问题（如错误是否在其他地方产生过等）。
5. 软件测试自动化
   • 实施理由 ：提高测试效率、降低成本、避免人工错误、实现复杂测试场景等。
   • 引入条件 ：从项目规模、产品特征、人员素质和角色分配等方面考虑。
   • 不同阶段的优势 ：明确在不同测试阶段（如单元测试、集成测试、系统测试、回归测试、性能测试）自动化测试的应用优势和手工测试的适用情况。
   • 常用自动测试开发工具 ：介绍多种厂商及其工具的特点、优缺点，如 Mercury Interactive Corporation 的 Winrunner、Loadrunner 等，IBM Rational 的工具，Compuware Corporation 的工具，Segue Software 的工具等。
6. 小结
   • 总结软件测试管理的重要性，强调软件测试管理继承了软件工程学和管理学的多种理念和方法，鼓励软件测试工程师迎接挑战。

第16章 测试 “题外话”

1. 可用性测试
   • 定义与地位 ：可用性测试是用户体验测试，具有重要地位，但其定义和评价较为模糊。
   • 基本要素 ：涵盖软件操作是否考虑用户理解力、教育背景、环境压力，程序输出和错误提示信息的意义性，用户界面设计的一致性，是否符合使用习惯等方面。
   • 流程 ：包括测试用户的选择（普通用户和测试专家）、测试人员规模、数据采集方法（如自我记录、眼球跟踪等）、可用性调查问卷设计，以及确定测试结束的条件。
2. 软件复杂度
   • 圈复杂度 ：是衡量代码复杂度的标准，介绍计算公式（如 V(G)=E-N+2 等）和在单元级、集成级、面向对象级的应用。
   • 面向对象的复杂度度量 ：如 CK 度量法的 6 种度量（WMC、DIT、NOC、CBO、RFC、LCOM）。
3. 软件分析建模
   • 流程图、控制流图、决策表、因果图、Petri 网 ：介绍这些分析建模工具的结构、特点和应用，特别是 Petri 网的结构元素（库所、变迁、有向弧）、变迁发生规则、演变（如令牌着色、时间戳、层次化、时序逻辑）等内容。
4. 软件质量保证与测试
   • SQA（Software Quality Assurance） ：强调软件质量保证的重要性，与软件测试（ST）共同构成软件质量保障体系。