【软件质量与软件测试】

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

1.1 软件特征与软件工程

软件的定义（IEEE）

• 软件是计算机程序、规程以及可能的相关文档和运行计算机系统需要的数据。

• 软件包含计算机程序、规程、文档和软件系统运行所必需的数据四个部分

计算机硬件vs计算机软件

• 软件是逻辑产品，而不是物理产品，所以， 软件具有和硬件完全不同的特征

软件具有与硬件完全不同的特征

• 软件是开发产生的，而不是用传统方法制造。
• 软件不会像硬件一样有磨损。
• 很多软件不能通过已有构件组装，只能自 己定义。

硬件、软件失效曲线图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GBoZpE6v-1684854031351)(D:\Typora Img\image-20230523191933514.png)]

​

1.1.1 软件分类

当前的计算机软件分为七个大类

• 系统软件
• 应用软件
• Web应用软件
• 工程和科学软件
• 嵌入式软件
• 产品线软件
• 人工智能软件

新的挑战

• 普适计算
• 网络资源
• 开源软件
• 新经济

​

1.1.2 层次化软件工程

• 指将软件生命周期分解为若干个阶段，并在每个阶段中执行一定的活动来实现软件开发过程的工程化管理。

软件工程

• （1）将系统化的、规范的、可度量的方法 应用于软件的开发、运行和维护的过程，即将工程化 应用于软件中。
• （2）（1）中所述方法的研究

软件工程的视图

• 指从不同的角度出发，通过组织系统的各种元素（如代码、模块、接口、数据等）来描述、理解和分析软件系统的不同方面，以便更好地管理和开发软件。

三个视图

• 定义阶段针对“做什么”
• 开发阶段针对“如何做”
• 维护阶段针对“改变”

1.1.3 软件范型的转变

• 指随着软件工程的不断发展，软件范型也在不断变化。传统的软件开发模型如瀑布模型逐渐被敏捷开发、 DevOps等新型模型所取代。

1.1.4 现代软件开发

• 指在全球化、跨组织、分布式等背景下，以用户为中心、强调快速迭代、高质量和创新的软件开发方式。

1.2软件质量

1.2.1质量概念

• 指符合预期要求的特性和特征的总体体现。

1.2.2质量运动

• 指以质量为中心的全面管理和改进过程。

全面质量管理四个步骤

1. 规划：确定质量目标和过程，建立质量保证体系。
2. 实施：执行规划阶段确定的质量保证体系，进行过程控制、持续改进和培训等活动。
3. 检测：监控和测量过程和产品，以确定它们是否符合质量标准和要求。
4. 改进：通过分析检测结果和不断改进来提高产品和过程的质量，并寻求新的改进机会和方法。

1.2.3 软件质量概念

• IEEE关于软件质量的定义：软件质量是

• 系统、部件或者过程满足规定需求的程度。

• 系统、部件或者过程满足顾客或者用户需要或期望的程度。

该定义相对客观，强调了产品（或服务）和客户/社会需求的 一致性

6个主要特征

• 功能性：软件实现的功能达到要求的和隐含的用户需 求以及设计规范的程度，
• 可靠性：软件在指定条件和特定时间段内维持性能的 能力程度，
• 易使用性：用户使用该软件所付出的学习精力，
• 效率：在指定条件下，软件功能与所占用资源之间的 比值，
• 可维护性：当发现错误、运行环境改变或客户需求改 变时，程序能修改的容易程度，
• 可移植性：将软件从一种环境移入另一种环境的容易程度

软件质量保证和测试的关系

• 质量保证+测试=好的软件

1.2.4 软件质量评价体系与标准

• 指用于评估和衡量软件质量的标准、模型和框架等。

软件质量保证（SQA）

• 软件质量保证是一系列计划和活动，旨在确保软件产品和相关工作过程符合预期的标准和质量要求，并为提高软件质量提供方法和支持。

1.3 软件测试与可靠性概述

1.3.1 软件测试的意义

• 在于发现和修复软件缺陷，提高软件质量和可靠性。

1.3.2 软件测试的定义

• 软件测试是使用人工或自动手段来运行或测定某个系统的过程，检验它是否满足规定的需求或者弄清预期结果与实际结果之间的差别

1.3.3 软件测试方法

• 静态方法和动态方法
• 黑盒测试、白盒测试和灰盒测试
• 基于软件开发阶段的测试方法

1.3.4 软件测试自动化

• 指利用工具和技术实现自动化测试的过程。
  • 白盒测试工具
  • 功能测试工具
  • 负载压力测试工具
  • 测试管理工具

1.3.5 软件缺陷的修复费用

• 修复软件缺陷费用，随着时间越来越多

软件测试工程师具备的素质

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qvgflCDx-1684854031352)(D:\Typora Img\image-20230523194608519.png)]

1.4软件质量保证与测试人才的特点

1. 具备技术能力：软件质量保证和测试人员需要拥有良好的技术能力，包括软件开发技术、测试工具和方法等方面的知识。
2. 注重细节：软件质量保证和测试人员需要注重细节，能够发现和记录问题，准确地描述问题并跟踪解决方案。
3. 沟通协作：软件质量保证和测试人员需要良好的沟通协作能力，与开发人员、项目经理和其他相关人员合作，积极参与项目，及时反馈和解决问题。
4. 分析判断：软件质量保证和测试人员需要具备敏锐的分析和判断能力，能够独立思考并快速找出问题的根本原因。
5. 持续学习：软件质量保证和测试人员需要具备持续学习的意愿和能力，关注新的技术和工具，并且积极地将其应用到日常工作中，提高工作效率和质量。
6. 责任心强：软件质量保证和测试人员需要具备强烈的责任心和敬业精神，能够承担自己的工作，保证项目质量和进度。

1.5本章小结

• 软件质量保证是建立一套有计划，有系统的方法，来向管 理层保证拟定出的标准、步骤、实践和方法能够正确地被 所有项目所采用。
• 软件测试是利用测试工具按照测试方案和流程对产品进行 功能和性能测试，甚至根据需要编写不同的测试工具，设 计和维护测试系统，对测试方案可能出现的问题进行分析和评估。

第二章 软件质量工程体系

2.1软件质量控制的基本方法

2.1.1 软件质量控制基本概念

• 软件质量控制是指在软件开发过程中对各个环节进行跟踪和监控，及时发现和解决问题，确保软件最终质量达到预期要求。

2.1.2 软件质量控制的基本方法

• 目标问题度量法

  • 设定目标：对项目的各个方面（产品、过程和资源）设定具体的目标，这些目标应该非常明确，能够反映出期望的质量和目标。
  • 提出问题：针对每一个目标提出一系列问题，这些问题应该能够反映出目标是否得到了满足，或者哪些方面需要改进。
  • 定量化目标：将回答问题的答案映射到软件质量等级的度量上，根据度量得出软件目标是否达到的结论，或确认哪些做好了，哪些仍需改善。
  • 收集数据：为收集和分析数据做出计划，将收集到的数据保存长期使用，以便使目标得到长期、持续的改善。

• 风险管理法

  • 根据经验识别风险要素
  • 评估风险
  • 划分风险等级并排序
  • 选择控制风险的技术并制定计划
  • 执行计划并监视进程
  • 持续评估风险状态并采取正确的措施

• SEI风险管理模型：定义了一套标准的风险管理过程

  • 风险识别
  • 风险分析
  • 风险计划
  • 风险控制
  • 风险跟踪

  风险控制方法

  • 风险避免
  • 风险弱化
  • 风险承担
  • 风险转移

2.2软件质量控制模型和技术

2.2.1 软件质量控制模型

• 指用于定量描述软件质量的模型。基于PDCA的全面统计质量控制(Total Statistical Quality Control， TSQC)模型，是我国实际采用的模型之一

2.2.2 软件质量控制模型参数

• 包括产品，过程，资源等方面。这些参数可以用来衡量软件的质量和可靠性。

2.2.3 软件质量控制的实施过程

• 预开发阶段，开发阶段，维护阶段

2.2.3 软件质量控制技术

• 包括静态分析、动态测试、代码审查、性能测试、安全测试等方法。通过这些技术，可以有效地提高软件的质量和可靠性。

2.3软件质量保证体系

• 软件质量保证（Software Quality Assure，SQA）是建立 一套有计划，有系统的方法，来向管理层保证拟定出的标准、 步骤、实践和方法能够正确地被所有项目所采用。软件质量保 证的目的是使软件过程对于管理人员来说是可见的。

2.3.1软件质量保证内容

能力成熟度模型（CMM）

• 是对于软件组织在定义、实施、度量、控制和改善其 软件过程的实践中各个发展阶段的描述
• 核心：是把软件开发视为一个过程，并根据这一原则对软件 开发和维护进行过程监控和研究，以使其更加科学化、 标准化、使企业能够更好地实现商业目标

CMM基本思想

• 通过分阶段的方式，对软件生产过程中的质量进行管理和改进，从而提高软件开发组织的成熟度和生产质量。

CMM必要性

• 在需求工程方面，CMM可以帮助系统分析人员理解问题或描述产品的外在行为，提高需求工程的效率和质量。
• 在软件复用方面，CMM可以利用已有的工程知识和方法，从已存在的系统中建造新的系统，提高软件产品的质量和生产率。
• 在其他方面，CMM也可以通过软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等手段来帮助软件开发组织提高成熟度和生产质量。

2.3.2软件质量保证SQA

