第一章 概述

1.1 软件缺陷

定义 软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，不能满足或不能全部满足用户的需求。

表现 （1）从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、误差等各种问题。

（2）从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

1.2 软件测试

发展历程

1957——1978，以功能验证为导向；

1978——1983，以破坏性为导向；

1983——1987，以质量评估为导向；

1988——至今，以缺陷预防为导向。

定义 

a.正向思维：软件测试是一系列活动以评价一个程序或系统的特性或能力，并确定是否达到预期的效果。

b.逆向思维：软件测试是为发现错误而针对某个程序或系统的执行过程。

要点

（1）测试是为了证明程序有错而不是无错；

（2）一个好的测试用例在于它能发现至今未发现的错误；

（3）一个成功的测试是发现了至今未发现的错误的测试。

V&V

即Verification  Validation，验证和有效性确认

（1）验证是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。

（2）有效性确认是确认所开发的软件能满足用户真正需求的活动。“确认”活动主要通过各种软件评审活动来实现。

V&V将软件测试扩展到用户需求、设计等早期阶段，越早执行对项目越有利，即将“需求评审、设计评审、代码评审”归为软件测试。

这样，软件测试就包括了动态测试和静态测试。

• 动态测试 通过运行程序来发现软件系统中的问题。
• 静态测试 主要活动是评审，不需要运行程序。

1.3 软件测试的层次和类型

层次

单元测试——集成测试——系统测试——验收测试

类型

P12和P156

1.4 软件测试的过程

传统的瀑布模型

需求评审、设计评审、单元测试、集成测试、系统测试、验收测试。

快速开发模型（V模型）

改进后得到W模型，测试的活动建立在软件开发的阶段性成果之上。

敏捷测试（小步快跑）

在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试依赖于自动化测试。

第二章 需求和设计评审

2.1 软件评审的方法和技术

1.评审的定义

软件评审是对软件元素或项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。

2. 评审就是检验产品、需求或设计文档是否正确满足了规范和需求。

评审可以分为管理评审、技术评审、文档评审、流程评审。

3.评审的方法

临时评审——轮查——互为复审——走查——会议审查

从左到右逐渐正式。

（1）互为复审（同行评审）：一对一的伙伴合作关系，相互审查对方的工作成果。

（2）走查：强调对评审的对象要从头到尾检查一遍，比互审更严格。

（3）会议审查：一种系统化、严密的集体评审方法。一般包含制定计划、准备、组织会议、跟踪、分析结果，涉及多个角色。对于最可能产生风险的工作成果，要采用这种最正式的方法。

4.评审会议过程

会议准备——召开会议——评审决议——问题跟踪

注意事项：明确自己的角色和责任，熟悉评审内容，分别讨论主要问题和次要问题，提高沟通能力，提出建设性意见。

5.评审的技术

缺陷检查表，场景分析技术。

2.2 产品需求评审

1.需求定义时遇到的问题

例如，用户不懂软件，开发人员不懂业务；仅凭想象来描述系统；用户需求发生变化；重视不足。

2.如何理解需求

who?——用户是谁

what?——用户有哪些业务

why?——业务流程和逻辑是什么样的

需求包括业务需求（功能）和用户操作需求（可操作性、易用美观）

3.软件文档质量标准

规范性，易理解性，一致性，准确性，易修改性，读者。

4.用户故事

三要素：角色，活动，商业价值。

对单个用户故事的评审标准可以概括为：“INVEST”，即独立的，可协商，有价值，可估算，足够小，可测试。

2.3 设计审查

1.设计技术的评审标准

设计结果的稳定性，设计的清晰性，设计合理性，结构简单性，系统的耦合度和内聚力，结构和数据的一致性，可测试性和可追溯性，依赖性，对不完整、易变动或潜在的需求的设计分析。

2.非功能性质量特性的设计评审要求

安全性，性能，稳定性，扩展性，可靠性。

3.系统架构设计评审

采用分层评审和整体评审相结合

第三章 测试分析与设计

3.1 测试需求分析

3.2 测试设计

• 客户需求导向的设计思路
• 尽量避免含糊的、冗长的或复杂的测试用例
• 尽量将具有相类似功能的测试用例抽象并归类

3.3 测试用例

