文章目录

1. 软件概述1.1 软件生命周期1.2 软件开发模型1.2.1 瀑布模型1.2.2 快速原型模型1.2.3 迭代模型（增量模型或演化模型）1.2.4 螺旋模型1.2.5 敏捷模型 1.3 软件质量概述1.3.1 软件质量的概念1.3.2 软件质量模型1.3.3 影响软件质量的因素 2. 软件缺陷管理2.1 软件缺陷产生的原因2.2 软件缺陷的分类2.3 软件缺陷的处理流程2.4 常见的软件缺陷管理工具2.4.1 Bugzilla2.4.2 禅道2.4.3 Jira（Java语言开发） 3. 软件测试概述3.1 软件测试的目的3.2 软件测试的分类3.2.1 按照测试阶段分类3.2.2 按照测试技术分类（黑盒测试、白盒测试）3.3.3 按照软件质量特性分类3.3.4 按照自动化程度分类3.3.5 按照测试类型分类3.3.6 其他分类 4. 软件测试与软件开发4.1 软件测试与软件开发的关系4.2 常见的软件测试模型4.2.1 V模型4.2.2 W模型 5. 软件测试的原则6. 黑盒测试方法6.1 等价类划分法6.1.1 等价类划分法概述6.1.2 等价类的分类（有效等价类、无效等价类）6.1.3 划分等价类的原则6.1.4 设计测试用例6.1.5 实例：三角形问题的等价类划分 6.2 边界值分析法6.2.1 边界值分析法概述6.2.2 边界值选取的规则6.2.3 实例：三角形问题的边界值分析 6.3 因果图与决策表法6.3.1 因果图设计法6.3.2 因果图法设计测试用例的步骤6.3.3 决策表6.3.4 实例：三角形决策表 6.4 正交实验设计法 7. 白盒测试方法（这里只介绍逻辑覆盖法）7.0 说明：后续逻辑覆盖法的示例都针对于下面这段程序7.1 语句覆盖7.2 判定覆盖（分支覆盖）7.3 条件覆盖7.4 判定-条件覆盖（分支-条件覆盖）7.5 条件组合覆盖7.6 实例：三角形逻辑覆盖问题 8. 性能测试8.1 性能测试概述8.2 性能测试的指标8.2.1 响应时间8.2.2 吞吐量8.2.3 并发用户数8.2.4 TPS（Transaction per Second）8.2.5 点击率（Hits per Second）8.2.6 资源利用率 8.3 性能测试的种类8.3.1 负载测试8.3.2 压力测试8.3.3 峰值测试（压力测试的一种）8.3.4 并发测试8.3.5 配置测试8.3.6 可靠性测试8.3.7 容量测试

1. 软件概述

1.1 软件生命周期

软件和其他产品一样，都有一个从“出生”到“消亡”的过程，这个过程称为软件的生命周期。

通常，可将软件生命周期划分为6个阶段：

第1阶段：问题定义，该阶段由软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。第2阶段：需求分析，该阶段对软件需求进行更深入的分析，划分出软件需要实现的功能模块，并制作成文档。需求分析在软件的整个生命周期中起着非常重要的作用，它直接关系到后期软件开发的成功率。第3阶段：软件设计，该阶段在需求分析结果的基础上，对整个软件系统进行设计，如系统框架设计、数据库设计等。第4阶段：软件开发，该阶段在软件设计的基础上，选择一种编程语言进行开发。在开发过程中，必须要制订统一的、符合标准的程序编写规范，以保证程序的可读性、易维护性以及可移植性。第5阶段：软件测试，该阶段是软件开发完成后对软件进行测试，以查找软件设计与软件开发过程中存在的问题并加以修正。软件测试过程包括单元测试、集成测试、系统测试3个阶段。第6阶段：软件维护，软件完成测试并投入使用之后，面对庞大的用户群体，软件可能无法满足用户使用需求，此时就需要对软件进行维护升级以延续软件的使用寿命。软件的维护包括纠错性维护和改进性维护两个方面。软件维护是软件生命周期中持续时间最长的阶段。

1.2 软件开发模型

1.2.1 瀑布模型

瀑布模型将软件开发过程分为6个阶段：计划→需求分析→软件设计→编码→测试→运行维护。

在瀑布模型中，软件开发的各项活动严格按照这条线进行，只有当一个阶段任务完成之后才能开始下一个阶段。瀑布模型是严格按照线性方式进行的，无法适应用户需求变更，用户只能等到最后才能看到开发成果，增加了开发风险。使用瀑布模型开发软件时，如果早期犯的错误在项目完成后才发现，此时再修改原来的错误需要付出巨大的代价。瀑布模型要求每一个阶段必须有结果产出，这就势必增加了文档的数量，使软件开发的工作量变大。

对于现代软件来说，软件开发各阶段之间的关系大部分不会是线性的，很难使用瀑布模型开发软件，因此瀑布模型不再适合现代软件开发，已经被逐渐废弃。

1.2.2 快速原型模型

快速原型模型与瀑布模型正好相反，它在最初确定用户需求时快速构造出一个可以运行的软件原型，这个软件原型向用户展示待开发软件的全部或部分功能和性能，客户对该原型进行审核评价，然后给出更具体的需求意见，这样逐步丰富细化需求，最后开发人员与客户达成最终共识，确定客户的真正需求。确定客户的真正需求之后，开始真正的软件开发。

与瀑布模型相比，快速原型模型克服了需求不明确带来的风险，适用于不能预先确定需求的软件项目。但快速原型模型关键在于快速构建软件原型，准确地设计出软件原型存在一定的难度。此外，这种开发模型也不利于开发人员对产品进行扩展。

1.2.3 迭代模型（增量模型或演化模型）

迭代模型又称为增量模型或演化模型，它将一个完整的软件拆分成不同的组件，然后逐个组件地开发测试，每完成一个组件就展现给客户，让客户确认这一部件功能和性能是否达到客户需求，最终确定无误，将组件集成到软件体系结构中。整个开发工作被组织为一系列短期、简单的小项目，称为一系列迭代，每一个迭代都需要经过需求分析→软件设计→编码→测试的过程。

迭代模型可以很好地适应客户需求变更，它逐个组件地交付产品，客户可以经常看到产品，如果某个组件没有满足客户需求，则只需要更改这一个组件，降低了软件开发的成本与风险。

1.2.4 螺旋模型

螺旋模型融合了瀑布模型、快速原型模型，它最大的特点是引入了其他模型所忽略的风险分析，如果项目不能排除重大风险，就停止项目从而减小损失。这种模型比较适合开发复杂的大型软件。

1.2.5 敏捷模型

敏捷模型以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷模型中，软件项目在构建初期被拆分为多个相互联系而又独立运行的子项目，然后迭代完成各个子项目，开发过程中，各个子项目都要经过开发测试。当客户有需求变更时，敏捷模型能够迅速地对某个子项目做出修改以满足客户的需求。在这个过程中，软件一直处于可使用状态。

