作为开发人员，我经常发布不同版本的应用程序，我希望它们由用户进行测试以识别错误并确认是否满足要求。

我向用户简要介绍了我已更改的内容或者需要测试的新功能，但这似乎有些破绽，但结构却不太好。

我想知道其他人在迭代开发过程中要求UAT时采用什么方法或者程序。

谢谢。

解决方案

通常，我在excel中创建一个脚本，其中包含每个功能列表以及"预期结果"和"实际结果"列，并在"预期结果"列中填写了应该蒸腾的内容。对于我自己的用途，我包括一列作为项目ID的列。这对应于团队系统中的任务ID或者创建的项目计划中的WSB

我发现编写测试脚本非常耗时，通常比放置此修复程序所需的时间更长。由于我们在这里进行大量工作，因此我们没有时间创建有效的测试脚本。

通过我们的更改，我们将测试推到了两个级别，即应用程序支持和业务接受。我们希望通过技术方法和业务方法可以测试变更的大多数方面。为了让他们知道他们应该测试什么，我们附上了更改所影响的操作列表(添加产品，删除产品，编辑产品)。

我认为，这再加上强大的单元测试方法，是应对大量环境的最佳方法。

用户故事或者用例可能是我们要寻找的东西，我们是如何首先决定更改的，以及如何指定的。如果我们编写了一个小故事，或者编写了一个更大的实际结构化用例，则可以将其用作更改的规范，然后用户可以针对该故事进行测试，以查看实现是否与描述匹配。

我们正在寻求一种有效且有效的方式来以结构化方式进行UAT。我强烈建议使用成对或者组合测试设计方法。我已经在超过2打的概念验证项目中使用了这种方法，并且发现，与手动识别测试用例的传统方法相比，该方法始终导致每个测试者小时发现的缺陷数量大大增加。实际上，根据最近我在IEEE Computer上我合着的一篇文章中的报道，平均而言，我们发现平均每个测试者小时缺陷数是2.4倍。

该方法在此处的视频中进行了描述。抱歉，如果这似乎是"使用我的工具"插件。我不是那个意思。这是一种将带来巨大收益的方法，而不是我们选择用来设计测试的特定工具。 James Bach在他的satisfice.com网站上还提供了一个名为AllPairs的免费工具。我的观点是，使用任何此类工具都将产生显着优异的结果，因为这些工具旨在在最少数量的测试中产生最大的覆盖率。他们避免重复；此外，它们会自动识别并弥合手动测试用例识别方法无法弥补的潜在差距。

尽管像Hexawise这样的工具将能够(在几秒钟内)识别出应该比测试人员能够更好地运行和测试(在几天之内)运行的UAT测试用例，这是违反直觉的，但这是事实。自己尝试一下。让团队中的一名UAT测试人员执行使用Hexawise创建的20个端到端"黑盒"或者"灰盒"测试，并让其他测试人员测试他们通常会执行的测试。我敢打赌，执行20次Hexawise测试的测试员每测试一个小时会发现更多缺陷(并且会发现"重要"缺陷和"不重要"缺陷)。

遗憾的是，在相对复杂的一组测试人员之外，这些方法在测试社区中没有得到更多的了解，他们花时间阅读诸如Lee Copeland的关于测试设计方法的书之类的书。成对和组合方法始终如一地工作，它们在效率和有效性方面都有了极大的提高，并且使测试团队立即开始使用它们非常容易。

贾斯汀(Hexawise创始人)