一、软件测试基础概念

1. 静态验证（Static Verification）​

• 定义：不执行代码，通过检查文档/代码结构来验证软件正确性（如代码审查、静态分析工具）
• 特点：早期发现错误，成本低
• 常见方法：代码走查、文档评审、静态分析

2. 动态验证（Dynamic Verification）​

• 定义：通过执行程序来验证软件行为是否符合预期（即软件测试）
• 特点：需运行程序，验证实际输出
• 包含：黑盒测试、白盒测试

3. 测试用例（Test Case）​

• 定义：描述输入、操作步骤和预期结果的文档，用于验证特定功能
• 组成要素：编号、标题、优先级、输入数据、操作步骤、预期结果

4. 黑盒测试 vs 白盒测试

• 黑盒测试​：
  • 定义：基于需求规格，不关注内部实现，验证功能正确性（功能测试、数据驱动、基于规范）
  • 优点：用户视角，与实现无关，适合回归测试
  • 缺点：覆盖率难100%，存在冗余用例
• 白盒测试​：
  • 定义：基于代码实现设计用例，验证程序内部逻辑
  • 优点：覆盖代码路径，发现深层缺陷
  • 缺点：依赖技术实现，维护成本高

5. 软件维护

• 类型：纠错性/适应性/完善性/预防性维护
• 目标：确保软件持续满足用户需求

---

二、黑盒测试技术

优点：
（1） 有目的地发现 bug，更准确地定位 bug。
（2）黑盒检测可以证明产品是否满足用户要求的功能，是否满足用户的工作要求。
（3） 黑盒测试与软件的状况无关
（4） 测试用例开发可以与软件开发同时进行，可以节省软件开发时间。大多数黑盒测试用例都可以通过软件用例进行设计。
（5） 可以重复相同的动作，测试中最无聊的部分可以由机器完成。
缺点：
（1） 需要充分了解待测软件产品中使用的技术，测试人员需要有更多的经验。
（2） 测试用例数量多
（3） 测试用例可能会产生大量冗余
（4） 功能测试覆盖率达不到 100%
（5） 在测试过程中，很多都是人工测试作。
（6） 测试员应负责准备和安排大量的文件和报告。

过程
（1） 测试计划阶段
（2） 测试设计阶段
根据程序需求规范或用户手册（manual），对软件功能进行划分，按照一定的标准化方法设计测试用例
（3） 测试执行阶段
根据设计的测试用例执行测试;
free测试（作为测试用例测试的补充）。
（4） 测试总结阶段

用于黑盒测试的测试用例设计技术

1. 等价类划分（Equivalence Partitioning）

• 定义​：将输入域划分为若干等价类，每类选代表值测试
• 步骤​：
  1. 划分有效/无效等价类
  2. 设计覆盖所有类的测试用例
     方法介绍
     1） 分区等价类
     等效类是指输入字段的子集。
     在这个子集中，每个输入数据等同于在程序中暴露错误。
     测试等效类中的代表性数据相当于测试等价类中其它数据
     等价类的划分：
  • 有效等价类：符合程序规范且有意义的输入数据集合；可用于检查程序是否达到规范中指定的功能和性能
  • 无效等价类：对程序规范不合理或无意义的输入数据集；对于特定问题，至少应该有一个无效的等价类，并且可能有多个。
  • 在设计测试用例时，应同时考虑两个等价类
    因为软件不仅要接收合理的数据，还要经得起意外的考验
    这样的测试可以保证软件具有更高的可靠性

2） 划分等价类别的标准：完成测试并避免冗余；子集彼此不相交
3） 划分等价类的方法：
4） 设计测试用例：1） 为每个等效类指定一个唯一编号。（2） 设计一个新的测试用例，以涵盖尽可能多的尚未覆盖的有效等价类。重复此步骤，直到覆盖所有有效的等价类。（3） 设计一个新的测试用例，以仅涵盖一个尚未涵盖的无效等价类。重复此步骤，直到覆盖所有无效的等价类。

• 划分方法（criteria）​：
  • 数值范围（如0-100分）
  • 数据集合（如学历选项）
  • 布尔条件（是/否）
  • 必须遵守的规则（密码）
  • 如果已知划分的等价类中的元素在程序处理中具有不同的方式，则应将等价类进一步划分为更小的等价类。
• 案例​：三角形类型测试（有效等价类：等边、等腰、一般；无效类：非数字、负数等）
  

2. 边界值分析（Boundary Value Analysis）

