静态测试技术:不运行被测试程序,对代码通过检查、阅读进行分析。
目录
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%。