【软件测试】如何梳理你测试的业务

目录

前言：

一、为什么要梳理业务？

二、梳理框架

1. 测试场景

2. 业务

3. 系统

4. 数据

5. 安全

6. 性能

7. 数据分析

8. 监控报警

9. 应急预案

---

前言：

在进行软件测试之前，合理和清晰地梳理测试的业务是非常重要的，它有助于确定测试的范围、目标和策略。

在日常的测试工作中，不知道大家是否会有梳理自己测试业务的习惯。我个人觉得这个事情是值得做的，最好还可以培养成一个习惯。

一、为什么要梳理业务？

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

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

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

同样大家平时都在做业务，同样并没有多少别的技术层的产出，这也是为什么有人能拿A，有人却只能拿C的原因之一。

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

二、梳理框架

优点这么多，如何进行梳理呢？这里我参照常规的服务系统，写一些思路（框架），仅供参考。

1. 测试场景

这部分可以整理出业务系统的测试场景。

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

2. 业务

这里就可以整理有关业务的更多细分领域。比如：

1）各种配置

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

2）前端

涉及到的产品前