理解业务测试

这周参加大团队的年度述职汇报，听下来有个很深的感受：在当前测试的观念里，对业务自身价值并不重视，更多的是想着要做体系、做系统。其实也可以理解，相对于枯燥的需求验证，搞自动化、搞性能似乎显得更有深度。

多数人对业务测试的看法，是要保证覆盖全、不出问题，想得再多一些的，会提到站在用户角度给产品提提建议，差不多也就到此为止。但这些都只是业务测试的表层，它其实可以很深入，只是容易被我们忽略。

为团队同学做复盘的时候，我提了几个问题，并做了一些沟通。今天我也对这些问题做个整理，借此来和大家聊聊所谓的业务深度到底是什么。PS：基于对公司业务的保密义务，里面提到的业务场景会做类比替换。

第一个问题：你测某个需求的时候，是否考虑过重心是什么？

比如百度首页的热搜展示，消失一整天可能都没什么感觉，但是搜索框故障一分钟都不行，发现一个搜索框的问题，远比发现三个热搜的问题来得有价值。再比如支付类业务，资金安全定然很重要，那我们的用例设计是否应该重点围绕这方面去进行？

第一篇文章里我就提过，质量是需要被定义的，测试最核心的能力就是定义质量。每个测试其实都希望做到面面俱到，但完全测试本来就不可能，我们要把有限的时间，投入到最重要的事情上去。

第二个问题：你测了这么多需求，它们的场景共性是什么？

比如涉及到返现的场景，用户关心的是金额正确性和到账及时性；涉及到存储的场景，用户关心的是数据安全性和内容保密性；涉及到播放的场景，用户关心的是画面清晰度和视频流畅度。

我们对业务的理解，不仅限于单个需求的描述，而是某一类业务的抽象。第一次接触某种业务，总会有些不足的地方，需要经过整理和总结。后续再碰到同类需求，就很清楚它的重点在哪里，可能会遇到什么样的问题。

第三个问题：之前遇到过的问题，下次要如何避免？

比如在业务链路中，依赖了第三方的服务，且由于三方不稳定造成自身业务受损。也许这次解决了这个服务的问题，那之后会不会还有别的三方服务不稳定？当然有可能。即然如此，为什么不对三方服务做统一实时监控和依赖降级？

如果业务测试只是来一个做一个，那么下次的需求和这次的需求，对我们来说其实并没有太大不同。长此以往，即使做功能的时间再长，对业务的理解还是停留在需求分析、用例评审、等价划分、边界测试上。

总结：测试工作价值的最终体现还是业务价值。

测试方法论、自动化、性能、平台等等，都只是手上的工具，是达成目标的手段。我们不必过于纠结理论的正确性和流程的合规性，重要的还是我们做这些事情的目的和意义。我们所为的一切，即是从业务中来，再回到业务中去，用测试特有的方式，来实现最终的业务价值。