敏捷模型有一个重要的概念——迭代，就是不断对产品进行细微、渐进式的改进，每次改进一小部分，如果可行再逐步扩大改进范围。在敏捷模型中，软件开发不再是线性的，开发的同时也会进行测试工作，甚至可以提前写好测试代码，因此在敏捷模型中，有“开发未动，测试先行”的说法。

1.3 软件质量概述

1.3.1 软件质量的概念

软件质量是指软件产品满足基本需求及隐式需求的程度。软件产品满足基本需求是指其能满足软件开发时所规定需求的特性，这是软件产品最基本的质量要求；其次是软件产品满足隐式需求的程度。例如，产品界面更美观、用户操作更简单等。

1.3.2 软件质量模型

如何评价一款软件的质量呢？目前，最通用的做法就是按照ISO/IEC 9126:1991国际标准来评价一款软件的质量。

ISO/IEC 9126:1991是最通用的一个评价软件质量的国际标准，它不仅对软件质量进行了定义，而且还制订了软件测试的规范流程，包括测试计划的撰写、测试用例的设计等。ISO/IEC 9126:1991标准由6个特性和27个子特性组成：

功能性：在指定条件下，软件满足用户显式需求和隐式需求的能力。可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力。可使用性：在指定条件下，软件产品被使用、理解、学习的能力。效率：在指定条件下，相对于所有资源的数量，软件产品可提供适当性能的能力。可维护性：指软件产品被修改的能力。修改包括修正、优化和功能规格变更的说明。可移植性：指软件产品从一个环境迁移到另一个环境的能力。

1.3.3 影响软件质量的因素

需求模糊：请记住，严重的软件缺陷主要来源于需求！软件开发缺乏规范性文件指导：软件开发缺乏规范性文件指导会导致团队成员开发随意，这会影响软件质量。而且一旦最后软件出现质量问题，也很难定责，导致后期维护困难。软件开发人员问题：软件是由人开发出来的，因此个人的意识对产品的影响非常大。除了个人技术水平限制，开发人员问题还包括人员流动，新来的成员可能会继承上一任的产品接着开发下去，两个人的思维意识、技术水平等都会不同，导致软件开发前后不一致，进而影响软件质量。缺乏软件质量控制管理：如果没有一个量化的指标去度量一款软件的质量，过多的关注开发成本和进度，则势必会影响软件的质量。

2. 软件缺陷管理

2.1 软件缺陷产生的原因

软件缺陷就是通常所说的Bug，它是指软件中（包括程序和文档）存在的影响软件正常运行的问题。

软件缺陷产生的原因主要有以下几点：

需求不明确。软件需求不清晰或者开发人员对需求理解不明确，导致软件在设计时偏离客户的需求目标，造成软件功能或特征上的缺陷。此外，在开发过程中，客户频繁变更需求也会影响软件最终的质量。软件结构复杂。如果软件系统结构比较复杂，很难设计出一个具有很好层次结构或组件结构的框架，这就会导致软件在开发、扩充、系统维护上的困难。即使能够设计出一个很好的架构，复杂的系统在实现时也会隐藏着相互作用的难题，而导致隐藏的软件缺陷。编码问题。在软件开发过程中，程序员水平参差不齐，再加上开发过程中缺乏有效的沟通和监督，问题累积越来越多，如果不能逐一解决这些问题，会导致最终软件中存在很多缺陷。项目期限短。现在大部分软件产品开发周期都很短，开发团队要在有限的时间内完成软件产品的开发，压力非常大，因此开发人员往往是在疲劳、压力大、受到干扰的状态下开发软件，这样的状态下，开发人员对待软件问题的态度是“不严重就不解决”。使用新技术。现代社会，每种技术发展都日新月异。使用新技术进行软件开发时，如果新技术本身存在不足或开发人员对新技术掌握不精，也会影响软件产品的开发过程，导致软件存在缺陷。

2.2 软件缺陷的分类

根据不同的划分标准，可以分为不同的缺陷类型，具体如下表所示：

2.3 软件缺陷的处理流程

每个公司的软件缺陷处理流程不尽相同，但是它们遵循的最基本流程是一样的，都要经过提交、分配、确认、处理、复测、关闭等环节。如下图所示：

2.4 常见的软件缺陷管理工具

软件缺陷管理是软件开发项目中一个很重要的环节，选择一个好的软件缺陷管理工具可以有效地提高软件项目的进展。软件缺陷管理工具有很多，免费的、收费的应有尽有，下面介绍几个比较常用的软件缺陷管理工具。

2.4.1 Bugzilla

Bugzilla是Mozilla公司提供的一款免费的软件缺陷管理工具。Bugzilla能够建立一个完整的缺陷跟踪体系，包括缺陷跟踪、记录、缺陷报告、处理解决情况等。

使用Bugzilla管理软件缺陷时，测试人员可以在Bugzilla上提交缺陷报告，Bugzilla会将缺陷转给相应的开发者，开发者可以使用Bugzilla做一个工作表，标明要做的事情的优先级、时间安排和跟踪记录。

2.4.2 禅道

禅道是一款优秀的国产项目管理软件，它集产品管理、项目管理、质量管理、缺陷管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程。

禅道分为专业和开源两个版本，专业版是收费软件，开源版是免费软件，对于日常的项目管理，开源版本已经足够使用。

2.4.3 Jira（Java语言开发）

Jira是Atlassian公司开发的项目与实务跟踪工具，被广泛用于缺陷跟踪、客户实务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。Jira配置灵活、功能全面、部署简单、扩展丰富、易用性好，是目前比较流行的基于Java架构的管理工具。

Jira软件有两个认可度很高的特色：

第1个是Atlassian公司对该开源项目免费提供缺陷跟踪服务。第2个是用户在购买Jira软件时源代码也会被购置进来，方便做二次开发。

3. 软件测试概述

3.1 软件测试的目的

结合软件开发、软件测试与客户需求可以将软件测试的目的归结为以下几点：

对于软件开发来说，软件测试通过找到的问题缺陷帮助开发人员找到开发过程中存在的问题，包括软件开发的模式、工具、技术等方面存在的问题与不足，预防下次缺陷的产生。对于软件测试来说，使用最少的人力、物力、时间等找到软件中隐藏的缺陷，保证软件的质量，也为以后软件测试积累丰富的经验。对于客户需求来说，软件测试能够检验软件是否符合客户需求，对软件质量进行评估和度量，为客户评审软件提供有力的依据。

3.2 软件测试的分类

3.2.1 按照测试阶段分类

按照测试阶段可以将软件测试分为单元测试、冒烟测试、集成测试、系统测试与验收测试。这种分类方式与软件开发过程相契合，是为了检验软件开发各个阶段是否符合要求。

