单元测试解析「单元测试解析」

一、我们存在的误区1、单元测试是一种浪费时间的工作2、单元测试只能证明代码做了什么3、我是个很棒的程序员， 我是不是可以不进行单元测试？4、集成测试能捕捉到所有的Bug5、单元测试的成本效率不高6、单元阶段不需要测试人员介入，是开发人员的事情7、没有专门的测试团队

二、单元测试概述单元测试是在软件开发过程中要进行的最低级别的测试活动，或者说是针对软件设计的最小单位——程序模块，进行正确性检验的测试工作。其目的在于 发现每个程序模块内部可能存在的差错。1.单元测试通常是一段可执行代码，并能验证执行结构是否和预期相等2.每个单元测试至少应该有两个测试例子( TestCase ):Negative/Positive3.单元测试可以是黑盒也可以是白盒，取决于执行方法

三、单元测试的目的单元测试目的主要有以下几点：（1）检查单元模块内部的错误，为软件的评审验收提供依据。（2）单元测试是以程序设计说明书和之前所作的测试数据（正常的和错误的）为指导，测试模块内重要的路径，以检查出错误；（3）检验信息能否正确地流入和流出单元；（4）在单元测试工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。（5）在为限制数据加工而设置的边界处，能否正确工作。（6）单元的运行能否做到满足特定的逻辑覆盖。（7）单元中发生了错误，其中的出错处理措施是否有效。

四、单元测试的优点1.由于单元测试是在编码过程中进行的，若发现了一个错误，不管是从做回归测试的角度，还是对错误原因理解的深刻性的角度，修复错误的成本远 小于集成测试阶段，更是小于系统测试阶段。2.在编码的过程中考虑单元测试问题，有助于编程人员养成良好的编程习惯，提高源代码质量。

单元测试主要采用白盒测试方法，辅以黑盒测试方法。白盒测试方法应用于代码评审、单元程序检验之中， 而黑盒测试方法则应用于模块、组件等软件的功能测试之中 。在进行单元测试常用的测试策略为：1.桩模块测试2.驱动模块测试3.自顶向下单元测试策略4.自底向上的单元测试策略5.孤立测试

一、驱动模块驱动模块(Drive) 用来模拟被测试模块的上一级模块，相当于被测模块的主程序。它接收数据，将相关数据传送给被测模块，启动被测模块，并打印出相应的结果。

二、桩模块桩模块(Stub) 用来模拟被测模块工作过程中所调用的模块。它们一般只进行很少的数据处理。示例：

三、自顶向下单元测试策略步骤：1. 从最顶层开始，把顶层调用的单元做成桩模块。2. 对第二层测试，使用上面已测试的单元做驱动模块。3. 依次类推，直到全部单元测试结束。

优点：可以在集成测试之前为系统提供早期的集成途径。

缺点：1. 单元测试被桩模块控制，随着单元测试的不断进行，测试过程也会变得越来越复杂，测试难度以及开发和维护的成本都不断增加；2. 要求的低层次的结构覆盖率也难以得到保证；3. 由于需求变更或其他原因而必须更改任何一个单元时，就必须重新测试该单元下层调用的所有单元；4. 低层单元测试依赖顶层测试，无法进行并行测试，使测试进度受到不同程度的影响，延长测试周期。

总结：从上述分析中，不难看出该测试策略的成本要高于孤立的单元测试成本，因此从测试成本方面来考虑，并不是最佳的单元测试策略。

四、自底向上单元测试策略步骤：1. 先对模块调用图上的最底层模块开始测试，模拟调用该模块的模块为驱动模块。2. 其次，对上一层模块进行单元测试，用已经被测试过的模块做桩模块。3. 依次类推，直到全部单元测试结束。4.优点：不需要单独设计桩模块。

缺点：1. 随着单元测试的不断进行，测试过程会变得越来越复杂，测试周期延长，测试和维护的成本增加；2. 随着各个基本单元逐步加入，系统会变得异常庞大，因此测试人员不容易控制；3. 越接近顶层的模块的测试其结构覆盖率就越难以保证；

另外，顶层测试易受底层模块变更的影响，任何一个模块修改之后，直接或间接调用该模块的所有单元都要重新测试。由于只有在底层单元测试完毕之后才能够进行顶层单元的测试，所以并行性不好。自底向上的单元测试也不能和详细设计、编码同步进行。

总结：相对其它测试策略而言，该测试策略比较合理,尤其是需要考虑对象或复用时。它属于面向功能的测试，而非面向结构的测试。对那些以高覆盖率为目标或者软件开发时间紧张的软件项目来说，这种测试方法不适用。

五、孤立测试步骤：无需考虑每个模块与其他模块之间的关系，分别为每个模块单独设计桩模块和驱动模块，逐一完成所有单元模块的测试。

