结构化UAT方法

Question

作为开发人员，我经常发布不同版本的应用程序，我希望用户通过测试来识别错误并确认要求得到满足。

我给用户一个粗略的想法，说明我已经改变了什么，或者需要测试的新功能，但是这看起来有点麻烦，而且结构也不是很好。

我想知道在迭代开发过程中，在询问UAT时，其他方法或程序。

谢谢。

Answer 1

通常，我在excel中为每个功能列表和“预期结果”和“实际结果”列创建一个脚本，预期结果列中填写了应该发生的内容。为了我自己的用途，我加入了一个栏目，即项目的ID。这与Team System的任务ID或创建的项目计划中的WSB相对应

Answer 2

我发现编写测试脚本耗时耗时，通常比将修补程序置于其位置所用的时间要长。由于我们在这里所做的大量工作，我们没有时间创建有效的测试脚本。

随着我们的变化，我们通过两个层面的测试，应用支持和业务接受度。我们希望通过技术方法和业务方法来对变革的大部分方面进行测试。为了让他们知道他们应该测试什么，我们附上一个由更改（添加产品，删除产品，编辑产品）所影响的操作列表。

在我看来，这与单元测试方法相结合是高容量环境的最佳方法。

Answer 3

用户故事或用例可能是您正在查找的内容，您是如何决定首先进行更改的，以及您是如何指定它的。如果你写了一个小故事，或者更大的一个实际的结构化用例，你可以用它作为你的改变规范，然后用户可以测试这个故事，看看实现是否与描述相匹配。

Answer 4

您正在寻求一种有效且有效的方式来以结构化的方式进行UAT。我强烈建议使用成对或组合测试设计方法。我已经在超过二十个概念验证项目中使用了这种方法，并发现与传统的手动识别测试案例的方法相比，这种方法始终导致每个测试者小时发现更多的缺陷。实际上，正如我在最近的IEEE计算机article中报告的平均情况一样，我们发现平均每台测试仪小时的误差为2.4×X，平均为。

该方法在视频here中描述。道歉，如果这似乎是一个“使用我的工具”插件。我不是这个意思。这是方法，这将带来巨大的好处，而不是您选择用来设计测试的特定工具。 James Bach还在其satisfice.com网站上提供名为AllPairs的免费工具。我的观点是，使用任何这样的工具将产生显着优异的结果，因为这些工具旨在以最少数量的测试产生最大覆盖率。他们避免重复;此外，他们还可以自动识别并消除手动测试案例识别方法无法关闭的覆盖范围中的潜在差距。

尽管像Hexawise这样的工具能够识别（以秒为单位）UAT测试用例应该比测试人员能够识别和记录（在几天内）更好地运行，尽管如此。自己尝试一下。让团队中的一名UAT测试人员执行由Hexawise创建的20个端到端“黑匣子”或“灰盒子”测试，并让其他测试人员测试他们通常会进行的测试。我敢打赌，测试人员执行20个Hexawise测试会在每个测试小时中发现更多的缺陷（并且会发现“重要”以及“不重要”缺陷）。

这些类型的方法在相对复杂的测试人员群体之外，在测试社区中并不是很出名，他们花时间阅读了Lee Copeland关于测试设计方法的书籍。成对和组合方法一致地工作，它们在效率和有效性方面提供了巨大的改进，而且测试团队很容易立即开始使用它们。

贾斯汀（Hexawise的创始人）