我最近对识别软件可扩展性测试的模式非常感兴趣。由于不同软件解决方案的可变性，对于可扩展性测试软件的问题似乎有与设计和实施软件一样多的好解决方案。对我来说，这意味着我们可能可以为这种类型的测试提炼出一些广泛使用的模式。
为了消除歧义，我会提前说我正在使用可扩展性测试的wikipedia definition。
我最感兴趣的是提出具有详尽描述的特定模式名称的答案。
【问题讨论】：
标签： testing scalability design-patterns
我知道的所有测试场景都使用相同的测试基本结构，其中涉及在一个或多个针对要测试的处理代理的请求者上生成许多请求。 Kurt 的回答是这个过程的一个很好的例子。通常，您将运行测试以找到一些阈值并运行一些替代配置（更少的节点、不同的硬件等...）以建立准确的平均数据。
请求者可以是生成请求的机器、网卡、特定软件或软件中的线程。它所做的只是生成一个可以以某种方式处理的请求。
处理代理是实际处理请求并返回结果的软件、网卡、机器。
但是，您对结果的处理决定了您正在进行的测试类型，它们是：
负载/性能测试：这是最常用的一种。处理的结果是看在各个级别或在各种配置中处理了多少。同样，Kurt 在上面寻找的是一个例子。
平衡测试：扩展的常见做法是使用负载平衡代理，将请求定向到进程代理。设置与负载测试相同，但目标是检查请求的分布。在某些情况下，您需要确保在处理代理之间实现请求的均匀（或尽可能接近）平衡，而在其他情况下，您需要确保处理特定请求者的第一个请求的处理代理处理所有后续请求（通常需要这样的网络农场）。
数据安全：通过此测试收集结果并比较数据。您在这里寻找的是锁定问题（例如 SQL 死锁），它会阻止写入或数据更改在可接受的时间内被复制到您正在使用的各个节点或存储库。
边界测试：这类似于负载测试，只是目标不是处理性能，而是存储效果性能的多少。例如，如果您有一个数据库，那么在 I/O 性能下降到可接受的水平以下之前，您可以拥有多少行/表/列。
我还推荐The Art of Capacity Planning 作为关于该主题的优秀书籍。
【讨论】：
我可以在 Robert 的列表中再添加一种测试类型：浸泡测试。你选择一个合适的重测试负载，然后运行它很长一段时间——如果你的性能测试通常持续一个小时，那么运行它一整夜、一整天或一整周。您监控正确性和性能。我们的想法是检测随着时间的推移缓慢累积的任何类型的问题：诸如内存泄漏、打包、偶尔的死锁、需要重建的索引等。
这是一种不同的可扩展性，但它很重要。当您的系统离开开发车间并上线时，它不仅会通过增加更多负载和更多资源而“横向”变大，而且在时间维度上也是如此：它将在生产机器上不间断地运行数周、数月或数年，这在开发过程中还没有完成。
【讨论】：