目录
前言:
在进行软件测试之前,合理和清晰地梳理测试的业务是非常重要的,它有助于确定测试的范围、目标和策略。
在日常的测试工作中,不知道大家是否会有梳理自己测试业务的习惯。我个人觉得这个事情是值得做的,最好还可以培养成一个习惯。
一、为什么要梳理业务?
因为在业务测试中,作为测试人员,熟悉负责的业务是非常重要的,而通过阶段性的梳理总结,可以让你的业务知识系统化的沉淀下来。
当被问起这个业务系统的测试重点在哪里?难点如何克服?为什么要这样设计等等问题,可以有条不紊的进行输出。
又或者,当你任务需要交接,或者需要别人支援你的业务,你可以自信的把文档丢过去,拍拍胸脯说:看一遍你就知道了。
同样大家平时都在做业务,同样并没有多少别的技术层的产出,这也是为什么有人能拿A,有人却只能拿C的原因之一。
另外,当你有了多种业务的沉淀之后,你甚至可以提炼出很多通用性的东西,姑且称为“方法论”吧。
二、梳理框架
优点这么多,如何进行梳理呢?这里我参照常规的服务系统,写一些思路(框架),仅供参考。
1. 测试场景
这部分可以整理出业务系统的测试场景。
可以重点贴出核心的测试场景,附带上全量的测试用例。如果用例有后续迭代,也可以根据时间和内容进行分分类,放在这里。
2. 业务
这里就可以整理有关业务的更多细分领域。比如:
1)各种配置
业务涉及到的各种后台配置、后台地址、配置影响范围、必须非必须配置、配置顺序、特殊注意项等等。
2)前端
涉及到的产品前