移动性能测试小菜的性能日记 3 (性能测试范围与用户行为模型)

心向东 · 2015年12月21日 · 最后由 august 回复于 2016年10月08日 · 3956 次阅读

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

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

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

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

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

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