所有新功能都必须通过betatest吗？

Question

显然，小的可用性修复和错误修复直接进入稳定的产品。那么小的新功能呢？你能负担得起在内部测试后发布它们吗?还是必须先得到客户的改进？

情境:这是一个年轻的商业项目，由一人公司生产.它有一个现有的用户群，是它的第二个主要版本。以前的测试已经产生了一些结果，但是大多数反馈来自稳定的产品，而不是测试版。

Answer 1

如果您的代码具有良好的测试覆盖率，包括单元测试和集成测试，并且它不是任务关键软件，我个人认为跳过beta测试版本没有坏处。毕竟，只有当人们实际使用beta测试来测试问题时，测试版测试才是有用的，而这里的情况听起来并非如此。

Answer 2

当然，理想情况下，您希望实际用户有机会测试新功能。但这并不总是可以做到的/实际的，而这样做的努力并不总是有回报的。我同意，在这种情况下，beta测试并不总是产生您需要的信息。对于小的变化，最有用的是由测试版测试人员进行一轮快速的“测试”，以确保没有明显的问题。

如果你对内部测试很满意，那么你可以做的就是让那些想要它的人在短时间内可以使用测试版。在你的网站上，或任何适当的地方。您可能会得到一些反馈，可能不会(取决于特性和规模/性质的用户基础)。在简短的“公开测试”之后，除非有重大问题被报告，否则把它发送出去。

如果你的用户基础允许，也许可以建立一个小的邮件列表的用户谁会有兴趣尝试测试版。这可以得到一个测试版到一些客户手中，只是为了确保没有任何节目停止，你可能会错过。这不一定是一个正式的测试过程。

这里的另一个选择是分离您的开发渠道。如果您的软件中内置了一个自动更新程序，请为用户提供一个选项，让用户知道测试更新的情况。将测试版更新放到网上，当你对它满意时，把它标记为一个发布版，这样其他人都会得到更新的通知。这样你就可以做一个“软”滚动，有一个子集的用户得到更新，所以如果有问题，只有10%的用户会受到影响，而不是100%。

Answer 3

我不想阻止测试版测试，但您可能想看看回归测试，以确保您的“修复”不会破坏任何其他。我收集每个新功能的测试计划，以便以后可以重新测试这些特性在引入新功能时不会中断。测试系统中最常用和最重要部分的基本计划，与系统特定部分的详细计划的链接似乎最有效，这样您就可以将测试集中在特定的版本上。

如果一个完整的、书面的回归测试对你来说是太多了，那么就假装向一个想象中的观众展示软件的特性。我发现更多的虫子这样..。