编写验收测试用例

我们正在将测试过程集成到SCRUM过程中。我的新角色是编写我们的Web应用程序的验收测试，以便稍后使它们自动化。我已经阅读了很多有关如何编写测试用例的文章，但是没有一个给我实用的建议来编写用于复杂Web应用程序的测试用例，相反，它们引发了我发现难以应用的矛盾原则：

• 测试用例应该简短：以CMS为例。简短的测试用例易于维护，并且易于识别输入和输出。但是，如果我想测试一系列的操作（例如，添加文档，向另一个用户发送通知，其他用户答复，文档更改状态，用户收到通知），该怎么办？在我看来，测试用例应该代表完整的场景。但是我可以看到这将如何产生明显复杂的测试文档。

• 测试应该标识输入和输出：如果我的表单很长，包含许多相互作用的字段，并且行为不同，该怎么办。我要为所有内容编写一份测试，还是为每项编写一份？

• 测试用例应该是独立的：但是如果测试上传操作要求连接操作成功，我该如何应用呢？它如何适用于编写测试用例？我应该为每个操作编写一个测试，但每个测试都声明其依赖关系，还是应该为每个测试重写整个场景？

• 测试用例应轻松记录在案：此原则特定于敏捷项目。那么，您对如何实施这一原则有何建议？

尽管我认为编写验收测试用例会很简单，但我发现自己对要做的每一个决定都不知所措（仅供参考：我是开发人员，而不是专业的测试人员）。所以我的主要问题是：为了编写适用于复杂应用程序的可维护验收测试用例，您有什么步骤或建议。谢谢。

编辑：澄清我的问题：我知道验收测试应该从需求开始，并将整个应用程序视为一个黑匣子。我的问题与编写测试文档，确定测试用例，处理测试之间的依赖关系的实际步骤有关...对于复杂的Web应用程序

在我的验收套件中，我远离使用特定于技术的控件，即，对于Web应用程序，如果您需要填写表格，请不要使用CSS，不要使用html元素。

我用黄瓜接受了以下食物

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

该示例由Web应用程序返回，但是我仍然可以使用该测试对桌面应用程序进行测试，因为这些步骤用于设置SUT，而不是验收测试

该测试位于购买结束时

生成->确认->付款->打印收据

上面的测试是针对付款步骤的，其他步骤则在其他测试中进行了设置，这是因为应用程序能够使用数据或http动作将其设置为这些状态，在这种情况下，付款具有给定的付款人，该付款人会执行确认步骤，确认会执行生成步骤，这样一来它们就有点脆弱

首先，您需要定义验收测试。

您似乎要描述的是集成或系统测试。

因此，尽管我不是100％同意维基百科上的定义，但它们在很大程度上仍然有效。

基本上，验收测试的目的是通过真实数据验证使用您构建的软件的“业务”流程是否确实按预期工作且符合目的。因此，您不会像进行单元测试或其余测试那样构建测试用例。它不应该以完全相同的方式进行设计。

要问的问题是“如何使用系统？”。因此，让我们以应有的方式对其进行测试。当然，现在您重新戴上工程帽，认真地进行业务需求以得出测试用例。假定您具有良好的书面业务要求。

如果没有，那还不算太晚，您必须与用户或他们的代表（以及业务分析师和技术设计人员）坐下来，写下他们期望软件以商业术语交付的内容（有一个明显的告诫，那就是太少了也太晚了，但总要迟到总比不到好-当然不要引入新功能）。这就是您的测试用例。

解决该问题的另一种方法（同样，如果您有这样的文档）是阅读用户手册。尽管这是从实际业务需求中删除的一步，所以只有在所有其他方法都失败的情况下才可以使用。

当您去买车时，通常不会在引擎盖下钻得太深（除非您是汽车修理工）。您只需坐在方向盘上检查舒适性，可用性，外观，声音……即一般的东西。您通常相信，如果首先要把汽车交到您的手中（至少对于新车来说），它通常是安全且结构良好的（有保修条款，您已经完成了家庭工作并仔细阅读了规格） ...）。因此，现在您检查这是否是您未来几年要驾驶的汽车。

与软件相同。

冲突的信息可能令人沮丧，并且难以一概而论并将其应用于您的特定情况。太好了，您可能必须做最适合自己情况的事情。

我不是长期测试文档的忠实拥护者，并且已将视觉效果有效地用于一些较小的项目。试试吧 像流程图（或任何其他UML图，如状态图等），而不是仅使用文本吗？指示输入，输出，条件，循环，通道，状态，与其他组件的交互作用等，然后根据您的标准指示它们是否成功，失败，转移，其他（？）。

一开始可能需要做一些工作，但从长远来看可能有助于保持理智。无论选择哪种方法，您使用的方法越多，就会越好。

祝您好运！

KM

我认为您已经确定了一些好的条件。第二点是定义测试范围的好方法，并且我建议也测试错误条件和错误（我主张每个错误修复至少要包含一个新的单元测试）。现在看来似乎不堪重负，但只要深入研究，并获得一些经验，就可以知道进行良好测试的条件将变得更加容易。