• 定义​：针对输入/输出边界值设计测试用例（对等价类方法的补充）
  通常，输入和输出等效类的边界是应该测试的边界。
  应选择完全等于、略大于或略小于边界的值作为测试数据，而不是选择典型值或等价类中的任何值作为测试数据
  与等价类法的区别
  边界值分析不是随机选择一个等价类作为代表，而是将等价类的每个边界作为检验条件。
  边界值分析不仅考虑输入条件，还考虑输出空间生成的测试条件。
• 原则​：
  • 选取刚好等于、稍大于、稍小于边界的值
  • 关注数值范围、循环次数、数据结构边界
• 案例​：学生成绩范围测试（0,1,100,101）
  

3. 组合测试

有许多不同的技术可以识别相关组合，例如因果图、决策表和真值表。
真值表：根据谓词逻辑中表示的输入原因和输出效果，指定了软件所需的操作

因果图/决策表（Cause-Effect Graphs）

• 定义​：分析输入条件组合与输出结果的关系

• 符号系统​：

  • 原因（输入条件）→ 结果（输出）

  • 逻辑关系：与/或/非/恒等
    §Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。
    

  • 约束条件：输入状态相互之间还可能存在某些依赖关系。互斥（E）、包含（I）等
    

  说明：
  §输入条件的约束有以下4类：
  ① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。
  ② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。
  ③ O约束（唯一）；a和b必须有一个，且仅有1个为1。
  ④R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。
  §输出条件约束类型
  输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。

  §因果图方法最终生成的是判定表。它适合于检查程序输入条件的各种组合情况。利用因果图生成测试用例的基本步骤:
  (1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符
  (2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图。
  (3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。
  (4) 把因果图转换为判定表。
  (5) 把判定表的每一列拿出来作为依据,设计测试用例。

• 转换步骤​：

  1. 建立因果图
  2. 转换为决策表
  3. 生成测试用例

• 案例​：文件修改程序（输入字符A/B+数字组合测试）
  

§判定表的建立步骤:（根据软件规格说明）
①确定规则的个数.假如有n个条件。每个条件有两个取值（0,1）,故有2^n种规则。
②列出所有的条件桩和动作桩。
③填入条件项。
④填入动作项。等到初始判定表。
⑤简化.合并相似规则（相同动作）。

[图片]

4. 随机测试（Random Testing）

• 定义​：使用随机生成的数据进行测试
• 应用场景：
  • 稳定性测试（验证程序不崩溃）
  • 模拟真实数据分布(分布可以是均匀的，也可以选择在统计意义上模拟程序在实际使用中将接收的输入类型。)
• 特点：快速生成用例，适合自动化，但缺陷发现率低
  随机数据选择有时用于稳定性测试，以确保没有输入数据值导致软件崩溃或引发意外异常。这种技术很容易以自动化方式实现，但不太可能发现错误，除非代码质量低。

5. 错误推测法（Error Guessing）

• 定义​：基于直觉和经验猜测易错场景设计用例
• 典型用例​：
  • 空值/零值测试（如除数为零），空字符串、数组、列表和类引用为空或 null。
  • 边界外数据（如负数）
  • 特殊字符（空格、null）
• 测试人员选择可能产生错误的值。每个值都是一个测试用例：此技术可以生成正常测试用例和错误测试用例。选择的值是那些可能在代码中暴露错误的值，它们不一定是非法值。
• 根据尚未覆盖的 Test Cases 选择 Input Test Data。 与其他测试技术一样，应单独执行错误情况
• 案例​：列表排序测试（空列表、单元素、重复元素）

6. 场景测试（Scenario Testing）

• 定义​：模拟用户使用场景，验证端到端功能和软件的所有流程正常工作

• 组成要素​：

  • 基本流（正常流程）：通过用例的最简单路径，即没有任何错误，程序直接从过程的开始到结束。大多数用户最常用的工作流程，体现软件的主要功能和流程。一个业务只有一个基本流，基本流只有一个start和一个end
  • 备选流（异常分支）：从基本流开始，在特定条件下执行，然后重新加入基本流（例如备选流 1 和 3）;.或源自其他备选流（例如流程 2）;
    • 反映了不同的错误场景
      
  1. Scenario1: Basic flow
  2. Scenario 2:Basicflow→Alternativeflow1
  3. Scenario 3: Basicflow→Alternativeflow1→Alternativeflow 2
  4. Scenario 4:Basicflow→Alternativeflow3
  5. Scenario 5: Basicflow→Alternativeflow3→Alternativeflow1
  6. Scenario 6: Basic Flow→Alternativeflow3→Alternativeflow1→Alternativeflow2
  7. Scenario 7: Basicflow→Alternateflow4
  8. Scenario 8: Basic flow→Alternative flow 3→ Alternativeflow4

• 设计步骤​：
  （1） 根据规范，描述被测软件的基本流程和替代流程。
  （2） 构建不同的场景，满足测试完备、无冗余的要求。
  （3） 为每个场景设计相应的测试用例。
  （4） 重新检查所有生成的测试用例并删除多余的测试用例。确定测试用例后，将确定每个测试用例的测试数据值。

  状态图
  

• 案例​：电商下单流程（正常下单→库存不足→支付失败）
  酒店系统支持在线预订。
  客户访问网站进行房间预订操作，选择预订日期、合适的房间、在线预订。
  在这种情况下，您需要使用您的个人帐户登录系统。
  登录成功后，您可以支付押金。
  支付押金成功后会生成房间预订表单，完成整个房间预订流程。
  该系统允许30天的预订期和400美元的押金。
  

如何根据场景流动设计测试用例呢？
V：为了让基本流被执行，条件必须为有效的
I：如果条件无效，那么就会激活可选流
NA：Not Applicable 条件无法被应用到测试用例中

根据可选流，结合题目的具体数据设计测试用例即可

---

三、其他重要概念

1. 状态图测试（State Transition Testing）​
   

• 定义：基于系统状态转换设计用例

• 模块
  

  • State
  • Transition
  • Event
  • Action
  • guard：与事件关联的谓词表达式，说明要触发的转换的布尔限制

• 覆盖标准（状态图分析）：

  • 全事件覆盖：状态机的每个事件都包含在测试套件中
  • 全状态覆盖
  • 全转移覆盖
  • 全路径覆盖：从入口到出口的路径覆盖。在图中没有退出状态，因此所有需要确定从 Entry 到每个 State 的路径。
  • 全回路覆盖

• 应用：协议测试、状态机验证
  

2. 测试阶段划分

• 计划阶段：确定测试策略/资源
• 设计阶段：创建测试用例
• 执行阶段：运行用例并记录结果
• 总结阶段：分析缺陷，生成报告

3. 测试管理要素

• 测试环境搭建
• 缺陷跟踪管理
• 风险评估与优先级

四、白盒测试

一、白盒测试基础概念

1. 定义

• 又称结构测试、逻辑驱动测试，基于程序内部结构设计测试用例。
• 白盒测试使用有关被测单元内部工作方式的信息，允许测试人员根据程序的内部逻辑结构和相关信息设计和选择测试用例来测试程序。
• 需了解代码逻辑（如条件、循环、分支）和数据结构。

2. 核心思想

• 通过覆盖程序内部逻辑路径，验证所有执行流程是否符合预期。

---

二、覆盖标准（由低到高）​

白盒测试覆盖标准：

• 确保模块中的所有独立 paths 至少执行一次;
• true 和 false 分支都需要针对所有逻辑值进行测试;
• 在上限和下限以及作范围内运行所有循环;
• 检查内部数据结构以确保其有效性。

1. 语句覆盖Statement coverage

1. （最弱的逻辑覆盖率，效果有限，必须与其他方法交互使用。）

• 目标​：每个语句至少执行一次。
• 局限性​：无法检测条件逻辑错误（如AND误写为OR）。
• 示例​（例1）：测试用例仅覆盖路径，但遗漏条件组合。
  如，例1：

PROCEDURE  M(VAR A，B，X：REAL)；  
BEGIN 
IF (A>1) AND (B=0)  THEN X:=X/A； 
IF (A=2) OR (X>1)   THEN X:=X+1； 
END.

语句测试：选择输入数据为：
A=2，B=0，X=3
就可达到“语句覆盖”标准

例2：
void  DoWork(int x,int y,int z)
{  int  k=0,j=0;
   if((x>3)&&(z<10))
   {       k=x*y-1;     //语句块1
         j=sqrt(k);
    }
   if((x= =4)||(y>5))
   {       j=x*y+10;   //语句块2
    }
   j=j%3;             //语句块3
}

为了测试语句覆盖率只要设计一个测试用例就可以把三个执行语句块中的语句覆盖了。测试用例输入为：
x=4、y=5、z=5
该测试用例虽然覆盖了可执行语句，但并不能检查判断逻辑是否有问题，例如在第一个判断中把&&错误的写成了||，则上面的测试用例仍可以覆盖所有的执行语句。

2. 判定（分支）覆盖Decision coverage

• 目标​：每个判断的取真分支和取假分支至少执行一次
• 优于语句覆盖​，但仍可能遗漏条件错误。
• 示例​（例1）：设计测试用例覆盖真/假分支。
  

可以选择输入数据为：
① A=3，B=0，X=1 (沿路径acd执行)；
② A=2，B=1，X=3(沿路径abe执行)

例2

    对于例2的程序，如果设计两个测试用例则可以满足条件覆盖的要求。
    测试用例的输入为：
            x=4、y=5、z=5 【a b d】
            x=2、y=5、z=5  【a c e】

   上面的两个测试用例虽然能够满足条件覆盖的要求，但是也不能对判断条件进行检查，例如把第二个条件y>5错误的写成y<5,、上面的测试用例同样满足了分支覆盖。 

3. 条件覆盖Condition coverage

• 目标​：每个条件的所有可能取值（真/假）至少执行一次。
• 问题​：可能无法覆盖所有分支（如条件组合不完整）。

例1的程序有四个条件：
A＞1、 B=0、A=2、X＞1 为了达到“条件覆盖”标准，需要执行足够的测试用例使得在a点有： A＞1、A≤1、B=0、B≠0 等各种结果出现，以及在b点有：
A=2、A≠2、X＞1、X≤1 等各种结果出现。 现在只需设计以下两个测试用例就可满足这一标准： ① A=2，B=0，X=4 (沿路径ace执行)； ② A=1，B=1，X=1 (沿路径abd执行)。

例2

例2中的所有条件取值加以标记。 对于第一个判断： 条件x>3 取真值为T1，取假值为-T1 条件z<10 取真值为T2，取假值为-T2
对于第二个判断： 条件x=4 取真值为T3，取假值为-T3 条件y>5 取真值为T4，取假值为-T4

4. 判定/条件覆盖

• 目标​：同时满足判定覆盖和条件覆盖。获取判定中每个条件的各种可能值，并获取每个判定的各种可能结果。
• 局限性​：未覆盖条件的所有组合。

5. 条件组合覆盖

• 目标​：每个判断中所有条件的可能组合至少执行一次。
• 优点​：覆盖条件组合，但可能遗漏某些路径。
• 示例​（例1）：4个测试用例覆盖8种条件组合。

我们需要选择适当的例子，使得下面8种条件组合都能够出现： 1）A>1, B=0 2) A>1, B≠0 3) A≤1,
B=0 4) A≤1, B≠0 5）A=2, X>1 6) A=2,X≤1 7）A≠2, X>1
8) A≠2, X≤1 下面设计的四个例子可以使上述 8种条件组合至少出现一次： ① A=2，B=0，X=4 使
1)、5)两种情况出现； ② A=2，B=1，X=1 使 2)、6)两种情况出现； ③ A=1，B=0，X=2
使 3)、7)两种情况出现； ④ A=1，B=1，X=1 使 4)、8)两种情况出现。
上面四个例子虽然满足条件组合覆盖，但并不能覆盖程序中的每一条路径，例如路径acd就没有执行，因此，条件组合覆盖标准仍然是不彻底。

