如何编写性能测试场景用例（如何编写性能测试用例）

如何编写性能测试场景⽤例（如何编写性能测试⽤例）
单场景
前⾔
写测试⽤例，是测试绕不开的⼯作内容，不管是功能、⾃动化，还是性能。

先来回顾⼀下功能测试⽤例主要包含的要素：测试⽤例编号、测试标题、所属模块、测试需求项编号、案例状态、预置条件、优先级、测试输⼊、操作步骤、预期输出、实际结果、案例设计者、设计⽇期、案例性质等。

性能测试⽤例（有的称为场景⽤例）的设计，有别于功能测试⽤例、⾃动化测试⽤例的设计，毕竟，考虑的点不⼀样。

对于性能测试来说，⼀般要考虑这4种场景：单场景、混合场景、稳定性场景、异常场景。

下⾯，结合笔者实际⼯作，分享下单场景的⽤例是如何设计的。

单场景的定义
有的称为接⼝基准（Benchmark）、或者单交易的容量，总之，这个不是真实的业务原型（可以简单理解为不同业务的使⽤情况）。

单场景压测的⽬的
既然单场景不是真实的业务原型，为什么不直接做混合场景的压测呢？其实，做单场景压测的⽬的是测试出这个单业务的最⼤tps，⽅便判断瓶颈，⽐如，业务部门给的混合场景的tps（假设这个tps值是合理有效的），根据业务原型⽐例计算后，业务A的⽬标tps都⽐你单场景的最⼤tps还要⼤，那是不是应该让开发提前优化了？如果在混合场景压测中，发现业务A的tps已经到达或者接近其单场景最⼤tps，但是混合场景还没有达标，那说明瓶颈在业务A。

单场景的来源
有⼈可能要问，单场景从哪⾥来？如果你们业务部门或者其它部门能给，那最好，如果不能给，你作为性能测试⼈员，要引导相关⼈员给，总之，我觉得这个不能性能测试单独定，否则后期出问题可能你独⾃背锅哦，要尽最⼤努⼒保证不出问题，哪怕出问题，也要⼀起背锅。

单场景是来⾃于业务原型，但是不是每个业务接⼝都需要做压测，所以，我们这⾥说的业务原型，是混合场景的业务原型，混合场景⾥⾯，每个业务接⼝都需要做单场景压测。

⾄于业务原型如何获取，这是⼀个⼤话题，本次分享暂不讨论，如果想交流，欢迎微信留⾔。

项⽬架构及服务器清单
我们⽤个简单的架构来举例：nginx + tomcat*2 + mysql
单场景⽤例
除了基于压测⼯具的设计（假设⽤的压测⼯具是jmeter），还包含监控的设计、预期结果、实际结果
部分预期结果（根据项⽬实际情况写）
部分实际结果
如果你的架构很复杂，写重点即可，⽆需把过多的时间耗费在⽂档上，况且后期你也可以慢慢完善。

补充：jmeter脚本
连续阶梯加压，看线程、tps、rt的趋势
另外，混合场景、稳定性场景、异常场景的⽤例设计，稍后空了分析，有不清楚的可以联系作者。

真实案例。