客户验收测试的详细程度如何？

Question

这是一个测试描述，测试“Create New Widget”用例。

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

---

这是另一个测试描述，测试“Create New Widget”用例。

• 提出申请。
  
• 创建名为“A-008”的新窗口小部件，描述为“接受测试3-45的测试窗口小部件”。
  
• 确认窗口小部件现在在最左侧的窗口小部件树视图中可见。
  
• 在树状视图中选择另一个小部件，然后再次选择小部件“A-008”。确认窗口小部件中的值显示与您输入的值相等。
  
• 删除小部件“A-008”并关闭应用程序

---

这是另一个测试描述，测试“Create New Widget”用例。

• 提出申请。
• 调出查看相同数据的应用程序的第二个实例。
  
• 在应用程序的第一个实例中，右键单击“Widgets”节点。在随后的上下文菜单中，激活“创建新窗口小部件”菜单项。
  
• 应激活“新窗口小部件”窗口。将每个字段留空，然后按OK按钮。应该出现一个消息框，上面写着“请输入一个小部件名称”。按此消息框上的确定。
  
• 在“名称”字段中输入“A-008”。
  
• 将描述字段设置为“美洲驼（Lama glama）是一种南美骆驼科动物，被印加人和安第斯山脉的其他土着人广泛用作包装动物。在南美洲，美洲驼仍然被用作野兽负担，以及纤维和肉的生产。一头成熟的全尺寸美洲驼的高度在头顶5.5英尺（1.6米）到6英尺（1.8米）之间。重量在280磅（127公斤）到450磅（204公斤）之间。出生时，婴儿骆驼（称为cria）的重量可达20磅（9公斤）到30磅（14公斤）。
• 按OK按钮。应出现一个消息框，说明“描述必须为512个字符或更少”
  
• 将描述设置为“'）; DELETE FROM WIDGET WHERE 1 = 1;”在“描述”字段中。按OK按钮。
• 在最左侧的树状视图中，应出现一个名为“A-008”的新小部件。
  
• 在应用程序的第二个实例中激活一个窗口，并确认Widget“A-008”也自动出现在该树视图中。
  
• 在应用程序的第一个实例中，右键单击“Widgets”节点。在随后的上下文菜单中，激活“创建新窗口小部件”菜单项。应激活“新窗口小部件”窗口。
  
• 将名称设为“A-008”，然后按OK。必须出现一个消息框，说“已存在具有此名称的小部件。请选择另一个小部件名称”。
  
• 按此消息框上的“确定”按钮，然后按“取消”按钮退出“创建小组件”对话框。
• 在第二个实例中显示小部件“A-008”的小部件页面。
• 首先，按“撤消”菜单项
• 确认第二个实例现在正在显示起始页。
• .................等..............

每个示例都测试您可以创建新窗口小部件。在第三个测试中，我正在测试作为一名经验丰富的程序员的功能，认为“好的，所有的地方都可以出现错误”，并检查每一个。第三个是否适合客户验收测试？

“全面”是多么全面？

Answer 1

用户验收测试用例应该详细而简单，但不如第三个示例详细。 验收测试旨在确保客户获得他们同意的内容。如果你只是简单地说，“点击这个然后点击那个，等等......”更像是一个功能测试。您没有引起用户验证功能是否符合验收测试中列出的测试用例。您只是要求他们点击您可以简单自动化的测试。

用户验收测试应该更像是“创建窗口小部件，验证它是否显示，删除窗口小部件等”。这也将鼓励用户寻找个别功能，并（作为副作用）清除您可能忽略的任何可用性问题。

Answer 2

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

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

Answer 3

这看起来更像是我的功能测试计划（即内部测试）

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

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

它的关键是;创建一个列出系统中每个页面的表，而不是为客户端创建一个初始列，另一个列表供自己初始化。你和客户坐了几个小时，然后经历了一切。如果他们对某个页面感到满意，他们就会在其上签名

有关模板的完整详细信息，请参阅：User Acceptance Testing

Answer 4

在一个完美的世界中，测试描述将为：

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

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

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

Answer 5

您的规格是什么？如果它涵盖了您的第三个测试用例中列出的所有内容，那么为什么我作为您的客户不希望看到您的产品符合整个规范？

如果您没有明确的要求（ facepalm ），那么将测试分解为模块：资格认证（与客户合作），集成（开发人员测试模块协同工作）和开发（开发人员测试各个模块。）

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

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

Answer 6

他们应该测试正常的用例（不是特殊用例）。但如果他们测试那些异常的，那就太酷了！

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