单元测试是软件开发的第一步测试，目的是为了验证软件单元是否符合软件需求与设计。单元测试大多是开发人员进行的自测。冒烟测试是对新构建版本软件进行的最基本测试。这种测试重点验证的是程序的主要功能，而不会对具体功能进行深入测试。集成测试是冒烟测试之后进行的测试，它是将已经测试过的软件单元组合在一起测试它们之间的接口，用于验证软件是否满足设计需求。系统测试是将经过测试的软件在实际环境中运行，并与其他系统的成分（如数据库、硬件和操作人员等）组合在一起进行的测试。验收测试主要是对软件产品说明进行验证，逐行逐字地按照说明书的描述对软件产品进行测试，确保其符合客户的各项要求。

3.2.2 按照测试技术分类（黑盒测试、白盒测试）

按照使用的测试技术可以将软件测试分为黑盒测试与白盒测试。

黑盒测试：

黑盒测试就是把软件（程序）当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎么样实现的。

白盒测试：

白盒测试又叫透明盒测试，它是指测试人员了解软件程序的逻辑结构、路径与运行过程，在测试时，按照程序的执行路径得出结果。白盒测试就是把软件（程序）当作一个透明的盒子，测试人员清楚地知道从输入到输出的每一步过程。

3.3.3 按照软件质量特性分类

按照软件质量特性可以将软件测试分为功能测试与性能测试。

功能测试：

功能测试就是测试软件的功能是否满足客户的需求，包括准确性、易用性、适合性、互操作性等。

性能测试：

性能测试就是测试软件的性能是否满足客户的需求，性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等。

3.3.4 按照自动化程度分类

按照自动化程度可以将软件测试分为手工测试与自动化测试。

手工测试：

手工测试是测试人员一条一条地执行代码完成测试工作。手工测试比较耗时费力，而且测试人员如果是在疲惫状态下，则很难保证测试的效果。

自动化测试：

自动化测试是借助脚本、自动化测试工具等完成相应的测试工作，它也需要人工的参与，但是它可以将要执行的测试代码或流程写成脚本，执行脚本完成整个测试工作。

3.3.5 按照测试类型分类

软件测试类型有多种，包括界面类测试、功能测试、性能测试、安全性测试、文档测试等，其中功能测试与性能测试前面已经介绍，下面主要介绍其他几种测试：

界面类测试：

界面类测试是验证软件界面是否符合客户需求，包括界面布局是否美观、按钮是否齐全等。

安全性测试:

安全性测试是测试软件在没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理，是否能保证软件与数据的安全。

文档测试：

文档测试以需求分析、软件设计、用户手册、安装手册为主，主要验证文档说明与实际软件之间是否存在差异。

3.3.6 其他分类

还有一些软件测试无法具体归到哪一类，但在测试行业中也会经常进行这些测试，如α测试（Alpha测试）、β测试（Beta测试）、回归测试等，具体介绍如下：

α测试（Alpha测试）：

α测试是指对软件最初版本进行测试。软件最初版本一般不对外发布，在上线之前，由开发人员和测试人员或者用户协助进行测试。测试人员记录使用过程中出现的错误与问题，整个测试过程是可控的。

β测试（Beta测试）:

β测试是指对上线之后的软件版本进行测试，此时软件已上线发布，但发布的版本中可能会存在较轻微的Bug，由用户在使用过程中发现错误与问题并进行记录，然后反馈给开发人员进行修复。

说明：根据软件开发版本周期划分软件测试

根据软件开发版本周期进行划分，可以将软件测试分为预览版本Preview测试、内部测试版本Alpha测试、公测版本Beta测试、候选版本Release测试。在这些测试完成之后产品就可以正式发布上线。

回归测试:

当测试人员发现缺陷以后，会将缺陷提交给开发人员，开发人员对程序进行修改，修改之后，测试人员会对修改后的程序重新进行测试，确认原有的缺陷已经消除并且没有引入新的缺陷，这个重新测试的过程就叫作回归测试。回归测试是软件测试工作中非常重要的一部分，软件开发的各个阶段都会进行多次回归测试。

随机测试:

随机测试是没有测试用例、检查列表、脚本或指令的测试，它主要是根据测试人员的经验对软件进行功能和性能抽查。随机测试是根据测试用例说明书执行测试用例的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

4. 软件测试与软件开发

软件开发与软件测试都是软件项目中非常重要的组成部分，软件开发是生产制造软件产品，软件测试是检验软件产品是否合格，两者密切合作才能保证软件产品的质量。

4.1 软件测试与软件开发的关系

软件测试贯穿软件项目的整个过程，但它的实施过程与软件开发并不相同。软件开发是自顶向下、逐步细化的过程，软件计划阶段定义软件作用域，软件需求分析阶段建立软件信息域、功能和性能需求等，软件设计阶段选定编程语言、设计模块接口等；软件测试与软件开发过程相反，它是自底向上、逐步集成的过程，首先进行单元测试，排除模块内部逻辑与功能上的缺陷，然后按照软件设计需求将模块集成并进行集成测试，检测子系统或系统结构上的错误，最后运行完整的系统，进行系统测试，检验其是否满足软件需求。

软件测试在项目各个阶段的作用如下所示。

项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。需求分析阶段：确定测试需求分析，即确定在项目中需要测试什么，同时制订系统测试计划。概要设计与详细设计阶段：制订单元测试计划和集成测试计划。编码阶段：开发相应的测试代码和测试脚本。测试阶段：实施测试并提交相应的测试报告。

软件测试与软件开发的关系可用下图表示：

4.2 常见的软件测试模型

4.2.1 V模型

V模型是瀑布模型的变种，在瀑布模型的后半部分添加了测试工作：

V模型应用瀑布模型的思想将复杂的测试工作分成了目标明确的小阶段来完成，具有阶段性、顺序性和依赖性，它既包含了对于源代码的底层测试，也包含了对于软件需求的高层测试。但是V模型也有一定的局限性，它只有在编码之后才能开始测试，早期的需求分析等前期工作没有涵盖其中，因此它不能发现需求分析等早期的错误，这为后期的系统测试、验收测试埋下了隐患。

4.2.2 W模型

W模型是由V模型演变而来的，它强调测试应伴随整个软件生命周期。其实W模型是一个双V模型，软件开发是一个V模型，而软件测试是与开发同步进行的另一个V模型，如图所示。

W模型的测试范围不仅包括程序，还包括需求分析、软件设计等前期工作，这样有利于尽早地全面发现问题。但是W模型也有自己的局限性，它将软件开发过程分成需求、设计、编码、集成等一系列的串行活动，无法支持迭代、自发性等需要变更调整的项目。

5. 软件测试的原则

没有缺陷的软件是不存在的，软件测试是为了找出软件测试中的缺陷，而不是为了证明软件没有缺陷。

