登陆

小安说测试┃为什么好多程序员不愿意做单元测试？

来源：上海控安

2021-03-09

3009

在讲解单元测试的难点之前，我们先来了解一下软件开发与测试的基本模型有哪些：

（1）V模型 —— 软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系。

（2）W模型——基于“尽早地和不断地进行软件测试”的原则，增加了软件各开发阶段中应同步进行的验证（verification）和确认（validation）活动。

（3）H模型——它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

以上三种模型对应着不同的开发规模，但可以从图中明确的是，单元测试处于软件测试的第一步。

开发能力相近的两个团队，同时开发相近的需求。进行单元测试团队在编码阶段时长增长了一倍，从7天到14天，但是，这个团队在集成测试阶段的表现非常顺畅，bug量小，定位bug迅速等。最终的效果、整体的交付速度及缺陷数量等综合来看，均是单元测试团队表现更佳。

下面这张图，来自微软的统计数据：bug在单元测试阶段被发现，平均耗时3.25小时，如果漏到系统测试阶段，想要发现这个bug需要花费11.5小时。

下面这张图，旨在说明两个问题：一是85%的缺陷都在代码设计阶段产生；二是发现bug的阶段越靠后，耗费成本就越高，呈指数级别的增长。所以，在早期的单元测试就能发现bug，省时省力，一劳永逸，何乐而不为呢。

但就算如此，为什么很多程序员乃至企业都会忽视单元测试呢？

那就要看做单元测试时所会面临的难点了：

1. 受人手数量制约

单元测试多采用白盒测试技术，要满足代码覆盖率、路径覆盖率等的要求，所需的人力成本非常高昂。一个4000多行的嵌入式软件，仅进行代码走查就需要1~2个人月,并且覆盖率难以手工统计；如果再加上测试用例设计、测试代码（如桩模块）的编写，工作量还要多出几倍。

2. 工具成本高

人力成本能否通过工具的使用减轻呢？答案是肯定的，但是由于驱动和桩编写困难，随之而来的是工具成本的上升。

3. 缺乏单元测试意识 & 实践经验

尽管单元测试很重要，但国内还是很少有程序员能够比较认真的去编写单元测试。他们普遍没有质量意识和单元测试意识、没有测试习惯、公司没有要求，以及为了赶项目进度，都是导致国内程序员不重视单元测试的原因。从公司和项目管理者角度来说，还没有意识到单元测试带来的好处和产出；从开发人员角度，也认为单元测试是对自己的代码质量没有提高的浪费时间的行为。

4. 框架对单元测试不友好

对于已经发展庞大但缺失单元测试的项目，由于代码不符合单测工具所约定的规范，再去补充单元测试很难，需要对项目进行拆分及规范化，反而是增加了工作量。

5. 业务繁重

一般来说软件开发任务繁重，时间短，不会把软件的单元测试作为一个独立的工序纳入到工作范畴。

单元测试任务太重？效率太低？

工业嵌入式系统单元测试工具

由上海控安自主研发的SmartRocket Unit作为一款单元测试工具，可以自动生成满足语句、分支、MC/DC准则的测试用例，自动执行测试驱动。通过使用SmartRocket Unit，用户可快速对安全攸关的代码进行单元级别的白盒测试和回归测试，从而进一步提升单元测试的效率。