为什么要进行性能测试
1.1 以最终用户的眼光看待性能
"性能" 是用户的一种最终感受.一个性能优异的应用程序,在最终用户执行某项任务时,程序不会产生过度的延迟而引起用户的不满.
1.1.1 性能度量
我们将它们划分为两种类型:服务型和效率型. 服务型指标有: 可用性和响应时间.它们所衡量的是应用程序为用户服务效果的好坏. 效率型指标有:吞吐量和利用率.它们所衡量的是应用程序的应用架构基础上发挥效率的高低.
- 可用性: 它是应用程序对于最终用户的可用时间(就是我们平常说的平均无故障时间.系统在不出现故障的情况下可以运行的最长时间.有的时候也叫它作系统的'可靠性')
- 响应时间:应用程序对用户请求给出响应的时间.从用户端发出请求到接收到应用程序给出的完整响应所经历的时间.
- 吞吐量: 面向应用程序的发生频率.如在一段特定的时间内对某个web页面点击的次数（每秒钟点击数 Hits/s:单位时间向web服务器发出的HTTP请求数，这里的请求包括HTML资源的请求和非HTML资源的请求)
- 利用率：占用系统资源的百分比。例如，当1000个用户同时在线时，在应用程序上消耗了多少网络带宽，以及在服务器上占用了多少内存等。
我们将以上两种类型的指标结合起来考虑，就能够较准确地衡量一个应用程序的性能，以及它在应用框架基础上对系统能造成的影响。
1.1.2 性能标准
目前还没有关于一个性能好坏的行业标准，业内倒是有许多非正式的标准，试图对系统的性能好坏做出评价。
- 超过15秒：出现这种情况，就基本排除了交互的可能性。
- 超过4秒：这样的延迟一般对于一个要求最终用户保存在短暂记忆里的会话来说太长了，这样的延迟将会妨碍解决问题的活动和破坏数据的录入。然而，当一个事物完成之后，4~15秒的延迟是可以忍受的。
- 2~4秒：超过2秒的延迟可以被这种需求的高度集中所抑制。当用户专注地去完成一项手头的任务时，终端的一个2~4秒左右的延迟看起来就似乎非常长了。同样的，在一个无关紧要的任务结束后，2~4秒的延迟是无关紧要的，又是可以接受的。 当一个买家在输入了她才地址和信用卡号码之后，让她等待2~4秒时间，她也许可以接受，然而如果是在早先阶段，当她正在比较不能的产品功能差异时，却又是不可容忍的。
- 低于2秒：当系统的用户需要记住几个响应消息时，此时的响应时间很短，如果要记住更为详细的信息，则要求就更高了，要求响应的时间不能超过2秒。因此，对于比较复杂的活动，例如通过不同的规格尺寸去浏览相机产品时，2秒是一个很重要的响应时间限制。
- 亚秒：对于那些思想密集型的工作来说（比如一本书），尤其是一个图形应用程序，响应时间要非常短，才能够保持用户的兴趣和吸引他长时间的关注。当一个艺术家将一副图片拖曳到另外一个位置时，程序必须能够立即对他下一次的创意给出响应。
- 0.1秒：在键盘上敲下一个按键，并在屏幕上出现相应的字符，或鼠标点击屏幕上一个对象，这种响应几乎是瞬间的。 很多电脑游戏都会要求非常快的交互响应。由此可见，关键的响应时间临界点是2秒。对于普通用户来说，响应时间超过2秒势必会对他们的使用造成一定的影响。
1.1.3 互联网的发展对于应用程序带来了商机也带来了性能方面的挑战
性能测试导入：
性能驱动(”Performance Driven"): 在程序生命周期中的每一个阶段，均对系统性能加以考虑。因此，当系统上线之后，出现的性能缺陷就不会太多（5%）。对企业来说，这是性能测试模型应该努力追求的目标。
大多数应用程序都是基于可独立进行测试的组件进行开发的，而这些组件在单独执行的时候，性能可能都还不错，然而同样重要的是，必须将整个系统作为一个整体来考虑。这些组件之间需要具有良好的交互性，才能在集成后达到一个良好的性能。
针对性能问题的测试越早开始越好，最好不要到了最后一刻才开始。
有多少用户在实际使用这套系统？
会有多少用户同时使用这套系统“？
用户是如何连接到系统上来的？
随着时间的推移，预计会增加多少用户访问？
最终应用程序架构是什么样？服务器的数量和位置如何分布？
网络的容量会对应用程序有什么样的影响？
性能测试过程中常说的几种用户的概念：
1）系统用户数：指所有可能访问这套系统的用户数，也叫系统的全部用户数
2) 在线用户数：指同时反问这套系统的用户数量
3）并发用户数：在某个时间切片上同时向这套系统发起请求的用户数。