测试需要做单元测试吗？

昨天在技术交流群里，有同学说自己还想多学点技术，打算去做单元测试，写单测代码来提升技术，然后群里的同学就测试要不要做单元测试展开了很多讨论。

单元测试这方面我没有太多的实践经验，但工作过的几家公司在单元测试的上都有不同程度的落地实践。

这篇文章，我会基于自己的一些实践经验和经历，谈谈我对单元测试的理解和观点。

测试要做单元测试吗

首先聊聊第一个问题：测试要做单元测试吗？

我的回答：测试需要做单元测试，但要综合评估团队成员技能、个人意愿、项目迭代周期以及协作默契程度等很多因素，用合适的方法和手段在合适的时机切入，而不是一味强推。

很多测试同学往往有一个误区：只要是名字带个测试，就觉得我也要做这件事，而忽略了事物的本质。

比如验收测试，一般指的是 QA 同学经过多轮测试后，交付给产品同学来进行验收交付的产出物是否满足预期设计。

比如全链路压测，很多测试同学都希望自己能主导落地，但忽略了为什么做全链路压测，怎么做，落地有哪些难点，自己能否解决，需要哪些角色和团队配合。

单元测试(unit testing)，是指对软件中的最小可测试单元进行检查和验证，最初都是由开发来完成，即保障自己所在的环节交付的产出物满足进入下一阶段的标准。

所以关于测试是否要做单元测试这个问题，我的观点是测试需要介入这个环节，尽可能早的去测试验证发现问题，但并不表示测试需要在这个环节什么都自己来做。

单元测试落地的挑战

接下来聊第二个问题：单元测试落地要面临哪些挑战，或者说需要考虑哪些问题？

常见的落地挑战因素有下面几点：

1、开发不知道如何写单元测试

国内大部分公司缺乏单元测试环节，甚至 code review 都很缺乏，没有实践经验很难推动；

2、单元测试如何有效的进行检查

又回到了最初的问题：做了单元测试，如何有效检查单元测试的执行结果和效果表现呢？

3、如何评估和度量单元测试的质量

没有数据没办法衡量做单元测试的效果，度量的话从哪些维度和指标去评估单元测试的质量？

4、做单元测试对整个项目的交付周期是否有影响

现在的互联网行业大多迭代周期较快，做单元测试意味着需要投入一定时间，对 deadline 有一定影响；

5、开发个人的意愿（时间投入、个人技能、物质回报）

很简单的一个逻辑，谁愿意吃力不讨好做一件短期内没什么明显收益还没啥好处的事情？

单元测试如何有效落地

下面是我总结的过往工作经历中关于单元测试落地的一些方法，会从不同维度去实施，仅供参考。

管理

1. 提高研发对于质量保障的认可度，加强宣讲；

2. 优先选择有意愿和有精力的团队进行推广试点；

3. 自上而下推动，和 OKR 挂钩，并且是持续的挂钩；

4. 参与的同学在需求和工时评估方面需要做一定调整；

5. 新入职员工或新参与员工的单元测试工作由师兄负责引导实现；

协作

1. QA 和 DEV 针对单元测试 case 级别达成共识；

2. QA 和 DEV 在单元测试环节进行合作共建和职责边界划分；

3. QA 提供用例，DEV 进行实现；

4. QA 提供的用例需要经过评审并通过；

5. QA 进行 Check 和校验(度量维度和评估指标与开发达成一致)；

实施

1. 设定优先级，从 P0 核心模块开始实现；

2. 覆盖范围以 service 核心模块，新增功能优先；

3. 在 code review 阶段，对单元测试实现情况进行检查；

4. 需要通过实施前后不同维度的比较度量来评估能否带来收益；

5. 数据度量：覆盖率、通过率；

6. 发现 bug 数：线上问题、线下发现的 block bug；

7. 度量粒度：小到最底层函数级别，大到代码类方法；

8. 测试用例：单元测试的实现和度量，一定是 case by case 的；

最后总结一下，为了进一步提高最终的交付质量，尽可能早的接入并发现软件系统存在的问题，测试需要做单元测试，但要综合评估团队成员技能、个人意愿、项目迭代周期以及协作默契程度等很多因素，用合适的方法和手段在合适的时机切入，而不是一味强推。