测试应基于客户需求：所有的测试工作都应该建立在满足客户需求的基础上，从客户角度来看，最严重的错误就是软件无法满足要求。测试要尽早进行：软件的错误存在于软件生命周期的各个阶段，因此应该尽早开展测试工作，把软件测试贯穿到软件生命周期的各个阶段中，这样测试人员能够尽早地发现和预防错误，降低错误修复的成本。尽早地开展测试工作有利于帮助测试人员了解软件产品的需求和设计，从而预测测试的难度和风险，制订出完善的计划和方案，提高测试的效率。穷尽测试是不可能的：由于时间和资源的限制，进行完全（各种输入和输出的全部组合）的测试是不可能的，测试人员可以根据测试的风险和优先级等确定测试的关注点，从而控制测试的工作量，在测试成本、风险和收益之间求得平衡。遵循GoodEnough原则：GoodEnough原则是指测试的投入与产出要适当权衡，形成充分的质量评估过程，这个过程建立在测试花费的代价之上。测试不充分无法保证软件产品的质量，但测试投入过多会造成资源的浪费。测试缺陷要符合“二八”定理：缺陷的“二八”定理也称为Pareto原则、缺陷集群效应，一般情况下，软件80%的缺陷会集中在20%的模块中，缺陷并不是平均分布的。因此在测试时，要抓住主要矛盾，如果发现某些模块比其他模块具有更多的缺陷，则要投入更多的人力、精力重点测试这些模块以提高测试效率。避免缺陷免疫：我们都知道虫子的抗药性原理，即一种药物使用久了，虫子就会产生抗药性。而在软件测试中，缺陷也是会产生免疫性的。同样的测试用例被反复使用，发现缺陷的能力就会越来越差；测试人员对软件越熟悉越会忽略一些看起来比较小的问题，发现缺陷的能力也越差，这种现象被称为软件测试的“杀虫剂”现象。它主要是由于测试人员没有及时更新测试用例或者是对测试用例和测试对象过于熟悉，形成了思维定式。

6. 黑盒测试方法

黑盒测试就是把软件（程序）当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎么样实现的。

黑盒测试是软件测试中经常使用的一种测试手段，常用的黑盒测试方法包括等价类划分法、边界值分析法、因果图与决策表法、正交实验设计法等。

6.1 等价类划分法

等价类划分法是一种常用的黑盒测试方法，它主张从大量的数据中选择一部分数据用于测试，即尽可能使用最少的测试用例覆盖最多的数据，以发现更多的软件缺陷。

6.1.1 等价类划分法概述

一个程序可以有多个输入，等价类划分就是将这些输入数据按照输入需求进行分类，将它们划分为若干个子集，这些子集即为等价类，在每个等价类中选择有代表性的数据设计测试用例。这种方法类似于学生站队，男生站左边，女生站右边，老师站中间，这样就把师生群体划分成了3个等价类。

使用等价类划分法测试程序需要经过划分等价类和设计测试用例2个步骤

6.1.2 等价类的分类（有效等价类、无效等价类）

等价类可分为有效等价类与无效等价类，其含义如下所示。

有效等价类：有效等价类就是有效值的集合，它们是符合程序要求、合理且有意义的输入数据。无效等价类：无效等价类就是无效值的集合，它们是不符合程序要求、不合理或无意义的输入数据。

6.1.3 划分等价类的原则

一般在划分等价类时需要遵守以下原则:

如果程序要求输入值是一个有限区间的值，则可以将输入数据划分为1个有效等价类和2个无效等价类，有效等价类为指定的取值区间，两个无效等价类分别为有限区间两边的值。例如，某程序要求输入值x的范围为[1,100]，则有效等价类为1≤x≤100，无效等价类为x<1和x>100。如果程序要求输入的值是一个“必须成立”的情况，则可以将输入数据划分为1个有效等价类和1个无效等价类。例如，某程序要求密码正确，则正确的密码为有效等价类，错误的密码为无效等价类。如果程序要求输入数据是一组可能的值，或者要求输入值必须符合某个条件，则可以将输入数据划分为1个有效等价类和1个无效等价类。例如，某程序要求输入数据必须是以数字开头的字符串，则以数字开头的字符串是有效等价类，不是以数字开头的字符串是无效等价类。如果在某一个等价类中，每个输入数据在程序中的处理方式都不相同，则应将该等价类划分成更小的等价类，并建立等价表。

6.1.4 设计测试用例

确立了等价类之后，需要建立等价类表列出所有划分出的等价类，用以设计测试用例。基于等价类划分法的测试用例设计步骤如下所示。

确定测试对象，保证非测试对象的正确性。为每个等价类规定一个唯一编号。设计有效等价类的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，直到测试用例覆盖了所有的有效等价类。设计无效等价类的测试用例，使其覆盖所有的无效等价类。

6.1.5 实例：三角形问题的等价类划分

三角形问题是测试中广泛使用的一个经典案例，它要求输入3个正数a、b、c作为三角形的3条边，判断这3个数构成的是一般三角形、等边三角形、等腰三角形，还是无法构成三角形。如果使用等价类划分法设计三角形程序的测试用例，首先需要将所有输入数据划分为不同的等价类。

对该案例进行分析，程序要求输入3个数，并且是正数，在输入3个正数的基础上判断这3个数能否构成三角形，如果构成三角形再判断它构成的三角形是一般三角形、等腰三角形还是等边三角形，如此可以按照下列步骤将输入情况划分为不同的等价类。

（1）判断是否输入了3个数，可以将输入情况划分成1个有效等价类，4个无效等价类，具体如下：

① 有效等价类：输入3个数。② 无效等价类：输入0个数。③ 无效等价类：只输入1个数。④ 无效等价类：只输入2个数。⑤ 无效等价类：输入超过3个数。

（2）在输入3个数的基础上，判断3个数是否是正数，可以将输入情况划分为1个有效等价类，3个无效等价类，具体如下。

① 有效等价类：3个数都是正数。② 无效等价类：有1个数小于等于0。③ 无效等价类：有2个数小于等于0。④ 无效等价类：3个数都小于等于0。

（3）在输入3个正数的基础上，判断3个数是否能构成三角形，可以将输入情况划分为1个有效等价类和1个无效等价类，具体如下。

① 有效等价类：任意2个数之和大于第3个数，a+b>c、a+c>b、b+c>a。② 无效等价类：其中2个数之和小于等于第3个数。

（4）在3个数构成三角形的基础上，判断3个数是否能构成等腰三角形，可以将输入情况划分成1个有效等价类和1个无效等价类，具体如下。

① 有效等价类：其中有2个数相等，a=b||a=c||b=c。② 无效等价类：3个数均不相等。

（5）在构成等腰三角形的基础上，判断这3个数能否构成等边三角形，可以将输入情况划分为1个有效等价类和1个无效等价类，具体如下。

① 有效等价类：三个数相等，a=b=c。② 无效等价类：三个数不相等。

