结构化UAT方法

Question

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

我给用户一个粗略的概念，告诉他们我修改了什么或者需要测试的新特性，但这看起来有点草率，结构也不是很好。

我想知道在迭代开发期间，其他人在请求UAT时采用了什么方法或过程。

谢谢。

Answer 1

我发现编写测试脚本非常耗时，通常比将修复放在适当位置所需的时间还要长。由于我们在这里做了大量的工作，我们没有时间来创建有效的测试脚本。

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

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

Answer 2

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

Answer 3

通常，我会在excel中创建一个脚本，其中包含每个功能列表和一个“预期结果”和“实际结果”列，其中“预期结果”列填充了应该发生的内容。为了便于我自己使用，我包含了一个列，它是项的id。这与Team System中的任务Id或创建的项目计划中的WSB相对应