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

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

  小菜最近又接到一个测试任务，这次的项目时一个旧系统升级改造项目。小菜接到任务后第一时间找到项目经理讨论性能测试范围，可项目经理扔给小菜一个100多测试点的文档就走了，这可让小菜头痛不已。小菜去找大鸟大吐苦水。

小菜：“大鸟，这次的项目好复杂啊，100多个功能点，光准备测试脚本都要好几个星期呢，而且因为没有监控模块项目经理对处理能力（TPS）的要求也说不出个所以然来，这要做好我估计怎么着也得半年吧”

大鸟 ：“呵呵。。你一个性能测试做个半年，你那项目还要不要上线了。”

小菜 ：“大鸟你倒是说的轻松，这100多个功能点，难道给你做就能半个月就能测的好吗？”

大鸟：”你要把全部功能点都测到 当然要很久。不过性能测试可做不到像做功能那样全覆盖，你可以挑选一些重要功能点纳入你的测试范围“

选择性能测试范围都会遵守下面三点：

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

2. 开发人员认为可能存在风险的功能（毕竟亲生的）

3. 重要的功能（比如支付等与钱相关的功能）

小菜扣了扣鼻子：“哎˜˜这道理你都和我说过好几遍啦，可这系统什么监控模块都没有怎么分析用户使用行为啊。”

大鸟“谁和你说没有的？中间件的access_log就是很好的监控模块。我早就帮你统计好啦，看吧”




“这个系统是用mvc struts编写的，每一个用户提交事件都会对应到一个.action方法，你只要统计每天每个方法的调用次数，就能大致的分析出用户的使用行为了“

“哦˜˜˜access_log 还能这样用啊，我一直以为它只是用来排查错误的呢 ”

“这样一来测试范围也差不多可以确定下来了，分析出来的调用数量也正好可以作为这次性能测试的指标（TPS）”

“哎呀，大鸟啊 经你这么一整这个项目看来还是蛮简单的嘛”

“小菜啊 ， 性能测试的重点永远在于分析与挖掘，每一份你能获得的数据都是宝贵的，你要懂得如何去分析使用这些数据。”

“大鸟 还是那么文邹邹的，我这道行当然不能和大鸟比啦 ”

可以结合这篇博客的shell 分析下日志文件(access_log)

/article/8457330.html