测试用例（test case）是为了特定测试目的而设计的测试条件、测试数据及与之相关的操作过程序列的一个特定的使用实例或场景。测试用例是可以被独立执行的一个过程，是一个最小的测试实体，不能再被分解。

第四章 软件测试自动化

4.1 特点

自动运行的速度快，是手工无法相比的。 测试结果准确。 高复用性。 永不疲劳。 可靠。 独特的能力。

4.2 

在系统功能逻辑测试、验收测试、适用性测试、涉及交互性测试时，多采用手工测试方法； 单元测试、集成测试、系统负载或性能、可靠性测试等比较适合采用自动化测试； 对那种不稳定、开发周期短或一次性的软件等不适合自动化测试 工具本身缺乏想象力和创造性，自动测试只能发现15%的缺陷，而手工测试可以发现85%的缺陷；

第五章 单元测试和集成测试

5.1 单元测试

1.定义 对已实现的软件最小单元进行测试，以保证构成软件的各个单元的质量。

强调被测试对象的独立性（可重复性）

2.方法：黑盒测试，也称数据驱动测试，是把程序看作一个黑盒子，不考虑程序内部结构和内部特性，而是考察系统的（数据）输入／输出、外部事件和条件限制，完成测试。

白盒测试，也称结构化测试或逻辑驱动测试，是基于内部逻辑结构（如程序语句、路径、变量状态等）来进行测试，检验程序中的各个分支条件是否得到满足、每条执行路径是否按预定要求正确的工作。 

3.驱动程序（driver）：对下层模块进行单元测试时所编制的调用被测模块的程序，用以模拟被测模块的上级模块

桩程序（stub）：也有人称为存根程序，对上层模块进行测试时，所编制的替代下层模块的程序，用以模拟被测模块工作过程中所调用的模块。

5.2 白盒测试的用例设计

• 语句覆盖，使得程序中每一条可执行语句至少被执行一次
• 分支覆盖，使得程序中每一个分支都至少被执行一次
• 条件覆盖，程序中每一个条件至少有一次被满足
• 路径覆盖，对程序模块的所有独立的基本路径至少要测试一次
• 条件组合覆盖，使得每个判定中条件的各种可能组合都至少出现一次
• 分支（判定）/条件覆盖，使得判断条件中的每个条件的所有可能取值至少执行一次，并使每个判断本身的可能判定结果也执行一次。

5.3 代码审查CR

1.目的

2.范围

3.方法

5.4 集成测试

• 非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，也常被称为大棒模式。
• 渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。

集成测试的方法：

1.自顶向下集成测试

2.自底向上集成测试

3.持续集成测试

5.5 单元测试工具

第六章 系统功能测试

6.1 功能测试

1.定义：功能测试依据产品设计规格说明书来完成对产品功能的操作，以验证系统是否满足用户的功能性需求。

功能性需求一般采用黑盒测试

功能测试有别于系统测试

2.范围：业务流程，业务规则，业务操作，业务安全性，业务可管理，业务发展。

3.LOSED模型

Logic   Operation   Structure  Environment  Data

逻辑           操作         结构           环境        数据

6.2 设计功能测试用例

1.等价类划分

设计测试用例时，要同时考虑这两种等价类： 有效等价类和无效等价类

• 有效等价类是有意义的、合理的输入数据，可以检查程序是否实现了规格说明中所规定的功能和性能
• 无效等价类和有效等价类相反，即不满足程序输入要求或者无效的输入数据构成的集合

2.边界值分析

程序的很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以更有效地发现缺陷。

设计方法：

• 确定边界情况（输入或输出等价类的边界）
• 选取正好等于、刚刚大于或刚刚小于边界值作为测试数据

3.因果图

通过因果图，可以建立输入条件和输出之间的逻辑模型，从而比较容易确定输入条件组合和输出之间的逻辑关系，有利于设计全面的测试用例

4.决策表

基于决策表的测试是最严格，最具有逻辑性的黑盒测试方法。 决策表是把条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的。 它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。 利用决策表能够设计出完整的测试用例集合。

决策表适合处理：针对不同逻辑条件的组合值，分别执行不同的操作这样的问题。

一个决策表由“条件和活动”两部分组成，列出测试活动执行所需的条件组合，每一个可能的条件组合代表着一个测试用例（测试场景）

步骤：

