今年跳槽到一家电商企业，性能测试需要从零开始。在性能测试不断推动落地过程中，积累了一些从零开始的经验和教训，自己也在有计划的写一个系列《性能测试从零开始实施指南》。
前面已经聊过了从零开始要做的一些事情，比如：《性能测试从零开始实施指南——流程篇》、《性能测试从零开始实施指南-文档建设篇》、《性能测试从零开始实施指南-测试计划篇》。
最近在忙着准备双十一全链路压测相关的工作，正好最近私信收到一个同行的消息，看完感触蛮多的，也算是督促了这篇博客的出现吧。私信的主要内容包含下面几点：
1、性能测试，需求分析是重中之重——分析不到位会导致场景不符合实际，做无用功；
2、工具+监控没太多学习成本；
3、真实的性能需求，才是影响最终测试结果的关键因素；
这几点问题，和我本人在实际工作中的感受是很类似的。相信很多性能测试的同学，都遇到过下面这些问题：
1、需求不明确，有时候甚至是“我们有个XXX接口，你给我压一下”这种伪需求；
2、需求不明确导致无法对测试点&测试场景进行详尽完善的分析，最终的测试结果与实际需要的结果差距很大，无法对瓶颈定位和线上容量规划提供精确的参考；
3、工作结果没有正向有效的反馈机制，出了问题甚至需要背锅这种蛋疼的事情；
。。。。。。
当然，实际工作中，还会遇到很多其他的问题，重要的是：我们如何分析问题背后的原因，然后想办法解决问题！
这篇博客，聊聊在性能测试过程中，我是如何理解并且去实践场景建模的方法。。。
关于场景建模，我个人的实践和经验，主要从如下三方面入手：
一、业务场景
在测试开始前的需求阶段，一定要梳理调研清楚，我们测试的范围和目的是什么？
以我司来说，主要是社交电商+鉴定，社交必备的风控业务，电商先天自带的物流仓储业务，基础的消息及推送服务，以及双十一必备的促销活动，在双十一大促期间，这些都是核心的业务链路。
那么，我们可以确定大体的测试范围，包含如下几个核心业务链路：
知道了测试的业务链路范围，接下来就是和对应的业务&产品&开发同学梳理确认各自负责的核心业务链路（这里指的是带有业务属性的链路及对应API，以及重要程度和优先级）。
以交易业务来说，交易业务链路，会包含如下的一些核心业务链路：
其中，首页可能会包含开屏页、登录首页、促销活动页，个人主页等；商品会包含商品详情、商品列表、商品收藏等；以及订单、购物车、支付、搜索等和交易有强依赖的业务。
根据不同业务链路包含的细分业务功能，以及结合系统架构类型（微服务可能会根据业务属性来做高度内聚解耦），划分不同功能的优先级和重要程度。
这样，我们在需求阶段，就可以得到一个比较明确的业务场景，从而开始下一步的工作。
二、链路场景
完成了测试范围的确认和业务场景的梳理划分，接下来，就是从需求→测试点的拆分（关于这点，初始的想法是和压测场景合并来说，但仔细想想，作为一个独立场景更好）。
在链路场景构建过程中，最重要的，是考虑到如下三点：
1、任务拆解
任务拆解，和字面意思一样，根据梳理出来的业务场景，从用户的角度来划分不同的操作流程，然后梳理出不同业务链路的任务List；
2、任务排期
根据拆分的业务链路，分析梳理它的前置项（环境准备、服务联调）、跨部门合作（运营投放、渠道引流）、资源投入（开发、运维、测试）、交付产出（版本、API文档、日志服务、监控）。
然后按照时间节点，预估工期并进行倒排，工时预估到天/人，可以有半天左右的浮动，但一定要明确交付时间和预案（比如各team交付太晚或资源不足的备份方案）。
3、权重划分
你看，按照上面的玩法，梳理出来的东西一定很多。但很多时候，交付产出总会晚点，资源投入总会少点，预案基本是没有的。
针对这种问题，作为性能测试，该如何做呢？答案其实上面已经说到了，划分权重和优先级，在有限的时间和资源投入范围内，优先保障核心和重要链路的测试覆盖！
毕竟，兜底方案，是有很多的，比如流量限流、服务降级甚至熔断（这些手段都是有损的，但为了保障到时候服务不挂掉，这些都是可接受的）。
PS：有些细节性的东西，限于保密和安全规则，无法详细介绍，但抓住重点，按照上面介绍的思路去实践，总归会有适合自己团队的方法。
三、压测场景
前面我们确认了测试范围、业务场景、业务链路，划分了优先级和权重，做了一些预案及任务排期，但最终要落地的，还是测试方案及具体的测试场景。
比如，针对不同的业务场景，我们要采用哪些测试策略，如何进行测试，什么时候开始，预期结果以及验收标准等等。
这里，我建议在输出最终的测试方案前，先画个思维导图，和开发、运维甚至架构童鞋快速的review一下，先达成大方向的一致，然后输入测试方案，执行压测。
可以参照如下的压测思路进行具体的测试场景设计：
如上，就是性能测试过程中，关于场景模型的梳理构建相关的内容，这里主要分享一些我个人的思路和方法，具体实践，还是建议根据各自team的特点，针对性执行。
