在日常的测试工作中,不知道大家是否会有梳理自己测试业务的习惯。我个人觉得这个事情是值得做的,最好还可以培养成一个习惯。
一、为什么要梳理业务?
因为在业务测试中,作为测试人员,熟悉负责的业务是非常重要的,而通过阶段性的梳理总结,可以让你的业务知识系统化的沉淀下来。
当被问起这个业务系统的测试重点在哪里?难点如何克服?为什么要这样设计等等问题,可以有条不紊的进行输出。
又或者,当你任务需要交接,或者需要别人支援你的业务,你可以自信的把文档丢过去,拍拍胸脯说:看一遍你就知道了。
同样大家平时都在做业务,同样并没有多少别的技术层的产出,这也是为什么有人能拿A,有人却只能拿C的原因之一。
另外,当你有了多种业务的沉淀之后,你甚至可以提炼出很多通用性的东西,姑且称为“方法论”吧。
二、梳理框架
优点这么多,如何进行梳理呢?这里我参照常规的服务系统,写一些思路(框架),仅供参考。
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. 应急预案
一些核心业务系统,可能还会针对极端情况有应急预案。比如机房切换、灾备预案等。
作者:佚名