测试方法的分类

静态测试

核心分类依据：根据是否执行程序分为静态测试和动态测试

静态测试方法

执行特征：不运行被测程序，通过人工检查或工具分析进行测试

测试对象：主要针对文档（包括需求文档、设计文档等）和源代码

实施方式：

基础检查：文档中的错别字、病句、标点符号错误、格式不一致等问题

深度验证：对照文档执行操作，验证文档描述的准确性和完整性

代码审查：检查源代码中的语法错误（如if语句后误加分号）和逻辑问题

类比说明：类似静态网站概念，不涉及用户交互修改，仅做内容展示

含义: 评审(review)和审查(inspection)是团队测试的通用概念，指对特定类型的检查对象进行的活动。
过程: 评审组对选择的评审对象进行审查和讨论，如需求规约说明书、系统设计、程序代码等。
目的: 在评审过程中发现评审对象的错误、缺省、不精确处，以及维护的不完善和接口的错误描述等；查找与需求、指南、标准或规定的不符之处。评审的目的不在于直接解决问题，而在于发现问题、记录问题并总结经验教训。

动态测试

动态测试方法

核心特征：必须运行程序，通过输入输出验证程序行为
包含类型：分为黑盒测试和白盒测试两大类
对比说明：类似动态网站概念，强调用户交互和内容修改能力

黑盒测试

别称：功能测试、数据驱动测试、基于规格说明书测试

核心思想：将程序视为不透明的"黑盒"，只关注输入输出关系

形象比喻：如同给鸡退毛的过程，只关心投入带毛鸡和产出无毛鸡的结果，不关心内部处理机制

测试原则

用户视角：从最终用户角度出发验证系统功能

依据文档：以软件规格说明书为主要测试依据

数据关系：重点验证输入输出数据间的正确对应关系

局限性：

无法检测程序内部结构问题

难以发现规格说明书本身的缺陷

测试数据的选择具有局限性

主要技术：大纲法、场景法、等价类划分、边界值分析、决策表、错误推测法等

应用特点：这些方法均不涉及程序内部逻辑，仅基于外部规格设计测试用例

非功能测试

    * 测试目标：验证"系统工作得怎么样"而非"做什么"* 测试类型：+ 质量特性：可用性、可靠性、稳定性、健壮性、可恢复性+ 维护特性：可维护性、易用性+ 环境适应：可移植性/兼容性测试、配置测试+ 辅助要素：文档测试、国际化/本地化测试

白盒测试

白盒测试：也称结构测试、逻辑驱动测试、基于程序本身的测试，需要完全了解程序的结构和处理过程，按照程序内部逻辑测试程序，检验程序中每条通路是否按照预定要求工作。

目的：测试程序的逻辑结构，如分支、循环等是否正确。

白盒测试与黑盒测试的对比

黑盒测试：不关注程序内部结构，只关注输入与输出是否符合预期。

白盒测试：深入程序内部结构，检查每条逻辑路径是否按预定要求工作。

黑盒测试与白盒测试的区别

黑盒测试:

关注点：功能的测试，主要从用户的角度出发进行测试。

优点：能从用户的角度出发，关注输入和输出，测试数据结果是否正确。

缺点：无法测试程序的内部逻辑和结构。

白盒测试:

关注点：程序结构的测试，即对程序内部的特定部位进行覆盖测试。

优点：能关注到程序的内部逻辑和结构。

缺点：无法检查程序的外部特性，以及未实现规格说明的程序内部欠缺部分。

灰盒测试:

结合了黑盒测试和白盒测试的方法。

在测试网站时，灰盒测试可以大量使用。例如，在前台输入数据时可以使用黑盒测试，如果容易获得后台的源代码，则也可以做一些白盒测试。

测试方法的应用

在实际工作过程中，可能会用到黑盒测试、白盒测试或两者的混合使用。

混合使用时，两者的界限有时很难完全分开，在做测试时可能黑白盒测试会混合使用。

评审的分类

文档审查

简单文档审查: 主要检查文档中的错别字、病句、标点符号错误以及排版错误，类似于校对工作。
复杂文档审查: 需要核对文档中的说法是否与用户要求一致，是否与开发的理解一致，确保文档内容的准确性和一致性。

代码审查和代码走查

代码审查的含义、过程和目的

代码审查定义: 一种同级评审，通过检查文档以检测缺陷，如不符合开发标准，不符合上层的文档等。这是最正式的评审技术，基于文档化的过程。

最正式的评审活动: 由专门培训的主持人（非作者）领导。
同行检查: 定义了不同的角色，引入了度量。
正式过程: 根据入口、出口规则的检查列表和规则定义，会议前需要准备，出具审查报告和发现问题列表。

静态分析方法

核心特征：分析软件产品（如需求或代码）而不执行这些工作产品，强调"分析"而非测试
静态特性：无需运行程序代码，因此称为"静态"分析
与动态测试区别：不同于代码审查和代码走查，更依赖理论和技术手段

静态分析的分类

