前言
Q：当我们谈起性能测试的时候，到底关注的是软件的什么内容？
A：目前最普遍的理解就是软件处理的及时性
衡量软件性能的四个维度
衡量软件性能的四个维度：终端用户、软件开发人员、系统运维人员、性能测试人员
一、终端用户
关注点：用户在界面上完成一个操作，到系统把这次操作的结果以用户能察觉的方式展现出来的全部时间 = 系统响应时间+前端展示时间
二、系统运维人员
关注点：大量用户并发访问时的负载，以及更大负载情况下系统的健康状态、并发处理能力、长时间运行稳定性和可拓展性
三、软件开发人员
关注点：算法设计、架构设计、数据库相关…
四、性能测试人员
关注点：算法、架构、数据库、性能最佳实践、性能可测试性
既要能够准确把握软件的性能需求，又要能准确定位引起“不好”性能表现得制约因素和根源，并提出相应的解决方案
性能测试四个角度
一、性能基准测试
每次对外发布产品版本前完成，执行固定的测试场景得到系统的性能测试报告，与上一版本发布的指标进行对比，达到保证新发布的系统整体性能没有下降的目的
二、稳定性测试
长时间（7*24h）来观察系统长期运行过程中是否有潜在问题
三、并发测试
高并发情况下验证单一业务功能
四、容量规划测试
性能测试关注点
不同类型系统
web类/手机端：一般以终端用户能感受到的端到端的响应时间来描述系统的性能
非交互式的应用：事情处理的速度、单位时间的事件吞吐量
并发用户数 响应时间 系统吞吐量
一、并发用户数
业务层面：实际使用系统的用户总数
后端层面：同时向服务器发送请求的数量
潜在用户数：拥有系统账号
业务并发用户数：登录了系统
实际并发用户数：真正对服务端产生了压力。取决于业务并发用户数+用户行为模式（停在界面未操作、进行了服务端相关操作…）
关键一环：分析用户的行为模块（例如：准点活动、商品秒杀、常规时间段…）
分析方法：
1.根据系统日志进行分析
2.行业类似系统的统计、多方收集到的系统用户信息
二、响应时间
前端展示时间：客户端收到服务器返回的数据后，渲染页面所消耗的时间
系统响应时间：发起请求到处理完成的时间
一般更关注服务器端
三、系统吞吐量
1.ThroughPut TPS
2.计算方式：requests/second、pages/second（考虑HTTP或业务层面） bytes/second（考虑系统/网络层面）
常用性能测试方法
一、后端性能测试：通过模拟大量的并发用户请求，获取系统性能的各项指标
关注：CPU、内存、磁盘、网络…
场景设计：1.基于性能需求目标的测试验证 2.探索系统的容量，验证系统容量的可拓展性
二、前端性能测试
关注：页面渲染时间、资源加载顺序、请求数量、前端缓存使用情况
优化：减少HTTP请求次数、减少DNS查询次数、避免页面跳转、使用CDN、压缩传输文件
三、代码性能测试：单元测试阶段就对代码的性能进行必要测试和评估，寻找底层代码的效率问题
四、压力测试：不断对系统施加压力，验证系统处于临界饱和阶段的稳定性，试图找到系统的瓶颈点
五、配置测试、并发测试、可靠性测试
性能测试的应用领域
一、能力验证
验证系统在A条件下是否具有B能力。在明确的软硬件环境下，根据系统性能需求设计测试方案和用例。
常用方法：后端性能测试、压力测试、可靠性测试
二、能力规划
采用探索性测试的方法来了解系统的能力，关注如何使系统达到要求的性能和容量
解决的问题：能否支持未来一段时间内的用户增长…
三、性能调优
解决性能测试过程中发现的性能瓶颈问题
四、缺陷发现
完整的性能测试流程
一、性能需求获取
二、性能场景设计
三、性能测试脚本开发
四、性能场景实现
五、性能测试执行
六、性能结果报告分析
七、性能优化
八、性能再验证