静态测试技术：不运行被测试程序，对代码通过检查、阅读进行分析。
目录
标准：建立起来必须遵守的规则
规范：建议最佳做法，推荐更好方式
一次检查少于200～400行代码
努力达到一个合适的检查速度：300～500LOC/hour
有足够的时间、以适当的速度、仔细地检查，但不宜超过60～90分钟
在审查前，代码作者应该对代码进行注释
使用检查表（checklist）肯定能改进双方（作者和复审者）的结果
验证缺陷是否真正被修复
定义：采用讲解、讨论和模拟运行的方式进行的查找错误的活动。
注意：
引导小组成员在走查前通读设计和编码。
限时，避免跑题。
发现问题适当记录，避免现场修改。
检查要点是代码是否符合标准和规范，是否有逻辑错误。
定义：采用讲解、提问方式进行，一般有正式的计划、流程和结果。主要方法采用缺陷检查表。
注意：
以会议形式，制定会议目标、流程和规则，结束后要编写报告。
按缺陷检查表逐项检查。
发现问题适当记录，避免现场修改。
发现重大缺陷，改正后会议需要重开。
检查要点是缺陷检查表，所以该表要根据项目不同不断积累完善。
1. 走查与审查的比较 ~ table
| 走 查 | 审 查 | |
|---|---|---|
| 准备 | 通读设计和编码 | 应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表 |
| 形式 | 非正式会议 | 正式会议 |
| 参加人员 | 开发人员为主 | 项目组成员包括测试人员 |
| 主要技术方法 | 无 | 缺陷检查表 |
| 注意事项 | 限时、不要现场修改代码 | 限时、不要现场修改代码 |
| 生成文档 | 会议记录 | 静态分析错误报告 |
| 目标 | 代码标准规范，无逻辑错误 | 代码标准规范，无逻辑错误 |
定义：通常在审查会后进行，审查小组根据记录和报告进行评估。
注意：
充分审查了所规定的代码，并且全部编码准则被遵守。
审查中发现的错误已全部修改。
动态测试需要真正将程序运行起来，需要设计系列的测试用例保证测试的完整性和有效性。
白盒测试 黑盒（灰盒）测试
驱动程序和桩程序
运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模块。
驱动模块（drive）:对底层 或子层模块进行测试所编写的 调用这些模块的程序。
桩模块（stub）：对顶层或 上层模块进行测试时所编写的 替代下层模块的程序。
单元测试模型的设计。
测试项目的设计。
构造最小运行调度系统，即驱动模块，用于模拟被测模块的上一级模块。
模拟实现单元接口，即单元函数需调用的其他函数接口，即桩模块。
模拟生成测试数据或状态，为单元运行准备动态环境。
对测试过程的支持，对测试结果的保留，对测试覆盖率的记录等。
单元测试环境的示意图如下：
测试项目是测试用例的一个总则，主要是根据测试需求设计测试点，不包含具体实践的用例。
在测试项目的设计中，主要从功能覆盖和代码覆盖两个角度进行考虑。
功能覆盖属黑盒的范畴，用来指出测试用例是否已经覆盖了程序应该提供的功能。逻辑覆盖率是考核单元测试质量的一个关键指标。
代码覆盖也称逻辑覆盖，包括语句覆盖、分支覆盖、路径覆盖，是一种常用的白盒测试方法。
覆盖率指标：核心代码覆盖率达到100%，共享资源库的代码覆盖率达到100%，非核心代码覆盖率达到90%。
