性能测试教程1简介
性能测试类型
1). 负载测试
测试应用程序在正常和峰值使用时的性能。检查应用程序对用户请求的响应，以及在不同用户负载下在可接受的容许范围内持续响应的能力。
主要的考虑因素有：
- 应用程序的最大负载是多少？
- 在应用程序开始出现意外前，应用程序能够承受的最大负载是多少？
- 在系统变慢或出现崩溃之前，数据库能够处理多少数据？
- 是否有任何网络相关的问题需要解决？
2). 压力测试
该测试还提供了系统可以承受的最大负荷范围。
压力测试采用渐进式方法，即逐渐增加负载。测试从应用程序已经测试过的负载开始。然后慢慢地增加更多的负载来给系统施加压力, 服务器对请求没有响应的点被认为是断点。
要解决以下问题。
- 系统在崩溃前能承受的最大负荷是多少？
- 系统是如何崩溃的？
- 系统一旦崩溃，是否能够恢复？
- 系统在处理意外负载时，有多少种方式会发生崩溃，哪些是薄弱节点？
3). 体积(Volume)测试
验证应用程序的性能是否受到应用程序所处理的数据量的影响。为了执行批量测试，需要将大量的数据输入到数据库中。该测试可以是增量测试或稳定测试。在增量测试中，数据量是逐渐增加的。
一般来说，随着应用的使用，数据库的规模会越来越大，这就需要对应用进行重度数据库的测试。
4). 容量测试
容量测试主要解决以下问题。
- 应用程序是否能够支持未来的负载？
- 环境是否能够承受即将增加的负载？
- 为了使环境有足够的能力，需要哪些额外的资源？
容量测试用于确定一个给定的网络应用程序能够支持多少用户和/或事务，并且仍然能够满足性能要求。在这个测试过程中，处理器容量、网络带宽、内存使用量、磁盘容量等资源都会被考虑并改变，以达到目标。
4). 可靠性/恢复性测试
可靠性测试或恢复测试--是验证应用程序在发生故障或异常行为后是否能够恢复到正常状态，以及需要多长时间才能恢复到正常状态（换句话说时间估算）。
如果一个在线交易网站发生了故障，用户在一天中的某个时间点(高峰期)无法买入/卖出股票，但在一两个小时后就能买入/卖出，我们就可以说这个应用是可靠的，或者说从异常行为中恢复过来了。
性能测试流程
- 需求分析/收集
性能团队与客户互动，以确定和收集技术和业务需求。这包括获取应用程序的架构、技术、使用的数据库、目标用户、功能、应用程序用途、测试要求、硬件和软件要求等信息。
- POC/工具选择
可用工具的列表取决于工具的成本、应用程序使用的协议、用于构建应用程序的技术、我们模拟测试的用户数量等。在POC期间，为确定的关键功能创建脚本，并与10-15个虚拟用户一起执行。
- 性能测试计划和设计
进行测试规划和设计。
测试规划包括性能测试如何进行的信息--测试环境、工作负载、硬件等。
- 性能测试开发
- 性能测试建模
性能负载模型是为测试执行而创建的。这一步的主要目的是验证给定的性能指标(由客户提供)是否在测试中实现。创建负载模型有不同的方法。大多数情况下使用 "Little's Law"。
- 测试执行
场景是根据Controller或Performance Center中的Load Model设计的，但初始测试并没有与Load Model中的最大用户一起执行。
测试执行是逐步进行的。例如，如果最大用户数是100个，则先以10个、25个、50个用户等场景运行，最终转为100个用户。
- 测试结果分析
测试结果是性能测试人员最重要的成果。这是我们可以证明性能测试工作所能提供的投资回报率(ROI)和生产力的地方。
一些有助于结果分析过程的最佳实践。
- 给每个测试结果取一个独特而有意义的名字--这有助于理解测试的目的。
- 在测试结果摘要中包含以下信息
- 失败的原因
- 与上一次测试相比，应用程序性能的变化。
- 从应用构建或测试环境的角度出发，在测试中做出的改变。
- 在每次测试运行后做结果总结是很好的做法，这样就不会每次参考测试结果时都要编制分析结果。
- 一般需要多次测试运行才能得出正确的结论。
- 结果总结中最好有以下几点。
- 测试的目的
- 虚拟用户数
- 情景摘要
- 测试时间
- 吞吐量
- 图形
- 图表比较
- 响应时间
- 错误
- 建议
- 报告
测试结果应该简化，使结论更清晰，不需要任何推导。开发团队需要更多关于分析、结果比较的信息，以及如何获得结果的细节。
测试报告如果能简明扼要、描述性强、切中要害，就可以认为是好报告。
性能测试的最佳实践
- 规划
尽量确定最常见的工作流程，即必须测试的业务场景。如果应用程序是现有的，那么检查服务器日志，了解最经常访问的场景。如果应用程序是新的，则与项目管理团队讨论以了解主要的业务流程。
计划负载测试的方式，你要覆盖广泛的工作流程，如轻度使用、中度使用和峰值负载。
你需要执行很多周期的Load Test，所以尽量创建一个框架，这样你就可以反复使用相同的脚本。另外，尝试对脚本进行备份。
尝试分析一个测试要运行多长时间，是1小时？8个小时？一天还是一周？通常情况下，长时间的测试会发现很多重大的缺陷，比如操作系统的bug、内存泄露等。
如果你的组织正在使用任何APM(应用程序监控工具)，那么你可以在测试运行期间加入它，这样你就可以很容易地发现性能问题，并更容易地找出根本原因。
- 开发
在开发脚本即录制的时候，尽量根据计划中提到的业务流名称，给出一个更有意义的事务名称。
不要录入任何第三方应用。
压力打到应用程序的后端，而不仅仅是缓存服务器。
- 执行
确保在类似生产的环境中运行测试，包括SSL、负载均衡器和防火墙等因素。这对于模拟系统的真实负载是必要的。
尽量创建一个非常现实的工作负载，如果是现有的应用程序，你可以通过检查服务器日志来获得，如果是新的应用程序，你需要从业务团队获得这些信息。
千万不要用生产规模一半的环境来运行测试来得出结论，总是建议在与生产环境相同的环境中进行测试。
在执行长期运行的测试时，尽量每隔一段时间就观察运行情况，以确保测试顺利进行。
- 分析
试着分析应用程序，先增加几个重要的计数器，当发现瓶颈时，再试着增加与瓶颈有关的计数器。这样一来，将有助于更容易地找到问题所在。
一个应用程序失败的原因有很多，比如它可能无法响应请求、响应错误代码、你的验证逻辑失败或者响应速度太慢。所以，在得出结论之前，尽量研究一下所有这些问题。
