爆肝整理，企业级性能测试-性能方案设计详细总结（一）

---

前言

1、需求分析

测试目的：

为什么测？目的在于测试系统相关性能能否满足业务需求。

通常分以下两种情况：
1）新项目上线
2）老项目优化
如果是老项目优化，可考虑是否存有历史测试方案，如果有可以参考，或许可以省事很多。

测试对象：

要测啥？

测试对象可以归结为“业务功能”。测试前，需要了解我们需要测试的业务功能（不深入细节）有哪些，比如“购买商品”、“寄送快递”。

有没有必要测？
需求来源哪里？，有没有数据支撑测试这个需求的必要性？

通常，可以从以下几个方面考虑：
1）是否核心功能，是否要求严格的质量
2）是否常用、高频使用的功能
3）可能占用系统较多资源的功能
4）使用人数多还是少
5）在线人数多还是少

拆分对象：

先从业务上来分，实现这个完整的功能包含哪些流程、环节

举例：购买商品
登录->搜索商品->提交订单->支付订单->退出

指标分析：

分析性能需求指标（如“支持300人并发登录”）是否合理
有必要测试这个需求，考虑需求指标是否合理？有没有数据支撑？

通常，支撑数据可以从以下方面考虑：
1）采样时间段内系统使用人数
2）采样时间段内系统在线人数
3）采样时间段内系统(页面)访问量
4）采样时间段内请求数
…

常用分析思路：
1）2/8法则，2/8法则：80%的业务量在20%的时间里完成。这里，业务量泛指访问量，请求数，数据量等
2）正态分布
3）按比例倍增
4）响应时间2-5-8原则

就是说，一般情况下，当用户能够在2秒以内得到响应时，会感觉系统的响应很快；
当用户在2-5秒之间得到响应时，会赶紧系统的响应速度还可以；
当用户在5-8秒以内得到响应时，会赶紧系统的速度很慢，但是还可以接受；
而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟糕透了，或者认为系统已经失去响应。

注意：这个要根据实际情况，有些情况下时间长点也是可以接受的，好比12306

举例：
某公司后台监控，根据一段时间的采样数据，分析得出日高峰时段(11:00-14:00)用户下单请求数平均为1000，峰值为1500，根据这个计算并发请求数

时段：3个小时-> 3 x 60 x 60 = 1080s
业务量：1500
吞吐量：1500 * 80% / (1080 * 20%) = 5.56请求数/s

假设用户下单遵循正态分布，那么并发请求数峰值会肯定大于上述估算的吞吐量

注意：
1）2/8原则计算的结果并非在线并发用户数，是系统要达到的处理能力（吞吐量）
2）如果要求更高系统性能，根据实际情况，也可以考虑1/9原则或其它更严格的算法
3）以上估值只是大致的估算，不是精确值

举例：
想了下，暂时没想到啥好的例子，大致就说一些涉及到数据量的性能测试，比如报表统计，或者是大数据挖掘，查询等，怎么去估算数据量？

数据生命周期：
一般来说，数据都是有一定的生命周期的，时间的选取需要结合数据周期考虑。这里假设3年后系统性能仍然需要满足业务需求。

数据增长率：
如果是老项目，可以考虑对应功能主表历史数据存放情况

这里假设按年统计，比如第一年10000，第二年15000，第三年20000，第四年25000，那么我们得出，以第一年为基准，数据增长率分别为0.5，1，1.5，每年在上一年的基础上，以5000的速度增长

预估3年后，数据增长率为3，需要测试数据量为（1+3）x 10000 = 40000

注意：
1）实际数据一般是没上面举例那么规律的，只能大致估算数据增长率。
2）一些大数据量的性能测试除了和数据量相关，还涉及到数据分布等，比如查询，构造数据时需要结合实际，尽量贴近实际。

3）不同业务模块，涉及表不一样，数据量要求也是不一样的，需要有区别的对待。

如果是新项目，那就比较不确定了，除非能收集相关数据。

2、系统分析

结合需求分析中第3点，分析系统架构。从功能实现上来看，怎么实现这个完整功能的。通常这些业务功能操作都对应着一个或多个请求(可能能是不同类型的请求，比如http, mysql等)，我们要做的是找出这些

1）请求顺序、请求之间相互调用关系
2）数据流向，数据是怎么走的，经过哪些组件、服务器等
3）预测可能存在性能瓶颈的环节（组件、服务器等）
4）明确应用类型IO型，还是CPU消耗性、内存消耗型->弄清楚重点监控对象
5）关注应用是否采用多进程、多线程架构->多线程容易造成线程死锁、数据库死锁，数据不一致等
6）是否使用集群/是否使用负载均衡

了解测试环境部署和生产环境部署差异，是否按1:1的比例部署
通常建议测试时先不考虑集群，采用单机测试，测试通过后再考虑使用集群，这样有个比较，比较能说明问题

3、业务分析

1）明确要测试的功能业务中，功能业务占比，重要程度。
目的在于，明确重点测试对象，安排测试优先级，建模，混合场景中，虚拟用户资源分配，针对不同业务功能施加不同的负载。

2）明确下“需求分析-指标分析”中相关业务功能所需基础数据及数据量问题，因为那块需求分析时可能只是大致估算下，评估指标是否合理，需要认真再分析下

4、用例设计

1）用例设计
通常是基于场景的测试用例设计
单业务功能场景：
运行测试期间，所有虚拟用户只执行同一种业务功能某个环节、操作

混合业务功能场景：
运行测试期间，部分虚拟用户执行某种业务的某个环节操作，部分虚拟用户执行该业务功能的其它环节

或者
运行测试期间，部分虚拟用户执行某种业务功能，部分虚拟用户执行其它业务功能

注：这里用例没说到多少用户去跑，跑多久等，这里只是把他当作相同场景用例下的的一组组测试数据了。

2）事务定义
根据用例合理的定义事务，方便分析耗时（特别是混合业务功能场景测试），进而方便分析瓶颈。

比如，购买商品，我们可以把下订单定义为一个事务，把支付也定义为一个事务。

3）场景监控对象
针对每条用例，结合“系统分析”第4）点，明确可能的压力点（比如数据库、WEB服务器），需要监控的对象，比如tps，耗时，CPU，内存，I/O等

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

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

奋斗是生命的底色，只有不断努力，才能铸就辉煌人生，让自己的存在在时间的长河中留下浓墨重彩的一笔。

不要畏惧失败，因为它是成功的前奏；不要停止追求，因为奋斗是成长的动力；只有坚持不懈，才能实现自己的价值，书写人生的壮丽篇章。

抓住每个机会，迎接每个挑战，踏上艰难的征程，因为只有在奋斗中，我们才能超越自我，实现理想，燃烧生命的意义。