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

测试要做单元测试吗

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

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

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

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

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

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

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

单元测试落地的挑战

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

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

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

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

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

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

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

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

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

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

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

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

单元测试如何有效落地

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

管理

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

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

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

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

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

协作

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

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

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

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

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

实施

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

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

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

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

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

• 发现bug数：线上问题、线下发现的blockbug；

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

• 测试用例：单元测试的实现和度量，一定是casebycase的；

最后总结一下，为了进一步提高最终的交付质量，尽可能早的接入并发现软件系统存在的问题，测试需要做单元测试，

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

作者：老_张

原文链接：https://www.cnblogs.com/imyalost/p/16387477.html