现对例2中的各个判断的条件取值组合加以标记如下

1、x>3,z<10 记做T1 T2，第一个判断的取真分支 2、x>3,z>=10 记做T1 -T2，第一个判断的取假分支
3、x<=3,z<10 记做-T1 T2，第一个判断的取假分支 4、x<=3,z>=10 记做-T1 -T2，第一个判断的取假分支
5、x=4,y>5 记做T3 T4，第二个判断的取真分支 6、x=4,y<=5 记做T3
-T4，第二个判断的取真分支 7、x!=4,y>5 记做-T3 T4，第二个判断的取真分支 8、x!=4,y<=5 记做-T3 -T4，第二个判断的取假分支

6. 路径覆盖

• 目标​：覆盖程序中所有可能的路径。
• 挑战​：路径数量庞大，需通过基本路径测试压缩。
  

白盒测试举例

---

三、白盒测试主要方法

逻辑驱动测试方法

1. 核心方法

• 基于覆盖标准设计测试用例，逐级提高覆盖强度。（不包括路径覆盖）

2. 示例分析

• 例1​：两个IF语句的程序，通过不同覆盖标准设计用例。
• 例2​：含多条件判断的函数，演示条件覆盖与分支覆盖的区别。
• 例3​：工资管理程序，展示如何综合应用覆盖标准。

