很多人会问，性能测试需要设计方案吗？需要测试用例（性能场景）吗？拿一个性能测试工具，比如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，没有归属城市。
所以我一直以为性能测试方案的设计，是最体现一个性能测试工程师价值的地方。对业务的熟悉，对性能的敏感，都可以体现在设计方案中。
