设计篇——单元测试设计及自动化测试_单元测试 设计

单元测试（Unit Testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如 C 语言中单元指一个函数，Java 里单元指一个类，图形化的软件或 Web 页面中可以指一个窗口、一个菜单或一个功能区等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，将软件的独立单元在与程序的其他部分相隔离的情况下进行测试。

在一种传统的结构化编程语言中，比如 C，要进行测试的单元一般是函数或子过程。在像 Java 这样的面向对象的语言中，要进行测试的基本单元是类。对 Ada 语言来说，开发人员可以选择是在独立的过程和函数，还是在 Ada 包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言（4GL)的开发中，基本单元被典型地划分为一个菜单或显示界面。

经验表明一个尽责的单元测试方法将会在软件开发的某个阶段发现很多的 Bug，并且修改它们的成本也很低。在软件开发的后期阶段，Bug 的发现并修改将会变得更加困难，并要消耗大量的时间和开发费用。无论什么时候做出修改都要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。在提供了经过测试的单元的情况下，系统集成过程将会大大地简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上，而不是陷入充满很多 Bug 的单元之中不能自拔。

单元测试也是一种开发设计方式，开发软件相关类之前，应该先有测试的思想，评估要设计的类是否对业务实现提供价值。设计的类应该清晰明确，其他团队成员容易理解。同接口测试一样，应该举例说明设计的类的行为方式，也就是会在什么情况下使用该类。单元测试就是按照使用举例一一验证类的行为是否正确。

总体来说单元测试有以下好处：

1. 带来比功能测试更广的测试覆盖率。 功能测试对软件代码的覆盖率一般为70%左右，而单元测试可以轻易做到对程序代码更高的测试覆盖率。

2. 提高团队工作效率。 单元测试可以让软件开发人员不必等被调用的软件功能模块就绪就可以开展测试，可以更快的完成软件模块的编程开发和测试工作。

3. 监测衰退和减少调试。 成功通过单元测试可以确认软件开发人员编写的代码可以正常运行，同时如果需要修改现有代码，也给予修改现有代码的信心，使得新增特性，或修改现有特性变得更容易。单元测试不通过时可以让软件开发人员更容易定位错误位置和更容易查找错误原因。

4. 自信地重构。 单元测试提供了一个安全网，可以及时发现重构过程中带来的问题，并及时改正，为软件开发人员提供重构的信心。

5. 将预期的行为文档化。 单元测试代码是目标程序代码的使用示例，它展示了如何使用程序代码。单元测试代码与目标程序代码保持同步，它可以算是最新的目标代码使用说明文档。

6. 方便的代码覆盖率和其它指标收集方式。 单元测试工具可以很容易的获得单元测试过程中执行了哪些目标程序的代码和哪些目标程序代码没有被执行过。从而给出目标程序代码的测试覆盖率。

单元测试从被测试目标的粒度的大小来分可以分为逻辑单元测试、集成单元测试和功能单元测试。对它们的介绍如下（图1显示了单元测试种类）。

逻辑单元测试：这种单元测试主要针对一个单独的方法来检查代码。可以通过 Mock Objects 或 Stub 来控制测试方法的便捷。 集成单元测试：这种单元测试主要用来测试在真实环境中（或真实环境的一部分）不同组件之间的相互作用。例如，测试一段访问 MySQL 数据库的代码是否真实有效的调用了数据库。 功能单元测试：这种单元测试比集成单元测试的范围更大，主要是用来测试一个功能模块的交互响应是否正确。例如，向一个需要授权的 HTTP 地址发送一个未经授权的 HTTP 请求，验证是否能够收到未经授权的 HTTP 状态码。

图1 单元测试类型

 

单元测试设计常用方法包括白盒测试和黑盒测试：

1. 白盒测试。单元测试的案例编写人员根据对程序实现细节的理解编写测试用例和测试代码脚本。常用设计方法如下：

   • 语句覆盖：每条语句至少执行一次。
   • 判定覆盖：每个判定的每个分支至少执行一次。
   • 条件覆盖：每个判定的每个条件应取到各种可能的值。

2. 黑盒测试。不知道系统内部的状态和行为，仅通过系统外部接口来验证系统的正确性。常用设计方法有如下：

   • 等价类划分法：等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。

• 边界值分析法：边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。
• 错误推测法：错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
• 因果图法：考虑多种条件的组合，相应产生多个动作的形式来设计测试用例

因为白盒测试和黑盒测试各有优缺点，在设计单元测试用例时一般建议组合使用，根据具体被测程序代码选择适合的测试设计方法。

叨咕了一堆单元概念后，下面是我们在敏捷项目中的单元测试设计方法，我们采用从外到里（Outside-in code）的分析方法，来梳理设计单元测试用例。具体步骤如下：

1. 从验收性测试的角度分析产品功能的用户使用场景和检查点。
2. 把用户使用场景和检查点拆分成更细的用户使用步骤。
3. 把用户使用步骤对应的功能点和实现代码进行关联分析。
4. 以实现代码对外提供的功能为出发点设计单元测试场景用例。

以新会员注册为例，对从外到里（Outside-in code）的分析方法进行具体说明。

1.从用户故事的验收测试场景开始分析。

场景: 新会员注册后初始状态为铜牌会员。

假设: 小明童鞋还不是一位常旅客会员。

当: 小明童鞋注册常旅客会员。

那么: 注册成功后，小明童鞋的初始会员级别为铜牌会员。

2.实现验收测试的自动化测试步骤。

图2 验收测试步骤

 

3.从验收测试步骤延伸到底层相对应的单元测试。

图3 验收测试分析单元测试

 

4.从单元测试检查点分析待实现功能类的设计和编码。

设计和编码

 

从用户故事向验收测试再向接口测试、单元测试分析的好处是：

• 从用户故事、用户场景分析到产品设计和编码，以及验收测试、接口测试和单元测试都关注产品的价值。因为这种从外到里（Outside-in)，从业务目标到技术设计的编码测试方法原始出发点是从带有预期产出结果的业务场景描述开始的，因此后面进行的任何编码和测试工作都有业务价值和它们对应。验收场景可以帮助程序员和测试人员把精力放在所要达到的目标和价值上。

• 更有利于良好的产出产品设计和易读的程序编码。这种从外到里（Outside-in)，从业务目标到技术设计的编码测试方式，让开发和测试人员提前考虑将实现的一个 Java 类的方法将在什么场景下调用，谁会调用，这种思路会使初始程序员设计出更整洁、高效的应用程序代码。

• 从开始就避免浪费，提高程序员的工作价值和效率 这种从外到里（Outside-in)，从业务目标到技术设计的编码测试方式，使得程序员和测试人员关注在验收测试条件通过，在避免遗漏编码或遗漏测试的同时，可以减少多余的编码和测试，从而提高程序员和测试人员工作的价值和效率。

时牧敏捷社区