软件测试基础理论体系学习4-单元测试的目的？概念是什么？过程是什么？

1 单元测试目的

可以说进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。

1.1 单元测试的错误认识

• 它太浪费时间了，现在要赶进度，时间上根本不允许，或者随便做做应付领导。
• 我是一个很棒的程序员，我写的代码肯定是没有问题的。
• 做单元测试太烦了，直接集成，到时有问题在集成测试时肯定能发现的，实在不行在系统测试总该能发现吧。
• 它仅仅是证明这些代码做了什么。

对于以上错误认识的产生归根结底还是由于对单元测试的理解还是不够，没有真正认识到单元测试的重要性。

1.2 单元测试的重要性

• 单元测试是软件测试的基础，单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。

单元测试的主要目的是验证你的应用程序能够很好的工作，以及尽早的发现错误。它不仅能够简单的验证应用程序能正常工作，它还具有如下意义：

1.2.1 时间方面

• 做好单元测试，在系统集成联调时非常顺利；
• 反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题；
• 而这种问题在集成时遇到往往很难让开发人员预料到，最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间，这种时间上的浪费一点都不值得，正所谓得不偿失。

1.2.2 测试效果

• 它是测试阶段的基础，做好了单元测试，在做后期的集成测试和系统测试时就很顺利。
• 在单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发现而在集成测试和系统测试很难发现的问题。
• 单元测试关注的范围也特殊，它不仅仅是证明这些代码做了什么，最重要的是代码是如何做的，是否做了它该做的事情而没有做不该做的事情。

1.2.3 测试成本

• 在单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所花的成本将成倍数上升。
• 比如在单元测试时发现1个问题需要1个小时，则在集成测试时发现该问题需要2个小时，在系统测试时发现则需要3个小时，同理还有定位问题和解决问题的费用也是成倍数上升的，这就是我们要尽可能早的排除尽可能多的bug来减少后期成本的因素之一。

1.2.4 产品质量

单元测试的好与坏直接影响到产品的质量，可能就是由于代码中的某一个小错误就导致了整个产品的质量降低一个指标，或者导致更严重的后果，如果我们做好了单元测试这种情况是可以完全避免的。

1.3 单元测试的优点

1.3.1 它是一种验证行为

• 程序中的每一项功能都是测试来验证它的正确性，为以后的开发提供支缓。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。
• 而且它为代码的重构提供了保障，这样，我们就可以更自由的对程序进行改进。

1.3.2 它是一种设计行为

• 编写单元测试将使我们从调用者观察、思考，特别是先写测试（test-first），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。
• 另外还可以使编码人员在编码时产生预测试，将程序的缺陷降低到最小。

1.3.3 它是一种编写文档的行为

单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。

1.3.4 它具有回归性

自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测试。

2 单元测试的概念

• 单元测试时一种细粒度的测试。又称模块测试，属于白盒测试，是最小单位的测试。模块分为程序模块和功能模块。
• 功能模块指实现了一个完整功能的模块（单元），一个完整的程序单元具备输入、加工和输出三个环节。
• 而且每个程序单元都应该有正规的规格说明，使之对其输入、加工和输出的关系做出名明确的描述。

2.1 测试的内容

• 单元测试的对象是软件设计的最小单位——模块或函数，
• 单元测试的依据是详细设描述。
• 测试者要根据详细设计说明书和源程序清单，了解模块的I/O条件和模块的逻辑结构。
• 主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理和不合理的输入都能鉴别和响应。
• 要求对所有的局部和全局的数据结构、外部接口和程序代码的关键部分进行桌面检查和代码审查。
• 在单元测试中，需要对下面5个方面的内容进行测试，也是构造测试用例的基础。
  

2.1.1 模块接口

对于模块接口需要如下的测试项目：

• 调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；
• 所测模块调用子模块时，它输入个子模块的参数与子模块的形式参数在个数、属性、顺序上是否匹配；
• 是否修改了只做输入用的形式参数；
• 输出给标准函数的参数在个数、属性、顺序上是否匹配；
• 全局变量的定义在各模块中是否一致；
• 限制是否通过形式参数来传送。

2.1.2 局部数据结构测试

设计测试用例以检查以下各种错误：

• 检查不正确或不一致的数据类型说明；
• 使用尚未赋值或尚未初始化的变量；
• 错误的初始值或错误的默认值；
• 变量名拼写错误或书写错误；
• 不一致的数据类型。

2.1.3 路径测试

对基本执行路径和循环进行测试会发现大量的错误。根据白盒测试和黑盒测试用例设计方法设计测试用例。设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。

常见的不正确的计算有：