主要方向：
- 符合编程原则和标准（如编码规则）
- 控制流分析（结合程序执行路径）
- 复杂度分析（评估代码复杂程度）

数据流分析

检测内容：

未声明变量使用：如直接写而未声明int a

未初始化变量使用：如声明int a后直接print a

冗余变量声明：声明变量后从未使用（如int a但后续未引用）

严格性说明：

Java/C等语言严格要求变量先声明后使用

int a是声明，int a=3是定义

变量声明后必须使用，否则视为缺陷

控制流分析

控制流图

- 基本构成：* 图形特性：带开始和结束节点的有向图（可用椭圆表示）* 节点表示：程序指令/语句（顺序语句序列可合并为一个节点）* 边表示：语句执行路径（用箭头表示控制流向）
- 绘制原则：* 分支语句（if/switch）必须单独节点* 循环语句（while）单独节点* switch中的case不单独分节点* 开始/结束节点可省略
- 应用要点：* 根据需求或算法图绘制（非程序代码）* 边需要命名（如a→b→c表示执行路径）* 典型结构示例：

复杂度分析

圈复杂度

定义：复杂度分析给出一组能描述程序代码复杂度特征的度量，主要用于评估程序的复杂程度。

白盒测试方法

单元测试用例的设计方法

主要方法: 以白盒测试方法为主，适当结合黑盒测试方法

执行顺序: 一般采用"先黑后白"的测试策略

黑盒方法: 包括大纲法、场景法、边界值法、等价类划分、决策表、错误猜测等方法

白盒测试方法

1.逻辑覆盖法

测试对象: 主要测试程序中的顺序语句、分支语句(if/switch)、循环语句(while)以及条件表达式(>,<,>=,<=,and,or等)

覆盖类型:
- 语句覆盖
- 判定覆盖
- 条件覆盖
- 判定条件覆盖
- 条件组合覆盖

2.路径覆盖法

测试原理: 对程序中的所有执行路径进行测试
示例说明: 假设程序从a点到b点，可能经过c、d、e等节点，则测试路径包括：
- a→c→b
- a→d→b
- a→e→b
- 若存在交叉路径(如c→d)，则增加a→d→c→b等更多路径

白盒测试方法的步骤

获得需求、获得/画出程序流程图/算法图

- 流程图符号:* 圆角矩形: 表示开始和结束* 平行四边形: 表示输入/输出* 菱形: 表示判断/条件* 程序输入三个变量a、b、c* 判断条件1:a>0a>0a>0且b>0b>0b>0+ 满足则执行c=c/ac=c/ac=c/a+ 然后判断条件2:a>1a>1a>1或c>1c>1c>1- 满足则执行c=c+1c=c+1c=c+1* 最终执行c=b+cc=b+cc=b+c并输出结果

绘制控制流图

例题:画控制流图

选择覆盖方法设计测试用例

语句覆盖法

1.目标

最低标准：属于C0标准（Coverage的缩写），是测试理论中最基础的要求
核心要求：程序中的每个可执行语句至少被执行一次，对应控制流程中的每个圆圈节点
执行次数：允许语句多次执行，但要求最少执行一次
死代码检测：若存在永远无法执行的语句，则表明程序存在缺陷（死代码）
示例说明：对于条件分支结构，需要设计至少两条用例分别覆盖不同路径，如：

2.度量

计算公式：覆盖率 = 被执行语句数 / 所有可能语句数 × 100%
路径覆盖：除语句外还需考虑路径覆盖率，如分支结构中不同路径的执行情况
理想目标：要求语句覆盖率必须达到100%，路径覆盖率根据测试需求而定
重复执行：应尽量减少用例的重复执行，在保证覆盖率前提下优化用例数量
实际应用：单元测试中常用，功能测试中较少使用该标准

语句覆盖法设计用例

1.语句覆盖要求: 在设计用例时，需要确保程序中的每一个语句都被执行至少一次。

2.语句覆盖路的走法

走法示例: 输入a, b, c，如果a>0且b>0，则执行c=c/a；如果a>1或c>1，则执行c=c+1；最后执行c=b+c，并输出a, b, c。需要设计用例使得这些语句都被执行。

设计用例

用例设计: 根据语句覆盖的要求，设计用例a=2, b=1, c=6。

用例解释: 这个用例可以确保所有语句都被执行。首先，a>0且b>0，所以执行c=c/a，c变为3；然后，a>1，所以执行c=c+1，c变为4；最后执行c=b+c，c变为5，并输出a, b, c的值为2, 1, 5。

用例有效性: 这个用例满足了语句覆盖的要求，因为所有语句都被执行了。

4.语句覆盖率: 通过设计用例并执行程序，可以计算出语句覆盖率。在本例中，通过用例a=2, b=1, c=6，所有语句都被执行，所以语句覆盖率为100%。

5.路径覆盖率: 路径覆盖率是指程序中所有可能的执行路径被测试的比例。在本例中，存在四条可能的执行路径，但语句覆盖法只测试了其中一条，所以路径覆盖率为25%。

