【软件测试】单元测试

1.什么是单元测试？

1.1  单元测试的定义

定义:

    单元测试是对软件基本组成单元进行的测试。

时机:

    一般在代码完成后由开发人员完成,QA人员辅助.

概念:

    模块, 组件, 单元　

              

1.2  为何要进行单元测试?

尽早发现错误

错误发现越早,成本越低.

开发人员过于自信,后期复杂

度高,发现解决BUG困难.

检查代码是否符合设计和规范
1.3  单元测试的背景

开发流程时间表与修改Bug代价的关系图如下：



编程过程中，每写100行代码会犯150个错误

编程与编译运行结束后，每100行代码中大约残留有1-3个Bug

寻找与修改程序错误的代价占总体开发投资的40%-80%

Bug在整个研发流程中被发现的越早，修改的代价就越低

2.单元测试的目标和任务

2.1   单元测试的目标

目标是单元模块被正确编码

信息能否正确地流入和流出单元；
在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。 
在为限制数据加工而设置的边界处，能否正确工作。
单元的运行能否做到满足特定的逻辑覆盖。 
单元中发生了错误，其中的出错处理措施是否有效

2.2  单元测试的任务

2.2.1    任务1：模块接口测试

检查模块接口是否正确，checklist:
 输入的实际参数与形式参数是否一致。

个数、属性、量纲
 调用其他模块的实际参数与被调模块的形参是否一致。

个数、属性、量纲
 全程变量的定义在各模块是否一致。
 外部输入、输出

文件、缓冲区、错误处理
 其它
2.2.2  任务2： 模块局部数据结构测试

检查局部数据结构完整性

Checklist:
 不适合或不相容的类型说明。
 变量无初值。
 变量初始化或默认值有错。
 不正确的变量名或从来未被使用过。
 出现上溢或下溢和地址异常。
 其它

2.2.3  任务3： 模块边界条件测试

检查临界数据处理的正确性

Checklist:
 普通合法数据的处理。
 普通非法数据的处理。
 边界值内合法边界数据的处理。
 边界值外非法边界数据的处理。
 其它

2.2.4  任务4： 模块独立执行通路测试

检查每一条独立执行路径的测试。保证每条语句被至少执行一次。

Checklist:
 算符优先级。
 混合类型运算。
 精度不够。
 表达式符号。
 循环条件，死循环。
 其它

2.2.5  任务5：模块的各条错误处理通路测试

预见、预设的各种出错处理是否正确有效。

Checklist:
 输出的出错信息难以理解。
 记录的错误与实际不相符。
 程序定义的出错处理前系统已介入。
 异常处理不当。
 未提供足够的定位出错的信息。
 其它

2.3  Microsoft对单元测试的理解

2.3.1  单元测试具体分类

验证产品实现符合功能规格书
验证产品代码运行的正确性
边缘条件测试
产品安全性测试
从已有Bug增加的回归测试
产品代码覆盖度测试(Code Coverage)
产品代码注射测试(Code Injection)
异常测试
产品速度性能的比较测试
产品极限情况测试
产品与国际标准的兼容性测试
产品与以前版本的操作系统，文件格式的兼容测试
同一产品不同版本共同运行的兼容性测试
产品在不同语言操作系统下的运行测试
2.3.2  单元测试具体流程

测试过程从产品设计开始

Spec Review 非常重要

微软产品Spec Review演示

Sharepoint Server的应用
测试代码编写由软件开发设计者(SDE)自己开始

DRT (Developer Regression Test)的重要性

没有相随的DRT， Feature Area不算开发完

DRT不全部编译并100%通过，不允许Check-in

测试组的测试不100%编译并100%通过0级测试(BVT), 70%通过1级测试，不允许Check-in

测试代码主体由软件测试工程师(SDET,STE)编写
测试从写软件测试规格书(Test Spec)开始
Test Spec必须通过PM，Dev与同组Tester共同开会研究通过
测试代码根据不同测试的情景分为0-4级的优先级
0级测试称为BVT (Build Verification Test)
在Dev主要的功能实现Check-in前,0-1级测试代码必须已由测试工程师完成
在Dev进行Check-in时，0级测试必须100%通过
在Dev进行Check-in时，1级测试必须至少有70%通过
Dev进行产品代码的Check-in
Test进行测试代码的Check-in
产品编译由Build团队每日进行
Test编译由测试团队在产品编译完成后进行
测试编译完成后，由测试自动化系统进行测试
在随后的代码优化与稳定期内，测试工程师编写2-4级测试代码，并报告产品Bug，Dev负责修改Bug，稳定并优化产品

3.静态测试技术的运用

3.1 静态测试技术的概念

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

三步曲：
 走查 （Walk Through）。
 审查 （Inspection）。
 评审 （Review）

3.2  编码的标准和规范

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

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

实施标准和规范的原因：
 可靠性。
 可读性和可维护性。
 可移植性。

3.3  走查 （Walk Through）

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

注意：
 引导小组成员在走查前通读设计和编码。
 限时，避免跑题。
 发现问题适当记录，避免现场修改。
 检查要点是代码是否符合标准和规范，是否有逻辑错误。

3.4 走查与审查的比较



3.5  评审 （Review）

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

注意：
 充分审查了所规定的代码，并且全部编码准则被遵守。
 审查中发现的错误已全部修改。

4.动态测试技术的运用

4.1  动态测试技术的概念

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

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

4.2  白盒测试方法

主要是逻辑驱动法和基本路径法。

  语句覆盖。

  判定覆盖。

  条件覆盖。

  判定/条件覆盖。

  条件组合覆盖。

  路径覆盖。

4.3  黑盒测试方法

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

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

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



4.4  黑盒常用方法

 等价类划分法                   

 边界值分析法                     三种数据：

 错误推测法                             -- 正常数据

 因果图法                                -- 错误数据

 功能图法                                -- 边缘数据

另外还得考虑接口测试、性能测试、内存测试

 性能分析

 内存分析

5.调试与评估

调试与测试的对象及采用的方法有很大程度上的相似，调试还用到断点控制等排错方法，但其目的却完全不同。测试是为了找出软件中存在的缺陷，而调试是为了解决存在的缺陷。 

 软件单元功能与设计需求一致。 
 软件单元接口与设计需求一致。 
 能够正确处理输入和运行中的错误。 
 在单元测试中发现的错误已经得到修改并且通过了测试。 
 达到了相关的覆盖率的要求。 
 完成软件单元测试报告 

6.单元测试的过程与文档管理

6.1 单元测试的过程

过程:
在详细设计阶段完成单元测试计划。 
建立单元测试环境，完成测试设计和开发。 
执行单元测试用例，并且详细记录测试结果。 
判定测试用例是否通过。 
提交《单元测试报告》。



6.2  单元测试的文档

《软件需求规格说明书》、《软件详细设计说明书》 ----> 《单元测试计划》 
《单元测试计划》、《软件详细设计说明书》 ----> 《单元测试用例》 
《单元测试用例》文档及《软件需求规格说明书》、《软件详细设计说明书》 --->
《缺陷跟踪报告》/《缺陷检查表》  
《单元测试用例》、《缺陷跟踪报告》、《缺陷检查表》 ---> 《单元测试检查表》 
评估---> 《单元测试报告》 

7. 单元测试常用工具简介

7.1  工具分类

 静态分析工具

 代码规范审核工具

 内存和资源检查工具

 测试数据生成工具

 测试框架工具

 测试结果比较工具

 测试度量工具

 测试文档生成和管理工具