3. 常见问题

• 条件短路（如||左侧为真时跳过右侧）可能影响测试结果。
• 循环和复杂数据结构需额外关注（如边界值、有效性检查）。

---

基本路径测试
把大量的路径压缩到一定限度
它在程序控制图的基础上，通过分析控制构造的环行(圈，loop)复杂性，导出基本可执行路径集合，从而设计测试用例的方法。
设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。
流图：对待测试程序过程处理的一种表示。

1. 步骤
2. 绘制控制流图​（描述程序的控制流）：将代码转换为节点（语句块）和边（控制流）。
   细节一：第几行 for (a; b; c)
   细节二：先执行 5，再执行 4c

2. 计算圈复杂度
   - 方法：区域数、边数-节点数+2、判定节点数+1。
   - 示例​（例4）：圈复杂度为4，对应4条独立路径。
3. 导出独立路径​：每条路径至少包含一条新边。独立路径条数为圈复杂度
4. 设计测试用例​：覆盖每条独立路径。
5. 工具方法（图形矩阵）​

• 矩阵表示节点连接关系，辅助确定独立路径。

3. 示例​（例4）

• 控制流图绘制 → 圈复杂度计算 → 导出4条路径 → 设计输入数据。
  
  
  
  
  
  
  
  

---

五、数据流测试（扩展知识）​