提高路径覆盖率: 为了提高路径覆盖率，需要设计更多的用例来覆盖其他可能的执行路径。这通常需要使用更复杂的测试方法，如条件覆盖、路径覆盖等。

分支覆盖标准

分支覆盖（判定覆盖）定义

定义: 分支覆盖（判定覆盖）是指程序中的每个判定的真分支和假分支至少各执行一次。

判定: 即大条件，如if、where语句中的条件表达式。

题目给出了一个包含多个判定条件的程序片段，要求设计测试用例以满足分支覆盖标准。

解题思路:
- 首先识别程序中的判定条件，即a>0且b>0和a>1或c>1。
- 然后设计测试用例，使得每个判定的真分支和假分支至少各执行一次。
- 可以通过选择不同的路径来实现，例如：
  - 用例1：a<0, b<0, c<0，此时两个判定条件均为假。
  - 用例2：a=2, b=1, c=6，此时两个判定条件均为真。

分支覆盖的定义

分支覆盖: 也叫判定覆盖，是软件测试中的一种覆盖准则，要求设计测试用例，使得程序的每一个分支（或判定）至少被执行一次。
语句覆盖率: 在这个例子中，语句覆盖率是百分之百，但分支覆盖率可能不同。

分支覆盖的计算

覆盖率计算: 若有七个语句，其中五个语句被覆盖，则分支覆盖率为5/7，即约71.43%，而非100%。
单独分析: 需要单独看每个分支是否被覆盖，而不能只看整体的语句覆盖率。

分支覆盖的覆盖率

覆盖率概述

总体覆盖率: 在进行代码测试时，总体上达到了百分之百的语句覆盖率。

路径覆盖率: 提及了路径覆盖率的概念，并指出在特定的测试用例中，只走了两条路径，因此路径覆盖率为百分之五十。

条件覆盖法设计测试用例

定义: 条件覆盖（C2标准）要求使每个判定中的每个条件的可能取值至少满足一次，即每个条件都要真（True）一次，假（False）一次。
与分支覆盖的对比: 分支覆盖关注大条件的正确性，而条件覆盖能发现条件错误（如大于、小于、等于写错），但不能发现逻辑错误。

例题：

条件覆盖的例子与分析

判定条件覆盖C1+C2

同时满足判定覆盖和条件覆盖的要求

判定条件覆盖C1+C2应用案例

例题:条件掩盖问题

用例：

测试用例输入	原子条件	判定条件
a=2 b=1 c=4	a>0 真，b>0 真，a>1真，c>1真	判定3取真，判定6取真
a=-1 b=-2 c=-3	a>0 假，b>0 假，a>1假，c>1假	判定3取假，判定6取假

条件组合覆盖

定义: 条件组合覆盖，也称为多条件覆盖C3，要求每个判定中的所有的条件取值组合至少执行一次。

路径覆盖C4

覆盖路径

路径覆盖: 除了满足条件组合覆盖外，还需要考虑路径的覆盖，即程序执行的所有可能路径都要被测试到。

示例: 在给定的判定条件下，需要确保真真、假真、假假等所有路径都被覆盖到，如果有遗漏的路径（如真假），则需要补充相应的用例。

注意: 路径覆盖通常比条件组合覆盖要求更高，用例数量可能会翻倍。

路径覆盖法

核心目标：要求测试用例覆盖程序中所有可能的执行路径，包括循环路径
覆盖标准：属于白盒测试中的C4级覆盖标准，比条件组合覆盖更严格
执行难点：程序中的循环结构会导致路径数量呈指数级增长，例如操场跑步的比喻（第500圈状态无法预测）

应用案例

四路径模型：通过a>0、b>0、a>1、c>1四个条件组合形成4条独立路径
用例设计：
- 全真路径：a=2,b=1,c=6（判定3真/判定6真）
- 全假路径：a=-1,b=-2,c=-3（判定3假/判定6假）
- 混合路径1：a=1,b=1,c=-3（判定3真/判定6假）
- 混合路径2：a=-1,b=2,c=3（判定3假/判定6真）
适用条件：适用于无循环或有限循环次数的程序段

路径覆盖优化

McCabe的基路径方法 02:51

理论基础：基于圈复杂度计算线性独立路径数（边-节点+2）
优化原理：通过控制流图识别基本路径，避免无限循环测试
McCabe的控制图

- 节点定义：A为起始节点，G为终止节点，B/C/D等为过程节点
- 循环识别：B→C→B形成循环结构，需特殊处理
- 复杂度计算：闭合环数+1=5（示例中需设计5条独立路径）

路径覆盖法设计用例

路径示例

    * 路径选择原则：+ 允许部分重叠（如p1与p2在A→B→C段重叠）+ 禁止完全包含（如p2不应完全包含p1的路径）+ 循环结构仅测试单次迭代（如p2中的B→C→B）* 典型路径：+ p1：A→B→C→G（边1,4,9）+ p2：A→B→C→B→C→G（边1,4,3,4,9）+ p3：A→D→E→F→G（边2,6,8,10）+ p4：A→D→F→G（边2,7,10）+ p5：A→B→E→F→G（边1,5,8,10）