• SQA（Software Quality Assurance，软件质量保证）是指在软件开发过程中，通过执行一系列的计划、行动和控制来确保软件满足预期的要求和质量标准的过程。
  • SQA的背景是由于软件产品质量问题频繁出现，为了解决这些问题，SQA应运而生。
  • SQA的目标是确保软件开发过程中的质量标准得以满足，从而提高软件产品质量、提高客户满意度、减少开发成本和时间。
  • SQA的任务包括：建立SQA计划、执行SQA活动、监控SQA效果、评估SQA效果和改进SQA过程。
  • 在软件开发不同阶段实施SQA的目标是不同的。
    • 在需求定义阶段，SQA的目标是审查并确认需求规格书的正确性、完备性和一致性。
    • 在设计阶段，SQA的目标是确保软件设计符合规范、设计的可靠性和可维护性。
    • 在编码和测试阶段，SQA的目标是确保代码质量可靠，测试用例充分覆盖且结果正确。
  • 常见的SQA活动包括对软件开发活动的计划、评审和审计。
    • 计划方面，SQA需要制定SQA计划和各项活动的计划。
    • 评审方面，SQA需要对软件文档（例如需求规格书、设计文档和测试用例）进行评审，以保证其质量和符合标准。
    • 审计方面，SQA需要进行代码审计、测试审计和配置管理审计等活动，以确保所有开发活动的一致性、可管理性和可追溯性。
  • 实施SQA的过程中，需要进行多个方面的工作，包括建立SQA组织、制定SQA政策和计划、开展SQA培训、建立SQA指标和测量方法、设定质量标准和过程标准等，通过这些措施来提高软件开发的质量、效率和可靠性。

2.4小结

• 软件质量控制是一组由开发组织使用的程序和方法，使用 它可在规定的资金投入和时间限制的条件下，提供满足客 户质量要求的软件产品并持续不断地改善开发过程和开发 组织本身，以提高将来生产高质量软件产品的能力。
• 用于软件控制的一般性方法有三种: 目标问题度量法；风险管理法；PDCA质量控制法。其中在我国最常用的是模 型是基于PDCA的全面服务质量管理（TSQC）模型。
• 软件质量保证（SQA）是建立一套有计划，有系统的方法， 来向管理层保证拟定出的标准、步骤、实践和方法能够正 确地被所有项目所采用。

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

3.1概述

3.1.1 度量

• 度量是指用数值来表达实体属性的过程。在软件质量保证中，度量是对软件质量和过程进行评价的一种有效手段。

3.1.2 软件度量

• 软件度量是对软件产品和软件过程的特征，进行定性和定量分析的一种方法。

3.1.3 软件度量的作用

• 通过软件度量增加理解；
• 通过软件度量管理软件项目，主要是计划和估算、跟踪和确认；
• 通过软件度量指导软件过程改善，主要是理解、评估和包装。 软件度量对于不同的实施对象，具有不同的效用

3.2软件质量度量

3.2.1软件质量和软件质量要素

• 软件质量是指软件产品同时满足用户需求和期望的能力。
• 软件质量要素包括功能性、可靠性、易用性、效率性、可维护性和可移植性等方面。

3.2.2影响软件质量的因素

• 人
• 过程
• 技术

3.2.3质量保证模型

• McCall模型：将软件质量定义为“软件的特性或特征对使用者需要和期望的满足程度”。该模型将软件质量分为11个方面，包括正确性、可靠性、效率、可维护性、灵活性、易用性等。这些方面被视为软件质量因素，是评估软件质量的重要指标。
• Boehm模型：将软件质量定义为“预定目标的符合程度”。该模型在质量因素上提出了6个大类共75个质量特性因素，并结合成本、进度等因素进行综合评估，是一种比较全面的软件质量评估方法。
• FURPS模型：将软件质量定义为“软件系统在使用过程中满足用户需求的能力”。该模型在功能、可用性、可靠性、性能和支持五个方面来描述软件质量，可以帮助开发者更好地理解用户需求，从而设计出更符合用户期望的软件产品。
• ISO9126：将软件质量定义为“软件产品满足规定的特性和相关的标准和程序要求的程度”。该模型将软件质量分为6个特性：功能性、可靠性、可用性、效率、可维护性和可移植性，是一种标准化的软件质量评估方法。

3.2.4 缺陷排除效率

• 缺陷排除效率是指在软件开发生命周期内，发现缺陷并将其纠正的成本和时间。

3.3软件过程度量

3.3.1 软件过程度量概念

• 软件过程度量是指对软件开发过程中的各个环节进行定量化分析的方法。

3.3.2 软件过程度量常见问题

• 度量的太多、太频繁
• 度量的太少、太迟
• 度量了不正确的事物或属性
• 度量的定义不精确
• 收集了数据却没有利用
• 错误的解释度量数据
• 自动化工具欠缺

3.3.3 基于目标的软件过程度量方法

• GQM模型是一种层次状结构，最上层，是一个目标， 对该目标细化就得到几个问题，构成问题层。 这几个问题，将关注的方面分解为几个部分

一个目标主要受几个因素的控制

• ISSUES（侧重点）：度量对象的质量重点。
• VIEWPOINT（立场）：信息使用者。
• OBJECT（对象）：要度量对象。
• PURPOSES（目的）：一般是理解、控制和改进要度量 的对象

使用GQM模型进行软件质量管理时，如何获得问题和选择数据项

1. 对于特定目标陈述中的对象，应该抓住可以量化的特征。例如，在评估同行评审效率时，可以关注同行评审的缺陷检测率、评审流程的符合度等可量化的特征。
2. 结合模型中的侧重点，应该对这些特征进行描述，并评价度量对象的这些特征。例如，在评估同行评审效率时，可以计算同行评审效率的偏差和趋势，以及每人发现的缺陷数量的变化等。
3. 在选择数据项时，应该尽可能利用现有数据，但也要考虑数据的有效性和稳定性。对于成熟、稳定的度量对象，应该多应用客观度量，而对于不成熟、不稳定的对象，则可以结合主观判断来获得数据。
4. 在使用GQM模型进行软件质量管理时，应该意识到这是一个渐进的过程，所选择的度量项不仅可以评价度量的对象，也反映了模型本身的可靠性和质量。

3.4软件配置管理

3.4.1 软件配置管理的目标

• 软件配置管理的目标是为了确保软件产品的正确性、完整性和可追溯性。

3.4.2 软件配置管理角色职责

• 项目经理（Project Manager，PM）
• 配置控制委员会（Configuration Control Board，CCB）
• 配置管理员（Configuration Management Officer，CMO）
• 系统集成员（System Integration Officer，SIO）
• 开发人员（Developer，DEV）

3.4.3软件配置管理过程描述

• 在项目计划阶段，首先CCB根据项目的开发计划确定各个里程碑和开发策略。然后，CMO根据CCB的规划，制定详细的配置管理计划，并提交给CCB审核。如果通过审核，CCB会将配置管理计划交给项目经理进行批准，并发布实施。
• 在项目开发维护阶段，软件配置管理工作主要由CMO完成。具体地说，SIO和DEV会执行软件配置管理策略，而CMO则负责管理和维护整个过程。在这个阶段，变更流程起着重要的作用，可以帮助团队及时、有效地处理变更请求，确保软件配置的正确性和一致性。

3.4.4 软件配置管理的关键活动

• 软件配置管理的关键活动包括配置项识别、配置项控制、变更控制、版本管理和审核等环节。

3.4.5 常用的软件配置管理工具

• 第一级别是入门级的工具，主要用于简单的版本控制，例如Concurrent Version System (CVS)和Visual Source Safe(VSS)等。这些工具的功能相对简单，适合小型项目或者个人使用。
• 第二级别是项目级配置管理工具，适合管理中小型的项目，例如PVCS和MKS等。这些工具可以提供更为复杂的配置管理功能，如需求管理、缺陷管理、任务管理等，并且支持协同开发和团队合作。
• 第三级别是企业级配置管理工具，具有强大的过程管理功能。例如CCC Harvest和ClearCase等，它们能够处理大规模、复杂的软件开发项目，提供完整的项目生命周期管理，包括需求管理、版本管理、构建管理、测试管理和发布管理等各个方面。

3.5小结

• 测量使得管理者和开发者能够改善软件过程；辅 助软件项目的计划、跟踪及控制；评估产生的产 品（软件）的质量。
• 过程度量使得一个组织能够从战略级洞悉一个软件过程的功效。
• 软件配置管理覆盖了整个软件的开发过程，因此 是改进我们的软件过程、提高过程能力成熟度的 理想的切入点

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

4.1 软件可靠性

4.1.1 软件可靠性发展史

• 软件可靠性的概念最早出现在20世纪60年代，随着计算机技术的快速发展和软件复杂度的不断提高，软件可靠性也逐渐引起了人们的重视，先后提出了多种软件可靠性模型和方法。

4.1.2 软件可靠性的定义

• ​ 软件可靠性是指在给定条件下，在规定时间内完成规定功能所需的程度。简单地说，软件可靠性就是软件能够在一定时间内正常运行，不发生故障或出错的能力。

4.1.3 软件可靠性的基本数学关系

• 当软件开始运行后，随着时间的延续，其失效概率逐渐增大， 在长期运行之后将趋近于1，其可靠度则逐渐降低，并趋近于0。

4.1.4 软件可靠性与硬件可靠性的区别

• 硬件有老化损耗现象，而软件不发生物理变化。硬件失效是物理故障，而软件失效是与输入数据有关的软件差错。
• 对硬件可采用预防性维护技术预防故障，采用断开失效部件的办法诊断故障，而软件则不能采用这些技术。
• 事先估计可靠性测试和可靠性的逐步增长等技术对软件和硬件有不同的意义。
• 硬件可靠性已有成熟的产品市场，而软件产品市场还很新。

4.1.5 影响软件可靠性的因素： 影响软件可靠性的因素包括

• 需求分析定义错误。如用户提出的需求不完整，用户 需求的变更未及时消化，软件开发者和用户对需求的 理解不同等等。
• 设计错误。如处理的结构和算法错误，缺乏对特殊情 况和错误处理的考虑等。
• 编码错误。如语法错误，变量初始化错误等。
• 测试错误。如数据准备错误，测试用例错误等。
• 文档错误。如文档不齐全，文档相关内容不一致，文档版本不一致，缺乏完整性等

4.1.6 软件的差错、故障和失效

• 软件的差错指的是代码中存在的错误
• 故障则是指软件在特定场景下出现的运行问题。
• 失效则是指软件无法完成所需功能的情况。

4.2 可靠性模型及其评价标准

4.2.1 软件可靠性模型

