软件测试知识点笔记

软件测试的基本概念

软件测试

目的

查找程序错误

角色

测试：第三方测试机构
调试：程序员

八个基本原则

1. 所有的软件测试都应追溯到用户需求。
2. 尽早和不断地进行软件测试。
3. 在设计测试用例时，应该包括合理的输入与不合理的输入以及相应的预期的输出结果。
4. 充分注意测试中的群集现象。
5. 程序员应避免检查自己的程序。
6. 尽量避免测试的随意性。
7. 应当对每个测试结果做全面的检查。
8. 保留测试文档，包括测试计划、用例、出错统计和最终分析报告。

使用质量4个特性

有效性、生产率、安全性和满意度。

软件质量定义

软件产品中能满足给定需要的性质和特性的总体。

软件质量特性

内部质量、外部质量和使用质量特性。

软件缺陷的定义

1. 软件未达到产品说明书中已经标明的功能；
2. 软件出现了产品说明书中指明不会出现的错误；
3. 软件未达到产品说明书中虽未指出但应当达到的目标；
4. 软件功能超出了产品说明书中指明的范围；
5. 软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。

软件缺陷的二八原则

软件缺陷的二八原则指的是：

1. 一般情况下，软件的80%的缺陷集中在20%的模块里面。
2. 在系统分析、设计、实现阶段的复审工作中能够发现和避免 80% 的软件缺陷。
3. 实践证明 80% 的软件缺陷可以借助人工测试而发现， 20% 的软件缺陷可以借助自动化测试能够得以发现。

软件缺陷的免疫性

免疫性指的是，就像一种农药使用久了，害虫会产生抗药性一样，缺陷也是有免疫性的。程序员修改完缺陷，把新版本提交给测试人员，测试人员根据相同的测试用例进行回归测试，就像是用同一种农药来杀害虫一样，其效果会大打折扣，这就要求测试人员要根据新版本的特点去修改维护测试用例。

软件缺陷群集现象

软件缺陷群集现象是指在同一模块如果出现错误或缺陷，则会有类似的或相关的缺陷更多地出现。

软件缺陷群集出现的原因主要有：

1. 程序员的主观错误。
2. 程序员不良的编程习惯。
3. 有些暴露的缺陷背后隐藏着更多的缺陷。

软件缺陷3种基本状态

1. 激活状态（Active或Open）
2. 已修正状态（Fixed或Resolves）
3. 关闭或非激活状态（Close或Inactive）

软件缺陷严重性四种级别

1. 严重级：致命的错误，造成系统崩溃、死机，或造成数据丢失、主要功能完全丧失等。当这种情况发生时，应设为最高优先级，需要立即修复错误，并停止进一步的测试行为。
2. 较严重级：严重错误，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明。
3. 一般级：不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。设修复级别为次高优先级，在时间条件允许的情况下应修复。
4. 建议级：一些小问题如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。设修复级别为最低优先级，可以修复也可以先发布产品。

测试和使用软件产品过程中进行的度量

外部度量

软件测试要尽早进行和不断进行的原因

1. 测试人员越早介入，对软件的了解越多，越晚开始，测试人员对软件了解越少，无法深入，可能会漏测；
2. 越早发现问题，越有利于解决问题，可以极大地降低开发成本，保证软件高效地开发；
3. 不断地进行测试，将测试活动贯穿于开发的整个过程，可以保证软件质量；
4. 投入的时间晚的话，可能短期内发现大量问题，不利于版本的稳定。

桌面检查

程序员对自己的代码进行一次自我检查。

代码走查

成立一个代码走查小组，以会议的方式来检查代码，一般代码走查是项目内部展开的代码检查工作。

代码检查

组成一个小组来对代码进行阅读，应用预先定义好的标准和检查技术，来检查已经编写好的程序和文档，发现错误和缺陷的过程。

软件开发阶段与测试类型

传统的软件生命周期阶段

1. 制定计划
2. 系统与软件需求定义
3. 软件设计
4. 编程与单元测试
5. 集成测试与系统测试
6. 运行与维护

黑盒（功能）测试

概念

黑盒测试是功能测试，指通过软件的外部表现来发现错误，是在程序界面处进行测试，只是检查是否按照需求规格说明书的规定正常实现。

参与角色

由编程人员完成

测试内容

黑盒测试的内容包括功能测试、界面测试、性能测试、安全性测试等

测试对象

软件系统的外部行为和功能，包括用户界面、输入输出、功能逻辑等。

测试目标

验证软件系统是否满足用户需求和规格要求，发现潜在的功能缺陷和错误。

