如何编写性能测试用例？

前言

写测试用例，是测试绕不开的工作内容，不管是功能、自动化，还是性能。先来回顾一下功能测试用例主要包含的要素：测试用例编号、测试标题、所属模块、测试需求项编号、案例状态、预置条件、优先级、测试输入、操作步骤、预期输出、实际结果、案例设计者、设计日期、案例性质等。性能测试用例(有的称为场景用例)的设计，有别于功能测试用例、自动化测试用例的设计，毕竟，考虑的点不一样。对于性能测试来说，一般要考虑这4种场景：单场景、混合场景、稳定性场景、异常场景。

下面，结合笔者实际工作，分享下单场景的用例是如何设计的。

同时，我也准备了一份软件测试视频教程（含接口、自动化、性能等），需要的可以直接在下方观看，或者直接关注VX公众号：互联网杂货铺，免费领取

软件测试视频教程观看处：

2023最新版性能测试保姆级实战教程全套完整版，48小时从小白到大神【项目实战、jmeter压力测试】

单场景的定义

有的称为接口基准(Benchmark)、或者单交易的容量，总之，这个不是真实的业务原型(可以简单理解为不同业务的使用情况)。

单场景压测的目的

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

单场景的来源

有人可能要问，单场景从哪里来？如果你们业务部门或者其它部门能给，那最好，如果不能给，你作为性能测试人员，要引导相关人员给，总之，我觉得这个不能性能测试单独定，否则后期出问题可能你独自背锅哦，要尽最大努力保证不出问题，哪怕出问题，也要一起背锅。单场景是来自于业务原型，但是不是每个业务接口都需要做压测，所以，我们这里说的业务原型，是混合场景的业务原型，混合场景里面，每个业务接口都需要做单场景压测。至于业务原型如何获取，这是一个大话题，本次分享暂不讨论，如果想交流，欢迎微信留言。

项目架构及服务器清单

我们用个简单的架构来举例：nginx + tomcat*2 + mysql

单场景用例

除了基于压测工具的设计(假设用的压测工具是jmeter)，还包含监控的设计、预期结果、实际结果

 部分预期结果(根据项目实际情况写)

 部分实际结果 

如果你的架构很复杂，写重点即可，无需把过多的时间耗费在文档上，况且后期你也可以慢慢完善。 

补充：jmeter脚本

连续阶梯加压，看线程、tps、rt的趋势

 另外，混合场景、稳定性场景、异常场景的用例设计，需要的可以关注公众号（互联网杂货铺），后台回复1

总结

PS：这里分享一套软件测试的自学教程合集。对于在测试行业发展的小伙伴们来说应该会很有帮助。除了基础入门的资源，博主也收集不少进阶自动化的资源，从理论到实战，知行合一才能真正的掌握。全套内容已经打包到网盘，内容总量接近500个G。如需要软件测试学习资料，关注公众号（互联网杂货铺），后台回复1，整理不易，给个关注点个赞吧，谢谢各位大佬！

☑ 240集-零基础到精通全套视频课程
☑ [课件+源码]-完整配套的教程
☑ 18套-测试实战项目源码
☑ 37套-测试工具软件包
☑ 268道-真实面试题
☑ 200个模板-面试简历模板、测试方案模板、软件测试报告模板、测试分析模版、测试计划模板、性能测试报告、性能测试报告、性能测试脚本用例模板（信息完整）

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。