数据流测试使用 control flowgraph（控制流图）来探索数据可能发生的不合理情况（即 anomalies（异常、不规则））。

1. 核心思想

• 分析变量的定义（d）和使用（u），确保数据操作合理。
• 检查变量是否在使用前初始化、是否被正确使用。
  数据对象分类
  

2. 关键概念

• 定义-清除路径​：路径中无重复定义变量。
• 简单路径段：最多只访问同一个节点两次
• Loop-free Path Segment(无循环路径段)：每个节点最多访问一次
• du路径：变量从定义到使用的路径，需简单且无重复定义。
  • 定义使用路径：关于变量v的定义使用路径（记作du-path），存在定义节点DEF(v,m)和使用节点USE(v,n)，使得m和n作为该路径的开始节点和结束结点．

3. def-use Associations（关联）

---

六、静态测试

一、静态测试的定义

静态测试​：在不实际执行程序的情况下，通过检查、评审软件相关制品（如需求文档、设计文档、源代码等）来发现缺陷的方法。

• 核心特点​：无需运行程序，依赖人工逻辑思维或自动化工具分析。
• 对象​：软件相关制品（文档、需求规格、源代码、测试用例等）。
• 形式​：可手动（如代码审查）或自动（静态分析工具）。

---

二、静态测试的重要性

1. 缺陷发现效率​：

• 静态测试：发现50-60%的软件缺陷。
• 动态测试：发现40-50%的软件缺陷。
• 互补性​：两者结合可提高整体缺陷检出率。

2. 成本效益​：

• 早期发现缺陷成本更低​：
  • 需求阶段：2-3小时/缺陷
  • 设计阶段：3-4小时/缺陷
  • 代码审查：3-5小时/缺陷
  • 动态测试：15-25小时/缺陷
• 无需测试用例设计​：直接通过逻辑分析发现缺陷。

3. 其他优势​：

• 无需特殊执行环境，实施便捷。
• 可发现逻辑错误和沟通障碍导致的缺陷（“解铃还需系铃人”）。

---

三、静态测试方法分类

1. 手动方法​：

• 代码审查（Code Review）​​：
  由团队（程序员、测试员等）集体阅读代码，对照审查单发现缺陷。

  • 流程​：准备 → 阅读代码 → 审查会议（识别缺陷，不讨论修复） → 跟踪报告。
  • 优点​：发现30-60%逻辑设计缺陷，缺陷定位明确，成本低。
  1. 代码审查单（Checklist）​​：
  • 分类错误类型（如数据引用、计算、控制流错误），指导审查：把程序设计和编码中可能发生的各种错误进行分类，对每类列举出尽可能多的典型错误，然后制成表格
  • 示例：Myers的8类错误（数据引用错误；数据声明错误；计算错误；比较错误；控制流程错误；子程序参数错误；输入／输出错误；其它错误）。
  • 代码审查单还可以包括：编程风格、标准、规范；
  • 在错误登记表中应写明所查出的错误的类型、错误类别、错误的严重程度、错误的位置、错误的原因
  2. 阅读方法：
  • 广度优先：快速了解程序全貌。
  • 深度优先：详细跟踪功能逻辑。
  • 推荐实践：至少4遍阅读（印刷错误→数据结构→控制流→处理逻辑）。
  3. 团队组成：
  • 代码审查组：组长（非代码作者）、资深程序员、测试员。

