性能测试

对于不同类型的系统，软件性能的关注点各不相同，比如:

从终端用户(也就是软件系统使用者)的维度来讲，软件性能表现为用户进行业务操作时的主观响应时间. 包含了系统响应时间和前端展示时间.

性能测试分为后端(服务器端)的性能测试和前端(通常是浏览器端)的性能测试

从软件系统运维(也就是系统运维人员)的角度，软件性能除了包括单个用户的响应时间外，更要关注大量用户并发访问时的负载，以及可能的更大负载情况下的系统健康状态、并发处理能力、当前部署的系统容量、可能的系统瓶颈、系统配置层面的调优、数据库的调优，以及长时间运行稳定性和可扩展性

系统运维人员必须在最大并发用户数和系统响应时间之间进行权衡取舍:

软件设计开发人员眼中，软件性能通常会包含算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试性这五大方面

算法设计包含的点:

架构设计包含的内容:

性能最佳实践包含的点:

数据库相关的点:

软件性能的可测试性包含的点:

系统部署级别的性能:

性能测试需要的技能

性能需求的总结和抽象能力;
根据性能测试目标，精准的性能测试场景设计和计算能力;
性能测试场景和性能测试脚本的开发和执行能力;
测试性能报告的分析解读能力;
性能瓶颈的快速排查和定位能力;
性能测试数据的设计和实现能力;
面对互联网产品，全链路压测的设计与执行能力，能够和系统架构师一起处理流量标记、影子数据库等的技术设计能力;
深入理解性能测试工具的内部实现原理，当性能测试工具有限制时，可以进行扩展二次开发
极其宽广的知识面，既要有“面”的知识，比如系统架构、存储架构、网络架构等全局的知识，还要有大量“点”的知识积累，比如数据库SQL语句的执行计划调优、JVM垃圾回收 (GC)机制、多线程常见问题等等

性能指标

包含了业务层面和后端服务器层面的两层含义

这个指标同时取决于业务并发用户数和用户行为模式，而且用户行为模式占的比重较大.获取用户行为模式的方法，主要分为两种

通俗来讲，响应时间反映了完成某个操作所需要的时间，其标准定义是“应用系统从请求发出开始，到客户端接收到最后一个字节数据所消耗的时间”，是用户视角软件性能的主要体现。

响应时间，分为前端展现时间和系统响应时间两部分。其中，前端时间，又称呈现时间，取决于客户端收到服务器返回的数据后渲染页面所消耗的时间;而系统响应时间，又可以进一步划分为Web服务器时间、应用服务器时间、数据库时间，以及各服务器间通信的网络时间

除非是针对前端的性能测试与调优，软件的性能测试一般更关注服务器端。但是，服务器端响应时间的概念非常清晰、直接，就是指从发出请求起到处理完成的时间，没有二义性; 而前端时间的定义，在我看来存在些歧义

虽然前端时间一定程度上取决于客户端的处理能力，但是前端开发人员现在还会使用一些编程技巧在数据尚未完全接收完成时呈现数据，以减少用户实际感受到的主观响应时间。也就是说，我们现在会普遍采用提前渲染技术，使得用户实际感受到的响应时间通常要小于标准定义的响应时间。

是最能直接体现软件系统负载承受能力的指标

空闲区间:当系统并发用户数较少时，系统的吞吐量也低，系统处于空闲状态
线性增长区间: 当系统整体负载并不是很大时，随着系统并发用户数的增长，系统的吞吐量也会随之呈线性增长
拐点: 随着系统并发用户数的进一步增长，系统的处理能力逐渐趋于饱和，因此每个用户的响应时间会逐渐变长。相应地,系统的整体吞吐量并不会随着并发用户数的增长而继续呈线性增长
过饱和区间: 随着系统并发用户数的增长，系统处理能力达到过饱和状态。此时，如果继续增加并发用户数，最终所有用户的响应时间会变得无限长。相应地，系统的整体吞吐量会降为零，系统处于被压垮的状态