上述分析一共将三角形输入划分为了15个等价类，给这些等价类确定编号，并建立等价类表，如下表所示：

建立了等价类表，接下来设计测试用例覆盖等价类，设计测试用例的原则是，尽可能使用最少的测试用例覆盖最多的等价类。

首先设计覆盖有效等价类的测试用例，在设计时，既要考虑测试输入情况的全面性，又要考虑对有效等价类的覆盖情况。

效等价类测试用例的设计原则与有效等价类的测试用例相同。

6.2 边界值分析法

对于测试人员来说，测试工作做得越多越会发现，程序的一些错误往往发生在边界处理上，例如，某程序的输入数据要求取值范围为1～100，当取值在1～100内部时没有问题，然而取边界值1或100时会发生错误，这就是程序开发时对边界问题没有做好处理。边界值分析法就是对边界值进行测试的一种方法。

边界值分析法作为一种单独的软件测试方法，它只在边界取值上考虑测试的有效性，相对于等价类划分法来说，它的执行更加简单易行，但缺乏充分性，不能整体全面地测试软件，因此它只能作为等价类划分法的补充测试。

6.2.1 边界值分析法概述

对于软件来说，错误经常发生在输入或输出值的关键点，即从符合需求到不符合需求的关键点，因此边界值分析法是在等价类的边界上执行软件测试工作，它的所有测试用例都是在等价类的边界处设计。

在等价类划分法中，等价类会有多个边界，而边界值分析法就是在这些边界附近寻找某些点作为测试数据，而不是在等价类内部选择测试数据。

6.2.2 边界值选取的规则

在等价类中选择边界值时，如果输入条件规定了取值范围或值的个数，则在选取边界值时可选取5个测试值或7个测试值。

如果选取5个测试值，即在两个边界值内选取5个测试数据：最小值、略大于最小值、正常值、略小于最大值、最大值。例如，输入条件规定取值范围为1～100，则可以选取1、1.1、50、99.9、100这5个值作为测试数据。如果选取7个测试值，则在取值范围外再各选取一个测试数据，分别是略小于最小值、最小值、略大于最小值、正常值、略小于最大值、最大值、略大于最大值。对于上述输入条件，可选取0.9、1、1.1、50、99.9、100、100.1这7个值作为测试数据。

如果软件要求输入或输出是一组有序集合，如数组、链表等，则可选取第一个和最后一个元素作为测试数据。如果被测试程序中有循环，则可选取第0次、第1次与最后两次循环作为测试数据。除了上述讲解到的边界值选取之外，软件还有其他边界值的选取情况，在对软件进行测试时，要仔细分析软件规格需求，找出其可能的边界条件。

6.2.3 实例：三角形问题的边界值分析

在前面，我们学习了三角形问题的等价类划分，在等价类划分中，除了要求输入数据为3个正数之外，没有给出其他限制条件，如果要求三角形的边长取值范围为1～100，则可以使用边界值分析法对三角形边界边长进行测试。在设计测试用例时，分别选取1、2、50、99、100这5个值作为测试数据，则三角形边界值分析测试用例如下表所示：

test1中的边长1是最小临界值test2中边长2是略大于最小值的数据test3中50是1～100范围内的任意值test4中边长99是略小于最大值的数据test5中边长100是最大临界值

使用这几组测试用例基本可以检测出三角形边界存在的缺陷。

6.3 因果图与决策表法

等价类划分法与边界值分析法主要侧重于输入条件，却没有考虑这些输入之间的关系，如组合、约束等。如果程序输入之间有作用关系，等价类划分法与边界值分析法很难描述这些输入之间的作用关系，无法保证测试效果。因此，需要学习一种新的方法来描述多个输入之间的制约关系，这就是因果图法。

6.3.1 因果图设计法

因果图：

因果图需要处理输入之间的作用关系，还要考虑输出情况，因此它包含了复杂的逻辑关系，这些复杂的逻辑关系通常用图示来展现，这些图示就是因果图。

因果图使用一些简单的逻辑符号和直线将程序的因（输入）与果（输出）连接起来，一般原因用ci表示，结果用ei表示，ci与ei可以取值“0”或“1”，其中“0”表示状态不出现，“1”表示状态出现。

ci与ei之间有恒等、非（～）、或（∨）、与（∧）4种关系，如下图所示：

恒等：在恒等关系中，要求程序有1个输入和1个输出，输出与输入保持一致。若c1为1，则e1也为1；若c1为0，则e1也为0。非：非使用符号“～”表示，在这种关系中，要求程序有1个输入和1个输出，输出是输入的取反。若c1为1，则e1为0；若c1为0，则e1为1。或：或使用符号“∨”表示，或关系可以有任意个输入，只要这些输入中有一个为1，则输出为1，否则输出为0。与：与使用符号“∧”表示，与关系也可以有任意个输入，但只有这些输入全部为1，输出才能为1，否则输出为0。

在软件测试中，如果程序有多个输入，那么除了输入与输出之间的作用关系之外，这些输入之间往往也会存在某些依赖关系，某些输入条件本身不能同时出现，某一种输入可能会影响其他输入。例如，某一软件用于统计体检信息，在输入个人信息时，性别只能输入男或女，这两种输入不能同时存在，而且如果输入性别为女，那么体检项就会受到限制。这些依赖关系在软件测试中称为“约束”，约束的类别可分为4种：E（Exclusive，异）、I（at least one，或）、O（one and onlyone，唯一）、R（Requires，要求）。上面这4种都是关于输入条件的约束。除了输入条件，输出条件也会相互约束，输出条件的约束只有一种——M（Mask，强制），在因果图中，用特定的符号表明这些约束关系，如下图所示：

E（异）：a和b中最多只能有一个为1，即a和b不能同时为1。I（或）：a、b和c中至少有一个必须是1，即a、b、c不能同时为0。O（唯一）：a和b有且仅有一个为1。R（要求）：a和b必须保持一致，即a为1时，b也必须为1；a为0时，b也必须为0。M（强制）：如果a为1，则b强制为0；如果a为0，则b强制为1。

6.3.2 因果图法设计测试用例的步骤

使用因果图法设计测试用例需要经过以下几个步骤。

分析程序规格说明书描述内容，确定程序的输入与输出，即确定“原因”和“结果”。分析得出输入与输入之间、输入与输出之间的对应关系，将这些输入与输出之间的关系使用因果图表示出来。由于语法与环境的限制，有些输入与输入之间、输入与输出之间的组合情况是不可能出现的，对于这种情况，使用符号标记它们之间的限制或约束关系。将因果图转换为决策表。根据决策表设计测试用例。

因果图法考虑了输入情况的各种组合以及各种输入情况之间的相互制约关系，可以帮助测试人员按照一定的步骤高效率地开发测试用例。此外，因果图是由自然语言规格说明转化成形式语言规格说明的一种严格方法，它能够发现规格说明书中存在的不完整性和二义性，帮助开发人员完善产品的规格说明。

