---

前言

性能测试，需求分析是重中之重——分析不到位会导致场景不符合实际，做无用功；
工具+监控没太多学习成本；
真实的性能需求，才是影响最终测试结果的关键因素；

相信很多做性能测试的同学，都遇到过下面这些问题：
需求不明确，有时候甚至是“我们有个XXX接口，你给我压一下”这种伪需求；

需求不明确导致无法对测试点&测试场景进行详尽完善的分析，最终的测试结果与实际需要的结果差距很大，无法对瓶颈定位和线上容量规划提供精确的参考；

工作结果没有正向有效的反馈机制，出了问题甚至需要背锅这种蛋疼的事情；
…

当然，实际工作中，还会遇到很多其他的问题，重要的是：我们如何分析问题背后的原因，然后想办法解决问题！

关于场景建模，主要从如下三方面入手：

业务场景

在测试开始前的需求阶段，一定要梳理调研清楚，我们测试的范围和目的是什么？

比如有些电商项目，项目主要是社交电商+鉴定，社交必备的风控业务，电商先天自带的物流仓储业务，基础的消息及推送服务，以及双十一必备的促销活动，在双十一大促期间，这些都是核心的业务链路。

以交易业务来说，交易业务链路，会包含如下的一些核心业务链路：

其中，首页可能会包含开屏页、登录首页、促销活动页，个人主页等；商品会包含商品详情、商品列表、商品收藏等；以及订单、购物车、支付、搜索等和交易有强依赖的业务。

根据不同业务链路包含的细分业务功能，以及结合系统架构类型（微服务可能会根据业务属性来做高度内聚解耦），划分不同功能的优先级和重要程度。

这样，我们在需求阶段，就可以得到一个比较明确的业务场景，从而开始下一步的工作。

链路场景

完成了测试范围的确认和业务场景的梳理划分，接下来，就是从需求→测试点的拆分（关于这点，初始的想法是和压测场景合并来说，但仔细想想，作为一个独立场景更好）。

在链路场景构建过程中，最重要的，是考虑到如下三点：

1、任务拆解
任务拆解，和字面意思一样，根据梳理出来的业务场景，从用户的角度来划分不同的操作流程，然后梳理出不同业务链路的任务List；

2、任务排期
根据拆分的业务链路，分析梳理它的前置项（环境准备、服务联调）、跨部门合作（运营投放、渠道引流）、资源投入（开发、运维、测试）、交付产出（版本、API文档、日志服务、监控）。

然后按照时间节点，预估工期并进行倒排，工时预估到天/人，可以有半天左右的浮动，但一定要明确交付时间和预案（比如各team交付太晚或资源不足的备份方案）。

3、权重划分
你看，按照上面的玩法，梳理出来的东西一定很多。但很多时候，交付产出总会晚点，资源投入总会少点，预案基本是没有的。

针对这种问题，作为性能测试，该如何做呢？答案其实上面已经说到了，划分权重和优先级，在有限的时间和资源投入范围内，优先保障核心和重要链路的测试覆盖！

毕竟，兜底方案，是有很多的，比如流量限流、服务降级甚至熔断（这些手段都是有损的，但为了保障到时候服务不挂掉，这些都是可接受的）。

PS：有些细节性的东西，限于保密和安全规则，无法详细介绍，但抓住重点，按照上面介绍的思路去实践，总归会有适合自己团队的方法。

压测场景

前面我们确认了测试范围、业务场景、业务链路，划分了优先级和权重，做了一些预案及任务排期，但最终要落地的，还是测试方案及具体的测试场景。

比如，针对不同的业务场景，我们要采用哪些测试策略，如何进行测试，什么时候开始，预期结果以及验收标准等等。

这里，我建议在输出最终的测试方案前，先画个思维导图，和开发、运维甚至架构童鞋快速的review一下，先达成大方向的一致，然后输入测试方案，执行压测。

可以参照如下的压测思路进行具体的测试场景设计：

具体实践，还是建议根据各自team的特点，针对性执行。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

人生没有彩排，每一次经历都是一场及时行乐的演出。投身于追求自己的理想与目标中，不断努力，你将收获更多的成功与快乐。

别让自己的人生被安排好，去探索更大的世界吧。用心经营每一天，积极面对每一个挑战，勇攀高峰，你将成为最耀眼的存在。

在你坚定的信念和不懈的努力中，每一个小小的进步都是一份收获。别放弃，别停止，不要忘记你为什么开始。成功属于那些永不言败的人。