16

这是一个测试描述,测试“创建新小部件”用例。

  • 确认您可以在系统中输入新的小部件。

这是另一个测试描述,测试“创建新小部件”用例。

  • 调出应用程序。
  • 创建一个名为“A-008”的新小部件,描述为“Test Widget for Acceptance Test 3-45”。
  • 确认小部件现在在最左侧的小部件树视图中可见。
  • 在树视图中选择另一个小部件,然后再次选择小部件“A-008”。确认小部件显示中的值等于您输入的值。
  • 删除小部件“A-008”并关闭应用程序

这是另一个测试描述,测试“创建新小部件”用例。

  • 调出应用程序。
  • 调出查看相同数据的应用程序的第二个实例。
  • 在应用程序的第一个实例中,右键单击“Widgets”节点。在随后的上下文菜单中,激活“Create New Widget”菜单项。
  • 应激活“新窗口小部件”窗口。将每个字段留空,然后按 OK 按钮。应该会出现一个消息框,说“请输入小部件名称”。按此消息框上的确定。
  • 在“名称”字段中输入“A-008”。
  • 将描述字段设置为“美洲驼(Lama glama)是一种南美骆驼,被印加人和安第斯山脉的其他原住民广泛用作驮畜。在南美洲,美洲驼仍然被用作驮畜,以及用于生产纤维和肉类。成年全尺寸美洲驼的头顶高度在 5.5 英尺(1.6 米)到 6 英尺(1.8 米)之间。它们的体重大约在 280 磅之间(127 公斤)和 450 磅(204 公斤)。出生时,小羊驼(称为 cria)的体重在 20 磅(9 公斤)到 30 磅(14 公斤)之间。
  • 按确定按钮。应该会出现一个消息框,上面写着“描述不得超过 512 个字符”
  • 将描述设置为“'); 从小部件中删除 1=1;” 在“描述”字段中。按确定按钮。
  • 在最左边的树视图中,应该出现了一个名为“A-008”的新小部件。
  • 在应用程序的第二个实例中激活一个窗口,并确认小部件“A-008”也已自动出现在该树视图中。
  • 在应用程序的第一个实例中,右键单击“Widgets”节点。在随后的上下文菜单中,激活“Create New Widget”菜单项。应激活“新窗口小部件”窗口。
  • 将名称设置为“A-008”,然后按 OK。必须出现一个消息框,显示“具有此名称的小部件已存在。请选择另一个小部件名称”。
  • 按此消息框上的确定按钮,然后按取消按钮退出“创建小部件”对话框。
  • 在第二个实例中显示小部件“A-008”的小部件页面。
  • 首先,按“撤消”菜单项
  • 确认第二个实例现在正在显示起始页。
  • .................ETC..............

每个示例测试您可以创建一个新的小部件。在第三个测试中,我作为一个有经验的程序员测试了这个功能,想着“好吧,所有可能出现错误的地方都在哪里”,并检查了每一个。第三个是否适合客户验收测试?

“太全面”有多全面?

4

6 回答 6

10

用户验收测试用例应该详细而简单,但不如您的第三个示例那么详细。验收测试是为了确保客户得到他们同意的东西。如果你简单地说,“点击这个然后点击那个,等等,等等……”这更像是一个功能测试。您不是在引导用户验证功能是否满足验收测试中列出的测试用例。您只是要求他们点击您可以简单地自动化的测试。

用户验收测试应该更接近于“创建小部件、验证它是否出现、删除小部件等”。这也将鼓励用户寻找单个功能并(作为副作用)清除您可能忽略的任何可用性问题。

于 2009-05-07T00:49:59.333 回答
1

我认为你的验收测试应该主要是好的路径测试。有时,“好”路径将确保正确处理错误。您应该进行其他测试来验证您的安全性并练习极端情况,但验收测试更多的是确保已构建正确的应用程序,而不是确保正确处理每个可能的条件。如果您有良好的单元测试并使用最佳实践,那么我认为良好的路径测试是完全合适的。

例如,如果我使用了强制参数化查询或手动生成查询的技术(我没有),我不一定会测试我在 SQL 注入方面没有问题,单元测试会验证这一点注入失败。解决单元测试中的极端情况使得在验收测试中关注它们变得不那么重要。如果您需要向客户提供一些示例,说明您的后端实现解决了他们的担忧,那么一定要这样做,但我不会测试我知道我已经通过其他测试充分解决的问题。

于 2009-05-07T00:47:17.123 回答
1

这对我来说更像是一个功能测试计划(即内部测试

验收测试通常是指您向客户展示的内容。我想你可以给客户一个这样的测试——不过祝你好运

对于用户验收测试,我更喜欢一种非常简单的格式(当然,这可能不适用于航天飞机软件或银行业务)。它适用于中小型 Web 项目

关键是;制作一张表格,列出系统中的每一页,而不是制作一列供客户初始化,另一列供您自己初始化。你和客户坐了几个小时,经历了一切。如果他们对某个页面感到满意,他们会在该页面上签字

有关模板的完整详细信息,请参阅:用户验收测试

于 2010-06-10T10:12:38.007 回答
0

在一个完美的世界里,测试描述应该是:

  • 确认所有自动化测试成功运行完成

用例中的每条路径都会有一个自动化测试。

任何形式的脚本化手动测试都容易出错并遗漏错误,更不用说劳动密集型了。

于 2009-05-07T00:32:51.667 回答
0

你的规格说明了什么?如果它涵盖了您的第三个测试用例中概述的所有内容,那么作为您的客户,为什么我不想看到您的产品符合整个规范?

如果您没有明确的需求集(facepalm),那么将您的测试分解为模块:资格(与客户)、集成(开发人员测试模块一起工作)和开发(开发人员测试单个模块)。

尽可能自动化 DT&E(例如,使用单元测试来测试 SQL 注入、字符串长度溢出等)。这应该很容易做到,因为您的后端应该与与之通信的 GUI 分开(对吗?)。您在第三个测试用例中概述的大多数 GUI 内容都可以作为集成测试的一部分进行介绍(因为您实际上是在测试后端和 GUI 之间的集成)。

如果客户可以查看您的单元测试、集成测试程序和结果,那么资格测试将非常容易和轻松。

于 2009-05-07T00:51:23.667 回答
0

他们应该测试正常用例(而不是特殊用例)。但是如果他们测试异常的,那就太酷了!

验收测试不能太详细。他们测试得越多,他们就越喜欢最终产品。

于 2009-05-07T00:55:33.283 回答