为什么进行性能测试
应用程序糟糕的性能表现，通常不能让企业达到预期的利益。
以最终用户的眼光看待性能
关注“应用程序”的性能，此处的“应用程序”指的是应用程序的所有部分（硬件、操作系统、系统架构、中间件、应用程序、网络等），而非指某一部分。
性能度量
性能度量的两种类型：服务型、效率型。
服务型指标：可用性和响应时间，衡量的是应用程序为用户服务效果的好坏。
- 可用性（Availability）：应用程序对于最终用户的可用时间。可用性不好，意味着最终用户无法有效地使用该应用系统，是很严重的问题。
- 响应时间（Response Time）：一般指系统响应时间（平均响应时间、90%的平均响应时间、方差等），即从用户端发起请求到接收到应用程序给出完整响应所经过的时间。
效率型指标：吞吐量和利用率，衡量的是应用程序在应用架构基础上对发挥效率的高低。
- 吞吐量（Throughput）：应用程序在单位时间内能处理的请求数量。例如，在一段特定的时间内对某个接口请求的次数。
- 利用率（Utilization）：占用系统资源的百分比。例如，当100个用户同时在线时，消耗了多少网络带宽，以及在服务器上内存、CPU、磁盘等使用情况。
性能标准
关于性能好坏的行业标准，没有这样的指导标准存在。不过，业内倒有一个约定俗成的标准，即响应时间的临界点为2秒，尤其对于 B/S 应用。
糟糕性能原因分析
性能问题通常会比较晚才发现，而且越晚发现，解决成本就越高。
性能测试成熟度级别
- 救火（Firefighting）：应用程序发布前很少或从来没有进行过性能测试的情况。所有性能缺陷（100%）都在生产环境上发现并解决。
- 性能验证（Performance Validation）：公司为性能测试单独安排了一段时间，而不是在产品的后期才开始进行性能测试。因此，在研发过程中，仍然有相当多的性能缺陷被发现（ 30% ）。这是当前绝大多数公司的做法。
- 性能驱动（Performance Driven）：在应用程序生命周期中的每一阶段都考虑了性能。因此，当系统上线后，出现的性能缺陷就不会太多（ 5% ）。性能驱动（Performance Driven）级别是所有企业应该追寻的目标。
糟糕性能的原因
- 系统设计阶段缺少性能方面的考虑（考虑整体系统集成后的性能）;
- 直到最后一刻才进行性能测试（性能测试越早越好）;
- 对系统的容量或规模没有足够的考虑（最终用户的规模和分布）;
- 对性能峰值预期偏低（12306）;
- 性能测试还不规范，没有有效的方案参考或实施;
- 没有使用性能测试自动化工具。
根本原因：在应用程序的整个生命周期中，性能测试未能得到应有的重视。
性能测试的用户概念
- 系统用户数：指所有可能访问这套系统的用户数，也叫系统的全部用户数。
- 在线用户数：指同时访问这套系统的用户数量。
- 并发用户数：在一个时间切面上同时向这套系统发起请求的用户数。
参考文档
《应用程序性能测试的艺术》
