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