方案设计是设计中的重要阶段，它是一个极富有创造性的设计阶段，同时也是一个十分复杂的问题，它涉及到设计者的知识水平、经验、灵感和想象力等。下面小编给大家带来方案设计思路，欢迎各位阅读。
为什么测？目的是检测系统相关性能能否满足业务需求。通常分以下两种情况：
如果是老项目优化，可考虑是不是存有历史测试方案，如果有可以借鉴，或许可以省事很多。
测试对象可以归结为“业务功能”。测试前，有必要了解我们应该测试的业务功能（不深入细节）有哪些，比如“购买商品”、“寄送快递”。
然后从功能实现上来看，怎么实现这个完整功能的。通常这些业务功能操作都对应着一个或多个请求(可能能是不一样的请求，比如http, mysql等)，我们要做的是找出这些操作对应的请求，请求之间的顺序是如何的。
2/8法则：80%的业务量在20%的时间里完成。这里，业务量泛指访问量，请求数，数据量等
就是说，正常的情况下，当用户能在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会赶紧系统的响应速度还可以；当用户在5-8秒以内得到响应时，会赶紧系统的速度很慢，但是还可接受；而当用户在超过8秒后仍旧没办法得到响应时，会感觉系统糟糕透了，或者认为系统已经失去响应。
注意：这个要根据真实的情况，有些情况下时间长点也能接受的，好比12306
某公司后台监控，根据一段时间的采样数据，分析得出日高峰时段(11:00-14:00)用户下单请求数平均为1000，峰值为1500，根据这个计算并发请求数
1、2/8原则计算的结果并非在线并发用户数，是系统要达到的解决能力（吞吐量）
2、如果要求更高系统性能，根据真实的情况，也可优先考虑1/9原则或其它更严格的算法
想了下，暂时没想到啥好的例子，大致就说一些涉及到数据量的性能测试，比如报表统计，或者是大数据挖掘，查询等，怎么去估算数据量？
一般来说，数据都是有一定的生命周期的，时间的选取需要结合数据周期考虑。这里假设3年后系统性能仍然需要满足业务需求。
这里假设按年统计，比如第一年 10000，第二年 15000，第三年 20xx0，第四年25000，那么我们得出，以第一年为基准，数据增长率分别为 0.5，1，1.5，每年在上一年的基础上，以5000的速度增长
2、一些大数据量的性能测试除了和数据量相关，还涉及到数据分布等，比如查询，构造数据时需要结合实际，尽量贴近实际。
3、不同业务模块，涉及表不一样，数据量要求也是不一样的，需要有区别的对待。
1）请求顺序、请求之间相互调用关系2）数据流向，数据是怎么走的，经过哪些组件、服务器等
4）明确应用类型 IO型，还是CPU消耗性、内存消耗型- 弄清楚重点监控对象
5）关注应用是否采用多进程、多线程架构- 多线程易引起线程死锁、数据库死锁，数据不一致等
通常建议测试时先不考虑集群，采用单机测试，测试通过后再考虑使用集群，这样有个比较，比较能说明问题
2）明确下“需求分析-指标分析”中相关业务功能所需基础数据及数据量问题，因为那块需求分析时可能仅仅是大致估算下，评估指标是不是合理，需要认真再分析下
运行测试期间，部分虚拟用户执行某种业务的某个环节操作，部分虚拟用户执行该业务功能的其它环节
运行测试期间，部分虚拟用户执行某种业务功能，部分虚拟用户执行其它业务功能
注：这里用例没说到多少用户去跑，跑多久等，这里只是把他当作相同场景用例下的的一组组测试数据了。
根据用例合理的定义事务，方便分析耗时（特别是混合业务功能场景测试），进而方便分析瓶颈。
比如，购买商品，我们大家可以把下订单定义为一个事务，把支付也定义为一个事务。
针对每条用例，结合“系统分析”第4）点，明确可能的压力点（比如数据库、WEB服务器），需要监控的对象，比如tps，耗时，CPU，内存，I/O等
2）负载测试 - 压力测试- 稳定性测试- 强度测试注：如果测试稳定性，时间建议至少8小时；
好处：不仅比较真实的模拟现实环境，而且在性能指标比较模糊，且不知道服务器解决能力的情况下，可以帮我们确定一个大致基准，因为通常情况下，随着用户数的持续不断的增加，服务器压力也会随着增加，如果服务器不够强大，那么就会出现不能立即处理请求、处理请求失败的情况下，对应的运行结果图形中，运行曲线也会出现对应的.形态，比如从原本程一条稳定直线的情况，到突然极限下降、开始上下波动等，通过一系列分析我们就能得出服务器大致解决能力，供后续测试参考。
比如使用集合点，单独针对某个环节的并发测试，通常是针对某个环节的性能调优时使用。
保证系统能正常运行(通常是满足某些系统性能指标)的前提下，让被测对象承担不同的工作量，以评估被测对象的最大解决能力及存在缺陷而进行的测试
不保证系统能否正常运行的前提下，让被测对象承担不同工作量，以评估被测对象能提供的最大解决能力及存在缺陷而进行的测试
测试系统的长期稳定运行的能力。同疲劳强度测试的区别是，稳定性测试的压力强度较小，一般趋向于客户现场日常状态下的压力强度，当然在通过时间不能够确保稳定性的状态下，需要加大压力强度来测试，此时的压力强度则会高于正常值。
通常模拟系统在较差、异常资源配置下运行，如人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以评估被测对象在资源不足的情况下的工作状态
注：疲劳强度测试是一类特殊的强度测试，主要检测系统长时间运行后的性能表现，例如7x24小时的压力测试。
一般性能测试工具都是基于协议开发的，所以先要明确应用使用的协议2）工具选取
2.异步请求：发出一个调用请求，在没有正真获得请求结果之前，该调用可立即返回。该调用请求的处理者在处理完成后通过状态、通知和回调等来通知调用者。
通常为了排除网络型瓶颈，通常建议在局域网下来测试。通常，这里我的分析思路是这样的：
不同DNS，其速度和准确率是不一样的，比如114.114.114.114速度远比8.8.8.8快，如果有用到DNS（特别是压测机），需要仔细考虑下是否适当
如果测试时是基于UI层操作的操作，那么得估算页面平均大小，这个能通过浏览器自带工具查看打开单个页面服务器返回的请求数据大小。如果是测试时是基于接口层的请求测试，能够最终靠工具查看服务器响应数据大小。
注意：1） 这里监控不单单是服务器自身性能指标监控，如cpu，还包括事务耗时监控等