• ​ 软件可靠性模型是指通过对软件进行分析，预测软件运行过程中可能出现的故障和失效，从而提高软件可靠性的方法。常用的软件可靠性模型包括魏布尔分布、指数分布等。

4.2.2 软件可靠性模型参数

• ​ 软件可靠性模型的参数包括故障率、失效率、可靠性和平均失效时间等。

4.2.3 软件可靠性模型及其应用

• Musa基本模型：是软件可靠性模型的经典模型之一，用于估计软件故障/失效的数量和故障率。该模型假设故障发生的时间间隔服从参数为lambda的指数分布，在故障被检测到时，发生故障的部分会被修复并重新测试，如此循环直到新的故障不再被发现。该模型的优点在于简单易懂，适用于大多数软件开发过程，但缺点是对于长时间的可靠性预测较为困难。
• Musa对数模型：是在基本模型的基础上进一步发展而来，将故障发生的时间间隔取对数后假设服从高斯分布，可以更加准确地估计故障发生的数量和故障率，并且还能够考虑到故障率对时间的变化趋势。但是这个模型需要更多的数据以及更加复杂的参数估计方法，使用上也更加困难。
• Goel-Okumoto模型：是另一个常用的软件可靠性模型，基于泊松过程和马尔科夫链理论，用于描述软件故障率的变化。该模型假设每个故障都是独立发生的，故障发生的速率也随着时间而变化，同时假设故障率满足一定的数学分布形式。该模型优点在于能够准确地估计故障率的变化趋势，但缺点在于需要更多的可靠性数据以及复杂的参数调整过程。

4.2.4 软件可靠性模型评价准则

• 模型拟合性
• 模型预计有效性
• 模型偏差
• 模型偏差趋势
• 模型噪声

4.3 软件可靠性测试和评估

4.3.1 软件可靠性评测

• 软件可靠性评测是指通过对软件进行测试，评估软件的可靠性，找出其中存在的问题和缺陷，并提出改进建议的过程。

4.3.2 软件可靠性测试的具体实施过程

• 软件可靠性测试包括测试计划的制定、测试环境的搭建、测试数据的准备、测试用例的设计、测试执行和测试结果分析等环节。

4.4 提高软件可靠性的方法和技术

4.4.1 建立以可靠性为核心的质量标准

• 建立以可靠性为核心的质量标准是提高软件可靠性的关键所在。在软件开发过程中，应该优先考虑软件的可靠性，确保软件能够稳定运行。

确定划分的各开发过程的质量度量

• 需求分析质量度量
• 设计结果质量度量
• 测试结果质量度量
• 验收结果质量度量

4.4.2 选择开发方法

• 选择适合的开发方法也是提高软件可靠性的重要因素。比如采用敏捷开发方法，可以让开发人员更快地进行反馈和修正。

4.4.3 软件重用

• 软件重用是指在软件开发过程中复用已有的软件模块或代码。通过软件重用，可以减少代码编写，提高生产效率，同时也可以提高软件的可靠性。
• 软件重用不仅仅是指软件本身，也可以是 软件的开发思想方法、文档，甚至环境、 数据等，包括三个方面内容的重用：
  • 开发过程重用，指开发规范、各种开发方法、 工具和标准等。
  • 软件构件重用，指文档、程序和数据等。
  • 知识重用，如相关领域专业知识的重用

4.4.4 使用开发管理工具

• 使用开发管理工具可以帮助我们更好地进行项目管理和代码管理，从而提高软件的可靠性。

4.4.5 加强测试

• 测试是提高软件可靠性的关键所在。应该在开发过程中加强对软件的测试，包括单元测试、集成测试、系统测试等环节。

4.4.6 容错设计

• 容错设计是指在软件设计的过程中，考虑程序出现故障时的应对措施。通过容错设计，可以减小程序故障对用户造成的影响，提高软件的可靠性。

4.5 软件可靠性研究的主要问题

• 软件可靠性研究的主要问题包括模型的有效性、参数的选择、测试方法以及可靠性评估标准等方面。

4.6 小结

• ​ 本章介绍了软件可靠性的基本概念，包括软件可靠性的定义、发展史、影响因素、可靠性模型及评价标准、软件可靠性测试和评估、提高软件可靠性的方法和技术等方面。通过加强对软件可靠性的研究和应用，可以提高软件的质量和可靠性，保障软件系统的稳定运行。
• 软件可靠性是指在规定的条件下和规定的 时间内，软件不引起系统故障的能力。
• 软件可靠性不但与软件中存在的缺陷有关， 而且与系统输入和系统使用有关。
• 软件可靠性是软件质量特性中重要的固有 特性和关键因素。
• 软件可靠性反映了用户的质量观点

第五章 软件质量标准

5.1 软件质量标准概述

5.1.1 国际标准

• 由国际机构指定和公布供各国参考的标准称为国际标准。
• 20世纪60年代初，国际标准化组织建立了“计算机与信息处理技术委员会”，专门负责与计算机有关的标准工作。

5.1.2 国家标准

• 由政府或国家级的机构制定或批准，适用于本国范围的标准， 称为国家标准。如
• GB（GuoBiao） 中华人民共和国国家技术监督局是中国的最高标准化机构，它所公布实 施的标准简称为“国标”。
• ANSI（American National Standards Institute） 美国国家标准协会。是美国一些民间标准化组织的领导机构，具有一定的权威性。

5.1.3 行业标准

• 行业标准是由一些行业机构、学术团体或国防机构制定，并适 用于某个业务领域的标准。
• 中华人民共和国国家军用标准（GJB）。是由我国国防科学技 术工业委员会批准，适合国防部门和军队使用的标准。 例如，1988年发布实施的GJB473-88军用软件开发规范。
• 美电气 和电子工程师学会（Institute Of Electrical and Electronics Engineers，IEEE），该学会成立了软件标准技术委员会 （SESS），开展软件标准化活动。
• 美国国防部标准（Department of Defense-Standards， DOD-STD）。美国军用标准（Military-Standards， MIL-S）。
• 另外，我国的一些部门（如信息产业部）也开展了软件标准化 工作，制定和公布了一些适合本部门工作需要的规范。
• 这些规范的制定参考了国际标准和国家标准。这些标准的制定 对各自行业的软件工程起到了强有力的推动作用

5.1.4 企业规范

• 一些大型企业或公司，由于软件工程工作 的需要，制定适用于本部门的规范。
• 例如，美国IBM公司通用产品部（General Products Division）1984年制定“程序设 计开发指南”

5.1.5 项目规范

• 一些大型企业或公司，由于软件工程工作 的需要，制定适用于本部门的规范。
• 例如，美国IBM公司通用产品部（General Products Division）1984年制定“程序设 计开发指南”

5.2 ISO9001和9000-3在软件中的应用

• ISO 9001提供了一套关于质量管理的具体要求
• 而ISO 9000-3则针对软件开发过程中的特殊要求进行了说明。两者相互结合，可以为软件开发建立完整的质量管理体系。

5.3 能力成熟模型CMM&CMMI

5.3.1 CMM质量思想

• CMM提供了一种全面管理和改进软件开发过程的方法，它把软件开发过程中的各个阶段和活动划分为5个能力级别，通过逐步提高能力级别来保证软件开发过程的质量。

5.3.2 CMM关键域

• 初始级
• 可重复级
• 已定义级
• 已管理级
• 优化级

5.3.3 PSP和TSP

• PSP（个人软件过程）是SEI提出的一种针对个人的软件开发过程模型
• TSP（团队软件过程）则是针对团队而提出的一种软件开发过程模型。

5.3.4 CMMI——软件能力成熟度集成模型

• CMMI是CMM继承者，强调了不仅要改进软件开发过程，还要把软件开发和企业战略目标相结合。

5.3.5 CMM中的质量框架

CMM中的质量框架包括过程改进、项目管理、支持过程、组织级过程等。

5.4 IEEE软件工程标准

5.4.1 IEEE 730:2001 结构与内容

定义了软件测试计划应该包括哪些内容，以及这些内容的组成结构。

• 目的
• 参考文档
• 管理
• 文档
• 标准、实践、约定和度量
• 软件评审

5.4.2 IEEE/EIA Std 12207——软件生命周期过程

定义了软件生命周期的13个过程，包括需求、设计、实现、测试、维护等各个方面。

• 主要过程：包括5个过程，这些过程供各主要当事方（如需方、供方、开发者、运行者 和维护者）在参与或完成软件产品开发、运行或维护时使用
• 包括8个过程，其每个过程均有明确的目的支持其它过程，帮助软件项目获 得成功及良好的产品质量。

5.4.3 IEEE Std 1012——验证与确认

定义了软件验证和确认的活动，并提供了相关的标准和指南。

• 验证是用来评价某一系统或某一组件的过程，来判断给定阶段的产 品是否满足该阶段开始时施加的条件。
• 确认是开发过程中间或结束时对某一系统或某一组件进行评价的过 程，以确认它是否满足规定的需求。

5.4.4 IEEE Std 1028——评审

定义了软件评审的活动，并提供了相关的标准和指南。

5.5 其它质量标准

5.5.1 ISO/IEC 15504-2:2003软件过程评估标准

是一种基于过程的评估模型，可以帮助企业评估自己的软件开发过程的效率和质量。

5.5.2 Tick IT

是欧洲计算机应用技术研究所（ECAT）开发的一套面向中小企业的软件质量认证标准。

5.6小结

• 从通用标准的概念、层次等方面展开，侧重于软件 质量标准的介绍，并从整体上了解软件行业标准体 系结构和内容。
  • CMM为软件过程改进提供了一个框架，将整个软件改进 过程分为5个成熟度等级，这5个等级定义了一个有序的 尺度，用来衡量组织软件过程成熟度和评价其软件过程能 力。
  • 在每一级中，定义了达到该级过程管理水平所应解决的主 要问题和关键域。
• CMM成功与否，与组织内部有关人员的积极参与 和创造性活动密不可分，而且，CMM并未提供有 关子过程实现域所需要的具体知识和技能。
  • 因此，个体软件过程和团体软件过程应运而生

第六章 软件评审

6.1 为什么需要软件评审

