【软件测试】单元测试

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 单元测试的过程

过程:

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

6.2  单元测试的文档

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

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

7.1  工具分类

 静态分析工具
 代码规范审核工具
 内存和资源检查工具
 测试数据生成工具
 测试框架工具
 测试结果比较工具
 测试度量工具
 测试文档生成和管理工具