很多人会问,性能测试需要设计方案吗?需要测试用例(性能场景)吗?拿一个性能测试工具,比如loadrunner,对被测系统进行压测,不就是性能测试了吗?是的,这种拿性能测试工具来进行压测,就以为是做性能测试的思维,仍然存在很大一部分的人心里。
我可以大声的告诉你:不是!性能测试是一门系统性的工作,包括:测试方案的设计、性能环境的搭建,编写性能脚本进行压测,分析测试结果,调优&回归,出性能报告。针对每一个步骤,我都尽量写一篇文章来描述。如果你拿性能测试工具进行压测,那么只是其中的一小步而已。本文先重点描述如何设计性能测试方案。
首先要确认性能测试的目的是什么?有个成语叫:有的放矢。这是我们做事的原则。我遇到很多开发,他们很喜欢说一句话就是:“这个帮我压下,看下性能如何?”当然这也是目的。那我们性能测试工程师的价值体现在哪里?每天屁颠屁颠跟在开发后面,帮他压一下这个项目,帮她压一下这个页面,帮TA压一下。。。。。?
我觉得作为性能测试工程师,要从系统的性能角度出发,从用户的角度出发,如何更好的模拟用户行为?找出系统的性能瓶颈所在,预估系统的容量。性能测试方案的设计也是基于这几点出发。
为了更好的理解,举个例子,就拿www.juhuasuan.com聚划算来说明。
上了聚划算后,你会发现有很多页面,那么我们是不是每个页面都要进行性能测试?开发当然希望你这么做了。。。。
身为性能测试工程师的你,必须以数据为依托,用数据来说话。首先获得整个聚划算的一天的访问量,比如1000万。那么这1000万是由哪些页面的访问组成的呢?
我相信这些数据,通过线上应用的监控,很容易获得的。比如聚划算的首页300万,商品的详情页面200万,今日团购页面150万,吃喝玩乐页面100万,商品团购页面100万,其他页面加起来150万。
为了模拟线上的访问量,取其top5访问量的页面。
场景1:首页(30%)+详情页(20%)+今日团购页(15%)+吃喝玩乐页面(20%)+商品团购页面(15%)
在性能环境压测场景1的话,基本模拟了聚划算系统的访问量的模型。
如果我在杭州,我默认打开城市是“杭州”的商品列表;如果你在北京,你默认打开的城市是“北京”。而杭州和北京的商品列表数据是不一样的。这里就要取第二笔真实的数据,线上有多少个城市,每个城市的商品数是多少?
所以场景可以这样设计:
场景2:城市是杭州,商品列表 100个(比如说程序的上限就是100个)
场景3:城市是北京,商品列表50个(30%左右的城市的商品数)
场景4:城市是上海,商品列表30个(30%左右的城市的商品数
以上说的4种场景,都是正常的场景,为了检验的系统的健壮性,我们也需要设计一些异常的场景。比如有的城市没有商品。
场景5:城市是拉萨,没有商品。
场景6:商品A,没有归属城市。
所以我一直以为性能测试方案的设计,是最体现一个性能测试工程师价值的地方。对业务的熟悉,对性能的敏感,都可以体现在设计方案中。