性能测试范围与用户行为模型

  小菜最近又接到一个测试任务,这次的项目时一个旧系统升级改造项目。小菜接到任务后第一时间找到项目经理讨论性能测试范围,可项目经理扔给小菜一个 100 多测试点的文档就走了,这可让小菜头痛不已。小菜去找大鸟大吐苦水。
小菜:“大鸟,这次的项目好复杂啊,100 多个功能点,光准备测试脚本都要好几个星期呢,而且因为没有监控模块项目经理对处理能力(TPS)的要求也说不出个所以然来,这要做好我估计怎么着也得半年吧”
大鸟 😰:“呵呵。。你一个性能测试做个半年,你那项目还要不要上线了。”
小菜 😤:“大鸟你倒是说的轻松,这 100 多个功能点,难道给你做就能半个月就能测的好吗?”
大鸟:” 你要把全部功能点都测到 当然要很久。不过性能测试可做不到像做功能那样全覆盖,你可以挑选一些重要功能点纳入你的测试范围 “
选择性能测试范围都会遵守下面三点:

__1. 用户使用最频繁的功能

  1. 开发人员认为可能存在风险的功能(毕竟亲生的)
  2. 重要的功能(比如支付等与钱相关的功能)__

小菜扣了扣鼻子😩:“哎˜˜这道理你都和我说过好几遍啦,可这系统什么监控模块都没有怎么分析用户使用行为啊。”
大鸟💢:“谁和你说没有的?中间件的 access_log 就是很好的监控模块。我早就帮你统计好啦,看吧”

“这个系统是用 mvc struts 编写的,每一个用户提交事件都会对应到一个.action 方法,你只要统计每天每个方法的调用次数,就能大致的分析出用户的使用行为了 “
“哦˜˜˜access_log 还能这样用啊,我一直以为它只是用来排查错误的呢😅
“这样一来测试范围也差不多可以确定下来了,分析出来的调用数量也正好可以作为这次性能测试的指标(TPS)”
“哎呀,大鸟啊 经你这么一整这个项目看来还是蛮简单的嘛😄
“小菜啊 , 性能测试的重点永远在于分析与挖掘,每一份你能获得的数据都是宝贵的,你要懂得如何去分析使用这些数据。
“大鸟 还是那么文邹邹的,我这道行当然不能和大鸟比啦 🙏


↙↙↙阅读原文可查看相关链接,并与作者交流