我成为测试人员数年,在很多时候负载测试常常让我感觉如芒刺在背。它需要花很长时间来实现一个定制的解决方案,但现代的方法模拟负载又并不是行之有效的。众包测试在我看来就是一种负载测试;它可以使您在许多不同的环境中将一个特定的“东西”在大量的测试人员中测试。但就像所有类型的测试一样,我相信它有一个适用的时间和地点。
让数据说话
我最近参加的一个会议上展示了一个众包测试最好的案例(尽管不是会议的目的)。让我重现一下当时的场景。想象一下，一个在酒店举行的超过800人参加的会议,再加上这是一个技术性会议。启用无线设备的数量是大约每3位出席者就有一个。除此之外,许多与会者都入住该酒店,在他们逗留期间每个人都可以使用免费wifi。
当酒店人员在设置WIFI的时候，他能够预期到如此大的使用量吗？
第一天结束的时候，你并不能质疑酒店的服务。我们都有一个通过我们的房间门连接的不会收取费用的网络。然而,作为一个参展商,这不是一个试图证明使用云端的虚拟机的好时机。
与前面的示例不同,我认为有些情况下,应用测试众包形式确是不必要的。过去我曾经参与过得一个产品，发布测试周期大约为两周。如何处理在许多遗留产品中常见的情况,这种问题又来了。有一些人建议众包测试，把公司看作是服务提供者。然而，我相信这是一个滥用的词了,而且它为大家建立了什么。产品是很复杂的,需要比较深入的理解才能确定一个问题是否实际上是一个问题,这不是一个典型的以用户为中心的应用程序。它不是一个大众市场的产品,设计语言环境和语言的多样性是一个因素。它也并不是完美到用户很难找到几个被确认为是Bug的产品，此情景下，关键问题确实发现的大量问题是否被记录且反馈。
时间和地点
我们无可否认测试众包的力量,事实上,它使不同的人,在不同的空间,测试在现实的真实世界的场景。但在努力加快测试的情况下,人们不应该选择测试众包。测试众包有巨大的能量,但使用它时，应该经过一个深思熟虑的选择,确保它是适当的技术。
关于作者
艾玛·阿姆斯特朗(@EmmaAtester)是一个测试工程师，all-round do-gooder at Red Gate，他为软件质量服务了超过13年。在此期间，她擅长手动和自动测试，从而有机会从编译器深入到web应用程序。
我成为测试人员数年,在很多时候负载测试常常让我感觉如芒刺在背。它需要花很长时间来实现一个定制的解决方案,但现代的方法模拟负载又并不是行之有效的。众包测试在我看来就是一种负载测试;它可以使您在许多不同的环境中将一个特定的“东西”在大量的测试人员中测试。但就像所有类型的测试一样,我相信它有一个适用的时间和地点。
