记一次性能测试实践

1.测试对象

这次测了一些http接口和几个网页。

2.测试策略

2.1 基准测试:单个调用各接口循环100次计算平均响应时间

2.2 性能测试:单个接口调用以50并发用户数为单位,逐步加压直到预估的实际负载300并发用户,观察测试指标变化

2.3 压力测试:单个接口调用以50并发用户数为单位,逐步加压直到错误率过高或服务器资源使用率过高,观察测试指标变化

2.4 负载测试:预估实际负载为300并发用户数,在此基础上持续测试5分钟左右,观察测试指标是否达标

2.5 稳定性测试:预估实际负载为300并发用户数,在此基础上持续测试60分钟左右,观察测试指标是否达标,重点观察错误率

2.6 疲劳性测试:预估实际负载为300并发用户数,在此基础上持续测试240分钟左右,观察测试指标是否达标,重点观察错误率

2.7 组合测试:对2.2-2.5的测试采用不同接口同时调用(即系统不同模块同时测试)

2.8 其他:以不同ip地址加压,测试服务器负载均衡效果。

以上,本次只做了2.2、2.3、2.4、2.8

3.测试指标

测响应时间、错误率;同时专人监控服务器硬件资源使用状况、监控tomcat应用服务器等。

计算和监控吞吐量(测试工具自动计算测试执行过程中的吞吐量(每秒钟处理请求数),同时服务器监控软件业监控到了测试执行时服务器的吞吐量)

本次实际测试得到吞吐量距离预估有较大差距;错误率超出预期;且测试数据准备有一定问题。

4.测试工具

本次选用Jmeter,因为便宜且灵活。

需设置语言为英文,默认中文翻译不完整。

5.测试脚本编写、调试

5.1 提前对接口、网页进行录制。每个待测接口、网页需要加断言。 断言多采用JQuery断言和Regular Expression断言

5.2 重点在测试数据的准备。

5.3 采用了本地web应用提供数据,jmeter获取这些数据,再发送给服务器的方法(这次发现这个本地应用生成的数据在较高并发时有重复,导致了不必要的错误率)

5.4 测试结果监听器: assertion results, summary report, aggregate report, result tree, result table

5.5 测试接口调用时,可用网页、数据库等其他方法确认接口调用成功。观察接口调用是否生效,是否和网页同样效果。

6.测试执行

6.1 一台电脑加压300-600并发用户。如果需要更多则需要增加电脑。

6.2 以不同ip地址加压,测试服务器负载均衡效果。

6.3 机房测试,排除internet网络延迟问题

6.4 数据备份和还原,排除性能测试对数据的改变

6.5 生产环境测试(系统未上线),排除测试环境的影响

7.测试报告

7.1 截取了jmeter监听器的结果,可以截取服务器监控的截图

8.调优

本次测试结果不理想,服务器因硬件强大,几乎无负载,但应用本身有java出错。并发现接口调用结果未正确影响网页的bug。

后续需要等开发修复、优化之后再次测试

时间: 2024-10-29 03:04:33

记一次性能测试实践的相关文章

记一次性能测试:mysql占用磁盘IO过高 的解决过程

在一次性能测试时,发现mysql的cpu使用率不高,但是磁盘io很高, 一开始考虑是mysql的慢日志比较多,但是查看后发现慢日志并不多,而且只有一台mysql. 进入实例,查看sync_binlog变量 mysql> show variables like '%sync_binlog%' -> ; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | sync_binlog | 1 |

渗透测试实践指南(1)

各种编码方案 base64 url html unicode 渗透测试实践指南(2016/1/14) 3.3 端口扫描 3.4 漏洞扫描 工具:Nessus 3.5 如何实战 4 漏洞利用 4.2 工具:Medusa(暴力破解,以破解ssh为例),Hydra 4.3 工具:Metasploit介绍使用 4.4 john the ripper 破解系统密码 (windows linux) 4.5 密码重置 4.6 嗅探网络流量 (受限于广播或hub) 4.7 macof:泛洪攻击交换机 工具集:D

SWTBOK测试实践系列(7) -- 测试用例设计的参考输入有哪些?

不管是文档化的测试用例,还是存在于测试人员头脑中的测试想法和思维,针对测试对象的分析和设计都是整个测试过程的重要测试活动之一.在进行测试分析和设计之前,测试人员首先需要确定测试的需求来源,即测试用例设计需要参考哪些测试依据文档? 测试用例设计的输入文档是什么?测试人员头脑中第一个蹦出的参考依据就是需求规格说明.确实,需求文档是我们测试设计的最主要参考文档.但是,由于时间限制.成本限制和个人能力限制等方面的原因,提供完备的需求规格说明几乎是不可能的.现实情况是,需求规格说明常常是不全的.模糊的,甚