• 运算的优先次序不正确或误解了运算的优先次序；
• 运算的方式错误（运算的对象彼此在类型上不相容）；
• 算法错误；
• 初始化不正确；
• 运算精度不够；
• 表达式的符号表示不正确等。

2.1.4 常见的比较和控制流错误有

• 不同数据类型的比较；
• 不正确的逻辑运算符或优先次序；
• 因浮点运算精度问题而造成的两值比较不等；
• 关系表达式中不正确的变量和比较符；
• “差1错”，即不正确地多循环或少循环一次；
• 错误的或不可能的循环终止条件；
• 当遇到发散的迭代时不能终止循环；
• 不适当地修改了循环变量等。

2.1.5 错误处理测试

比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理对策，以便在程序出错时，能对出错程序重新做安排，保证其逻辑上的正确性。这种出错处理也是模块功能的一部分。

表明出错处理模块有错误或缺陷的情况有：

• 出错的描述难以理解；
• 出错的描述不足以对错误定位和确定出错的原因；
• 显示的错误与实际的错误不符；
• 对错误条件的处理不正确；
• 在对错误进行处理之前，错误条件已经引起系统的干预；
• 如果出错情况不予考虑，那么检查恢复正常后模块可否正常工作。

2.1.6 边界测试

设计测试用例检查：

• 在n次循环的第0次、1次、n次是否有错误；
• 运算或判断中取最大最小值时是否有错误；
• 数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误。

2.2 单元测试的环境构成

单元测试在编码阶段进行。在源程序代码编制完成、经过评审和验证、确认没有语法错误之后，就可以开始进行单元测试的测试用例设计。要利用软件设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。

对于每一组输入，应该有预期的正确结果。在单元测试时，如果模块不是独立的程序，需要辅助测试模块，有两种辅助模块：

• 驱动模块（Driver）：所测模块的主程序。它接收测试数据，把这些数据传递给所测试模块，最后再输出测试结果。当被测试模块能完成一定功能时，也可以不要驱动模块。
• 桩模块（Stub）：用来代替所测模块调用的子模块。
  被测试模块、驱动模块和桩模块共同构成了一个测试环境，如图3-1所示：
  

2.3 主要单元测试方法

单元测试的基本方法有：人工静态分析、自动静态分析、自动动态测试，人工动态测试。

2.3.1 人工静态分析

通过人工阅读代码来查找错误，一般是程序员交叉查看对方的代码，可能发现有特征错误和无特征错误。

2.3.2 自动静态分析

使用工具扫描代码，根据某些预先设定的错误特征，发现并报告代码中的可能错误，自动静态分析只能发现语法特征错误。

2.3.3 自动动态测试

使用工具自动生成测试用例并执行被测试程序，通过捕捉某些行为特征（如产生异常/程序崩溃等）来发现并报告错误，自动动态测试只能发现行为特征错误，对无特征错误完全无能为力。

例如，前面所说的加法函数，代码可以说是最简单的，错误也是最简单的，但是自动动态测试仍然无法发现，因为测试工具不可能自动了解代码的功能。

2.3.4 人工动态测试

人工设定程序的输入和预期的正确输出，执行程序，并判断实际输出是否符合预期，如果不符合预期，自动报告错误。

3 单元测试过程

3.1 角色的作用

3.1.1 系统分析设计人员

进行需求跟踪，确保系统需求的实现和更新。进行软件单元可测性分析，确定单元测试的对象、范围和方法。

3.1.2 软件开发人员

负责编码和单元测试过程，完成单元测试计划、方案和报告。

3.1.3 软件测试人员

参与单元测试计划、方案和报告的评审，对单元测试的计划、设计和执行质量进行监控。根据实际情况，可选择参与由开发人员负责的代码检视、单元测试等活动。

3.1.4 配置管理人员

对代码及单元测试文档进行配置管理。

3.1.5 质量保证（QA）人员

参与编码与单元测试评审，对编码和单元测试过程进行审计。

3.2 单元测试输入

《软件需求规格说明书》
《软件详细设计说明书》
《软件编码与单元测试工作任务书》
《软件集成测试计划》
《软件集成测试方案》
用户文档

3.3 单元测试的输出

• 《单元测试计划》
• 《单元测试方案》
• 《需求跟踪说明书》或需求跟踪记录
• 代码静态检查记录
• 《正规检视报告》
• 问题记录
• 问题跟踪和解决记录
• 软件代码开发版本
• 《单元测试报告》
• 《软件编码与单元测试任务总结报告》

---

【特别说明】：知识来源于网络、各种资料、书本、网站等，本文仅用于学习使用，不做他用，如果涉及版权问题，请联系博主删除，谢谢