6.3.3 决策表

实际测试中，如果输入条件较多，再加上各种输入与输出之间相互的作用关系，画出的因果图会比较复杂，容易使人混乱。为了避免这种情况，人们往往使用决策表法代替因果图法。

决策表也称为判定表，其实质就是一种逻辑表。在程序设计发展初期，判定表就已经被当作程序开发的辅助工具，帮助开发人员整理开发模式和流程，因为它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。利用决策表可以设计出完整的测试用例集合。

为了让读者明白什么是决策表，下面通过一个“图书阅读指南”来制作一个决策表。图书阅读指南指明了图书阅读过程中可能出现的状况，以及针对各种情况给读者的建议。在图书阅读过程中可能会出现3种情况：是否疲倦、是否对内容感兴趣、对书中的内容是否感到糊涂。如果回答是肯定的，则使用“Y”标记；如果回答是否定的，则使用“N”标记。那么这3种情况可以有2^3=8种组合，针对这8种组合，阅读指南给读者提供了4条建议：回到本章开头重读、继续读下去、跳到下一章去读、停止阅读并休息，据此制作的阅读指南决策表如下表所示：

上表就是一个决策表，根据这个决策表阅读图书，对各种情况的处理一目了然，简洁高效。

决策表通常由4个部分组成，具体如下：

条件桩：列出问题的所有条件，除了某些问题对条件的先后次序有要求之外，通常决策表中所列条件的先后次序都无关紧要。条件项：条件项就是条件桩的所有可能取值。动作桩：动作桩就是问题可能采取的操作，这些操作一般没有先后次序之分。动作项：指出在条件项的各组取值情况下应采取的动作。

这4个组成部分对应到上表中：

条件桩包括是否疲倦、是否对内容感兴趣、对书中内容是否感到糊涂；条件项包括“Y”与“N”；动作桩包括回到本章开头重读、继续读下去、跳到下一章去读、停止阅读并休息；动作项是指在问题综合情况下所采取的具体动作，动作项与条件项紧密相关，它的值取决于条件项的各组取值情况。

在决策表中，任何一个条件组合的特定取值及其相应要执行的操作称为一条规则，即决策表中的每一列就是一条规则，每一列都可以设计一个测试用例，根据决策表设计测试用例就不会有所遗漏。

在实际测试中，条件桩往往很多，而且每个条件桩都有真假两个条件项，有n个条件桩的决策表就会有2^n条规则，如果每条规则都设计一个测试用例，不仅工作量大，而且有些工作量可能是重复且无意义的，例如，在上表中，第1、2条规则，第1条规则取值为：Y、Y、Y，执行结果为“停止阅读并休息”；第2条规则取值为：Y、Y、N，执行结果也为“停止阅读并休息”。对于这两条规则来说，前两个问题的取值相同，执行结果一样，因此第3个问题的取值对结果并无影响，这个问题就称为无关条件项，使用“-”表示。忽略无关条件项，可以将这两条规则进行合并，如下图所示：

由上图可知，规则1与规则2合并成了一条规则。由于合并之后的无关条件项（-）包含其他条件项取值，因此具有相同动作的规则还可进一步合并，如下图所示：

将规则进行合并，可以减少重复的规则，相应地减少测试用例的设计，这样可以大大降低软件测试的工作量。图书阅读指南决策表最初有8条规则，进行合并之后，只剩下5条规则，简化后的图书阅读指南决策表如下表所示：

6.3.4 实例：三角形决策表

在测试用例中，三角形问题是一个永盛不衰的经典案例，这里继续使用三角形讲解决策表的构建与测试用例的设计。三角形的三边是否能构成三角形？如果能构成三角形，那么是构成一般三角形、等腰三角形还是等边三角形？据此分析:

三角形问题有4个原因：是否构成三角形？a=b？b=c？c=a？有5个结果：不构成三角形、一般三角形、等腰三角形、等边三角形、不符合逻辑，具体如下表所示。

每个原因可取值“Y”和“N”，因此共有2^4=16条规则，如下表所示：

在上表中，由规则9到规则16可知，只要c1为N，则无论c2、c3、c4取何值结果都是e1，因此c2、c3、c4为无关条件项，可以将规则9到规则16合并成一条规则，而剩余其他规则无法合并简化，因此简化后的决策表如下表所示：

根据简化后的决策表可设计9个测试用例用于测试三角形，如下表所示：

6.4 正交实验设计法

正交实验设计法（Orthogonal Experimental Design）是指从大量的实验点中挑选出适量的、有代表性的点，依据Glois理论导出“正交表”，从而合理地安排实验的一种实验设计方法。

正交实验设计法包含3个关键因素，具体如下所示：

指标：判断实验结果优劣的标准。因子：因子也称为因素，是指所有影响实验指标的条件。因子的状态：因子的状态也叫因子的水平，它指的是因子变量的取值。

利用正交实验设计法设计测试用例时，可以按照如下步骤进行。

（1）提取因子，构造因子状态表

分析软件的规格需求说明得到影响软件功能的因子，确定因子可以有哪些取值，即确定因子的状态。例如，某一软件的运行受到操作系统和数据库的影响，因此影响其运行是否成功的因子有操作系统和数据库2个，而操作系统有Windows、Linux、Mac 3个取值，数据库有MySQL、MongoDB、Oracle 3个取值，因此操作系统的因子状态为3，数据库因子状态为3。据此构造该软件运行功能的因子-状态表，如下表所示：

（2）加权筛选，简化因子-状态表

在实际软件测试中，软件的因子及因子的状态会有很多，每个因子及其状态对软件的作用也大不相同，如果把这些因子及状态都划分到因子-状态表中，最后生成的测试用例会相当庞大，从而影响软件测试的效率。因此需要根据因子及状态的重要程度进行加权筛选，选出重要的因子与状态，简化因子-状态表。

加权筛选就是根据因子或状态的重要程度、出现频率等因素计算因子和状态的权值，权值越大，表明因子或状态越重要，而权值越小，表明因子或状态的重要性越小。加权筛选之后，可以去掉一部分权值较小的因子或状态，使得最后生成的测试用例集缩减到允许的范围。

（3）构建正交表，设计测试用例

正交表最大的特点是取点均匀分散、齐整可比，每一列中每种数字出现的次数都相等，即每种状态的取值次数相等。例如，在上表中，每一列都是取2个0和2个1；此外，任意两列组成的对数出现的次数相等，例如，在上表中，第1～2列共组成4对数据：（1，1）、（1、0）、（0、1）、（0，0），这4对数据各出现一次，其他任意两列也如此。在正交表中，每个因子的每个水平与另一个因子的各水平都“交互”一次，这就是正交性，它保证了实验点均匀分散在因子与水平的组合之中，因此具有很强的代表性。

7. 白盒测试方法（这里只介绍逻辑覆盖法）

