结构化UAT方法

Question

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

我让用户大致了解我已经改变了什么或者需要测试的新功能，但这看起来有点打击，并且没有很好的结构。

我想知道其他人在迭代开发期间要求UAT时采取的方法或程序。

感谢。

Answer 1

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

通过我们的更改，我们将测试推向两个层面，即应用支持和业务接受度。我们希望通过技术方法和业务方法来测试变更的大多数方面。为了让他们知道应该测试什么，我们附上了一个受更改影响的操作列表（添加产品，删除产品，编辑产品）。

在我看来，加上强大的单元测试方法是大批量环境的最佳方法。

Answer 2

用户故事或用例可能是您正在寻找的，您是如何决定变更的，以及您是如何指定变更的。如果您编写一个小故事，或者更大的实际结构化用例，您可以将其用作更改的规范，然后用户可以测试该故事，以查看实现是否与描述相符。

Answer 3

通常我在excel中创建一个脚本，其中包含每个要素列表和“预期结果”和“实际结果”列，其中“预期结果”列填写了应该发生的内容。对于我自己的用途，我包括一个列为该项的id的列。这与Team System中的Task Id或创建的项目计划中的WSB相对应

Answer 4

您正在寻求一种有效且有效的方式来以结构化的方式进行UAT。我强烈建议使用成对或组合测试设计方法。我在二十多个概念验证项目中使用了这种方法，并发现，与传统的手动识别测试用例的方法相比，这种方法始终导致每个测试时间内发现的缺陷明显更多。事实上，平均而言，正如我最近编写的IEEE计算机article所报告的那样，我们发现每个测试人员小时平均平均 2.4 X.

。

视频here中介绍了该方法。如果这似乎是“使用我的工具”插头，请道歉。我不是故意的。 方法将带来巨大的好处，而不是您选择用于设计测试的特定工具。 James Bach还在他的satisfice.com网站上提供了一个名为AllPairs的免费工具。我的观点是，使用任何此类工具都会产生非常出色的结果，因为这些工具旨在以最少的测试数量生成最大的覆盖范围。他们避免重复;此外，它们还可以自动识别并消除手动测试用例识别方法无法关闭的覆盖范围中的潜在差距。

虽然像Hexawise这样的工具能够识别（以秒为单位）应该比测试人员能够识别和记录（以天为单位）更好的UAT测试用例，但这可能是违反直觉的，但它仍然是真正。亲自试试吧。让团队中的一个UAT测试人员执行使用Hexawise创建的20个端到端“黑盒子”或“灰盒子”测试，并让其他测试人员测试他们通常会做什么。我敢打赌，执行20次Hexawise测试的测试人员会在每个测试时间内发现更多缺陷（并且会发现“重要”以及“不重要”缺陷）。

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

贾斯汀（Hexawise的创始人）