一、需求调研
1）系统信息
1、了解系统的架构、网络拓扑图信息
2、了解系统所用的协议、中间件、数据库信息及对应的核心配置参数信息、使用的什么开发语言
3、系统是否有加密、有没有验证码、采用了什么特殊的技术
2）业务信息
1、性能测试的业务测试范围（业务流程是怎么样的）
2、测试的每个业务的访问量多大、系统整体的用户访问量是多少、业务的配比是怎样的
3、测试的目的，预期的结果是什么
3）选择对应的测试工具
1、根据实际的需要选择对应的测试工具信息
二、性能测试计划方案
测试的目的
测试范围和性能测试需求
性能测试业务流
性能测试场景
构造测试数据
测试相应文档的存放位置
部署测试环境
测试压力机环境信息
监控响应部件
测试结果
测试的入口准则、出口准则、停止开始准则
测试的风险
测试附件信息
三、前端的页面的性能测试
1、可以利用httpwatch工具、fidder工具、或者浏览器自带的开发工具F12键，查看页面每个资源的响应时间、资源的大小
2、可以利用yslow工具对页面上的js、css、图片等信息是否压缩、位置是否合理等信息进行测试
四、脚本开发
测试范围确定之后根据对应的协议及使用的测试工具开发测试脚本，在开发测试脚本的过程中主要有以下六个知识点：
1、参数化：为了实现脚本与数据的分离模拟多用户的操作故需要对脚本中的一些数据进行参数化，难点在于构造合理的测试数据，根据实际的业务逻辑选择对应的取值更新方式
2、关联：关联与技术无关，与系统的业务有关，由于系统某种业务的限制，脚本的某个请求会用到前面请求返回的某个动态变化的值，故需要使用关联函数将要的动态值先取到，赋给需要的请求中以保证脚本业务功能的实现，关联的难点一个是找到要关联的动态值是哪个请求返回的，关联函数就写在该请求前面，外一个就是确定关联值的左右边界
3、集合点：用于测试某个或多个业务的瞬间并发测试（例如同时抢票），根据需要在脚本添加集合点之后，在运行场景时，设置集合点的集合策略
4、思考时间：主要是模拟用户真实操作，让脚本压力更接近真实的压力，提高测试结果参考价值
5、检查点：主要是保证脚本的功能业务正确，如果是脚本功能业务一定是正确的情况下可以不加检查点，在不知道结果是否正确的情况下可以加检查点来保证脚本业务功能正确
6、事务：主要作用是分析结果，只有添加了事务，LR场景运行报告中才会有响应时间、每秒处理事物数等图表信息
参数化、关联 保证脚本的业务功能正确实现
集合点、事务、检查点、集合点只是用来优化脚本
五、场景设计
1）根据测试目的的不同设置不同的场景进行测试，场景设计中主要的知识点有五个：
1、添加压力机
2、设置压力（画压力曲线图）
3、设置场景参数（思考时间、事务、日志）
4、并发测试设置一下集合点的集合策略
5、添加监控的参数
2）注意事项：
1、脚本在单次调试成功后并不代表脚本就没有问题了，在设置场景多用户并发运行后成功才代表是真正的没有问题
2、所以我们在单次调试通过之后 在场景里先少用几个用户 先跑上几分钟，保证脚本 是没有问题 在大量用户的去长时间的跑
3）基准测试
单个用户的 响应时间 吞吐量 事物数
基准测试通过之后再进行大量虚拟用户去压服务器
4）压力测试
如果目的是要测试出来系统的最大处理能力，就是极限测试出来，关注的就是压力上升的一个过程
1、把时间间隔 设置的长点 每个时间间隔 增加的用户数 可以少点
2、持续、结束就可以随便设置，我们关注的是压力上升的过程
5）负载测试
如果我们做长时间的负载测试，想要看一系统在长时间的运行情况下，看看服务器 能不能支撑的住，关注的就持续过程
1、压力上升 跟减少 我们可以 快点
2、持续时间可以长点，结束就可以随便设置我们关注的是压力持续的过程
场景设计 主要是 思路 操作还上很简单，场景的设计肯定是根据测试目的来，目的不一样 设置的就不一样
六、监控
在运行场景的同时还需要监控服务器的资源消耗情况，例如CPU、内存等资源的使用情况。
1、服务器 要是win系统可以试用系统自带的性能监视器来监控
2、服务器要是linux系统可以使用自带的命令 vmstat、top、ipstat监控或者使用nmon工具
自带的命令监控的话就是直接输出要监控的资源的信息比如cpu、内存、网络、磁盘都是实时输出且都是文字的，没有图形化的表nonm监控可以直接输出图形化的表
七、测试结果分析
1、场景运行结束之后要根据测试结果跟系统资源消耗情况一块分析系统是否存在瓶颈
2、在运行场景之前首先要预估一下运行场景所需的带宽，看公司目前的带宽是否满足需要，在测试之前就将网络问题排除
3、问题排除要从前到后来一步步排除，问题越靠近底层成本越大，从前端页面、网络、中间件、操作系统、代码、数据库、SQL这样的顺序一步步定位问题到底在哪
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