SWTBOK测试实践系列(3) -- 既然计划永远赶不上变化,我们还要测试计划干嘛?

一天,测试经理老马迟疑着点下了Email的"发送"按钮,长叹一声,往后一仰靠到椅背上.发送这个主题为"回归测试将推迟一周"的通知实为无奈之举啊!一些重要的缺陷开发团队还来不及修复,加上最近几天测试环境的部署经常出现莫名的异常,导致半天都无法测试,原定下周开始的回归测试不得不推迟了!几分钟后,测试人员小王兴冲冲地跑到老马跟前,满脸疑惑地问:"经理,我刚看到你的Email了.又要延期啊!既然我们的测试计划老是在变,干嘛还要定计划?"老马坐正,略带欣慰

SWTBOK测试实践系列(2) --你会把开发人员提交测试的版本打回去吗?

开发人员奋斗了很多个夜晚,终于把版本提交测试了.他们可以松一口气了.但是噩耗很快传来,软件没有通过测试团队的预测试(为了保证测试进程,对开发人员提交的代码进行基本功能或业务流程的验证).开发经理老王,迅速找到负责预测试的测试经理老张. 老王说:老张啊,怎么回事?出什么问题了?我们好不容易开发完成了,你们怎么不测试还把版本打回来了? 老张说:你们提交的版本质量太差,没有我们的预测试,需要重新修改后,符合我们的要求,我们才能测试.你看看我们发现的这两个问题. 老王并没有看这两个问题,而是直接质疑老张

SWTBOK测试实践系列(9) -- 设计的测试用例是否越详细越好?

测试人员设计测试用例的时候,面临的第一个问题就是测试用例的步骤是否越详细越好?或者如何把握测试用例的详细步骤?在这个问题上,赞成测试用例详细化的人肯定有不少,因为详细测试用例可以提供如下优点: 1)缺乏经验或者技能的测试人员,可以按照测试用例的步骤顺利开展测试执行工作.这是脚本化测试实践中的思维:有经验与技能的测试人员设计测试用例,而缺乏经验的人员去执行测试用例. 2)缺乏经验的测试人员,按照详细测试用例的步骤执行的过程,不仅可以帮助他们了解测试对象的功能与业务知识,也可以帮助他们了解测试设计技

测试管理012:结对测试 - 不错的测试实践

由于项目测试中测试平台资源的不足,因此在测试过程中引入了一些结对测试(Pair Testing)的尝试,通过2个月左右的实践,最终的效果还不错.因此,本文简单来谈谈结对测试的实践.不管是开发人员还是测试人员,都应该有属于他们角色的创造性.开发人员创造软件产品,而测试人员可以创造性的发现缺陷,每个角色都可以按照自己的方式前行.开发人员可以结对编程,我们测试人员可以进行结对测试.那么,什么是结对测试呢?不同的人对它的理解会有所不同的.我们定义的结对测试是两个测试人员坐在一起(根据需要,他们可以共用一

SWTBOK测试实践系列(6) -- 开发人员为什么不做静态分析?

场景 某年某月某日,产品环境的2000多封自动发出的Email让我们项目组许多人的邮箱爆了.追查下来根源是一个很不起眼的缺陷.我们的程序对一个布尔值做了if(XXX = true)的判断,可来自上游系统的这个值不光是有true和false,还有空.也就是说上游系统中使用的是一个大布尔,是有true, false,null三态的,  而我们程序使用的是小布尔,只有true和false两态. 掉在大小布尔这个坑里也不是头一回了.记忆中前两年我们也掉进来过.有执著的QA一枚,翻箱倒柜地找,终于找到了当

SWTBOK测试实践系列(1) -- 测试在项目前期的评审投入划算吗?

测试策略:静态测试还是动态测试? [对话场景] 成功发布某个软件版本之后,项目团队召开了项目的经验教训总结大会.在会议期间,项目经理小项和测试经理小测进行了如下的对话: 小项:"小测,我们的项目时间压力很大,测试执行是我们的关键路径,测试团队是否可以在测试执行阶段投入更多的人力和物力?"限定时间和人力资源同等条件. 小测:"啊!假如增加我们的测试执行时间,在整个周期不变的情况下,我们就需要压缩前期的学习和评审投入的时间和工作量,是吗?" 小项:"是的,你看