软件测试金字塔,软件质量思考（一）测试金字塔

软件的质量该如何定义呢？衡量软件的质量可能有很多维度，我们这里不想那么学术。但你可以想象，糟糕的软件质量体现在哪里？从开发者的角度看，基本体现在两方面：

不好读懂

不好维护

当然，读懂是维护的前提，代码都看不懂，该怎么改呢？即便是读懂了，你就敢改吗？你怎么确认自己改得没问题呢？有没有引入新的bug呢？对！测试！

说起测试，你头脑中浮现的是什么画面呢？点开界面，点几下鼠标，确认结果是否复合预期。嗯，这个是手工测试。然而手工测试成本太高了。如果，软件不需要频繁改动，几次测试可能就够了。可惜，需求在变，不频繁改动并不现实。但若每次改动都手动回归，工作量是巨大的。

这时，我们想到自动测试。但怎么做自动测试呢？通过写脚本，模拟人工点击？这样的测试跟手工测试的覆盖面一致，都关注软件外在的表现行为，同属端到端测试，也叫验收测试。这个技术上是可以实现的，可惜成本几乎比手工测试有过之而无不及。为什么？因为UI是软件架构的最外层，改动的可能性最高。即便不考虑UI变动可能行，如果测试框架不能做到分辨率无关，也很难兼容不同的UI环境。

此时，我们可以向内推一层。如果架构分层够清晰的话，我们可以直接对接口进行测试。接口比UI稳定多了。如果接口是团队间协作的协议，并且接口由客户方定义，甚至给出测试用例，则被称为消费契约测试。然而，这是集成测试的一种，需要开启被依赖的服务才能进行测试，测试效率较低，成本仍然偏高。集成测试还有一个问题，整个调用链的各环节都有出错的可能，不利于定位问题。

终于，我们发现单元测试是最低成本的自动化测试。测试效率高，每个测试单元作用范围小，利于快速定位问题。至此，我们得到了整个测试金字塔，如下图：

测试金字塔.JPG

成本上，验收测试最高，单元测试最低。单元测试更靠近开发者，也是开发者的责任。所以，我们一定要做单元测试，其他层面的测试依资源情况取舍。