测试用例设计方法

• 等价类划分法：将输入数据划分为等价类，选择代表性的测试用例进行测试。
• 边界值分析法：测试各个边界条件下的功能和性能表现，包括最大值、最小值、临界值等。
• 因果图法：因果图法根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。。
• 决策表法：创建决策表，将系统的规则和条件列举出来。
• 场景覆盖法：设计测试用例覆盖各种使用场景和用户操作，确保系统在实际使用中的功能和性能表现。
• 正交法

等价类划分法设计测试用例的基本步骤

1. 确定等价类
2. 建立等价类表，列出所有划分出的等价类
3. 从划分出的等价类中按以下的3个原则设计测试用例：
   1. 为每一个等价类规定一个唯一的编号；
   2. 设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效 等价类，重复这一步，直到所有的有效等价类都被覆盖为止；
   3. 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的 无效 等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

决策表法设计测试用例的基本步骤

1. 列出所有的条件桩和动作桩；
2. 确定规则的个数；
3. 填入条件项和动作项，得到初始决策表；
4. 简化决策表，合并相似规则。

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

1. 根据输入条件与输出之间的关系，画出因果图；
2. 在因果图上标明约束条件或限制条件；
3. 把因果图转换成判定表；
4. 化简判定表，将判定表的每一列作为依据，设计测试用例。

白盒（结构）测试

白盒测试

概念

白盒测试是结构测试，指通过对程序内部结构的分析、检测来寻找问题。检查是否所有的结构及逻辑都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。

测试用例设计方法

• 逻辑覆盖法：指以程序内部的逻辑结构为基础的设计测试用例的技术。
• 基本路径法：从一个程序的入口开始，执行所经历的各个语句的完整过程。
• 循环测试法：字面意思
• 程序插桩法：了解一个程序在某次运行中所有可执行语句被覆盖的情况
• Z路径法：对循环机制进行简化，从而极大地减少路径的数量，使得覆盖这些有限的路径成为可能。

逻辑覆盖法设计测试用例的步骤

1. 语句覆盖
2. 判定覆盖
3. 条件覆盖
4. 判定/条件覆盖
5. 条件组合覆盖

基本路径方法设计测试用例的步骤

1. 画出程序的控制流图；
2. 计算程序的环形复杂度，导出程序基本路径集中的独立路径条数；
3. 导出基本路径集，确定程序的独立路径；
4. 根据(3)中的独立路径，设计测试用例的输入数据和预期输出。

环路复杂度计算公式计算方法（三种）：

1. 控制流图中区域的数量对应于环形复杂度
2. V(G)=E-N+2, E 是流图中边的数量，N 是流图中节点的数量。即边-点+2
3. V(G)=P+1, P 是流图 G 中的判定节点数。即判定节点+1。

覆盖率

反映代码被测试程度的一种指标，不是一种测试技术，无法协助找出代码中的语法错误。

单元测试

概念

单元测试是模块测试，检查每个程序单元能否正确实现详细设计说明中的模块功能等。

参与角色

绝大部分情况下，单元测试由编程人员完成。

测试用例设计方法

• 模块接口
• 边界条件
• 局部数据结构
• 独立路径
• 出错处理

单元测试设计用例遵循原则

1. 对软件设计文档规定的软件单元的功能、性能和接口等要求逐项设计测试用例（功能原则）；
2. 每个软件特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖（正常/异常测试原则）；
3. 测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值（等价类原则）；
4. 语句覆盖率达到100%（语句覆盖原则）；
5. 分支覆盖率应达到100%（分支覆盖原则）。

单元测试策略

单元测试策略主要包括自顶向下的单元测试、自底向上的单元测试、孤立测试和综合测试策略。

1. 自顶向下的单元测试先测试上层模块，再测试下层模块。由于测试下层模块时它的上层模块已测试过，所以不必另外编写驱动模块。
2. 自底向上的单元测试先测试下层模块，再测试上层模块。由于测试上层模块时它的下层模块已测试过，所以不必另外编写桩模块。
3. 孤立的单元测试不需要考虑每个模块与其他模块之间的关系，逐一完成所有单元模块的测试。由于各模块之间不存在依赖性，单元测试可以并行进行，但因为需要为每个模块单独设计驱动模块和桩模块，增加了额外的测试成本。
4. 上述3种单元测试策略各有利弊，一种方法的优点恰好对应于另一种方法的缺点，实际测试时可根据软件特点及进度安排将几种测试方法混合使用。

基于调用图的集成策略