• ​ 软件评审是确保软件开发过程和产品质量的一种重要方法。通过评审，可以发现并纠正潜在的问题、提高软件质量、降低风险和成本。同时，评审可以促进团队协作和沟通，帮助团队成员共同理解需求和标准，提高开发效率和客户满意度。
• 提高项目的生产率。这是由于早期发现了错误，因而 减少了返工时间，还可能减少测试时间
• 通过评审，标志着软件开发的一个阶段的完成。
• 生产出更容易维护的软件。主要原因是：对于被评审 的软件，评审者必须是非常熟悉的；同时，在评审过 程中，一定会产生并利用很多证明文档，于是评审就 迫使开发者产生出许多有用的文档，

6.2 软件评审的角色和职能

• 软件评审通常由专门的评审小组或者专业人士进行，他们的主要职能是识别和纠正软件产品和过程中存在的问题。评审人员应该具备相关的技术知识和经验，并且独立于软件产品的开发和维护人员。
• 评审组（Moderator）
• 宣读员（Reader）
• 记录员（Recorder）
• 作者（Author）
• 评审员（Reviewer、Inspector）
• 熟悉评审内容，为评审做好准备。
• 在评审会议上应该关注问题而不是针对个人。
• 主要的问题和次要的问题可以被分别讨论。
• 在会议前或者会议后可以就存在的问题提 出建设性的意见和建议。
• 明确自己的角色和责任。
• 做好接受错误的准备

6.3 评审的内容

• ​ 评审通常包括管理评审、技术评审、文档评审和过程评审四个方面。

6.3.1 管理评审

• 管理评审主要是对软件项目计划、进度、财务等方面的评审，以保证项目能够按时完成，达到预期的质量和效果。
• 输入
  • 近期内、外审的评审结果；
  • 顾客信息反馈；
  • 相关方关注的问题；
  • 工作业绩与存在的问题；
  • 纠正与预防措施实施情况；
  • 上次管理评审有关决定和措施的执行情况；
  • 可能影响管理体系变更的情况 （如：法律、法规的变化，组织机构或产品、活动的 变化、外部环境的变化等）；
  • 管理方针、目标和指标的适宜性及其实现情况
• 输出
  • 管理评审的目的、时间、参加人员及评审内容；
  • 管理体系及过程的适用性、充分性、有效性的 综合评价和需要的改进；
  • 管理方针、目标、指标适宜性的评价及需要的 更改；
  • 资源需求的决定和措施；
  • 管理评审所确定的改进措施、责任部门和完成 日期

6.3.2 技术评审

• 技术评审主要是对软件产品设计、代码、测试和实施等技术方面的评审，以保证软件产品符合标准和规范，并且具有良好的可维护性和可扩展性。
• 技术评审的主要目的：是发现软件在功能、逻辑、实现上的错误，确保软件符合需求规格，验证软件符合预先定义的开发规范和标准，保证软件在统一的模式下进行开发，并便于项目管理。
• 技术评审的输入：包括评审的目的、评审内容，以及评审检查单和其他必需文档。评审的内容通常包括需求文档、源代码、测试用例等。
• 技术评审的输出：是技术评审报告，其中包括会议的基本信息、存在的问题和建议措施、评审结论和意见、问题跟踪表以及技术评审问答记录（作为附录出现在报告中）。通过技术评审报告，开发团队可以更好地了解软件存在的问题和改进方向，从而提高软件质量和效率。

6.3.3 文档评审

• 文档评审主要是对各种软件文档（如需求、设计、测试计划等）的评审，以保证文档的完备性、正确性、一致性和易于理解。

• 文档评审的主要目的：是确保软件开发过程中产生的文档符合标准和规范，检查文档内容是否准确、完整、一致，避免可能存在的错误和漏洞，以便及早发现并纠正问题，提高软件质量和效率。

• 在软件开发过程中，需要进行评审的文档很多，主要包括：需求评审、设计评审、代码评审和质量验证评审等。

6.3.4 过程评审

• 过程评审主要是对整个软件开发过程的评审，以保证过程中的各个阶段都能够遵循标准和规范，确保软件质量和效率。
• 过程评审的作用主要包括：评估主要的质量保证流程，考虑如何处理和解决评审过程中发现的不符合问题，总结和共享好的经验，以及指出需要进一步完善和改进的部分。过程评审可以帮助团队更好地了解自己的工作流程，发现并解决问题，提高整体开发效率和质量。

6.4 评审的方法和技术

6.4.1 评审的方法

• 评审的方法包括可行性研究、代码走查、代码审查、测试评审等。其中，代码审查是一种常用的评审方法，可以通过静态分析工具或者手动检查来发现潜在的问题。
• 特别检查（Ad hoc review）
• 轮查（Pass Around）
• 走查（Walkthrough）
• 团队评审（Group Review）
• 检视（Inspection

6.4.2 评审的技术

• 评审的技术包括会议技巧、运用案例和测试技巧等。会议技巧可以帮助评审人员提高沟通和决策能力，运用案例可以帮助评审人员更好地理解需求和标准，测试技巧可以帮助评审人员发现潜在的问题。
• 缺陷检查表
• 规则集
• 评审工具的使用
  • Gerrit
  • Jupiter
  • SourceMonitor
• 从不同角度理解产品
• 场景分析技术

6.5 评审会议流程

• 评审会议的流程包括准备评审会议、召开评审会议和跟踪和分析评审结果三个步骤。在准备评审会议阶段，需要确定评审对象、评审标准和评审计划。在召开评审会议阶段，需要按照预定的计划进行评审，并记录评审结果。在跟踪和分析评审结果阶段，需要对评审结果进行分类和分析，制定相应的改进计划。

6.5.1 准备评审会议

评审会议召开时间点

• 应该根据项目进展情况和评审材料的复杂程度等因素进行合理安排。通常来说，评审会议会在项目开发的中期或者后期召开，以确保评审材料已经具备一定的完整性和可用性。同时，评审会议的召开时间也应该考虑到评审成员的时间安排和工作负担，以避免影响他们正常的工作进度。在确定评审会议召开时间点时，评审组长需要提前通知评审会议成员，并协调好评审会议与项目进度之间的关系，确保评审活动进度的顺畅进行。

选择哪些评审材料

• 需要根据材料的重要性和复杂程度等因素进行筛选，选择最关键、最危险、最具挑战性的部分进行评审。评审材料通常包括可交付产品和文档、前期文档、评审员需要的表格和工具，以及测试文档等。

打包分发评审材料

• 需要确保所有需要评审的部分都被包含，并提供帮助评审员发现缺陷的工具和文档。

合理安排评审活动进程

• 评审组长需要预留足够的准备时间，制定活动进度表、安排会议房间，并提前通知评审会议成员，避免同一个人一天参加多个评审会议，并合理协调项目进度和评审会议之间的关系。

6.5.2召开评审会议

• 需要进行评审预备、评审决议等步骤。
• 评审预备包括评审开始、成员介绍、评审员进行演示或说明、评审员就不清楚或疑惑的地方与作者进行沟通以及记录员在会议过程中完成会议记录。
• 在评审决议阶段，评审会议成员对评审结果进行讨论和决策。
• 评审会议的结束需要对评审结果进行总结，并确定下一步工作计划。
• 在评审过程中，应该把握好几个原则，包括客观公正、尽职尽责、注重质量、考虑安全、实事求是等。

6.5.3跟踪和分析评审结果

• 跟踪
  • 有条件接受的缺陷跟踪
  • 不接受的缺陷跟踪
• 分析
  • 有效性
  • 效率和成本

6.6 小结

• 软件评审是保证软件质量和效率的一种重要手段，包括管理评审、技术评审、文档评审和过程评审等方面。评审的方法和技术非常多样化，评审会议流程也需要严格执行，才能有效提高软件开发的质量和效率。
• 人的认识不可能100%符合客观实际，因此在 软件生存期的每个阶段的工作中，都可能引入人 为的缺陷。
  • 在某一阶段中出现的缺陷，如果得不到及时的纠正， 就会传播到开发的后续阶段中去，并在后续阶段中引 出更多的缺陷。
• 提交给测试阶段的产品中包含的缺陷越多，经过 同样时间的测试之后，产品中仍然潜伏的缺陷也 越多。
• 必须将发现缺陷的工作提前，在开发时期的每个 阶段，都要进行严格的软件评审，尽量不让缺陷 传播到下一阶段

代码审查

代码审查主要工作

• 发现代码中的bug和考察代码的质量，提出修改建议。具体来说，需要检查是否符合Java开发规范和代码审核检查表。

代码审查流程

• 包括重要性、激活级别、检查项等多个方面。其中，重要性、激活级别和检查项是关键点。常见检查项包括命名规范、代码注释、声明、空白、缩进、语句格式、功能分布、规模、可靠性、可维护性等。

Java代码审查的常见错误

• 常见错误包括多次拷贝字符串、没有克隆返回的对象、自编代码来拷贝数组、未检查new操作结果为null、在catch块中未作清除工作、增加不必要的catch块等。

第七章 软件全面质量管理

7.1 全面质量管理概述

7.1.1 质量控制理论的发展阶段

质量控制理论经历了简单统计方法、控制图方法、抽样检验方法、品质保证方法、全面质量管理方法等几个发展阶段。

7.1.2 相关问题探讨：

全面质量管理需要解决的问题包括质量概念的界定、质量管理目标的确定、质量管理方法的选择、质量管理组织的建立等问题。

7.1.3 全面质量管理与ISO9000的对比：

ISO9000是一种国际标准，强调质量管理体系的规范化和体系文件的管理。而全面质量管理则更注重质量管理的全面性和持续改进。

7.1.4 全面质量管理与统计技术：

全面质量管理与统计技术密切相关，其中包括控制图、抽样检验、SPC技术等。

7.2 6σ项目管理：

7.2.1 6σ管理法简介：

6σ管理法是一种以数据为基础、强调持续改进的管理方法，它的目的是将过程的不良率降低到每百万次操作中不超过3.4次。

7.2.2 6σ管理法与零缺陷：

