一、为什么要梳理业务？

因为在业务测试中，作为测试人员，熟悉负责的业务是非常重要的，而通过阶段性的梳理总结，可以让你的业务知识系统化的沉淀下来。

当你被别人问起这个业务系统的测试重点在哪里？难点如何克服？为什么要这样设计等等问题，可以有条不紊的进行输出。

又或者，当你任务需要交接，或者需要别人支援你的业务，此时你可以自信的把文档丢过去，拍拍胸脯说：看一遍你就知道了。

另外，当你有了多种业务的沉淀之后，你甚至可以提炼出很多通用性的东西，我称为“方法论”。

二、梳理业务框架

如何进行梳理呢？这里我参照常规的服务系统，写一些思路，仅供参考。

1、测试场景

这部分可以整理出业务系统的测试场景。可以重点贴出核心的测试场景，附带上全量的测试用例。如果用例有后续迭代，也可以根据时间和内容进行分分类。

2、业务

这里就可以整理有关业务领域。比如：

1、各种配置

业务涉及到的各种后台配置、后台地址、配置影响范围、必须与非必须配置、配置顺序、特殊注意项等等。

2、前端

涉及到的产品前端功能是哪些、重要链接、主要的前端交互等等。

3、核心流程

梳理业务的核心流程，可以包含对用户的操作流程，以及对应交互的接口。

另外，可以自己手动画一画核心业务流程图，一般产品会给出，但是有时间自己画一画，脑海里再过一过更加深刻，说不定还有意外发现来补充测试用例设计。

例如：仓配对接业务流程图

还有一个重点就是业务数据的处理过程，如果涉及到其他像kafka、es、缓存等中间件，数据处理的细节也可以整理出来。

4、问题排查

在测试工作中一定会遇到杂七杂八的问题，抽出一些典型问题，记录下排查手段以及可能因素，方便自己以及其他人查看。

3、系统

业务层梳理完，就应该关注应用服务层的了。

1、应用站点

可以从入口往下，整理出业务系统下各个站点，服务名称、作用等信息。

2、接口与日志

这里可以汇总下接口文档，根据不同情况进行分类，反正目的就是为了高效查看对应文档。

在测试过程中如何查看关键性的日志也很重要，对理解接口交互，排查问题都很有帮助。这里可以记录不同流程，涉及到的站点，如果过滤日志等信息。

3、MQ消息

记录交互的 MQ 有哪些，topic、不同tag的作用是什么、消息体等等。

4、异常机制

记录下系统都有哪些异常的处理机制，常见的比如超时、重试、补偿、兜底等等。

4、数据

到了数据层了，自是离不开 mysql 、缓存、mongoDB等等。

梳理好各数据库名，用来处理什么，核心的表以及关键的字段，比如一些订单类型、状态等等。

redis这些nosql数据库，梳理重要的 key、field、value等等。

5、安全

比如接口的鉴权机制，一些涉及到更复杂加密处理的接口的细节。

还有一些并发操作类的控制也可以整理出来。

6、性能

通常是单接口和链路场景的性能。

1、接口性能

比如：前端用户体验最直观的接口、创单接口、详情接口、预处理接口等等。

2、链路性能

最核心的链路场景，串起来进行压测。

3、限流

如果涉及到限流的场景，可以进一步整理出考虑限流的因素，触发的机制，处理的手段等。

7、数据分析

数据是多样的，比如日志数据、埋点数据、或者数据大屏的数据，列出需要关心的点，以及数据的正常趋势、不正常的趋势。

8、监控报警

通常就是测试右移后关注的点，可以监控线上运行的服务，对核心业务接口的一些常规指标进行监控。另外对日志系统不同类型的日志数量监控也有必要。

如果运维配套系统比较完备的话，我们测试自己就可以进行配置了，如果没有的话，积极的参与其中吧。

9、应急预案

一些核心业务系统，可能还会针对极端情况有应急预案。比如机房切换、灾备预案等。

三、结语

拿我自己来说，想做的事情和正在的做的事情其实是有很多的，目前也是一点点的在梳理着，很多事情做不做是一回事，做了能不能坚持下去又是一回事，这方面的话我自己肯定会长期坚持做有意义的事情！

作者：好好先生&Mr.Li

原文链接：https://blog.csdn.net/weixin_44275820/article/details/123508616