《JMeter实战》第二章 性能测试初体验 摘录

• 设计模型：圈定性能测试范围后，把业务模型映射成测试模型。什么是测试模型呢？比如一个支付系统需要与银行的系统进行交互，由于银行不能提供支持，我们就要开发程序去代替银行系统功能（这就是挡板程序，Mock程序），保证此功能的性能测试能够开展；这个过程就是设计测试模型。用例只关注业务，模型还需关注如何实现，是否具有可操作性，可验证性，最后根据不同的测试目的组合成不同的测试场景。
• 计划编写：范围，资源，时间，工作内容，风险。
• 测试数据准备：存量、历史业务数据，考虑数量与分布。
• 测试执行： 同样脚本不同执行人员得出的结果可能差异较大，差异主要体现在场景设计与测试执行上。

性能测试成功与失败要素

• 性能测试有几大难点：需求分析，场景设计，性能诊断调优，环境搭建和模拟
• 失败原因：需求分析方面没有做到位，不能准确地预估用户行为，在场景上不能复现用户操作，无法把需求体现在脚本和场景设计上，无法模拟真实的系统负载。
• 性能测试要点：

1. 评估系统，需求分析: 对于初次上线的系统，需要用同行的系统数据，进行用户行为分析和商业数据结构的估算法推算出要验证的模型的能力。对于已经上线的系统，通过运维人员获取TPS和时间的比例分布图，用户数和时间的分布图，数据库ER关系图，容量数据等精确得出性能需求。

2. 场景设计、用例设计: 如何有效地组织测试用例？按业务分布，业务量，业务时段，业务角色来综合分配用户数、执行时间、执行比例等。

3. 测试执行、是否通过

4. 性能诊断优化

不同角色看性能

1. 黑盒测试只关心应用程序的单步响应时间：操作应用界面->数据请求经过网络发送->服务器前端接收处理->在DB Server获取相关数据->前端处理后返回数据->应用界面收到数据响应下一步。

2. 开发：架构合理性，数据库设计合理性，代码，系统里内存的使用方式，系统里线程使用方式，系统资源是否有恶性，不合理竞争

3. 系统管理员：硬件资源利用率，JVM, DB,换哪些硬件能提高系统性能，系统能否支持7*24的服务，扩展性、兼容性、最大容量、可能的瓶颈

4. 性能测试：服务器硬件性能，根据需求和历史数据制定性能目标，建立性能通过模型，对开发代码框架和硬件框架进行性能分析，针对开发发布版本的基准测试，执行软件性能验收及稳定性测试，生产环境的配置和优化，制定性能测试的场景设计，协调各部门配合，特定的性能分析

性能测试工具选择

专业、稳定、高效，简单易上手，在测试脚本上不用花太多时间，有技术支持，文档完善，不用在疑难问题上花费时间，集中精力在性能分析上，要考虑投入产出比。

性能测试相关术语

1. 负载：模拟业务操作对服务器造成压力的过程。
2. 性能测试：模拟用户负载来测试系统在负载情况下，系统的响应时间、吞吐量等指标是否满足性能要求。
3. 负载测试：在一定软件环境下，通过不断加大负载来确定在满足性能指标情况下能够承受的最大用户数。
4. 配置测试：为了合理地调配资源，提高系统运行效率，通过测试手段来获取、验证、调整配置信息的过程。
5. 压力/强度测试：在一定软硬件环境下，通过高负载的手段来使服务器资源处于极限状态，测试系统在极限状态下长时间运行是否稳定，确定是否稳定的指标包括TPS, RT, CPU Using, Mem Using等。
6. 稳定性测试： 在一定软硬件环境下，长时间运行一定负载，确定系统在满足性能指标的前提下是否运行稳定。
7. TPS：每秒完成的事务数（成功）
8. RT/ART: 响应时间/平均响应时间，指一个事务花费多长时间完成。
9. PV(Page View）：每秒用户访问页面的次数
10. Vuser虚拟用户：模拟真实业务逻辑步骤的虚拟用户。
11. 并发：狭义的并发即所有的用户在同一时刻做同一件事情或操作。广义的并发即多个用户对系统发出了请求或者进行了操作，但这些请求或操作可以是不同的。

性能测试通过标准