6σ管理法的目标是将缺陷率降至最低，但并不意味着要实现零缺陷。

7.2.3 6σ管理的特征：

6σ管理具有以数据为基础、注重过程改进、强调变革和领导层支持等特征。

7.2.4 6σ管理的优点：

6σ管理可以有效提高产品和服务质量、降低成本、提高顾客满意度、增强企业竞争力等优点。

7.2.5 DPMO与6σ的关系：

DPMO是每百万机会中出现的缺陷数，与6σ的目标值相对应。

7.2.6 6σ管理的人员组织结构：

6σ管理需要设立专门的6σ团队，包括6σ军团、6σ黑带、6σ绿带等不同级别的人员。

7.2.7 6σ与其它管理工具的比较：

6σ与TQM、ISO9000等管理工具有所不同，主要体现在管理目标、方法和实施方式等方面。

7.3 质量功能展开设计：

7.3.1 质量功能展开的概念：

质量功能展开是一种先确定用户需求，在此基础上设计产品或服务的方法。

7.3.2 质量功能展开分解模型：

质量功能展开采用房屋结构的分解模型，将用户需求展开为多个层次，然后进行功能设计。

7.3.3 质量屋的构成：

质量屋由需求墙、功能墙和特性墙组成，以及一个基础墙以支撑整个结构。

7.3.4 质量功能展开的特点：

质量功能展开具有全面性、系统性、顾客导向、持续改进等特点。

7.4 DFSS流程及主要设计工具：

7.4.1 DMAIC与DFSS简介：

DMAIC是6σ过程改进方法的缩写，而DFSS是Design for Six Sigma的缩写，强调在设计阶段就预防缺陷。

7.4.2 DFSS流程及主要设计工具：

DFSS包括DMADV和IDOV两种流程，主要设计工具有质量功能展开、QFD、TRIZ等。

7.4.3 DFSS与DMAIC的区别：

DFSS强调产品或服务的设计阶段已经避免缺陷，而DMAIC是面对已经存在的问题进行改进。

7.4.4 DFSS的重要性及其内涵：

DFSS在设计阶段就考虑到顾客需求，从源头上控制缺陷率，是一种有效的质量管理方法。

7.4.5 DFSS的集成框架：

DFSS要求不同部门和岗位之间进行紧密合作，形成一个集成框架，以确保目标的实现。

7.4.6 6σ实施中的注意问题：

6σ实施需要对员工进行培训、确保数据的准确性、建立有效的绩效评价体系等。

7.4.7 DFSS的发展方向

DFSS将会在自动化、智能化、数字化等方面得到进一步拓展和应用。

7.5小结：

本章介绍了全面质量管理、6σ项目管理、质量功能展开设计和DFSS流程及主要设计工具的概念、特点、优点和与其他管理工具的比较。这些方法和工具可以帮助组织提高质量水平、提高用户满意度、实现业务目标。

• 全面质量管理是指在全面社会的推动下，企业中所有部门， 所有组织，所有人员都以产品质量为核心，把专业技术， 管理技术，数理统计技术集合在一起，建立起一套科学严 密高效的质量保证体系，控制生产过程中影响质量的因素， 以优质的工作最经济的办法提供满足用户需要的产品的全 部活动。
• 在此基础上，介绍了6σ管理和零缺陷，并介绍了6σ设计 流程和主要设计工具。6σ管理法是一种统计评估法，核 心是追求零缺陷生产，防范产品责任风险，降低成本，提 高生产率和市场占有率，提高顾客满意度和忠诚度。
• 6σ管理既着眼于产品、服务质量，又关注过程的改进。 p
• 同时，将6σ管理和BRP以及全面质量管理进行了比较。 随后，介绍了DMAIC管理、DFSS管理、QFD的概念、 分解模型、质量屋等。

第九章 软件测试

9.1软件测试的目的和原则：

9.1.1 软件测试的目的

软件测试是指在执行程序之前或者在发布程序之前，对程序进行系统性的检查和分析，以发现并纠正程序中的错误、缺陷和问题。软件测试的目的主要包括：发现和纠正程序中的错误，提高软件的质量和可靠性，减少开发成本和维护成本，提高用户满意度，保障安全性和稳定性。

9.1.2 软件测试的原则

软件测试的原则包括以下几点：

• 测试应该从需求开始，全面覆盖所有功能和场景；
• 测试应该始终在产品生命周期内进行，而不仅仅是在最后一个阶段；
• 测试应该尽早进行，在开发过程的早期阶段就应该进行单元测试；
• 测试应该完全自动化，以提高效率和减少人工错误；
• 测试应该重视安全性和稳定性，以保护用户隐私和数据；
• 测试应该是一项持续改进的过程，通过评估测试结果和反馈信息来改进测试策略。

9.2 软件测试种类：

软件测试种类可以根据不同的分类标准进行划分，主要包括以下几种：

• 按照测试目的：功能测试、性能测试、安全测试、兼容性测试等；
• 按照测试方法：黑盒测试、白盒测试、灰盒测试等；
• 按照测试阶段：单元测试、集成测试、系统测试、验收测试、回归测试等；
• 按照测试方式：手动测试、自动化测试等。

9.3 软件测试过程概述：

9.3.1 单元测试

单元测试是指对单个程序模块或函数进行测试，以保证其功能的正确性和可靠性。它通常由开发人员在编写代码时执行，采用白盒测试的方法，在源代码的基础上进行测试。

9.3.2 集成测试

集成测试是指将多个单元组合起来进行测试，以验证各个单元之间的接口和交互是否正常，是否符合设计要求和规范。

9.3.3 系统测试

系统测试是指对整个软件系统进行测试，以确保系统的功能和性能满足用户需求，同时也要测试系统的安全性、易用性、可维护性等方面。

9.3.4 验收测试

验收测试是运行于预定环境下的软件系统的测试，以确定软件系统是否符合用户需求并且是否可以可靠的运行。

9.3.5 回归测试

回归测试是指针对软件系统某个功能或模块进行修改时，需要重新执行相关测试用例来验证是否对原有的系统功能产生了影响。

9.4软件测试与软件开发的关系：

9.4.1 软件测试贯穿于整个软件开发生命周期

软件测试与软件开发的关系密切，它贯穿于整个软件开发生命周期。在软件开发的不同阶段都需要进行相应的测试，以确保软件交付后符合用户需求并且具有较高的质量和可靠性。

9.4.2 生命周期测试与V模型

生命周期测试是指在整个软件开发生命周期中进行的测试，主要包括单元测试、集成测试、系统测试和验收测试等。V模型是一种将软件测试过程与软件开发过程相结合的方法，把软件开发过程划分为开发阶段和测试阶段，并将各个测试阶段与对应的开发阶段相匹配。

9.4 .3软件测试的现状：

随着计算机技术的飞速发展，软件测试领域也不断创新和进步，同时也面临着诸多挑战。如何克服测试成本和效率的问题，如何提高测试覆盖率和质量水平等都是当前测试领域需要解决的难题。

9.5 测试工具选择：

9.5.1 白盒测试工具

白盒测试工具是一种基于源代码的测试工具，主要用于单元测试和集成测试，在测试过程中可以帮助开发人员快速定位和修复缺陷。常见的白盒测试工具有Junit、NUnit、PHPUnit等。

9.5.2 黑盒测试工具

黑盒测试工具是一种面向功能的测试工具，主要用于系统测试和验收测试，在测试过程中可以验证软件系统是否满足用户需求。常见的黑盒测试工具有Selenium、Appium、JMeter等。

9.5.3 测试设计和开发工具

测试设计和开发工具主要用于编写测试脚本和测试用例，以及自动化测试的实现。常见的测试设计和开发工具有TestLink、TestRail、Xray等。

9.5.4 测试执行和评估工具

测试执行和评估工具主要用于执行测试用例和评估测试结果，其中包括测试管理工具、测试报告工具等。常见的测试执行和评估工具有TestNG、JUnitReport、ExtentReports等。

9.5.5 测试管理工具

测试管理工具主要用于测试计划、测试进度、测试资源等方面的管理。常见的测试管理工具有Jira、TestLink、TestRail等。

9.5.6 功能和成本

在选择测试工具时，需要考虑工具的功能和成本。不同的工具适合于不同类型的测试和测试需求，因此需要结合实际需求和预算来进行选择。

9.6小结：

本章主要介绍了软件测试的相关概念、分类、原则、过程以及与软件开发的关系，同时也涉及到了测试工具的选择和测试现状等内容。在软件开发过程中，软件测试是保证软件质量和可靠性的重要手段，需要结合实际情况和需求进行有效的测试规划和实施。

随着人们对软件质量的重视程度越来越高， 软件测试在软件开发中的地位越来越重要。

软件测试是目前用来检验软件能否完成预 期的功能的惟一有效的方法

第十章 黑盒测试

10.1 等价类划分：

10.1.1 划分等价类

等价类是指所有数据中的一组，它们具有相同的测试结果或相同的响应。等价类划分是将输入数据分为多个等价类的过程。

10.1.2 划分等价类的方法

划分等价类方法主要包括以下几种：

• 特殊值法：选取特殊值作为等价类的代表值；
• 范围法：按照输入值的范围进行划分；
• 组合法：将两个或多个输入值进行组合，形成等价类。

10.1.3 设计测试用例

设计测试用例时，应该覆盖每个等价类，并且尽可能选择少量的测试用例来覆盖整个系统。同时还需要考虑到异常情况和错误处理。

10.2 边界值分析法

10.2.1 边界条件

边界条件是指输入数据的最大值和最小值。

10.2.2 次边界条件

次边界条件是指介于最大值和最小值之间的数值。

10.2.3 其他一些边界条件

其他一些边界条件包括：无效数据、空字符串、非法字符等。

10.2.4 边界值的选择方法

在选择边界值时，应该选择基本的边界值和等价值，同时需要考虑到特殊情况和异常情况。

10.3 盒测

盒测是一种结合边界值和等价类划分的测试方法，它能够有效地发现程序中的缺陷和问题。

10.4 因果图法

10.4.1 因果图设计方法

