背景

如何回答以下这个问题的知识支撑：系统的测试重点在哪，难点是什么，怎么攻克，为什么要这样设计？项目交接效率？

同样是做业务测试，为什么有的人是A有的人只能C

二、框架

2.1 测试场景

重点贴出核心的测试场景，附带上全量的测试用例

2.2 业务范围

2.2.1 配置

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

2.2.2 前端

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

2.2.3 核心流程

这个可以根据业务进行梳理，可以梳理出业务流程图，一般产品人员会画，测试人员也可以自己画画

2.2.4 问题记录

项目从立项开始到目前，都遇到了什么问题，可能的因素，如何处理的过程，便于自己和他人查看

2.3 系统

2.3.1 应用服务

项目涉及的应用服务名称，作用，

2.3.2 接口

项目的接口文档地址，接口文档

2.3.3 日志

在测试过程中如何查看关键性的日志也很重要，对理解接口交互，排查问题都很有帮助，可以在过程总结和梳理好日志查看命令和说明

2.4 MQ消息

消息中间件，提高系统的高可用，高性能，高并发

MQ的优点：

解耦：就像高可用里面说的一样，发淘金币服务挂了，关下单什么关系，发淘金币服务挂了，我还是可以正常下单，只不过后期可以数据补偿或者分布式事务去解决这个问题。

削峰：比如说我平时服务就只能支撑几万的qps，像淘宝京东那种秒杀，那时候服务突然打进来（如果采用第二种方案）那服务就会直接被压死了。但是如果采用消息队列，这秒杀进来的所有的请求都不会直接打到具体服务上，都会先打到消息队列里，然后我后面的服务再慢慢消费。

可以看看淘宝京东双11秒杀的时候，是不是有的时候慢是慢了点，但是服务起码没挂。等我秒杀结束之后，服务还能正常运转。

消息队列就像是一个三峡大坝，用来拦截上游给的压力。

异步：连接消息队列的服务可以异步去执行。而且每次多增加一个步骤，我下单的代码是不需要动的，只需要再增加一个消费者即可。
 

2.5 异常机制

异常的兜底，超时处理，重试，补偿

2.6 数据

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

2.7 安全

重要接口的参数加密情况，接口鉴权方式

2.8 性能

性能脚本，性能场景和压测结果说明

2.9 业务数据分析

1、整个业务需要哪些数据？

2、哪些数据是需要配用户提供？

3、哪些数据是需要自己初始化？

4、哪些可以是假数据？

5、哪些又必须是真数据？

6、添加数据的时候可以用哪个库？

2.10 监控报警

2.11 应急预案

学习参考:测试工作中一定要学会做业务总结_数据测试需不需要先学习业务-CSDN博客