一、性能测试流程：
整体流程：收集需求-->搭建测试环境-->设计性能测试场景-->开发测试脚本-->执行测试-->收集数据-->分析和报告
1、收集需求：
- 什么时候结束性能测试？性能测试的周期有多长
- 执行性能测试需要的内部及外部资源
- 设计测试环境，测试环境需要尽可能与真实环境一致，注意这可能会耗费很多时间
- 冻结代码，保证每一轮性能测试的过程中代码不要被修改
- 保证测试环境只用作性能测试，换句话说保证性能测试的过程中没有其他人使用测试环境
- 确定性能测试目标。一般需要项目负责人拍板
- 确认核心用例。核心用例一定是来自核心业务，确认之后尽量文档化，用例化，并进行评审，如果不抓住核心用例的话，很有可能性能测试会变成无用功
- 部分测试用例需要分别监控(比如登录或搜索)，因为这是独立业务(微服务？)
- 确认用例的输入，目标及测试数据(比如多用户登录的话至少要提前创建一些测试用户)，测试数据尽量真实准确，并考虑数据的安全性及机密性
- 确定负载模型
- 设计测试场景，比如虚拟用户数，用户的思考时间，运行的速率等
- 确定被测系统,服务器及网络的关键性能指标
- 确定性能测试的输出，一般是以测试报告的形式，最佳实践是形成一套测试报告模版
- 确定性能缺陷处理流程
2、搭建测试环境：
- 尽可能争取多一点的时间来进行环境搭建
- 考虑部署模型。比如尽量让环境可以配置以得到不同的环境
- 考虑stub外部链接
- 考虑自己的负载生成能力，因为有时候我们需要生成足够大的负载
- 确保系统部署正确
- 为系统及支持软件提供足够的license
- 部署及配置性能测试工具(分布式)
- 部署好监控工具
3、设计性能测试场景：
- 测试类型（基准、容量、隔离、压力测试、稳定性）
- 思考时间和执行速度
- 确定每个用例的负载
- 确定每个用例的负载模型（最大并发、ramp up、混合模式）
- 让性能测试正确退出（达到执行时间、达到执行的迭代、数据被消费完，确保一定要准备足够多的数据）
- 是否需要模拟不同的带宽
- 确定后台监控策略
- 是否需要忽略浏览器缓存
4、开发测试脚本：
- 确定session data：很多时候session data是贯穿整个事务的，比较难把握，需要提前确定是使用session data还是target data
- 确定输入数据
- 确定回放性能脚本时所需要带来的额外变更：比如wordpress项目中创建post需要修改后台代码
- 确保性能脚本能正确回放：单用户，多用户
5、执行性能测试
二、APDEX
如何判断系统的性能是好还是坏？从直觉上分析，可以通过系统的响应时间是可以判断系统性能的好坏的。如果响应时间短，那么系统的性能就好，反之响应时间长，系统的性能就差。但是还有如下问题：
- 不知道在某个响应时间下用户是感到满意，还是觉得可以将就，抑或是觉得不能忍受。
- 使用平均响应时间来来度量系统的性能，那么就会有一个问题，也许有很多用户的响应时间大大超过系统的平均响应时间，对于这部分用户来说，这个系统完全是不可用、无法忍受的
- 不同的应用是有不同的响应时间的，比如web应用响应时间2s之内用户大概是可以忍受的，如果是移动应用的话，某个界面如果需要2s来渲染，那显然是不现实的。
APDEX的出现就是为了解决上述问题的，APDEX的倡导者认为应该有更好的办法来描述性能的好坏。APDEX将所有用户的响应时间转换为0-1之间的某个值，0表示没有用户满意，1表示所有用户满意。
首先确定2个响应时间，分别是用户可以容忍的时间T和用户不能容忍的时间F
- Satisfied（满意)：如果系统的响应时间小于T，那么可以认为系统的性能是令人满意的
- Tolerating（可容忍）:如果系统响应时间大于T小于F，那么可以认为系统的性能是可以容易的
- Frustrated（烦躁期）:如系统的响应时间大于F，那么可以认为系统的性能是无法忍受的
1、公式：
这个公式的意思就是将所有满意的请求个数加上二分之一的可容忍请求的个数再除以所有请求的个数，得出apdex的值。
2、例子：
有100个样本，我们定义T=3s，F=12秒，其中60个样本小于3s、30个样本在3s-12s之间、其他样本大于12s，那么apdex的值如下图所示：
详细介绍：点击
三、linux性能指标
Linux是一个由全世界各地开发者合作打造的开源操作系统。Linux的源代码可以在互联网上自由获取，并且在GPL(GNU General Public License)协议下自由使用。