【实际开发17】- 静态测试

静态测试技术：不运行被测试程序，对代码通过检查、阅读进行分析。

目录

1. 静态测试

1. 静态测试三步曲 : 走查 / 审查 / 评审

2. 编码的标准和规范

3. 代码评审

1. 代码走查 ( Walk Through )

2. 正式会议审查 ( Inspection )

3. 评审 ( Review )

2. 动态测试

1. 动态测试需要真正将程序运行起来

2. 单元测试设计

1. 单元测试模型设计

2. 测试项目设计

---

1. 静态测试

---

1. 静态测试三步曲 : 走查 / 审查 / 评审

---

2. 编码的标准和规范

• 标准：建立起来必须遵守的规则

• 规范：建议最佳做法，推荐更好方式

---

3. 代码评审

• 一次检查少于200～400行代码

• 努力达到一个合适的检查速度：300～500LOC/hour

• 有足够的时间、以适当的速度、仔细地检查，但不宜超过60～90分钟

• 在审查前，代码作者应该对代码进行注释

• 使用检查表（checklist）肯定能改进双方（作者和复审者）的结果

• 验证缺陷是否真正被修复

---

1. 代码走查 ( Walk Through )

定义：采用讲解、讨论和模拟运行的方式进行的查找错误的活动。

注意：

• 引导小组成员在走查前通读设计和编码。

• 限时，避免跑题。

• 发现问题适当记录，避免现场修改。

• 检查要点是代码是否符合标准和规范，是否有逻辑错误。

---

2. 正式会议审查 ( Inspection )

定义：采用讲解、提问方式进行，一般有正式的计划、流程和结果。主要方法采用缺陷检查表。

注意：

• 以会议形式，制定会议目标、流程和规则，结束后要编写报告。

• 按缺陷检查表逐项检查。

• 发现问题适当记录，避免现场修改。

• 发现重大缺陷，改正后会议需要重开。

• 检查要点是缺陷检查表，所以该表要根据项目不同不断积累完善。

1. 走查与审查的比较 ~ table

走 查	审 查
准备	通读设计和编码	应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表
形式	非正式会议	正式会议
参加人员	开发人员为主	项目组成员包括测试人员
主要技术方法	无	缺陷检查表
注意事项	限时、不要现场修改代码	限时、不要现场修改代码
生成文档	会议记录	静态分析错误报告
目标	代码标准规范，无逻辑错误	代码标准规范，无逻辑错误

---

3. 评审 ( Review )

定义：通常在审查会后进行，审查小组根据记录和报告进行评估。

注意：

• 充分审查了所规定的代码，并且全部编码准则被遵守。

• 审查中发现的错误已全部修改。

---

2. 动态测试

---

1. 动态测试需要真正将程序运行起来

动态测试需要真正将程序运行起来，需要设计系列的测试用例保证测试的完整性和有效性。

白盒测试 黑盒（灰盒）测试

驱动程序和桩程序

运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模块。

• 驱动模块（drive）:对底层 或子层模块进行测试所编写的 调用这些模块的程序。

• 桩模块（stub）：对顶层或 上层模块进行测试时所编写的 替代下层模块的程序。

---

2. 单元测试设计

• 单元测试模型的设计。

• 测试项目的设计。

---

1. 单元测试模型设计

• 构造最小运行调度系统，即驱动模块，用于模拟被测模块的上一级模块。

• 模拟实现单元接口，即单元函数需调用的其他函数接口，即桩模块。

• 模拟生成测试数据或状态，为单元运行准备动态环境。

• 对测试过程的支持，对测试结果的保留，对测试覆盖率的记录等。

单元测试环境的示意图如下：

---

2. 测试项目设计

• 测试项目是测试用例的一个总则，主要是根据测试需求设计测试点，不包含具体实践的用例。

• 在测试项目的设计中，主要从功能覆盖和代码覆盖两个角度进行考虑。

功能覆盖属黑盒的范畴，用来指出测试用例是否已经覆盖了程序应该提供的功能。逻辑覆盖率是考核单元测试质量的一个关键指标。

代码覆盖也称逻辑覆盖，包括语句覆盖、分支覆盖、路径覆盖，是一种常用的白盒测试方法。

• 覆盖率指标：核心代码覆盖率达到100%，共享资源库的代码覆盖率达到100%，非核心代码覆盖率达到90%。