优点：该方法简单、容易操作，因此所需测试时间短，能够达到高覆盖率。

缺点：1. 不能为集成测试提供早期的集成途径。2. 依赖结构设计信息，需要设计多个桩模块和驱动模块，增加了额外的测试成本。

总结：该方法是比较理想的单元测试方法。如辅助适当的集成测试策略， 有利于缩短项目的开发时间。

单元测试流程：

1.单元测试计划阶段（1）确定测试用例应覆盖的范围和程度（2）确定测试终止的要求（3）确定用于测试的资源要求（4）确定需要的技术和方法（5）确定单元测试活动的进度（6）对单元测试计划进行评审

2.单元测试设计阶段（1）测试用例的设计编码、驱动程序和桩程序的设计及代码编制（2）获取测试数据（3）确定测试顺序（4）获取测试资源（6）建立和校准测试环境（7）编写软件单元测试文档（8）应该对单元测试用例进行评审

3.单元测试执行阶段（1）执行单元测试用例（2）对测试过程中发现的缺陷进行记录

4.单元测试评阶段（1）测试完备性评估（2）代码覆盖率评估

5.单元测试总结阶段对单元测试的结果进行评估，根据测试计划、测试记录和软件问题报告对测试工作进行总结。

原则如下：① 应当今早和不断地进行软件测试② 对全新的代码或修改过的代码一定进行单元测试③ 被测试的对象为实现一组相关功能的代码④ 单元测试最好根据单元测试计划和方案进行，排除测试的随意性⑤ 当测试用例的测试结果与预期结果不一致时，单元测试的执行人员需如实记录实际的测试结果⑥ 当单元测试计划中的结束标准达到时，单元测试结束⑦ 项目管理者保证测试用例经过审核⑧ 当程序进行了修改，测试执行人员执行回归测试以保证对发现错误的修改没有引入新的错误

没时间做单元测试对策：① 单元测试计划在项目计划中应有体现② 编写代码之前或同时，先设计测试用例，每个软件单元应该有什么功能？是否每个功能都有测试用例来验证它。

单元测试责任人不清楚对策：① 强调单元测试必须由类包的设计者负责编写，因为只有这样，测试才能保证对象的运行时态行为符合需求。② 让测试人员或第三方人员编写测试用例，讲话费风多的工作量③ 执行测试用例可以让测试人员或自动构造系统。

测试代码难以管理对策：① 采用测试工具管理代码，如：Xunit、C Test等② 使用配置管理工具管理代码，如：SVN

覆盖率难以手工统计对策 :利用各种工具C Test（C/C ， Windows /UNIX）RTRT（ C/C /JAVA,嵌入式系统）Discover（Delphi，Windows）

故障报告形式对策：各种工具一般都会生成测试报告Xunit 生成测试用例执行报告RTRT C test生成各种综合报告（测试用例执行结果、测试用例覆盖率内存检查和性能）

驱动和桩编写困难对策：① 通常情况下，测试驱动难以编写，测试难以进行由以下几个方面原因导致：② 被测试对象需要传入的参数过多③ 内部的逻辑判断过多（内部牵扯复杂）④ 和界面显示不得你交互过于频繁（耦合性太强）⑤ 被测试对象过度的调用了其他类和方法⑥ 需要构造的作为参数的对象本身过于复杂

Junit底层设计框架：

JUnit几个核心类及接口：

Assert 超类所提供的8个核心方法：

Junit测试框架的四要素：

1.测试Fixtures是一组认定被测对象或被测程序单元测试成功的预定条件或预期结果的设定。Fixture就是被测试的目标，可能是一个对象或一组相关的对象，甚至是一个函数。测试人员在测试前就应该清楚对被测对象进行测试的正确结果是什么，这样就可以对测试结果有一个明确的判断。

2.测试集测试集就是一组测试用例，这些测试用例要求有相同的测试Fixture，以保证这些测试不会出现管理上的混乱。

3.测试执行单个单元测试的执行可以按下面的方式进行：setUp();/首先，我们要建立针对被测程序单元的独立测试环境/……/然后，编写所有测试用例的测试体或测试程序/……tearDown();/最后，无论测试成功还是失败，都将环境进行清理，以免影响后继的测试/

4.断言断言实际上就是验证被测程序在测试中的行为或状态的一个宏或函数。断言失败实际上就是引发异常，终止测试的执行。

示例：在Eclipse中使用JUnit4进行单元测试

第一步：导入被测的JAVA项目

第二步：生成测试框架

第三步：编写测试用例

第四步：执行测试

————————————————版权声明：本文为CSDN博主「zljain」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/zljain/article/details/81482193