网站标题字体深圳市昊客网络科技有限公司
背景
如何回答以下这个问题的知识支撑：系统的测试重点在哪，难点是什么，怎么攻克，为什么要这样设计？项目交接效率？
同样是做业务测试，为什么有的人是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博客