• 代码走查（Code Walkthrough）​​：
  通过模拟测试用例执行程序逻辑，用头脑执行代码路径。

  • 流程​：准备测试用例 → 会议模拟执行 → 记录缺陷。
  • 特点​：侧重启发式错误检测，但覆盖范围有限。
  • 团队组成：

    • - 代码走查组：组长、秘书（负责记录发现的错误，要有一定水平）、测试人员（设计测试用例）。
      

与代码审查不同，不是读程序和使用代码审查单
而是由被指定的作为测试员的小组成员提供若干测试用例（程序的输入数据和期望的输出结果），让参加会的成员当计算机，在会议上对每个测试用例用头脑来执行程序，也就是用测试用例沿程序逻辑走一遍，并由测试人员讲述程序执行过程，在纸上或黑板上监视程序状态（变量的值）
这里测试用例是作为怀疑程序逻辑与计算错误的启发点，在随测试实例遍历程序逻辑时，在怀疑程序的过程中发现错误
- 缺点：代码走查使用测试用例启发检测错误，人们注意力会相对集中在随测试用例遍历的程序逻辑路径上，不如代码审查检查的范围广，错误覆盖面全

• 桌面检查（Desktop Check）​​：
  程序员自行检查代码，效率较低（易受心理偏好和思维定式影响）。

• 代码审查和代码走查的优点：
  它不仅比桌面检查优越得多，而且与动态测试方法相比也具有许多优势
  首先，使用这种方法进行测试，一旦发现 bug，就可以知道bug 的性质和位置，调试成本低
  其次，使用此方法可以一次显示一批 bug，而不是一次只显示一个 bug，如果使用动态测试，通常只揭示 bug 的症状，程序不会终止，但性质和位置

2. 自动方法​：

• 静态分析​：通过工具检查代码规范性（如未初始化变量、语法错误等）。
• 工具辅助​：交叉引用表、逆向工程工具、代码规范检查器等。

---

四、技术评审（Technical Review）​

• 定义​：使用走查和审查对需求、设计文档进行逐页、逐节检查，确保质量与标准符合性。
• 范围​：软件全生命周期各阶段（需求分析、设计、实现）。
• 作用​：
  • 提升软件质量，收集质量数据。
  • 作为管理工具，确保流程规范性。

---

五、静态测试核心实践

1. 需求定义的静态测试​：着重于测试对用户需求的描述和解释是否完整、准确

• 高级审查​：验证需求完整性、是否符合用户期望、行业标准。找出根本性的问题、疏忽或遗漏之处
• 低层测试​：检查术语模糊性（如“通常”“快速”）、逻辑完整性（如缺少“否则”分支）。
• 对照条例​：完备性、一致性、正确性、可行性、易修改性、健壮性、可追溯性、易理解性、易测试和可验证性等。
  

2. 设计文档的静态测试​：着重于分析设计是否与需求定义一致

• 验证内容​：
  • 设计是否满足需求？4
  • 算法可行性？模块划分合理性？
• 检查项​：完备性、一致性、正确性、可行性、易修改性、健壮性、可追溯性、易理解性、易测试和可验证性等。（跟需求定义的静态测试相同）

3. 源代码的静态测试​：着重于分析实现是否正确、完备

• 检查重点​：
  • 完备性、一致性、正确性、可行性、易修改性、健壮性、可追溯性、易理解性、易测试和可验证性等
• 规则​：避免全局变量、递归、死循环，确保单入口/出口。

---

七、静态测试与动态测试的互补性

• 静态测试优势​：
  • 发现逻辑错误、规范性问题。
  • 早期低成本发现缺陷。
• 动态测试优势​：
  • 验证运行时行为（如性能、内存泄漏）。
• 结论​：两者缺一不可，结合使用最大化缺陷覆盖率。

---

注意事项

• 代码审查会议​：时长1.5-2小时，聚焦缺陷发现而非修复。
• 需求评审​：避免模糊术语，量化非功能性需求（如响应时间）。
• 设计验证​：使用信息隐藏、高内聚低耦合原则