今天的话题，从一个真实的故事说起。某年某月某日，笔者带团队去某 BU 做实施调研时，对方的产品经理提出了一个需求，他说：我们的团队目前没有专职的测试人员，希望借助平台的 UI 自动化能力，让业务人员也拥有测试的能力，能够参与到自动化测试当中去。然后就提出了一些 “需求”：希望能够在页面上录入数据，能够自动验证数据是否正确，能够简单地维护页面元素就好，能够自动判断业务是否展示正常，能够......。你猜最后的结果是什么呢？嗯，什么也做不了。UI 自动化又不是全能的，对吧。你以为我是要吐槽这位产品经理么？其实，不是的。

01 关于测试分层

为什么我不吐槽那位产品经理呢？实际上，很多测试人员也没搞清楚在 UI 测试层我们应该做些什么。如上图，对于左边的测试金字塔，我相信很多测试人员都很清楚，也很向往自己的团队真的能够做到。但是呢，对于每一层的目标是否清楚？我见过很多人，在单接口测试时，断言做得很简单，而在多接口的场景测试中，加入了大量的非业务断言。在 UI 自动化中，去做很多数据校验，导致代码臃肿，变得难以维护。如上述两种情况，怎么能算是做好 “分层” 呢？所以应该对齐下右边的目标是什么。
单元测试：在笔者接触的团队中，做好单元测试的人非常少，所以这方面的实践也比较少。简单而言，对于单元测试，其实和业务的关联性并不太大。在这一层，主要验证的是代码的逻辑是否存在问题，关注语句覆盖、判定覆盖、条件覆盖、路径覆盖等内容。（如有不对，请指教，这方面确实经验少。）

接口测试：接口测试主要分两类：单接口测试及多接口场景测试。
先说第一种，对于单接口的验证，主要集中在接口的返回结构是否与文档定义是否相一致，是否能满足业务需求。同时也关注异常入参、非法入参时，接口是否能正常捕获异常，返回业务可接受的信息（直接抛出代码异常非常不可取，用户体验极差，还有安全风险）。最多，再校验下数据是否正确（理论上数据返回的正确与否应该在数据层做验证，考虑到实际情况，可以放到单接口用例中去做验证）。

再说说第二种：多接口场景测试，在这类测试中，我们应该更关注于接口间的数据传递、数据状态是否正常，数据流转是否正常。断言应该更集中于那些和业务形态相关的字段上，而不是过多地去校验一些没有变化的数据。为什么呢？因为数据结构等问题应该在单接口中被验证，而不是耦合到这里来。
这样做的好处是，当接口发生变更后，我们只需要更新单接口的用例即可，如果影响到接口间的调用，再更新场景接口即可，（通常接口的变更不应该影响到已有业务的调用。即使有影响到，我们也能够快速分析出来，而不是混合在一起，不知道是哪里出了问题）脚本的可维护性会大大的增强。

UI 测试：等到了 UI 层，我们已经不再需要关注业务数据的正确性了，因为在接口层已经做了保证，如果发现问题，应该去补充接口用例，而不是在 UI 层去校验这些内容。在 UI 层，我们应该关注的是页面元素是否正常展示，按钮是否可用，交互是否能够正常跳转等体验性的问题。

02 做好专项测试

在梳理清楚了分层测试的基本思路后，我们再来聊聊专项测试，专项测试一般是指基于某些特别明确的目标而进行的测试。从这个角度上讲，接口和 UI 也算是专项测试，一些常见的专项测试还包含：性能测试、安全测试、弱网测试、兼容性测试、健壮性测试等等。

接口专项测试：接口测试是测试人员接触、练习代码能力很好的一个入口。关于接口测试，可以参考笔者之前的文章（接口测试平台演进思考、你写的接口脚本合理么）。这里再说一点。接口测试是练习代码能力的一个入口，但现在大家好像都停在这个口子上了，各类接口平台层出不穷（某个 200 人群，据说基本上人手一个接口平台，吓得我差点退群），都在这里卷，并不是个好现象。测试环节中，还有很多痛点值得大家去解决的。比如测试数据管理、测试环境治理等，期待有新的东西出来。

UI 专项测试：关于 UI 自动化测试的工具，可参考朱老师的文章（https://mp.weixin.qq.com/s/U769tMdt2dvrSccb5br1GA）。
工具并不是主要的，希望大家还记得上文提到的分层思路，做 UI 层做该做的事。从收益最大化模块入手，优先级：稳定模块 > 有影响风险的旧模块 > 新模块。并做好对于 UI 自动化测试的预期管理，它并不能一键傻瓜式地解决问题，需要有较好的前端规范，否则脚本维护会是个大问题。

性能专项测试：这些专项测试中，其实性能笔者是做得最久的，现在性能也得到了大家的关注。但是很多人对性能的基本概念理解存在偏差。例如，大家对 “并发数” 这个指标特别关注，动不动就上百万的并发（双 11 才多少），太吓人了。实际上，除了某些特定的场景（抢红包、秒杀等活动），并发的意义并不大，持续压测的过程中，并没有严格意义上的并发（实际的业务中，大多数业务也没有严格的并发，而是持续不断产出压力），我们更多考虑的是 TPS 或者 QPS 能达到多少，这就又涉及到业务模型和测试策略的问题了。大家有兴趣可以看看老张的公众号。

安全专项测试：安全测试需要更专业的技能和知识，一般是由专门安全团队定期进行验证的，这个已经脱离了一般的测试范畴了，简单地使用工具扫一扫，并不能算安全测试。笔者也没有深入了解过，有机会找个大牛写一篇。

弱网专项测试：虽然现在网络的速度在不断地提升，WIFI 的覆盖率也在增加。大家似乎都很少遇到弱网的情况。但是在一些特别的场景下，比如人多的地方，比如车库等，还是会存在弱网的情况。所以弱网的专项测试还是非常有必要的。目前在测试移动设备上进行弱网络专项测试的方案主要有 3 种：
Fiddler 等通过设备连接到 PC 上进行弱网络测试

*ATC、Wetest-WiFi 等在专有服务器上构建弱网络 WiFi，移动设备连接该 WiFi 进行弱网络测试

还有一种就是以 APP 独立存在，提供弱网络模拟服务，如弱网测试工具 QNET。

其他专项测试：还有诸如兼容性测试、兼容性测试、健壮性测试等等，就不展开介绍了 *。

03 小 结

基于分层测试思路，我们在做专项测试时，需要有针对性地去做验证。其实每个专项展开来讲，都会有很多的内容，本文篇幅有限，主要思考的还是如何去开展这些专项测试，至于工具的使用，现在有太多的工具可选择了。以终为始，希望测试同行们在提升代码能力的同时，不忘初心，记住我们是为了什么目标而开展专项测试，不要让技术偏离业务，而成为炫耀的存在。

今天就聊到这啦，接下来，我们聊点什么呢？敬请期待。

原文连接：https://mp.weixin.qq.com/s/WmGk7mMva6lp5ZqwbPuFUA