因果图是一种图形化表示方法，它将输入和输出之间的关系用箭头表示。因果图的设计方法包括以下几个步骤：

• 明确需要测试的功能；
• 确定所有的输入和输出；
• 建立输入和输出之间的逻辑关系；
• 绘制因果图。

10.4.2 因果图测试用例

在根据因果图生成测试用例时，应该覆盖所有的输入条件，并且尽可能选择少量的测试用例来覆盖整个系统。测试用例应该考虑到所有的输入组合以及异常情况和错误处理。

10.5 功能图法

10.5.1 功能图设计方法

功能图是一种图形化表示方法，它将一个系统或者一个模块的所有功能用框图表示出来，其中每个框代表一个功能，每个箭头表示数据流和控制流。功能图的设计方法包括以下几个步骤：

• 明确需要测试的功能；
• 确定所有的输入和输出；
• 绘制功能图。

10.5.2 功能图法生成测试用例

在根据功能图生成测试用例时，应该覆盖所有的输入和输出条件，并且尽可能选择少量的测试用例来覆盖整个系统。测试用例应该考虑到所有的输入组合以及异常情况和错误处理。

10.6 比较与选择

不同的测试方法适用于不同类型的软件系统和测试需求，因此需要结合实际情况和预算来进行选择。在测试过程中，应该综合运用多种测试方法，以确保测试覆盖率和测试质量。

10.7 黑盒测试工具介绍

10.7.1 WinRunner介绍

WinRunner是一款基于GUI的自动化测试工具，主要用于测试桌面应用程序和Web应用程序。它支持多种脚本语言，包括VBScript和JavaScript等。

10.7.2 LoadRunner的使用

LoadRunner是一款针对Web应用程序的负载测试工具，它能够模拟真实用户在访问Web应用程序时所产生的负载，以验证系统的性能和可扩展性。

10.7.3 QuickTest Pro的使用

QuickTest Pro是一款基于GUI的自动化测试工具，主要用于测试桌面应用程序和Web应用程序。它支持多种脚本语言，包括VBScript和JavaScript等。

10.8 小结

本章主要介绍了等价类划分、边界值分析法、因果图法、功能图法以及黑盒测试工具的相关概念、原理和应用。在软件测试过程中，需要根据实际情况和需求选择适合的测试方法和工具，以提高测试效率和测试质量。

第十一章 白盒测试

11.1 白盒测试的概述：

白盒测试是一种基于代码内部结构的测试方法，即测试人员可以直接访问源代码，进行针对代码逻辑、程序流程等的测试。

11.2 控制流测试：

控制流测试是白盒测试的一种方法，主要包括语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖测试、路径覆盖和循环测试等。

11.2.1 语句覆盖：

语句覆盖是指至少执行一次每个语句，以保证每个语句被执行过程中没有发生错误。

11.2.2 判定覆盖：

判定覆盖是指每个判定语句至少执行一次，并且每个判定语句的结果为 true 和 false 都被覆盖。

11.2.3 条件覆盖：

条件覆盖是指每个条件语句的每个条件都至少执行一次，并且使得条件的结果为 true 和 false 都被覆盖。

11.2.4 判定-条件覆盖测试：

判定-条件覆盖测试是指每个判定和条件之间的关系都至少执行一次，以保证每个判定和条件的结果都被覆盖。

11.2.5 路径覆盖：

路径覆盖是指覆盖程序所有可能的执行路径，以保证覆盖所有可能的错误。

11.2.6 几种常用逻辑覆盖的比较：

语句覆盖 < 判定覆盖 < 条件覆盖 < 判定-条件覆盖测试 < 路径覆盖

11.2.7 循环测试：

循环测试是指对包含循环结构的代码进行测试，其中包括循环的进入条件、出口条件、循环体和循环次数等的测试。

11.3 基本路径测试：

基本路径测试是白盒测试的一种方法，通过对程序中每条可行的路径进行测试来提高软件质量。

11.3.1 程序的控制流图：

程序的控制流图是指描述程序结构的有向图，其中节点表示语句或基本块，边表示程序中的控制转移。

11.3.2 程序结构的要求：

程序结构的要求包括线性结构、分支结构、循环结构等，它们可以用控制流图来表示。

11.3.3 举例分析：

通过对程序的控制流图进行分析，可以找到并测试程序中所有可能的路径，以保证程序的正确性。

11.4 程序插装/程序变异测试：

程序插装/程序变异测试是一种通过对程序源代码进行修改来产生错误的测试方法，以检测软件程序对错误的容忍能力。

11.5 白盒测试工具：

常用的白盒测试工具包括 C++Test 和 JUnit 等，它们可以辅助测试人员对代码进行覆盖率分析、路径分析等操作。

11.6 软件缺陷分析：

软件缺陷分析是指对软件中发现的缺陷进行分析和处理的过程，其中包括缺陷的类别、级别、原因和构成等方面的分析。

11.6.1 简介：

软件缺陷是指在开发和使用软件过程中发现的错误或问题。

11.6.2 软件缺陷的类别：

软件缺陷的类别包括逻辑缺陷、接口缺陷、性能缺陷、安全缺陷等。

11.6.3 软件缺陷的级别：

软件缺陷的级别包括致命级别、严重级别、一般级别和提示级别等。

11.6.4 软件缺陷产生的原因：

软件缺陷产生的原因包括需求不明确、设计错误、编码问题、测试不充分等。

11.6.5 软件缺陷的构成：

软件缺陷的构成包括缺陷明细、缺陷跟踪和缺陷报告等。

11.7 小结：

本章介绍了白盒测试的概念、方法和技术，包括控制流测试、基本路径测试、程序插装/程序变异测试等。同时还介绍了白盒测试工具和软件缺陷分析的相关知识。

• 本章主要讲解了白盒测试的基本概念和技术，包括 白盒测试的基本概念、分类、白盒测试中的边界值 技术、语句覆盖测试、分支覆盖测试、条件覆盖测 试、分支-条件覆盖测试、条件组合覆盖测试、路 径覆盖测试。
• \也介绍了常用的白盒测试工具C++Test软件以及软件缺 陷的原因，构成，产生的危害等。  白盒测试允许观察“盒子”内部，不像黒盒测试那 样把系统理解为一个“内部不可见的盒子”，不需 要明白内部结构。
• 为了完整的测试一个软件，这两种测试都是不可或缺的。
• 一个产品在其概念分析阶段直到最后交付给用户期间往往 要经过各种静态的、动态的、白盒的和黒盒的测试

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

12.1 概述：

12.1.1 相关定义：

软件缺陷是指在软件开发过程中或软件使用过程中出现的导致软件无法正常工作或者工作不符合预期的问题。

12.1.2 软件缺陷的产生原因：

软件缺陷产生的原因主要包括需求不明确、设计错误、编码问题、测试不充分等。

12.1.3 减少缺陷的关键因素：

减少软件缺陷的关键因素包括规范化的开发流程、有效的质量保证、高效的测试策略、简洁的代码实现以及严格的代码审查等。

12.1.4 软件缺陷的特征：

软件缺陷的特征包括多样性、复杂性、隐藏性、破坏性、连锁反应等。

12.2 软件缺陷属性：

12.2.1 缺陷类型：

软件缺陷的类型包括逻辑缺陷、接口缺陷、性能缺陷和安全缺陷等。

12.2.2 缺陷严重程度：

缺陷严重程度包括致命级别、严重级别、一般级别和提示级别等。

12.2.3 同行评审错误严重程度：

同行评审错误严重程度包括严重问题、一般问题和提示问题等。

12.2.4 缺陷优先级：

缺陷优先级包括高、中、低等级别。

12.2.5 缺陷状态：

缺陷状态包括新建、打开、解决、关闭等状态。

12.2.6 缺陷起源：

缺陷起源包括需求、设计、编码、测试等环节。

12.2.7 缺陷来源：

缺陷来源包括内部因素和外部因素两种。

12.2.8 缺陷根源：

缺陷根源包括人、过程和技术三个方面。

12.3 软件缺陷的严重性和优先级：

12.3.1 缺陷的严重性和优先级的关系：

缺陷的优先级取决于缺陷的严重性，严重程度越高，优先级就越高。

12.3.2 处理缺陷的严重性和优先级的常见错误：

处理缺陷的严重性和优先级时，常见的错误包括无法合理评估缺陷的严重程度和优先级，以及没有根据实际情况及时调整缺陷的优先级等。

12.3.3 缺陷的严重性和优先级的表示和确定：

缺陷的严重性和优先级通常用数字或字母表示，其确定可以依据严重程度、影响范围、修复难度和用户需求等因素。

12.4 软件缺陷管理和CMM的关系：

12.4.1 初始级的缺陷管理：

初始级的缺陷管理主要包括制定缺陷管理计划和建立基本缺陷管理过程等。

12.4.2 可重复级的缺陷管理：

可重复级的缺陷管理主要包括缺陷分类与报告、缺陷分析和缺陷跟踪等。

12.4.3 已定义级的缺陷管理：

已定义级的缺陷管理主要包括缺陷预防和过程控制等。

12.4.4 定量管理级的缺陷管理：

定量管理级的缺陷管理主要包括缺陷度量和缺陷度量分析等。

12.4.5 持续优化级的缺陷管理：

持续优化级的缺陷管理主要包括改进管理过程和提高缺陷管理水平等。在CMM模型中，软件缺陷管理是软件质量保证的一部分，旨在最小化软件缺陷并提高软件质量

12.5 报告软件缺陷:

12.5.1 报告软件缺陷的基本原则:

报告软件缺陷的基本原则包括：及时性、准确性、清晰度和简洁性等。报告软件缺陷应该尽可能地详细描述缺陷，包括缺陷的类型、发现时间、发现位置、复现步骤、影响范围等。

12.5.2 IEEE软件缺陷报告模板:

IEEE软件缺陷报告模板包括报告标题、缺陷简述、重现步骤、期望结果、实际结果以及缺陷类型、严重程度和优先级等内容。

12.6 软件缺陷管理:

12.6.1 缺陷管理目标：