单元调用图是一种有向图，节点表示程序单元，边表示程序调用。基于调用图的集成方式有两种，即成对集成和相邻集成。

1. 成对集成：对应调用图的每一条边建立并执行一个集成测试会话，使用实际代码来代替驱动模块和桩模块。虽然要完成多个集成测试过程，但可以大大减轻驱动模块和桩模块开发的工作量。
2. 相邻集成：这里的相邻是针对节点而言的，相邻节点就是由给定节点引出的节点集合。相邻集成就是对每个邻居建立并执行一个测试会话，使用实际代码来代替驱动模块和桩模块，从而减轻驱动模块和桩模块开发的工作量。

静态测试、动态测试

概念

静态测试方法是指无须执行被测代码，而是借助人工或专用测试工具评审软件程序或文档。

动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。

集成测试

概念

集成测试又称“组装测试”、“联合测试”。

单元测试完成之后，将程序模块进行有序的、递增的测试,集成测试遵循特定的策略和步骤，将已经通过单元测试的各个软件单元（或模块）逐步组合在一起进行测试，以期望通过测试发现各软件单元接口之间存在的问题。

主要内容

1. 集成功能测试
2. 接口测试
3. 全局数据结构测试
4. 资源测试
5. 任务优先级冲突测试
6. 性能测试
7. 稳定性测试

集成测试用例设计原则

1. 为软件设计文档规定的软件功能和性能等特性逐项设计测试用例（功能原则）；
2. 为软件单元之间、软件和硬件之间的所有接口设计测试用例（接口原则）；
3. 每个软件特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖（正常/异常测试原则）；
4. 测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值（等价类原则）；
5. 为软件单元之间的所有调用设计测试用例，达到100%的调用覆盖率（调用覆盖原则）；
6. 为运行条件（如数据结构、输入/输出通道容量、内存空间和调用频率等）在极限状态的软件特性设计测试用例（极限原则）；
7. 为软件功能、性能的强度测试设计测试用例（强度测试原则）；
8. 对于完整性级别高的软件，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并有针对安全性设计测试用例（安全性原则）。语句覆盖和分支覆盖原则属于单元测试。

集成模块划分

集成模块划分应该满足以下几点：

1. 被集成的几个模块之间的关系必须密切。
2. 可以方便地隔离集成模块的外围模块。
3. 能够简便地模拟外围模块向集成发送消息。
4. 外围模块向集成模块发送的消息能够模拟实际环境中的大多数情况。

系统测试

意义

针对整个产品系统进行的测试，目的是验证系统是否满足需求规格的定义，找出与需求规格不相符或与之矛盾的地方。

角色

由独立的测试小组完成，此时不需要用户的介入。

测试对象

不仅包括需要测试的产品系统的软件，还包括软件所依赖的硬件、外设甚至某些数据、某些支持软件及其接口等。

主要内容

1. 功能测试：即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。由于正确性是软件最重要的质量因素，所以功能测试必不可少。
2. 健壮性测试：即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。
3. 性能测试：即测试软件系统处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考（如用于宣传）。
4. 用户界面测试：重点是测试软件系统的易用性和视觉效果等。
5. 安全性测试：是指测试软件系统防止非法入侵的能力。“安全”是相对而言的，一般地，如果黑客为非法入侵花费的代价（考虑时间、费用、危险等因素）高于得到的好处，那么这样的系统可以认为是安全的。
6. 安装与反安装测试。

主要目标

1. 确保系统测试的活动是按计划进行的。
2. 验证软件产品是否与系统需求用例不相符或与之矛盾。
3. 建立完善的系统测试缺陷记录跟踪库。
4. 确保软件系统测试活动及其结果及时通知相关小组和个人。

常用的系统测试

1. 功能测试
2. 协议测试
3. 性能测试
4. 压力测试
5. 容量测试或负载测试
6. 安全性测试
7. 易用性测试
8. 安装测试
9. 备份测试
10. 健壮性测试
11. 失效恢复测试
12. GUI测试
13. 兼容性测试
14. 文档测试
15. 在线帮助测试和数据转换测试。

验收测试

以需方（客户）为主的测试

测试对象

对象是完整的、集成的计算机系统。

测试目的

在真实的用户（或称系统）工作环境下检验完整的软件系统是否满足软件开发技术合同（或软件需求规格说明）规定的要求。

测试结论

软件的需方确定是否接收该软件的主要依据。验收测试以需方为主，但是不一定需要第三方测试机构代表用户来测试。

测试目标

根据需求来验证软件是否符合用户要求。