性能测试基础知识

1.性能测试的类型/划分

1.1 压力测试

压力测试（stress testing）——测试系统在一定饱和状态下，例如CPU、内存、磁盘等饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。

特点：

1.目的：测试系统已经达到饱和状态的业务处理能力；
2.手段：通过模拟负载使系统资源达到一个较高的水平；
3.该方法一般用于系统稳定性测试

压力测试属于负面测试。

负面测试：测试系统是否不执行它不应该完成的操作。
正面测试：测试系统是否完成了它应该完成的功能。

1.2 负载测试

负载测试（load testing）——通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。
负载测试主要是为了找到系统的最大负载能力，为性能调优提供数据。

特点：

1.目的：找到系统最大负载能力；
2.手段：不断加压，直到超过预定的指标或者部分资源已经达到饱和状态。

1.3 性能测试

性能测试——模拟真实系统中用户行为来测试系统的性能，以确定是否能否能满足用户要求

1.4稳定性测试

稳定性测试（Endurance testing）——通过负载测试得出的较稳定的并发数做一个长时间的测试，主要观察系统是否存在内存等方面的问题。

2.性能测试的目的

• 能力验证/性能指标验证
• 规划能力
• 性能调优
• 缺陷发现

3.性能测试不同角色的关注点

开发设计的关注点

• 架构设计是否合理——系统架构
• 数据库设计是否存在问题——数据库设计
• 代码是否存在性能问题——代码
• 系统是否有不合理的内存使用——代码
• 系统是否有不合理的线程同步方式——设计或代码
• 系统是否存在不合理的资源竞争（异步）——设计或代码

运维的关注点（测试也需要关注）

• 服务器的资源使用是否合理——资源利用率
• 应用服务器和数据库资源使用是否合理——资源利用率
• 系统是否能实现扩展（架构也关注）——系统可扩展性
• 系统支持多少用户访问，系统最大业务处理量是多少——系统容量
• 系统性能可能的瓶颈——系统可扩展性
• 系统能否支持7*24小时的访问——系统稳定性

用户的关注点（测试也需要关注）

• GUI呈现时间（即速度、响应时间）
• 本地资源消耗是否合理

4.性能测试不同阶段的测试方法

开发/技术预演阶段：

• 架构设计、方案选定、数据库设计——压力测试，得出吞吐量（测试数据可以为公司积累沉淀用）
• 并发测试

系统测试/上线前：

• 负载测试——系统最大并发、最优并发、系统稳定——》响应时间、TPS（Transaction Per Second每秒事务处理量）、系统资源、系统所支持的用户或者处理能力

5.性能测试的流程

（1）计划测试
（2）测试设计
（3）创建脚本
（4）创建场景
（5）运行场景
（6）分析结果

6.性能测试前期规划

（1）分析应用程序

• 1）确定系统组件

  • 系统体系架构（B/S、C/S）以及核心framework
  • 各组件直接协议（http、web、services、socket、oracle）
  • 采用的开发语言
  • 网络拓扑结构
  • 各组件在系统架构中的作用
  • 软件、硬件配置

• 2）分析负载模型

  • 确定关键测试用例

    • 关键业务
    • 高访问量
    • 复杂的动态内容

  • 业务层面

    • 用户数
    • 关键用例吞吐率以及行为习惯——》负载测试

  • 用户体验

  • 数据来源：服务器端监控/数据库日志/专家估算

• 3）安全系数：在估计规模、成本、进度的时候，应该保留2~10的系数，以弥补我们在某个方面考虑的缺陷

（2）定义测试目标

• 度量最终用户的响应时间
• 定义最优的硬件配置
• 检查稳定性
• 度量系统容量
• 确定瓶颈
• ……

（3）制定测试计划

• 组织架构以及各自职责
• 测试资源（人力/工具）
• 搭建测试环境（开发、系统工程师、测试）
• 进度计划
• 沟通管理（例会、工作规范）
• 风险规避（技术攻关先行）

（4）制定测试方案

• 测试需求
• 测试方法与策略
• 测试环境
• 测试用例
• 测试场景
• 监控点

7.眼观六路

• 调试脚本

  • VuGen（脚本生成器）单次回放
  • VuGen多次回放
  • Controller单脚本多用户（并发性）
  • Controller多脚本多用户（验证是否脚本依赖）
  • extend log

• 压力测试——增加并发TPS已经无法上升

  1. 确认施压机资源是否充分（否——》下一步）
  2. 网络是否存在瓶颈（否——》下一步）
  3. 确认服务端哪个组件出现瓶颈（否——》下一步）
  4. 说明资源利用率不足，若能达到性能标准，可以降低硬件标准；若没有达到，需要考虑优化程序性能或者应用的配置

• 负载测试

  • 每秒处理的交易数—并发数关系：最佳并发数处理能力
  • 响应时间—并发数关系：最大并发数、用户感受

• 网络资源

  • 了解客户端和服务端网络带宽
  • 了解测试请求的是占用上行还是下行大
  • 如果是下行多，可以观察LR的throughput，是否存在瓶颈
  • 如果是上行大，可以通过sar -n DEV 12观察rxbyt/s、txbyt/s来确认瓶颈

• 硬件资源

  1. Cpu %idle是否小于15~20%（N：不是CPU瓶颈；Y：CPU，内存或IO转2）
  2. Cpu %wa是否大于10~15%(N：NO IO瓶颈为CPU瓶颈；Y： 内存或IO转3)
  3. Free –m看swap是否有用到或free是否小于100M（N：NO内存瓶颈为IO瓶颈；Y：内存瓶颈）
  4. 常用linux查看资源命令：top、free、vmstat、iostat、sar

PS：这是一篇复习/回顾文。