白盒测试又叫透明盒测试，它是指测试人员了解软件程序的逻辑结构、路径与运行过程，在测试时，按照程序的执行路径得出结果。白盒测试就是把软件（程序）当作一个透明的盒子，测试人员清楚地知道从输入到输出的每一步过程。

逻辑覆盖法是白盒测试最常用的测试方法，它包括语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定-条件覆盖、条件组合覆盖5种。

7.0 说明：后续逻辑覆盖法的示例都针对于下面这段程序

后续逻辑覆盖法的示例都针对于下面这段程序：

它的流程图如下，其中a、b、c、d、e表示程序执行分支：

7.1 语句覆盖

语句覆盖（Statement Coverage）又称行覆盖、段覆盖、基本块覆盖，它是最常见的覆盖方式。语句覆盖的目的是测试程序中的代码是否被执行，它只测试代码中的执行语句，这里的执行语句不包括头文件、注释、空行等。语句覆盖在多分支的程序中，只能覆盖某一条路径，使得该路径中的每一个语句至少被执行一次，但不会考虑各种分支组合情况。

在语句覆盖测试用例中，使程序中每个可执行语句至少被执行一次。可以设置如下语句覆盖测试用例（来源于7.0 说明：后续逻辑覆盖法的示例都针对于下面这段程序）。

执行上述测试用例，程序运行路径为acd。可以看出程序中acd路径上的每个语句都能被执行，但是语句覆盖对多分支的逻辑无法全面反映，仅仅执行一次不能进行全面覆盖，因此，语句覆盖是弱覆盖方法。

语句覆盖无须详细考虑每个判断表达式，可以直观地从源程序中有效测试执行语句是否全部被覆盖，由于程序在设计时，语句之间存在许多内部逻辑关系，而语句覆盖不能发现其中存在的缺陷，因此语句覆盖并不能满足白盒测试的测试所有逻辑语句的基本需求。

7.2 判定覆盖（分支覆盖）

判定覆盖（Decision Coverage）又称为分支覆盖，其原则是设计足够多的测试用例，在测试过程中保证每个判定（分支）至少有一次为真值，有一次为假值。判定覆盖的作用是使真假分支均被执行，虽然判定覆盖比语句覆盖测试能力强，但仍然具有和语句覆盖一样的单一性。

可以设置如下的测试用例（来源于7.0 说明：后续逻辑覆盖法的示例都针对于下面这段程序）：

这4个测试用例覆盖了acd、abd、ace、abe 4条路径，使得每个判定语句的取值都满足了各有一次“真”与“假”。相比于语句覆盖，判定覆盖的覆盖范围更广泛。判定覆盖虽然保证了每个判定至少有一次为真值，有一次为假值，但是却没有考虑到程序内部的取值情况，例如，测试用例test4，没有将x>2作为条件进行判断，仅仅判断了z>0的条件。

判定覆盖语句一般是由多个逻辑条件组成的，如果仅仅判断测试程序执行的最终结果而忽略每个条件的取值，必然会遗漏部分测试路径，因此，判定覆盖也属于弱覆盖。

7.3 条件覆盖

条件覆盖（Condition Coverage）指的是设计足够多的测试用例，使判定语句中的每个逻辑条件取真值与取假值至少出现一次。例如，对于判定语句IF(a>1 OR c<0)中存在a>1、c<0 2个逻辑条件，设计条件覆盖测试用例时，要保证a>1、c<0的“真”“假”值至少出现一次。

设计条件覆盖测试用例，在该程序中（来源于7.0 说明：后续逻辑覆盖法的示例都针对于下面这段程序），有2个判定语句，每个判定语句有2个逻辑条件，共有4个逻辑条件，使用标识符标识各个逻辑条件取真值与取假值的情况，如下表所示：

得到执行条件判断语句的8种状态，设计测试用例时，要保证每种状态都至少出现一次。设计测试用例的原则是尽量以最少的测试用例达到最大的覆盖率，则可设计条件覆盖测试用例。

7.4 判定-条件覆盖（分支-条件覆盖）

判定-条件覆盖（Condition/Decision Coverage）要求设计足够多的测试用例，使得判定语句中所有条件的可能取值至少出现一次，同时，所有判定语句的可能结果也至少出现一次。

例如，对于判定语句IF(a>1 AND c<1)，该判定语句有a>1、c<1两个条件，则在设计测试用例时，要保证a>1、c<1两个条件取“真”“假”值至少一次，同时，判定语句IF(a>1 AND c<1)取“真”“假”值也至少出现一次。这就是判定-条件覆盖，它弥补了判定覆盖和条件覆盖的不足之处。

根据判定-条件覆盖原则，以（ 7.0 说明：后续逻辑覆盖法的示例都针对于下面这段程序）为例设计判定-条件覆盖测试用例，如下表所示：

条件1是指判定语句“IF x>0 AND y<0”，条件2是指判定语句“IFx>2 OR z>0”，条件判断的值0表示“假”，1表示“真”。表3-4中的3个测试用例满足了所有条件可能取值至少出现一次，以及所有判定语句可能结果也至少出现一次的要求。

相比于条件覆盖、判定覆盖，判定-条件覆盖弥补了两者的不足之处，但是由于判定-条件覆盖没有考虑判定语句与条件判断的组合情况，其覆盖范围并没有比条件覆盖更全面，判定-条件覆盖也没有覆盖acd路径，因此判定-条件覆盖仍旧存在遗漏测试的情况。

7.5 条件组合覆盖

条件组合（Multiple Condition Coverage）指的是设计足够多的测试用例，使判定语句中每个条件的所有可能至少出现一次，并且每个判定语句本身的判定结果也至少出现一次，它与判定-条件覆盖的差别是，条件组合覆盖不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的所有可能组合都至少出现一次。

以（7.0 说明：后续逻辑覆盖法的示例都针对于下面这段程序）为例，该程序中共有4个条件：x>0、y<0、x>2、z>0，我们依然用S1、S2、S3、S4标记这4个条件成立，用-S1、-S2、-S3、-S4标记这些条件不成立。由于这4个条件每个条件都有取“真”“假”两个值，因此所有条件结果的组合有2^4=16种，如下表所示：

上表列出了4个条件所有结果的组合情况，经过分析可以发现，第2、6、8、13这4种情况是不存在的，这几种情况要求x>0不成立，x>2成立，这2种结果相悖，因此最终图3-1的所有条件组合情况有12种。根据这12种情况设计测试用例，具体如下表所示：

这12个测试用例覆盖了4个条件结果的所有组合，与判定-条件覆盖相比，条件组合覆盖包括了所有判定-条件覆盖，因此它的覆盖范围更广。但是当程序中条件比较多时，条件组合的数量会呈指数型增长，组合情况非常多，要设计的测试用例也会增加，这样反而会使测试效率降低。

7.6 实例：三角形逻辑覆盖问题

