DevOps性能测试入门的4个想法

David Buch发布于2016年5月17日 如果您在财富2000强公司工作，很有可能您已经发现DevOps的好处。 至少这就是Gartner和IDC的观点。

但是，尽管大多数DevOps自动化包括开发、部署和一些回归测试，但是很少有公司拥有自动化的性能测试。我的猜测是，性能测试并非总是一帆风顺，并且自动化可能更具挑战性。 例如，构建可靠的性能测试环境和测试数据集本身就是一项任务。 如果测试环境必须通过频繁的测试来支持敏捷过程，则将变得更加困难。

为了帮助您实现性能测试的自动化，这里有4个技巧可以帮助您入门。

1 – 确定应该自动化的性能测试

首先，我们要说明一下，一般来说，技术通常可能最终成为开始使用DevOps以及进行性能测试的障碍。无穷无尽的技术、协议、工具和集成。把所有这些问题放在一边，从关注最终结果开始。也就是说，您的哪些性能测试是自动化的最佳候选?具体来说，在性能方面，您的哪些测试对于构建/发布的验证或失效至关重要?

例如，提供防病毒软件和Internet安全服务的AVG使用WebLOAD运行负载测试，以验证其收入关键页面的稳定性和响应时间。尽管性能测试也涵盖了其他方面，但关键业务领域的响应时间却是自动化的，并与软件版本相关联并定期运行。

在教育型ERP软件公司Ellucian上，性能测试小组有150-200个负载测试用例，这些用例每天运行（约3500个并发用户），以验证多个产品系列。但是，这些测试可验证其作为服务提供商的生产基础架构的可扩展性，这些测试已集成到DevOps流程中，并针对管道中的每个构建自动编排测试。

2 – 保存基准

在DevOps以及持续集成（CI）和持续交付（CI）的背景下，您通常需要将新的软件版本与某些历史基准测量结果进行比较。基准可以是过去的一组“硬编码”结果，也可以只是当前现场制作版本的性能统计信息。

如果检测到相对于基准的性能下降，则可以生成警报并调查问题。 另外，您可能会发现一些调整更改对性能产生了积极影响。 无论如何，基准线都可以帮助您凭经验了解每次测试运行的结果。

3 – 定义明确的成功与失败标准

在使任何事情自动化之前，您需要为每个测试明确定义通过/失败定义。

您可能会考虑以下一些测试目标：

• 响应时间 – 每个事务的最大响应时间，或多个事务的平均响应时间，超过此时间测试将被定义为失败。
• 错误率 – 可接受的事务错误率阈值。
• 命中数或每秒请求数 –每秒命中数的减少表明服务器可以处理较少的请求，您希望对其进行调查。
• 平均吞吐量 -虚拟用户在任意给定秒内从服务器接收到的平均字节数可以帮助您发现导致发送的数据超出所需的服务器问题。
• 服务器CPU或内存 –确保CPU或内存不超过特定阈值有助于避免潜在的崩溃和响应缓慢。

4 –就团队角色和结果分析流程达成一致

通过将性能测试集成到DevOps中，您将扩大其他组和个人的参与范围，而这些以前不是负载测试的一部分。例如，如果由于性能测试失败而没有将软件构建推到实时生产系统中，您可以确信性能测试组之外的涉众会对细节感兴趣。

这意味着您应该定义流程、工具和机制，通过这些流程、工具和机制，多个组可以访问测试结果、接收的报告，并可能深入查看详细信息。性能测试涉及大量数据，因此您需要为如何提供访问和分发信息定义清晰的过程。 上面的WebLOAD Web仪表板允许多个涉众共享预定义的结果视图，并带有有关性能阈值的警告。