然而，结果却比最初想像的要有价值得多，特别是因为开发人员也从其他开发人员那里得到了有关组件在使用时的真实感觉的早期反馈。此外，我们通常会发现大量错误，因为在这半小时的直观测试中，经常会执行功能，而这些功能甚至都不是最近更改的一部分。
因此，基本上，问题在于是否为此命名整个团队还有一些开发人员在一段时间内单击测试？
#1 楼
我们一直称此为错误放荡错误放荡我们使用的一些准则包括：
设置日期并将其放在团队的日程安排上
提供有关bash的目的/范围的指导-特定区域（处于危险状态，全球化，安全性等）或发生的任何事情
提供用于提交错误的模板（包括pri / sev等的指导）
提供奖励措施（食物，认可等）
在活动开始前至少1天发送邮件，并提供详细信息（环境，内部编号，区域，模板链接，POC等）
整天发送状态
/>鼓励探索专业知识/所有权以外的功能
第二天向所有参与者表示感谢，并总结bash的结果。
如果可能的话，我也鼓励人们摆脱困境他们的办公室（例如移动应用程序测试）或让他们与另一个人进行伙伴测试。
我们尝试过的另一个想法是制作一个游戏（例如，人们必须使用各种功能来解决难题）
#2 楼
听起来不错。您描述了至少两种活动：十个人在同一服务器上并行单击。我将其称为非正式负载测试。这是非正式的，即个人没有在协调他们的活动，并且可能没有遵循预定的（或可重复的）过程。尽管该过程是非正式的，但您仍然可以如前所述从中收集一些有用的反馈。
开发人员可以尝试其他开发人员的组件。我将其称为非正式的可用性测试。出于与上述相同的原因，我将其称为非正式。非正式的可用性测试对于发现错误和可用性问题仍然非常有用。
我将整个实践称为测试方。我之所以选择这个词，是因为它听起来非正式而有趣，而不是官僚主义。 （这也暗示了啤酒的可能性，这可能会增加参与度。）
#3 楼
在过去，我偶尔将其称为“测试巨星”。有时，我对其进行了形式化，甚至还增加了背景负荷元素：
http://www.allthingsquality.com/2010/04/automation-assisted-test-fest.html
在适当的情况下，这可能是非常有用的做法。
#4 楼
在Microsoft以及整个西雅图地区（无疑在其他地方）使用的术语是“ Bug Bash”。链接指向Wikipedia文章，该文章描述了您所描述的内容（目前尚不是好文章，但至少可以确认以这种方式使用了该术语）。有人在没有测试用例的情况下进行测试的测试称为“探索性测试”，而漏洞修复（使整个团队或公司花费一段时间“扑灭”产品以发现错误）是探索性测试中使用的一种技术。
#5 楼
探索性测试每个人在做什么听起来像是探索性测试。换句话说，您公司中的人员使用他们的领域知识来测试前端。我不认为它涵盖的测试的多线程方面没有正式的术语。
您可以将其称为探索性负载测试或手动体积测试。在人们从应用程序中发现的东西中发现了很多价值这一事实，从功能角度来看，这往往会导致我仅使用术语“探索性测试”来涵盖这两个领域（“探索功能和探索量”）。体积测试，但只剩下一部分。
评论
几个月前，我们的团队采用了“漏洞修补程序”，并发现它们具有惊人的价值-作为小型ISV，这也是让市场营销，销售，管理人员等了解您所从事工作的好方法！我们至少发现，大约一个半小时的会话时间足够长，足以使每个版本（大约每月）发现很多好的数据/问题，并且在那之后，收益递减。
– Bittercoder
2012年9月27日11:28