0

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

我让用户大致了解我所做的更改或需要测试的新功能，但这似乎有点草率而且结构不太好。

我想知道其他人在迭代开发过程中要求 UAT 时采取了哪些方法或程序。

谢谢。

4

4 回答 4

2

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

于 2008-09-25T23:53:32.923 回答
2

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

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

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

于 2008-09-25T23:33:55.310 回答
1

通常，我在 excel 中创建一个脚本，其中包含每个功能列表和一个“预期结果”和“实际结果”列，其中“预期结果”列填写了应该发生的内容。为了我自己的使用，我包含一个作为项目 id 的列。这对应于团队系统中的任务 ID 或创建的项目计划中的 WSB

于 2008-09-25T23:23:14.227 回答
0

您正在寻找一种高效且有效的方式来以结构化的方式进行 UAT。我强烈建议使用成对或组合测试设计方法。我在超过 2 打的概念验证项目中使用了这种方法，发现与手动识别测试用例的传统方法相比，这种方法始终导致每个测试人员每小时发现更多的缺陷。事实上，正如我最近与人合写的一篇 IEEE 计算机文章中所报告的那样，平均而言，我们发现每个测试人员每小时的缺陷数是平均的 2.4 倍。

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

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

遗憾的是，除了一群相对成熟的测试人员花时间阅读 Lee Copeland 的关于测试设计方法的书等书籍之外，这些方法在测试社区中并不为人所知。成对和组合方法始终如一地工作，它们极大地提高了效率和有效性，并且它们很容易让测试团队立即开始使用。

贾斯汀（Hexawise 创始人）

于 2009-10-27T15:56:21.603 回答