单元测试怎样提升质量海量资源.pdfVIP

本文由简悦SimpRead转码，原文地址

上一篇文章，我讲到了微服务架构下的测试策略和体系，今天我来讲讲测试策略中的最底层测

试——单元测试。

单元测试的价值

单元测试是一种白盒测试技术，通常由开发人员在编码阶段完成，目的是验证软件代码中的每个单元

（方法或类等）是否符合预期，即尽早在尽量小的范围内问题。

我们都知道，问题发现得越早，修复的代价越小。，在开发阶段进行正确的单元测试可以极大

地节省时间和金钱。如果跳过单元测试，会导致在后续更高级别的测试阶段产生更高的缺陷修复成本。

如图，假一个只包含两个单元A和B的程序，且只执行端到端测试，如果在测试过程中发现了缺

陷，则可能有如下多种：

该缺陷由单元A中的缺陷引起；

该缺陷由单元B中的缺陷引起；

该缺陷由单元A和单元B中的缺陷共同引起；

该缺陷由单元A和单元B之间接口的缺陷引起；

该缺陷是测试方法或测试用例的错误导致的。

由此可见，忽略单元测试会导致后续发现缺陷时，要花费较高的成本来确认缺陷。

单元测试除了能够在较早阶段识别软件中的错误，它还有如下价值。

反馈速度快：单元测试通常以自动化形式运行，执行速度非常快，可以快速反馈结果，跟持续集成

结合起来，形成有效的反馈环。

重构的有力保障：系统需要大规模重构时，单测可以确保对已有逻辑的兼容，如果单元测试都通

过，基本上可以保证重构没有破坏原来代码逻辑的正确性。

使更熟悉代码：写单元测试的过程本身就是一个审视代码的过程，可以发现一些设计上的问题（代

码设计的不可测试）、代码编写方面的问题（边界条件的处理不当）等。

既然单元测试由开发人员来设计和执行，那作为测试人员是不是就不需要学习这门技术了？不知道你是

怎样看待这个想法的，我的观点是：

单元测试只是通常情况下由开发人员完成，并不是，在一些公司或项目里也存在测试人员完

成的情况；

在你负责的模块或服务里，第一级别的测试不是你来完成的，那么你更有必要去了解它的设计思路

和执行情况，这能帮助你发现单元测试可能存在的问题点，也有利于你设计和执行后续高级别的测

试类型；

开发人员总是不太擅长做测试类的工作，当你掌握了单元测试的技能，你便更有机会去帮助和影响

到开发人员，赢得他对你的尊重，也有利于更好地合作；

这种想法是测试人员的常见想法，所以掌握单元测试技能在测试人员群体中也会是稀缺技能，因

此，掌握它将会获得额外的锻炼机会和个人，要知道，机会总是留给有准备的人。

微服务下的单元测试类型

就像之前课程所说：微服务中最大的复杂性不在于服务本身，而在于微服务之间的交互方式，服务与服

务之间常常互相调用以实现更复杂的功能。

举个例子，我们需要测试的是订单类（Order）中的获取总价方法（getTotalPrice()），而在该方法中除

了自有的一些代码逻辑外，通常需要去调用其他类的方法。比如这里调用的是用户类（User）的等

级方法（reductionLevel()）和商品类（Goods）中的商品价格方法（getUnitPrice()）。很显然，

等级方法或商品价格方法，只要一方有错误，就会导致订单类获取总价方法的测试失败。基于这种情

况，可以有两种单元测试类型。

1.社交型单元测试（SociableUnitTesting）

如图，测试订单类的获取总价方法（Order.getTotalPrice()）时会真实调用用户类的等级方法

（User.reductionLevel()）和商品类的商品单价方法（Goods.getUnitPrice()）。将被测试单元视为黑

盒子，直接对其进试，这种单元测试称之为社交型单元测试（SociableUnitTesting）。

2.孤立型单元测试（SolitaryUnitTesting）

如图，如果测试订单类的获取总价方法（Order.getTotalPrice()）时，使用