1. 列出所有的条件桩和动作桩；
2. 填入条件项；
3. 填入动作项，制定初始判定表；
4. 简化、合并相似规则或者相同动作。

5.功能图

6.3 易用性测试和回归测试

回归测试应该兼顾效率和有效性两方面

1. 通过代码相依分析，识别出软件中被修改的部分和影响的范围。
2. 从原有测试用例基线库中，排除不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，从而建立起新的测试用例基线库T0
3. 基于操作剖面和风险选择相结合的策略，从新的测试用例基线库中选择测试用例构造有效的套件，测试被修改的软件。
4. 如果回归测试套件不能达到所需的覆盖要求，必须补充新的测试用例使覆盖率达到规定的要求，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。
5. 用T1执行修改后的软件。

6.4 功能测试工具

第七章 系统非功能测试

7.1 影响QoS要求的系统特性

7.2 负载测试，压力测试和性能测试

1.性能调优：系统性能的改善是测试、调整、再测试、再调整等，这是一个持续改进的过程。

2.负载测试是方法论，一种技术，可以用这个方法来进行压力测试和性能测试。

3.负载测试和性能测试有较多相似之处，例如：测试方法相近，都关注系统性能，大多可以使用相同的测试工具。

4.压力测试可以被看做负载测试的一种，即高负载下的测试。

5.容量测试也使用负载测试技术来实现。

7.3 负载测试技术

1.定义：负载测试是通过模拟实际软件系统所承受的负载条件、改变系统负载大小和负载方式来发现系统中所存在的问题。

2.负载测试过程：

（1）提取关键业务；

（2）指定负载测试方案；

（3）准备测试环境，完成相应的测试脚本的开发；

（4）设计测试场景；

（5）执行测试，观察或监控输出参数；

（6）分析测试结果，如果不满意则调整测试场景，循环。

可用下图表示：

3.输入参数

①并发用户数②思考时间③加载的循环次数或持续时间④每次请求发送的数据量⑤加载方式

4.常见加载方式

①一次加载

②递增（递减）加载：典型案例就是直播流量

③高低突变加载

④随机加载

5.输出参数

• 连接时间、发送时间
• 处理时间、页面下载时间
• 第一次缓冲时间
• 每秒连接数
• 每次事务总数、每秒下载页面数
• 每秒点击次数、每秒HTTP响应数
• 每秒重试次数

6.负载测试的执行

需要针对不同维度的变化进行：

①时间维     ②负载维    ③系统维

负载测试通常采用黑盒测试方法，并且要有适当的分析和详细的记录。

【注意】在压力测试中重启：断电重启确实可以强制清理掉一些内存，但是会忽略“累积效应”，使得一些缺陷无法被发现。

7.4 性能测试

1.性能指标：时间、容量、数据吞吐量、系统资源占用率

2.性能测试类型：①性能验证测试②性能基准测试③性能规划测试④容量测试

3.常见性能问题

• 资源泄露
• 资源瓶颈
• CPU使用率达到100%，系统被锁定
• 线程死锁、线程阻塞
• 数据库连接成为性能瓶颈
• 查询速度慢或列表效率低
• 受外部系统影响越来越大

前四个是硬件方面，之后两个是数据库，最后一个是第三方影响。

7.5 压力测试

1.压力测试是在强负载情况下（如大数据量、大量并发用户连接等）稳定性进行测试，查看应用系统在峰值（瞬间使用高峰）使用情况下的行为表现，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等，确认系统是否具有良好的容错能力和可恢复能力。

2.类型：

• 稳定性压力测试，高负载下持续运行24小时以上的压力测试  
• 破坏性压力测试，通过不断加载的手段，快速造成系统的崩溃，让问题尽快地暴露出来  
• 渗入测试（soak test），通过长时间运行，使问题逐渐渗透出来，从而发现内存泄漏、垃圾收集（GC）或系统的其他问题，以检验系统的健壮性
• 峰谷测试（peak-rest test），采用高低突变加载方式进行，先加载到高水平的负载，然后急剧降低负载，稍微平息一段时间，再加载到高水平的负载，重复这样过程，容易发现问题的蛛丝马迹，最终找到问题的根源。

7.6 兼容性测试

硬件兼容性测试

数据兼容性测试

系统版本之间的兼容性

7.7 安全性测试

