这是一种很常见的做法。在微软，我们称其为 bug bash，我也听说过它称为 bug 搜寻，我不确定业界是否有一个标准术语。

1. 是的，我和许多其他团队都做过类似的事情。
2. 是的，我们几乎总能从中得到一些好的数据。
3. 尽可能多的人，通常是几个小时（1-4）。我们通常有 pm、dev、writers、test 和有时支持人员参与。
4. 您需要确定概述当前已知问题的列表，以免被一堆已知问题淹没。您还想给出一些尝试的示例，以便人们从基本的快乐路径中分支出来并真正探索。您还想尝试概述新功能和对以前版本的更改，以便您对这些事情更加关注。最后，如果你把它变成半竞争性的，那么它会很有趣并获得更多的参与。您可以为大多数错误、最多重复的错误（故意搞笑，因为这不是一件好事）、最严重的错误、最挑剔的错误等奖励。但是请记住奖励每个人，也许是午餐或披萨或其他东西避免出现此处出现的问题：Bug 搜寻和可能的替代方案？

1. 是的，我们过去做过类似的事情。
2. 是的。出于多种原因——性能问题、功能问题、团队精神等。
3. 这对我们来说不是很耗时。QA、开发、客户支持都参与了
4. 并没有真正遇到任何问题

除了邀请其他人参与外，我们还使用负载测试工具来应用随着时间的推移逐步增加的后台负载。第一块时间无负载，然后是中等负载，然后是大负载，等等。

进行手工工作的人被要求记下他们发现任何问题的具体时间，以便我们可以将其与当时施加的负载相关联。

我们立即跟进讨论了当系统速度变慢时功能方面的作用。

总而言之，它对我们很有效。

另见：http ://www.allthingsquality.com/2010/04/automation-assisted-test-fest.html

1. 是的。这是一家前公司的主要发布流程的一部分，并且在我参与的其他公司中以临时方式完成。

2. 是的。除了上述 Joe 所述的原因之外，让具有不同软件知识的人结合不同的业务视图通常会导致开发团队没有想到的问题/场景。

3. 时间长短不一。但是，您对 1 小时的想法几乎是完美的。大多数人可以留出一个小时来运行该软件。再长一点，你就会开始被人排斥。至于谁和多少百分比的员工，这取决于资源。如果您打算让每个人都在会议室中使用该软件，那么座位数就是您的限制。如果他们要在办公桌上使用该软件，则可能会邀请每位员工

4. 有两个主要问题，一个是覆盖范围，第二个是报告（无论是问题还是结论）。对于覆盖范围，您可以将软件拆分为业务领域并将人员指向每个领域（按业务重要性排序）。对于报告，除非您设置正式的报告程序，否则您将收到大量不同质量的报告。通常，我会发送一封电子邮件，其中包含主要标题，供人们在报告中使用。这样他们就可以点击回复。