在前面的黑盒测试中我们使用了决策表法判断三角形类型，根据三角形3条边的关系可将三角形分为4种类型：不构成三角形、一般三角形、等腰三角形、等边三角形。根据该原则实现一个判断三角形的程序，伪代码如下：

上述代码的流程图如图所示：

对上述程序进行分析，程序的执行路径可用下图表示：

图中的数字是代码行号，当执行程序输入数据时，程序根据条件判断沿着不同的路径执行。如果使用判定覆盖（分支覆盖），使程序中每个判定语句至少有一次“真”值，至少有一次“假”值，可以设计如下测试用例：

8. 性能测试

性能测试是度量软件质量的一种重要手段，它从软件的响应速度、稳定性、兼容性、可移植性等方面检测软件是否满足用户需求。

8.1 性能测试概述

性能测试就是使用性能测试工具模拟正常、峰值及异常负载状态，对系统的各项性能指标进行测试的活动。性能测试能够验证软件系统是否达到了用户期望的性能需求，同时也可以发现系统中可能存在的性能瓶颈及缺陷，从而优化系统的性能。

8.2 性能测试的指标

性能测试不同于功能测试，功能测试只要求软件的功能实现即可，而性能测试是测试软件功能的执行效率是否达到要求。

性能测试常用的指标包括响应时间、吞吐量、并发用户数、TPS等。

8.2.1 响应时间

响应时间（Response Time）是指系统对用户请求做出响应所需要的时间。这个时间是指用户从软件客户端发出请求到用户接收到返回数据的整个过程所需要的时间，包括各种中间件（如服务器、数据库等）的处理时间，如图所示。

在上图中，系统的响应时间为t1+t2+t3+t4+t5+t6。响应时间越短，表明软件的响应速度越快，性能越好。

系统的响应时间会随着访问量的增加、业务量的增长等变长，一般在性能测试时，除了测试系统的正常响应时间是否达到要求之外，还会测试在一定压力下系统响应时间的变化。

8.2.2 吞吐量

吞吐量（Throughput）是指单位时间内系统能够完成的工作量，它衡量的是软件系统服务器的处理能力。吞吐量的度量单位可以是请求数/秒、页面数/秒、访问人数/天、处理业务数/小时等。

吞吐量是软件系统衡量自身负载能力的一个很重要的指标，吞吐量越大，系统单位时间内处理的数据就越多，系统的负载能力就越强。

8.2.3 并发用户数

并发用户数是指同一时间请求和访问的用户数量。例如对于某一软件，同时有100个用户请求登录，则其并发用户数就是100。并发用户数量越大，对系统的性能影响越大，并发用户数量较大可能会导致系统响应变慢、系统不稳定等。软件系统在设计时必须要考虑并发访问的情况，测试工程师在进行性能测试时也必须进行并发访问的测试。

8.2.4 TPS（Transaction per Second）

TPS是指系统每秒钟能够处理的事务和交易的数量，它是衡量系统处理能力的重要指标。

8.2.5 点击率（Hits per Second）

点击率是指用户每秒向Web服务器提交的HTTP请求数，这个指标是Web应用特有的一个性能指标，通过点击率可以评估用户产生的负载量，并且可以判断系统是否稳定。点击率只是一个参考指标，帮助衡量Web服务器的性能。

8.2.6 资源利用率

资源利用率是指软件对系统资源的使用情况，包括CPU利用率、内存利用率、磁盘利用率等。资源利用率是分析软件性能瓶颈的重要参数。例如某一个软件，预期最大访问量为1万，但是当达到6000访问量时内存利用率就已经达到80%，限制了访问量的增加，此时就需要考虑软件是否有内存泄漏等缺陷，从而进行优化。

8.3 性能测试的种类

性能测试是一个统称，它其实包含多种类型，主要有负载测试、压力测试、并发测试、配置测试等，每种测试类型都有其侧重点，下面对这几个主要的性能测试种类分别进行介绍。

8.3.1 负载测试

负载测试是指逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统性能指标的情况下，系统所能够承受的最大负载量。

对于负载测试来说，前提是满足性能指标要求。例如一个软件系统的响应时间要求不超过2s，则在这个前提下，不断增加用户访问量，当访问量超过1万人时，系统的响应时间就会变慢，超过2s，从而可以确定系统响应时间不超过2s的前提下最大负载量是1万人。

8.3.2 压力测试

压力测试也叫强度测试，它是指逐步给系统增加压力，测试系统的性能变化，使系统某些资源达到饱和或系统崩溃的边缘，从而确定系统所能承受的最大压力。

压力测试与负载测试是有区别的，负载测试是在保持性能指标要求的前提下测试系统能够承受的最大负载，而压力测试则是使系统性能达到极限的状态。例如软件系统正常的响应时间为2s，负载测试确定访问量超过1万时响应时间变慢。压力测试则继续增加用户访问量观察系统的性能变化，当用户增加到2万时系统响应时间为3s，当用户增加到3万时响应时间为4s，当用户增加到4万时，系统崩溃无法响应。由此确定系统能承受的最大访问量为4万。

压力测试可以揭露那些只有在高负载条件下才会出现的Bug（缺陷），如同步问题、内存泄漏等。

8.3.3 峰值测试（压力测试的一种）

性能测试中还有一种压力测试叫作峰值测试，它是指瞬间（不是逐步加压）将系统压力加载到最大，测试软件系统在极限压力下的运行情况。

8.3.4 并发测试

并发测试是指通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其他性能问题。并发测试一般没有标准，只是测试并发时会不会出现意外情况，几乎所有的性能测试都会涉及一些并发测试，例如多个用户同时访问某一条件数据，多个用户同时在更新数据，那么数据库可能就会出现访问错误、写入错误等异常情况。

8.3.5 配置测试

配置测试是指调整软件系统的软硬件环境，测试各种环境对系统性能的影响，从而找到系统各项资源的最优分配原则。配置测试不改变代码，只改变软硬件配置，例如安装版本更高的数据库、配置性能更好的CPU和内存等，通过更改外部配置来提高软件的性能。

8.3.6 可靠性测试

可靠性测试是指给系统加载一定的业务压力，使其持续运行一段时间（如7×24h），测试系统在这种条件下是否能够稳定运行。由于加载有业务压力且运行时间较长，因此可靠性测试通常可以检测出系统是否有内存泄漏等问题。

8.3.7 容量测试

容量测试是指在一定的软硬件及网络环境下，测试系统所能支持的最大用户数、最大存储量等。容量测试通常与数据库、系统资源（如CPU、内存、磁盘等）有关，用于规划将来需求增长（如用户增长、业务量增加等）时，对数据库和系统资源的优化。

软件测试常见概念（软件生命周期 软件开发模型 软件质量模型 软件缺陷管理 软件测试概述 软件测试分类 软件测试与软件开发 软件测试原则 黑盒测试方法 白盒测试方法 性能测试）