这篇文章中，作者以诚恳的笔触将自己在组织beta测试的亲身感受与大家分享，希望可以给广大开发人员带来帮助。
下面是一些关于如何组织一次软件的beta测试的秘诀。需要注意的是，这里所说的“软件”指的是面向大量用户的软件，也就是我所称的“包装盒软件（注：“包装盒软件”指的是在商场中上架销售、有独立包装、外面用热收缩塑料膜密封的软件商品。）”（shrink-wrap）。这些秘诀对商业项目和开源项目都适用。不管你开发软件的目的是获得报酬，还是获得眼球效应，或是提高在同行中的知名度，都可以参考这些秘诀。但是，我关注的只是有大量用户的软件产品，而不是公司内部的IT项目。
1. 开放式的beta测试是没用的。要是你那样做，只可能有两种结果。一种结果是你有太多的测试者（就像Netscape那样），这些人向你反馈了大量的意见，你从中根本不可能得到有用的数据。另一种结果是，现有的测试者根本不向你反馈他们的使用情况，导致你无法得到足够的数据。
2. 要想找到那些能够向你反馈意见的测试者，最好的方法是诉诸他们“言行一致”的心理。你需要让他们自己承诺会向你发送反馈意见，或者更好的方法是，让他们自己申请参加beta测试。一旦他们采取了某些主动行为，比如填写一张申请表，在“我同意尽快发回反馈意见和软件故障报告”的选项上打勾，许多人就会发送反馈意见，因为他们想要“言行一致”。
3. 不要妄想一次完整的beta测试的所有步骤能够在少于8-10周的时间内完成。我曾经试过，结果是除非老天帮忙，否则根本不可能做到。
4. 不要妄想在测试中发布新的软件版本的频率能够快于每两周一次。我曾经试过，结果是除非老天帮忙，否则根本不可能有效。
5. 一次beta测试中计划发布的软件版本不要少于4个。我从来没试过少于4个版本，因为太明显了，那样不可能达到测试目的。
6. 如果在测试过程中你为软件添加了一个功能，那么哪怕这个功能非常微小，整个8个星期的测试也要回到起点，从头来过，而且你还需要再发布3个或4个新版本。我犯过的最大错误之一就是，在CityDesk 2.0的beta测试接近尾声的时候，我向软件中加入了一些保留空格的代码，这产生了一些意想不到的副作用（如果我们可以这样说），测试的时间不够了，我本应该将测试时间加长、进一步收集数据的。
7. 即使你有一个申请参加beta测试的步骤，最后也只有五分之一的测试者会向你提交反馈意见。
8. 我们制定了一条政策，所有向我们提交反馈意见的测试者都将免费获赠一份正版软件。不管你的反馈意见是正面的，还是负面的，只要你提交给我们，就能获得赠品。但是，在测试结束的时候，那些不提交反馈意见的测试者什么也不会得到。
9. 你需要的严肃测试者（即那些会把反馈意见写成3页纸发送给你的人）的最小数量大约是100人左右。如果你独立开发软件，那么这是你能够处理的反馈意见的最大数量。如果你有一支测试管理团队或专门的beta测试经理，那么设法分别为每个处理反馈意见的人找到100个严肃测试者。
10. 根据第7条，即使你有一个参加beta测试的申请步骤，最后也只有五分之一的测试者会真地使用你的产品并将反馈意见发送给你。那么，假定你有一个质量控制部门，里面一共有3个测试管理人员，这就意味着你必须批准1500份参加beta测试的申请表，因为这样才能产生300个严肃测试者。批准的数量少于这个数目的话，你就不会得到充分的反馈意见；批准的数量多于这个数目的话，你就会被许许多多重复的反馈意见淹没。
11. 大多数beta测试的参与者只是在第一次拿到这个程序的时候才会去试用一下，然后就丧失了兴趣。此后每次你推出一个新的版本并发送给他们，他们也不会有兴趣重新测试它。除非他们每天都在用这个程序，但是对于大多数人来说，这是不可能的。因此，你需要错开不同版本的测试对象，将你的所有beta测试参与者分成四组，每次发布一个新版本的时候，就把一个新的组加入测试，这样就能保证每个版本都有第一次使用这个程序的测试者。
12. 不要混淆技术beta和市场beta。我上面谈的这些都是针对技术beta，它的目标是发现软件中的错误和得到及时的用户反馈意见。市场beta则是软件正式发布前的预览版本，对象主要是新闻媒体、大客户和那些写入门教程的家伙（该教程必须在软件上市的同一天问世）。对于市场beta，你的目的并不是得到反馈意见。（虽然无论你怎么做，那些写书的家伙很可能都会滔滔不绝地告诉你一大堆意见。如果你置之不理，这些意见就会被复制粘贴进他们自己的书里。）