软件安全性测试就是检验系统权限设置有效性、防范非法入侵的能力、数据备份和恢复能力等，设法找出以下各种安全性漏洞。

• 跨站点脚本（cross-site scripting，XSS）攻击
• SQL注入式漏洞
• 缓冲区溢出
• 不安全的数据存储或传递
• 口令设置不严，包括长度、构成和更新频率；
• 暴露的端口或入口

安全测试范围：

系统级别的安全性：整个系统的安全性，涉及系统的硬件、网络等的安全性，属于管理问题。

应用程序级别的安全性 （重点）：检验操作人员只能访问其所属的、特定的功能和数据，而不能非法访问其他数据或业务功能

7.8 容错性测试

容错性测试就是在各种异常条件下对系统的功能进行测试，以检验系统是否具有防护性的措施或者某种灾难性恢复的手段或能力。容错性测试可以分为两个层次：

功能层次的容错性测试，也称负面测试（negative test）、例外测试（exception test）。

系统层次的容错性测试，主要是灾难恢复性测试或故障转移测试。

7.9 负面测试

正面测试（positive testing）是从正向思维出发的，验证系统在正常条件下或正确的操作情况下系统的功能是否符合要求

负面测试（negative testing）是从逆向思维出发，检查系统在异常条件下或用户的非法操作下系统是如何响应的，是否有异常行为或执行了不应该执行的动作

• 无效等价类的测试用例就是一种负面的测试
• 在一些异常的或恶劣的条件下进行操作
• 探索式测试

负面测试的三部曲

1. 检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束；
2. 测试系统是否处理了用户的异常操作；
3. 检查系统的错误提示是否清晰且充分。

负面测试是在系统正常工作条件下进行测试

第八章 移动应用APP测试

第九章 缺陷报告

缺陷引起的故障对软件产品的使用有不同的影响，这种特性称为缺陷的严重性

严重性：缺陷对软件产品使用的影响程度

优先级：缺陷必须被修复的紧急程度 缺陷严重等级和缺陷优先级相关性很强，缺陷越严重，越要优先得到修正。

但也有例外，如有些缺陷比较严重，但由于技术的限制或第3方产品的限制，暂时没法修正，其优先级就会低

缺陷的生命周期可以简单地表现为：   “打开（open）——> 修正（ficed或solved）——>关闭（close）”

缺陷的中间状态可以处理一些特殊情况，并在整个软件开发组织中建立缺陷生命周期模型以获得一致的理解

第十章 测试计划和管理

1.基本原则：为了保证软件产品质量而进行充分的、全面的测试，并尽早、尽可能多地发现缺陷。

1. 尽早和不断地测试
2. 重点测试
3. 测试阶段性
4. 测试独立性
5. 测试客观性
6. 计划是一个过程
7. 测试是开发的一部分
8. 发现缺陷更多的地方
9. 其风险更大 想用户所想

2.构成：能管理整个测试过程，提高管理的效率和准确性，并提供一个协同合作的环境 测试管理系统以测试用例库、缺陷库为核心 

复习要点

软件缺陷生命周期
软件测试发展历程（三个）
验证和有效性确认
软件评审包括（      ）
评审的方法，从最不正式到最正式
设计评审的标准
软件测试的层次
黑盒测试和白盒测试
驱动程序和桩程序
白盒测试的用例设计
功能测试的用例设计
功能图的组成、定义
集成测试的分类，两种方法的优缺点
自顶向下集成测试和自底向上集成测试的优缺点
系统测试的分类
易用性测试的分类
回归测试的方法（4个），实施（5步）
负载测试、性能测试、压力测试的区别和联系
负载测试的过程、输入参数、输出参数、加载方式
性能测试的指标、分类、常见性能问题
压力测试的类型
兼容性测试的类型
向后兼容和向前兼容方法的定义
Web安全性测试的分类
容错性测试的定义和两个层次
软件测试自动化的特点
了解一些自动化测试工具
测试脚本
测试用例
测试用例的元素
单个质量要求、整体质量要求
测试用例的作用
测试集的基本方法
软件测试过程
软件测试原则（9个）
能写出W模型的示意图
敏捷开发模型的过程
软件缺陷生命周期
测试管理系统以什么为核心、示意图
易用性测试怎么选择测试人员（图6-19）