聊聊测试

为保证业务的质量和稳定性，一般会进行诸多测试，测试有很多类型，大致可以归类为：

• 验证是否实现了功能（验收测试）
• 验证是否正确实现了功能（单元测试）
• 对产品可用性做测试，如响应时间、性能、安全等（非功能性测试）

我们平时会写两类代码，一种是基础类代码，一种是业务类代码，前者更多的是面向团队，后者更多的是面向产品。

面向产品的代码主要是业务逻辑，大多数情况会在验收环节进行验证，这一环可以通过自动化+人工测试保障，实际情况更多还是人工测试，编写 UI 测试用例的成本是极高的，而且在业务迭代快的情况下，根本来不及写测试用例，还不如人工回归；而面向团队的代码通用性较强，功能模块的隔离性做的也比较好，就需要比较多的单元测试来保障了。

除了验收测试和单元测试，还有一类是面向产品体验的非功能性测试，如性能、响应时间、安全等，这类测试在 2C 的产品中要求得比较多，一般会通过 工具 来保障，如页面上线时进行真机测试、渗透测试和压力测试等。

非功能性测试往往会有一个很麻烦的问题：非功能性问题多样性强、差异化大，测试平台难以良好的满足平台用户的测试诉求。一般而言，测试平台需要平台方与开发者共建，平台提供机制，开发者贡献规则和套件。

测试的覆盖范围

从测试的覆盖范围来看，可以将测试分为三类：

• 函数块的功能测试，不会启动服务（单元测试）
• 绕开用户界面，直接对服务调用测试（服务测试）
• 打开用户界面进行测试（端对端测试）

单元测试覆盖的只是一个小的代码片段；服务测试则可能会依赖一连串的代码，甚至会依赖其他系统的服务；端对端的测试，通过时会让人十分放心，因为这类测试会覆盖大量的系统代码。

在合作的时候，会发现一个十分有意思的现象，很多开发者不愿意写单元测试，几乎每次发布之前，都是将代码提交到预发布环境，让前置依赖方通过端对端测试或者服务测试来验证服务的准确性和稳定性。这带来的问题是什么呢？

• 端对端测试容易忽略细节，一旦测试用例不够全面，系统的安全和稳定性将会有很大的挑战；
• 端对端测试周期和反馈周期都特别漫长，一次测试需要经过多层系统或者多次函数调用才能触发问题；
• 端上的很多操作会触发很多重复的底层代码测试，影响测试效率；
• 由于环境的限制，少部分的端对端测试无法进行等；

问题还有很多，就不一一列举了。如果你的服务会被多个系统调用，或者会被大量的用户使用，我建议你多写测试用例，不要总是依托于上游调用方给你反馈异常，尤其是作为基础服务的时候。