压力测试设计方案.doc

压力测试方案 一．目的 本次压力测试的目的是检测轰趴趴系统的核心业务的性能情况。 为了保证后期在业务量不断 增长的情况下系统能够稳定运行， 需要对核心业务场景的压力情况有充分了解。 因此， 希望 在产线环境下， 模拟用户并发数，对系统核心业务进行压力测试， 收集相应的系统参数，并 最终作为系统稳定运行的依据，同时为系统调优提供参考。 二．测试环境及工具 产线环境， loadrunner11 。 三．测试需求 1.测试功能点： 进入主页面 查询订单 2.性能要求 进入主页面，系统平均响应时间小于等于 3 秒 订单查询响应时间小于等于 3 秒 3.最大并发用户数量上下限估值 取系统目标期望最大在线用户需求数量的百分之五到百分之二十来计算。 四．测试前置条件 1.将轰趴趴 H5 抽离出来单独部署测试性能，并屏蔽掉与微信交互的内容（如支付、认证）， 保留区别用户账户身份的参数， 以便于在制作压力测试脚本时方便参数化、 达到不同用户多 用户并发测试。 2.为方便压力测试中多用户并发查询订单的测试，还要有对应的测试数据。 五．测试实施 1.利用 loadrunner 对手机页面脚本录制的原理： 需要保证手机终端和电脑在公司同一无线网 络内，手机终端可以通过代理将请求信息通过电脑进行转发。 2.对功能点事先录制好脚本，包括设置集合点、参数化等等，并且调试好，脚本能够成功回 放，保证在测试时能顺利运行。 3.创建测试场景，并配置好每个场景的设置。 4.测试过程中保存完好脚本和分析结果，并规范的对脚本和分析结果等进行命名。 5.并发数量大于单台 PC测试机运行性能时，部署其它 pc 机作为负载机一起测试。 6.并发访问有 ip 限制时，在测试工具中设置 ip 欺骗。 六．测试完成准则 1.符合上面列出的性能要求 2.期望值下的多人用户同时在线，脚本长时间运行后，系统不崩溃，各功能正常；服务器监 控 cpu、内存、响应时间等参数保持稳定。场景运行停止后，一段时间内占用的资源能够正 常释放。（注：服务器端监控需要运维官担当） 七．测试设计策略 1.组合测试策略 先按照单个场景进行并发测试， 在组合多个场景进行长时间测试， 即：先单独测试并发进入 主页面，再组合进入主页面、查询订单等进行长时间并发测试。 2.测试执行策略 采用阶梯式的方式，分别使用并发用户1、10、50、100、200? ? 等进行测试。每次增加虚 拟用户数时，查看系统的性能参数变化， 如果变化很大， 可以加大虚拟用户数量； 如果在某 一个并发数量 （如 200 个）下性能极具下降，则逐步减少并发数，以找出并发用户达到什么 数目时，系统性能极具下降。 3.测试结果分析 为达到测试效率，被测系统要避免非 200 的请求响应，如 404、500 等。 关注被测功能点最大并发数下，响应时间符合性能要求、事物通过率达到百分之九十以上、 cpu 使用率、内存使用率、错误率在正常范围内。 八．场景设计 1.进入主页面 测试目的：验证轰趴趴系统用户进入主页面、 在逐渐增加虚拟用户数量的情况下， 系统响应 时间如何变化及系统响应时间是多少。 前置条件：可以进入轰趴趴系统的用户 方法：逐渐增加用户个数进入轰趴趴系统用户，获取平均响应时间 2.支付成功进入主页面、查询订单 测试目的： 逐渐增加虚拟用户数量，获取查询订单的响应时间以及逐渐增加负载的过程系统 响应时间的变化，在用户数量达到峰值为多少时，系统的性能开始下降。 前置条件：可以进入轰趴趴系统的用户，名下有订单信息 方法：逐渐增加用户个数进行订单查询，获取平均响应时间 九．测试报告输出 在压力测试结束之后，根据测试结果，编写测试报告，并附上测试工具分析详情页截图。