缺陷管理的目标是最小化软件缺陷，并提高软件质量。通过缺陷管理能够发现软件缺陷并及时修复，避免缺陷对软件质量和用户体验造成损害。

12.6.2 人员职责：

缺陷管理团队由项目经理、软件开发人员和测试人员组成。项目经理负责制定缺陷管理计划，软件开发人员负责修复缺陷，测试人员负责发现缺陷并报告。

12.6.3 缺陷生命周期：

缺陷生命周期包括新建、打开、解决和关闭四个状态。缺陷在发现后，经过评估和确认后，进入打开状态，确认的缺陷将被分配给相应的开发人员进行修复，修复后的缺陷进入解决状态，最终在测试人员的确认下关闭。

12.6.4 缺陷管理系统：

软件缺陷管理系统是一种用于管理软件缺陷的软件工具。它可以帮助团队更好地跟踪、记录和处理缺陷，提高团队的协作效率。目前市场上有很多成熟的缺陷管理系统，如JIRA、Bugzilla等。

12.7 软件缺陷分析:

12.7.1 缺陷分析方法：

常见的软件缺陷分析方法包括根本原因分析、因果图分析、鱼骨图分析、5W1H分析等。这些方法可以帮助团队深入了解缺陷产生的根本原因，以便于未来避免类似的缺陷。

12.7.2 缺陷分析指标：

常用的缺陷分析指标包括缺陷密度、故障密度、缺陷率、平均修复时间和平均测试周期等。这些指标可以帮助团队评估软件质量，并及时采取相应的纠正措施。

12.8 小结：

软件缺陷管理是保障软件质量的重要手段。通过有效的缺陷管理，可以最小化缺陷对软件质量和用户体验造成的影响，提高团队协作效率。同时，软件缺陷分析也可以帮助团队深入了解缺陷产生的原因，并采取有效的纠正措施。

• 随着当今软件产业的不断发展，对于软件质量的要求不断 提高软件产品的竞争力已经不完全取决于技术的先进性， 还取决于软件质量是否稳定。
• 因此，对于软件缺陷管理及其管理工具缺陷跟踪系统的研究 受到越来越多的关注，成为当今软件工程领域里重要的研究 方向。  缺陷管理贯穿于整个软件开发生命周期中，是不可缺少的 重要环节，但国内一些开发商对此缺乏足够的重视。
• 如何结合CMM等过程能力改进的方法，帮助企业建立和完善 缺陷管理机制，提高缺陷管理水平是具有很大现实意义的问 题。
• 缺陷管理及缺陷跟踪系统的研究是一个具有发展前途的，与国外的研究状况相比，国内在这方面还是一个比较新的研究 领域，有很多的东西值得去深入研究探讨

第十三章 集成测试

13.1 概述：

13.1.1 集成测试的定义：

集成测试是指将不同的模块组装在一起进行测试，以验证它们之间的交互和协作是否正常，检测系统整体功能是否符合要求的过程。集成测试通常是在单元测试之后，系统测试之前进行的。

13.1.2 集成测试与单元测试和系统测试的区别：

集成测试、单元测试和系统测试是软件测试中的三个重要阶段，它们之间的区别如下：

• 单元测试是对软件中独立的、最小的可测试单元进行测试，目的是确保每个单元的功能和业务逻辑正确。
• 集成测试是将多个单元集成在一起，测试它们的交互和协作是否正常，以验证整个系统的功能是否符合要求。
• 系统测试是对整个软件系统进行测试，检测其是否满足用户需求和规格说明书中的要求。

13.1.3 集成测试的主要任务：

集成测试的主要任务包括以下几项：

• 验证各个模块之间的接口和数据传递是否正确。
• 验证系统的功能和性能是否符合规格说明书、用户需求和设计要求。
• 检测系统是否存在漏洞和缺陷，并进行修复和优化。
• 确保系统的稳定性和可靠性，以及满足质量要求。

13.1.4 集成测试的层次与原则：

集成测试通常分为四个层次：单元集成测试、模块集成测试、子系统集成测试和系统集成测试。集成测试的原则包括以下几点：

• 逐层集成：从单元测试开始，逐步将各个层次的模块集成起来，确保每个层次的功能正确无误。
• 模块化测试：将整个系统分解成若干个独立的模块进行测试，确保每个模块的功能正确无误。
• 接口测试：重点测试各个模块之间的接口和数据传递是否正确。
• 自动化测试：采用自动化测试工具对系统进行测试，提高测试效率和质量。
• 完备性测试：确保对系统的所有功能和边界情况进行测试，尽可能发现和解决所有可能出现的问题。

13.2 集成测试策略：

13.2.1 非渐增式集成：

非渐增式集成是指在所有模块实现完成之后，将它们一次性组装在一起进行测试。这种方法的优点是一次性完成测试，可以快速定位和解决问题，缺点是难以确定问题出现的具体位置，需要大量的调试和修复工作，效率低下。

13.2.2 渐增式集成：

渐增式集成是指从单元测试开始，逐步将各个模块集成起来进行测试。这种方法的优点是可以及早发现和解决问题，缩短测试周期，缺点是需要在每个阶段进行重复测试，增加了测试的工作量。

13.2.3 其他集成测试策略：

除了非渐增式集成和渐增式集成，还有混合集成、自上而下集成、自下而上集成等其他集成测试策略。其中混合集成是将渐增式集成和非渐增式集成相结合的方法，根据项目需求灵活选择。

13.2.4 几种集成测试实施方案的比较：

不同的集成测试策略有不同的实施方案，如表格所示：

集成测试策略	实施方案
非渐增式	一次性将所有模块组装，进行整体测试
渐增式	单元测试 -> 模块集成测试 -> 子系统集成测试 -> 系统集成测试
混合集成	先进行模块间的非渐增式集成测试，再进行整体的渐增式集成测试
自上而下集成	首先集成高层次的模块，再逐步往下集成低层次的模块
自下而上集成	首先集成低层次的模块，再逐步往上集成高层次的模块

不同的实施方案适用于不同的项目需求和技术条件，需要根据具体情况选择。

13.3 集成测试用例设计：

13.3.1 为系统运行来而设计用例：

这种方法是根据系统规格说明书和用户需求等文档，确定系统的功能和性能要求，设计测试用例以验证系统是否满足这些要求。

13.3.2 为正向测试设计用例：

这种方法是基于系统的正常使用场景，设计测试用例以验证系统在正常使用情况下的功能和性能是否符合要求。

13.3.3 为逆向测试设计用例：

这种方法是考虑系统的异常情况，例如输入错误、网络故障等，设计测试用例以验证系统在异常情况下的容错性和健壮性。

13.3.4 为满足特殊需求设计用例：

针对某些特殊需求，如安全性、可靠性、扩展性等，设计相应的测试用例以验证系统是否满足这些需求。

13.3.5 为高覆盖率而设计用例：

这种方法是根据代码分析或者测试覆盖率工具的分析结果，设计测试用例以覆盖代码的各个分支和边界条件，提高测试覆盖率。

13.3.6 基于模块接口依赖关系来设计用例：

这种方法是根据模块之间的接口依赖关系，设计测试用例以验证模块之间的接口和数据传递是否正确，避免接口问题导致的系统错误。

13.4 集成测试的过程：

13.4.1 计划阶段：

制定集成测试计划，确定测试策略和实施方案，确定测试资源和工具，编写测试用例和测试脚本，制定测试进度和报告等。

13.4.2 设计实现阶段：

按照测试计划进行测试用例和测试脚本的设计和实现，配置测试环境和工具，执行单元测试和模块集成测试，确保功能正确无误。

13.4.3 执行评估阶段：

执行子系统和系统集成测试，对测试结果进行分析和评估，记录和报告测试缺陷和问题，进行问题跟踪、修复和验证，最终确认系统的质量和稳定性满足要求。

13.5 面向对象的集成测试：

13.5.1 对象交互：

面向对象的集成测试强调对象之间的交互和协作，需要测试类之间的消息传递和数据共享是否正确，以及类之间的依赖关系是否符合设计要求。

13.5.2 面向对象的集成测试的步骤：

面向对象的集成测试主要包括以下几个步骤：

• 确定待测试的类和对象
• 确定类之间的依赖关系和接口
• 设计并实现测试用例
• 执行测试并记录结果
• 分析测试结果并解决问题

13.5.3 面向对象的集成测试常用的测试技术：

面向对象的集成测试可以采用多种测试技术，如分层测试、按功能划分测试、Mock对象测试等。其中，Mock对象测试是一种常见的方法，它可以模拟测试对象的行为，以便测试者能够更加方便地进行测试。

13.6 小结：

集成测试是软件测试中的重要环节，其目的是验证系统的功能和性能是否符合要求。根据实际情况，可以选择不同的集成测试策略和实施方案，并进行测试用例设计和测试过程管理。面向对象的集成测试强调对象之间的交互和协作，需要采用相应的测试技术来保证测试的可靠性和有效性。

• 集成测试是单元测试之后、系统测试之前的一个 重要环节，从某种意义上来说，集成测试是三个 阶段中最关键的一步。
• 集成测试最好由开发人员来完成，若将任务报给 测试部去完成，反而容易导致反复测试，延误进度。
• 集成测试的策略主要围绕单个集成测试用例对按 口的覆盖和对整个集成树的遍历路径进行设计，
• 各种策略在测试用例的规模、驱动和桩模块的工作量 以及缺陷定位等人面各有千秋，应根据实际情况灵活 使用

第十四章 系统测试

14.1 概述：

14.1.1 系统测试的定义：

系统测试是在软件集成完成之后，对整个软件系统进行测试的过程。其目的是验证软件系统的功能、可靠性、安全性、性能、可用性等是否满足用户需求和设计要求。

14.1.2 系统测试的流程：

系统测试的流程包括测试计划、测试设计、测试执行、测试分析和测试报告几个阶段。其中，测试计划确定测试资源和工具、测试策略和实施方案、测试时间和进度等；测试设计编写测试用例和测试脚本，配置测试环境和工具，确定测试场景和数据；测试执行按照测试计划和测试设计进行测试，并记录测试结果和问题；测试分析对测试结果和问题进行分析，找出问题的原因和解决方法；测试报告根据测试结果和分析，撰写测试报告并提交给相关人员。

