客户验收测试应该有多详细？
这是测试描述，测试“创建新小部件”用例。
- 确认您可以将新的小部件输入系统。
这是另一个测试描述，测试“创建新小部件”用例。
- 提出应用程序。
- 创建一个名为“A-008”的新小部件，描述为“验收测试 3-45 的测试小部件”。
- 确认该小部件现在在最左侧的小部件树视图中可见。
- 在树视图中选择另一个小部件，然后再次选择小部件“A-008”。 确认小部件中显示的值等于您输入的值。
- 删除小部件“A-008”并关闭应用程序
这是另一个测试描述，测试“创建新小部件”用例。
- 提出应用程序。
- 启动应用程序的第二个实例来查看相同的数据。
- 在应用程序的第一个实例中，右键单击“Widgets”节点。 在随后出现的上下文菜单中，激活“创建新小部件”菜单项。
- 应激活“New Widget”窗口。 将每个字段留空，然后按“确定”按钮。 应出现一个消息框，显示“请输入小部件名称”。 在此消息框中按“确定”。
- 在“名称”字段中输入“A-008”。
- 将描述字段设置为“美洲驼 (Lama glama) 是南美骆驼科动物，广泛用作印加人和安第斯山脉的其他土著人仍将美洲驼用作驮畜，并用于生产纤维和肉类。头顶高 5.5 英尺（1.6 米）至 6 英尺（1.8 米）。 出生时，它们的体重约为 280 磅（127 公斤）至 450 磅（204 公斤）。 cria) 的重量在 20 磅（9 公斤）到 30 磅（14 公斤）之间。
- 按“确定”按钮，将出现一个消息框，提示“描述必须为 512 个字符或更少”
- 设置描述。到 ”'）; DELETE FROM WIDGET WHERE 1=1;”（在“描述”字段中）。按“确定”按钮。
- 在最左侧的树视图中，应该会出现一个名为“A-008”的新小部件。
- 激活窗口中的应用程序的第二个实例，并确认窗口小部件“A-008”也已自动出现在该
- 应用程序的第一个实例中，右键单击“窗口小部件”节点。在随后的上下文菜单中，激活“创建新窗口小部件”菜单项，应激活“新窗口小部件”窗口，
- 将名称设置为“A-008”，然后按“确定”，弹出消息框。 “具有此名称的小部件已存在。 请选择另一个窗口小部件名称”。
- 在此消息框中按确定按钮，然后按取消按钮退出“创建窗口小部件”对话框。
- 在第二个实例中显示窗口小部件“A-008”的窗口小部件页面。
- 在第一个实例中，按“撤消”菜单项
- 确认第二个实例现在正在显示起始页......
- 等等。 ……
每个示例都测试您是否可以创建一个新的小部件，在第三个测试中，我以经验丰富的程序员的身份测试功能，思考“好吧，所有可能出现错误的地方都在哪里”，并检查。其中每一项是否适合客户验收测试
？
Here is a test description, testing the "Create New Widget" use-case.
- Confirm that you can enter a new widget into the system.
Here is another test description, testing the "Create New Widget" use-case.
- Bring up the application.
- Create a new widget by the name of "A-008", with the description being "Test Widget for Acceptance Test 3-45".
- Confirm that the widget is now visible in the leftmost widget tree view.
- Select another widget in the tree view, then select the widget "A-008" again. Confirm that the values in the widget display equal the values you entered.
- Delete widget "A-008" and close the application
Here is another test description, testing the "Create New Widget" use-case.
- Bring up the application.
- Bring up a second instance of the application viewing the same data.
- In the first instance of the application, right-click on the "Widgets" node. In the ensuing context menu, activate the "Create New Widget" menu item.
- A "New Widget" window should be activated. Leave every field blank, and press the OK button. A message box should come up saying "Please enter a Widget name". Press OK on this message box.
- Enter "A-008" in the "Name" field.
- Set the description field to "The llama (Lama glama) is a South American camelid, widely used as a pack animal by the Incas and other natives of the Andes mountains. In South America llamas are still used as beasts of burden, as well as for the production of fiber and meat. The height of a full-grown, full-size llama is between 5.5 feet (1.6 meters) to 6 feet (1.8 meters) tall at the top of the head. They can weigh between approximately 280 pounds (127 kilograms) and 450 pounds (204 kilograms). At birth, a baby llama (called a cria) can weigh between 20 pounds (9 kilograms) to 30 pounds (14 kilograms).
- Press the OK button. A message box should appear saying "The description must be 512 characters or less"
- Set the description to "'); DELETE FROM WIDGET WHERE 1=1;" in the "Description" field. Press the OK button.
- In the left-most tree view, a new widget by the name of "A-008" should have appeared.
- Activate a window in the second instance of the application, and confirm that Widget "A-008" has automatically appeared in that tree view as well.
- In the first instance of the application, right-click on the "Widgets" node. In the ensuing context menu, activate the "Create New Widget" menu item. A "New Widget" window should be activated.
- Set the name to "A-008", and press OK. A message box must come up, saying "A Widget with this name already exists. Please select another Widget name".
- Press the OK button on this message box, then press the Cancel Button to exit the "Create Widget" dialog box.
- Display the widget page for widget "A-008" in the second instance.
- In the first instance, press the "Undo" menu item
- Confirm that the second instance is now displaying the start page.
- .................etc..............
Each example tests that you can create a new widget. In the third test, I was testing the functionality as an experienced programmer, thinking "OK, where are all of the places a bug can appear", and checking every one of these. Is the third one appropriate for a customer acceptance test?
How comprehensive is "too comprehensive"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
用户验收测试用例应该详细且简单，但不像您的第三个示例那么详细。 验收测试是为了确保客户得到他们同意的内容。 如果你只是说，“单击这个然后单击那个，等等，等等......”这更像是一个功能测试。 您不会引导用户验证功能是否满足验收测试中规定的测试用例。 您只需要求他们点击您可以简单自动化的测试。
用户验收测试应该更多地遵循“创建小部件、验证它是否出现、删除小部件等”。 这也将鼓励用户寻找单独的功能，并（作为副作用）消除您可能忽略的任何可用性问题。
The user acceptance test cases should be detailed and simple but not as detailed as your third example. Acceptance testing is about making sure the customer gets what they agreed to. If you simply say, "click this then click that, etc, etc..." that is more like a functional test. You are not eliciting users to verify that functionality meets the test case laid out in the acceptance test. You are only asking them to click through tests that you could have simply automated.
User acceptance tests should be more along the lines of "create widget, verify that it appears, delete widget, etc." This will also encourage users to seek out individual features and (as a side effect) flush out any usability problems you may have overlooked.
我认为您的验收测试主要应该是良好的路径测试。 有时，“好的”路径将确保错误得到正确处理。 您应该进行其他测试来验证安全性并测试极端情况，但验收测试更多的是确保构建了正确的应用程序，而不是确保正确处理每个可能的条件。 如果您有良好的单元测试并使用最佳实践，那么我认为良好的路径测试是完全合适的。
例如，如果我使用了强制参数化查询或手动生成查询的技术（我没有），我不一定会测试我没有 SQL 注入问题，单元测试会验证这一点注射失败。 解决单元测试中的极端情况使得在验收测试中关注它们变得不那么重要。 如果您需要向客户提供一些示例，表明您的后端实现解决了他们的问题，那么请务必这样做，但我不会测试我知道我已经通过其他测试充分解决的问题。
I think that your acceptance tests should primarily be good path tests. Sometimes the "good" path will ensure that errors are properly handled. You should have other tests that validate your security and exercise the corner cases, but an acceptance test is more about making sure that the correct application has been built than making sure that every possible condition is handled correctly. If you have good unit tests and use best practices, then I think that the good path testing is entirely appropriate.
For example, I wouldn't necessarily test that I don't have problems with SQL injection if I've used a technology that enforces parameterized queries or where I generate queries by hand (I don't), that the unit tests validate that injection fails. Addressing the corner cases in unit tests makes it less important to focus on them in acceptance tests. If you need to include a few as examples to the customer that your backend implementation addresses their concerns, then by all means do so, but I wouldn't test things that I know I've addressed adequately via other testing.
对我来说，这看起来更像是一个功能测试计划（即内部测试）。
验收测试通常指的是您向客户展示的内容。 我想你可以给客户一个这样的测试 - 不过祝你好运
对于用户验收测试，我更喜欢一种非常简单的格式（当然，这可能不适合航天飞机软件或银行业务）。 它适合中小型 Web 项目，
其关键在于； 制作一个表格，列出系统中的每个页面，然后制作一列供客户首字母缩写，另一列供您自己首字母缩写。 你和客户坐在一起几个小时，仔细检查所有事情。 如果他们对页面感到满意，他们就会在该页面上签名。
有关模板的完整详细信息，请参阅：用户验收测试
That looks more like a feature test plan to me (i.e. internal testing)
Acceptance testing usually refers to what you show the customer. I guess you could give the customer a test like that - good luck though
For user acceptance testing, i prefer a very simple format (of course, this probably wont be appropriate say for space shuttle software or banking). Its fine for small-to-mid web projects
The crux of it is; make a table which lists every page in the system, than make a column for the client to initial, and another one for yourself to initial. You sit with the client for a few hours and go through everything. If they are happy with a page, they sign off on it
For the full details of the template, see: User Acceptance Testing
在完美的世界中，测试描述将如下：
用例中的每条路径都将有一个自动化测试。
任何形式的脚本化手动测试都容易出错并错过错误，更不用说劳动密集型的了。
In a perfect world, the test description would read:
There would be one automated test for each path in the use case.
Any form of scripted, manual testing is going to be error prone and miss bugs, not to mention labour-intensive.
你的规格怎么说？ 如果它涵盖了您的第三个测试用例中概述的所有内容，那么作为您的客户，为什么我不想看到您的产品符合整个规范？
如果您没有一组明确的要求（捂脸），那么请将您的测试分解为多个模块：资格（与客户一起）、集成（开发人员测试模块一起工作）和开发（开发人员测试单独的模块）模块）。
尽可能自动化 DT&E（例如，使用单元测试来测试 SQL 注入、字符串长度溢出等）。 这应该很容易做到，因为您的后端应该与与之通信的 GUI 分开（对吗？）。 您在第三个测试用例中概述的大多数 GUI 内容都可以作为集成测试的一部分进行涵盖（因为您实际上正在测试后端和 GUI 之间的集成）。
如果客户可以查看您的单元测试、集成测试程序和结果，那么资格测试就会变得非常简单且轻松。
What does your spec say? If it covers all of the things outlined in your third testcase then why would I, as your customer, not want to see that your product is compliant with the entire spec?
If you don't have an explicit set of requirements (facepalm), then break up your testing into modules: Qualification (with customer), Integration (developers testing modules work together) and Development (developers testing individual modules).
Automate DT&E as much as possible (e.g. use unit tests to test for SQL-injection, string-length overflows, etc.). This should be easy to do because your backend should be separate from the GUI that communicates to it (right?). Most of the GUI stuff you've outlined in the third testcase can be covered as part of Integration Testing (because you're really testing the integration between the backend and the GUI).
If the customer can review your Unit Tests, your Integration test procedures and results, then Qualification testing can be quite easy and painless.
他们应该测试正常用例（而不是特殊用例）。 但如果他们测试那些特殊的，那就太酷了！
验收测试不能太详细。 他们测试得越多，就越喜欢最终产品。
They should test the normal use cases (not the exceptional one). But if they test the exceptionnal ones, it is very cool !
Acceptance tests cannot be too detailed. The more they test, the more they enjoy the final product.