10 步负载测试
4.77/5 (17投票s)
大多数软件公司都在对其产品进行负载测试。负载测试是当今最重要的测试类型之一……
引言
大多数软件公司都在对其产品进行负载测试。负载测试是当今最重要的测试类型之一。在2008年6月6日，亚马逊网站瘫痪了两个小时，很难计算这次宕机给亚马逊造成的具体损失，因为客户可能稍后回来购买，但其股价收盘下跌4.6%，至80.63美元。所有人都认为“他们知道如何处理负载”。
在这篇文章中，我不打算谈论负载测试工具或高级测试技术，而是想谈谈构建一个良好、精确且强大的负载测试套件的10个基本步骤。
步骤1 - 确定目标
此步骤的目的是确定并写下应用程序的性能目标。您应该问自己的关键问题是：“我的应用程序在负载下应该如何表现？”
我们应该考虑的主要参数是
响应时间 - 应用程序显示特定输出或执行特定计算所需的时间。示例：产品目录必须在3秒内显示。
吞吐量 - 通过通信通道成功传递消息的速率。示例：系统必须支持每秒100个请求。
资源利用率 - 一个经常被忽视的方面，资源利用率定义了您的应用程序在CPU、内存、磁盘I/O和网络I/O方面消耗了多少资源。
最大用户负载 - 确定您的测试硬件配置可以运行多少用户。
这可能是最重要的一步！
步骤2 - 确定关键场景（或配置文件）
什么是场景？
场景是预期用户路径，通常包含多个应用程序活动。
如何识别场景？
关键场景是指您有特定性能目标或对性能有显著影响的场景。这些场景代表用户随时间的业务活动。
例如：“打开关于窗口”将比执行“购买”操作消耗更少的资源。
与“打开关于窗口”不同，“购买”操作将涉及多项操作，例如：SQL、信用卡验证、IIS。
步骤3 - 确定工作负载
确定工作分布/比例 - 对于每个关键场景，确定工作的分布/比例。分布基于执行场景的用户数量（根据其配置文件）。
对于现有应用程序，此信息可以从IIS日志/计数器中获取，如步骤1所述。
对于新应用程序，此信息可以基于市场研究、历史数据、市场趋势和原型。
计算每个场景的用户负载 - 根据之前的数据；计算应用程序可能的最大并发用户数。使用每个场景的工作分布计算每个关键场景的用户负载百分比。例如，关键场景的负载分布可能类似于下表所示。
步骤4 - 确定指标
指标是您的性能目标的衍生品。它们用于衡量您的应用程序与性能目标相比的实时性能。此外，它们还有助于您识别应用程序中的问题和瓶颈。
网络特定指标：这组指标提供有关网络（包括路由器、交换机和网关）的整体“健康”和效率的信息。
系统相关指标：这组指标帮助您识别服务器上的资源利用率。这组指标包括CPU、内存、磁盘I/O和网络I/O指标。
平台特定指标：平台特定指标与用于托管您的应用程序的软件相关，例如.NET Framework公共语言运行时和ASP.NET相关指标。
应用程序特定指标：这些包括嵌入在应用程序代码中的自定义性能计数器，用于监控应用程序的“健康”状况。您可以使用自定义计数器来确定等待获取特定锁的并发线程数，或排队等待向Web服务进行出站调用的请求数。
步骤5 - 选择负载测试工具
在编写测试之前，我们需要选择合适的负载测试工具。
为了为我们和我们的应用程序选择合适的工具，我们需要进行研究；负载测试工具需要特定的知识，并且每个工具都有其优缺点。
每个人都可以学习如何使用负载测试工具，然而，不同的工具适用于不同的目的，选择正确的工具可能对我们的测试过程产生显著影响。
大多数工具都具有非常好的功能和高级特性。您将用于比较工具的首要参数之一是用户限制（或缺乏）以及该限制的可伸缩性。根据经验法则，尽量避免使用通过许可限制模拟用户数量的工具（更多用户=更多金钱）。
例如，Team System Test Edition没有用户限制，因此我们可以模拟尽可能多的用户，只要我们的硬件允许。
就我个人而言，我正在使用微软的Team System；如果您选择了这个工具，您可以联系我寻求帮助。
步骤6 - 创建测试用例
- 什么是测试用例？
- 涉及场景/用户配置文件的一组活动。
- 测试用例是根据前几个步骤中确定的场景和配置文件组合创建的。
每个测试用例都应包含预期结果，以便在执行后，每个测试用例都可以标记为“通过”或“失败”。
测试用例：搜索电话所有者
创建一个自动化测试并为其设置特定的负载配置。
示例：400个用户持续1小时
以及测试用例：搜索电话所有者的负载测试预期结果：
步骤7 - 准备/理解您的负载环境
我们的设置环境应尽可能地复制生产环境的架构。
在与生产环境相似的环境中模拟负载非常重要，因为即使是最小的硬件或配置差异也可能对我们的结果产生重大影响。
创建一个完全复制生产环境的测试环境可能很难，并且并不总是可行，但我们需要尽力而为，因为这个环境将帮助我们估算我们产品的负载结果。
我们必须了解我们环境的硬件限制，并在开始测试之前找到瓶颈。
示例：我创建了一个由2台计算机组成的负载环境，将运行10,000个并发用户，ISP提供1Mbps的网络带宽。
每个用户将打开浏览器并在www.live.com中搜索动态词语。
在一台机器上打开5000个浏览器？
我从没试过，但我相信CPU使用率会在一段时间内达到100%。
当CPU使用率达到100%时，计算机无法产生所需的负载，我们将得到错误的信息，因此这是我们的第一个瓶颈。
你认为1Mbps的带宽足以支持10,000个用户吗？
不！10,000个用户无法在1Mbps带宽下同时工作，这是第二个瓶颈。
步骤8 - 逐步运行
从少量用户根据用户配置文件进行负载测试开始，然后逐步增加负载。重要的是在每个步骤之间留出足够的时间，以便系统在下一组用户连接执行测试用例之前有足够的时间稳定下来。
缓慢增加用户数量将使我们更容易找到系统因负载而崩溃或挂起的精确点/阈值。以大量模拟用户开始测试将阻止我们有效地检测到该点/阈值。
分循环运行负载测试。每个循环都应实现一定的负载增量，并且应在循环之间留出分析和修复时间。检查每个循环的指标并记录下来，以便您可以显示负载已达到的证据。
步骤9 - 运行
成功实施步骤8后，系统被认为是稳定的，我们可以按照预先计划的工作负载运行完整的负载测试。
在运行测试之前，我们必须确保我们正在监控运行负载测试的计算机和承受负载的计算机。这将帮助我们发现测试两侧的瓶颈。
Team System Test Edition可以执行这种双重监控。
如果您的负载工具没有此功能，您可以使用Windows性能监视器 (Perfmon)，使用Perfmon的缺点是您将有两个或更多独立的图表需要分析。
步骤10 - 分析和评估结果
每次运行后，当然也在完整运行后，我们分析结果并对照指标进行检查，确保我们的目标已实现。
我们保存每次运行的结果并与其他运行进行比较，通过这种方式，我们可以注意到应用程序性能和负载的改进或恶化。
确保您可以分享您的负载和性能测试结果和评估——性能和负载测试是一项严谨的学科，但它也需要得到其他关键业务学科（如业务运营、高级管理层甚至财务部门）的理解。
尝试简化内容，以便这些特定人群能够理解：拥有某种图形报告功能（在工具中）有助于我们与组织的其他部门分享测试结果。
我的规则是——一个环境的结果不一定等于另一个环境的结果。
我说是吧……
示例：生产环境有10台计算机，负载环境有2台计算机，负载测试显示2台计算机可以承受超过1000个用户，那么10台计算机可以承受大约5000个用户吗？不！
那么，如果结果与生产环境不一致，为什么还要进行负载测试呢？
负载测试帮助您评估应用程序在负载下的行为
总结
话虽如此，我确信对于经验丰富的性能测试工程师来说，上述经验法则都是显而易见的——你们已经在试错中尝试过它们。对于所有其他希望了解如何开始性能和负载测试并完成任务的测试人员，我希望我用足够简单的语言解释了为创建良好、精确和强大的负载测试套件而建议遵循的基本逐步行动。祝你好运！
兴趣点
Team System Team Edition – http://msdn.microsoft.com/zh-cn/teamsystem
Windows Performance Counters - http://msdn.microsoft.com/zh-cn/library/aa373083(VS.85).aspx
Shai的博客 – http://blog.microsoft.co.il/blogs/shair