14.1.3 系统测试的目标：

系统测试的主要目标是验证软件系统是否满足用户需求和设计要求，包括功能、可靠性、安全性、性能、可用性等方面。

14.1.4 系统测试的方针：

系统测试的方针是以用户为中心，以质量为导向，注重效率和可靠性，确保测试结果有效可靠。

14.1.5 系统测试的原则：

系统测试的原则包括全面性、独立性、有效性、重要性和持续性等方面，以确保测试的质量和有效性。

14.2 系统测试主要方法：

14.2.1 性能测试：

性能测试是评估软件系统在不同负载下的性能指标，如响应时间、吞吐量、并发用户数等，用于确定系统的容量和稳定性。

14.2.2 强度测试：

强度测试是对系统进行长时间运行或者高负荷运行的测试，以验证系统的可靠性和稳定性。

14.2.3 安全性测试：

安全性测试是评估系统的安全性能，检测系统是否容易受到攻击和破坏，用于提高系统的安全性和稳定性。

14.2.4 兼容性测试：

兼容性测试是验证系统与不同硬件和软件环境的兼容性，确保系统能够正常运行在各种环境中。

14.2.5 恢复测试：

恢复测试是测试系统在发生故障后能否正确地恢复正常工作，以评估系统的恢复能力和可靠性。

14.2.6 用户图形界面测试：

用户图形界面测试是验证系统的用户界面是否符合用户需求和设计要求，以提高系统的可用性和用户体验。

14.2.7 安装测试：

安装测试是验证系统的安装过程是否顺利、正确、完整，以确保用户能够正确安装和使用系统。

14.2.8 可靠性测试：

可靠性测试是验证系统的稳定性和可靠性，用于评估系统的错误处理和恢复能力。

14.2.9 配置测试：

配置测试是验证系统在不同配置下的运行情况和性能，以确保系统能够正常运行在各种配置中。

14.2.10 可用性测试：

可用性测试是评估系统的易用性和人机交互性，以提高系统的易用性和用户满意度。

14.2.11 文档资料测试：

文档资料测试是验证系统的文档和资料是否清晰、准确、完整，以提高系统的可理解性和易用性。

14.2.12 网站测试：

网站测试是验证网站的功能、性能、可靠性、安全性等方面，以提高网站的质量和用户体验。

14.3 系统测试工具及其应用：

14.3.1 系统测试工具分类：

系统测试工具可以分为测试管理工具、自动化测试工具、性能测试工具、安全性测试工具、兼容性测试工具、界面测试工具等多种类型，用于提高测试效率和可靠性。

14.3.2 测试管理系统 TestDirector 的使用：

TestDirector 是一种常用的测试管理工具，可以帮助测试人员进行测试计划、测试设计、测试执行、测试报告等方面的管理和协作，提高测试管理的效率和质量。

14.4 小结：

系统测试是软件测试中的重要环节，其目的是验证软件系统是否满足用户需求和设计要求。系统测试方法包括多种类型，如性能测试、安全性测试、兼容性测试、界面测试等。测试工具的应用可以提高测试效率和可靠性，如测试管理工具 TestDirector 等。

• 系统测试是将已经过良好的集成测试的软件系统， 作为整个计算机系统的一部分。
• 与计算机算硬件、外部没备、支持软件、数据以及人 员等其他系统元索结合在一起，在实际使用（运行） 环境下对计算机系统进行一系列的严格测试来发现软 件中的潜在缺陷，保证系统交付给用户之后能够正常 使用。
• 一般的，系统测试是产品交付前的最后一个测试 环节，占有重要的地位。
• 系统测试的最终目的是保证开发方交付给用户的 软件产品能够满足用户的需求，因此，系统测试 的测试用例应在实际的用户处用环境下来执行

第十五章 测试管理

15.1 概述：

15.1.1 测试的过程及组织

测试是软件开发过程中不可或缺的一环，测试过程包括计划测试、设计测试、执行测试和分析测试结果。测试需要在一定的组织结构下进行，测试人员需要与开发人员紧密配合。

15.1.2 测试方法的应用

测试方法是指对于特定的软件系统，所采用的测试技术和策略。常用测试方法包括黑盒测试、白盒测试、灰盒测试等。

15.1.3 测试的人员组织

测试人员的组织包括测试经理、测试工程师、测试分析师等角色。

15.1.4 软件测试文件

软件测试文件包括测试计划、测试用例、测试报告、缺陷报告等。

15.2 建立软件测试管理体系：

15.2.1 如何建立软件测试管理体系

建立软件测试管理体系的关键在于确定测试策略、制定测试计划，并且建立测试团队和测试管理机构，同时也需要评估测试质量和效率。

15.2.2 软件测试项目组织结构设计与选择

软件测试项目组织结构的设计需要考虑到项目的规模和测试的需求，可选的测试组织结构包括集中式、分布式、混合式等。

15.2.3 测试管理者的工作原则

测试管理者需要遵守的工作原则包括：确定测试目标、制定测试计划、优化测试流程、提高测试效率和质量等。

15.3 测试文档的撰写：

15.3.1 测试计划

测试计划是指制定测试策略和计划的文档，它包括测试目标、测试资源、测试进度、测试方法、测试用例等内容。

15.3.2 测试规范

测试规范是指测试流程和操作的规范，它包括测试环境的搭建、测试数据的准备、测试用例的编写、测试执行及测试报告等方面。

15.3.3 测试案例和测试报告

测试案例是指针对软件需求编写的测试用例，测试报告是指测试执行后生成的报告，它包括测试结果、缺陷报告等信息。

15.3.4 软件缺陷报告

软件缺陷报告是指在测试过程中发现的软件缺陷的报告，包括缺陷的严重程度、缺陷描述、缺陷的环境及重现步骤等信息。

15.4 调试的技巧：

15.4.1 调试过程

调试是指在软件开发过程中解决程序错误和缺陷的过程，它包括问题定位、问题分析、问题修复等过程。

15.4.2 调试方法

常用的调试方法包括打印调试、单步执行、断点调试、内存泄漏检查等。

15.4.3 心理因素

调试的成功与否还受到一些心理因素的影响，例如认知偏差、情绪波动等。

15.5 软件测试自动化：

15.5.1 概述

软件测试自动化是指通过编写脚本、使用工具等方式自动进行测试，以提高测试效率和质量。

15.5.2 实施软件测试自动化的理由

实施软件测试自动化的理由包括提高测试效率、降低测试成本、提高测试覆盖率等。

15.5.3 软件测试自动化的引入条件

引入软件测试自动化需要具备一定的测试规范和流程，并且测试对象稳定、需求明确。

15.5.4 不同阶段自动化测试的优势

不同阶段的自动化测试可以提高测试效率、及早发现问题、降低测试成本等优势。

15.5.5 常用自动测试开发工具

常用的自动测试开发工具包括Selenium、Appium、Robot Framework等。

15.6 小结

本章介绍了软件测试管理的相关概念、原理和技术，以及调试技巧和软件测试自动化的应用。在软件测试过程中，需要根据实际情况和需求选择适合的测试方法和工具，并严格执行测试规范和流程，以提高测试效率和质量。

• 软件测试的管理，从共性上继承了软件工程学和管理学的 项目管理理念、方法、技术和工具，这其中也包括过程管 理、进度管理、资源管理、风险管理和文档管理等领域的 继承。

• 软件已经变成了世界上最重要的产品和最重要的产业，软件的影响和重要性已经走过了一段长长的路。

第十六章

1. 第16章测试“题外话”是指在软件测试中的一些琐碎但却重要的内容，如测试计划、测试报告、缺陷跟踪等。
2. 可用性测试是指评价产品在特定使用环境下，特定用户能否有效、高效、愉悦地完成既定目标的程度。要求一定量的代表性用户对产品进行典型操作，并观察记录用户和开发人员的表现和反馈。
3. 可用性测试的基本要素包括：是否考虑到用户的理解力、教育背景、环境压力；程序输出是否有意义、争议、含糊；错误提示信息是否明确；用户界面设计是否保持一致、符合约定规律；是否提供了有效的输入验证；系统选项数量是否过多；用户操作是否易于上手、容易复现等。
4. 可用性测试的基本要素续还包括：软件设计是否有助于用户准确输入；用户在众多功能间的操作流畅性；是否符合用户主观的认知角度等。
5. 可用性测试的流程包括测试用户的选择、确定测试人员规模、数据采集方法、可用性调查问卷以及结束方式等。
6. 圈复杂度是一种衡量软件复杂度的标准，指代码中线性无关路径的数量。计算公式有三种，分别是V(G)=E-N+2、V(G)=P+1以及V(G)=R。
7. 软件复杂度的其他要素包括需要高精确度的软件系统是否提供了有效的输入验证；系统是否包含过多选项或不会使用的选项；是否容易上手等。
8. 软件复杂度的其他要素续包括软件设计规范是否被满足以及用户主观认知角度等。
9. CK度量法是面向对象软件复杂度的一种度量方法，包括WMC、DIT、NOC、CBO、RFC以及LCOM6种度量。
10. 软件分析建模包括流程图、控制流图、决策表、因果图以及Petri网等。
11. 软件复杂度在单元级别的度量包括圈复杂度以及决策复杂度。
12. 软件复杂度在集成级别的度量包括集成级圈复杂度以及消息流量复杂度。
13. Petri网是一种描述并发现象的工具，在Petri网中，库所用圆来标识可能的系统局部状态，变迁用矩形标识修改系统状态的事件，而有向弧可以从库所节点指向变迁节点或从变迁节点指向库所节点。
14. Petri网的演变包括令牌着色、增加属性、时间戳、层次化以及时序逻辑。
15. SQA是软件质量保证，而ST是软件测试。SQA包括了在软件生命周期中制定和实施质量标准、流程、方法和工具以确保最终产品质量的过程。ST则是对软件产品进行检测和验证，从而发现和修复缺陷的过程。