什么是方案测试以及如何创建复杂的测试方案？

#1 楼

是否有任何通用方法或方法可为任何应用程序创建复杂的用户场景，还是完全由上下文驱动。


在BBST测试设计幻灯片中，Cem Kaner将场景描述为“关于软件的假设故事。场景测试是基于场景的测试”。然后，他说一个好的场景测试具有5个特征：


该测试基于一个有关程序使用方式的连贯故事，包括人们的目标和情感。
这个故事是可信的。利益相关者将相信类似事情可能会发生。
测试失败会激励有影响力的利益相关者争辩说应该将其修复

故事涉及复杂性：程序的复杂使用或复杂的环境或复杂的环境数据集。
测试结果易于评估。这对场景很重要，因为它们很复杂。

这些特征旨在将场景测试与其他技术（例如用例或用户角色测试）区分开来。例如，用例不需要进行复杂的测试，就可以抽象出可能使用该软件的人员。另一方面，方案测试可以提供对该系统以及使用它的人员的更丰富的了解。

参考文献：


Cem Kaner-场景测试简介。 http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf

Michael Bolton-我们为什么要进行场景测试。 http://www.developsense.com/blog/2010/05/why-we-do-scenario-testing/

Michael Bolton-我们不喜欢的用户。 http://www.developsense.com/articles/2007-08-UsersWeDontLike.pdf

我上面提到的BBST幻灯片的参考部分中约有30个关于场景测试的参考：http：// /testingeducation.org/BBST/testdesign/BBSTTestDesign2011pfinal.pdf

#2 楼

方案测试中的两种方法


系统方案
用例和基于角色的方案

针对任何应用程序的测试方案步骤


在系统方案中，可以逐步使用模块明智的系统方案。通过使用模块和子模块功能。

系统方案示例应用程序：

测试方案1：检查登录功能


/>
测试方案2：检查是否可以创建新订单



测试方案3：检查现有订单是否可以打开


测试方案4：检查用户是否可以传真订单



测试方案5：检查信息是否显示在“帮助”部分正确

#3 楼

您可能会想到一种遍历系统状态和触发器的算法，但这不会使它成为“用户场景”。

我认为，如果您想要“用户”，那么它必须是取决于上下文。

#4 楼

它是上下文驱动的-必须如此。

也就是说，我用来生成场景的方法可以概括为：


用例或用户案例将至少包括一个场景（钢线）场景）。那是我的第一个。因此，例如，用户故事：



作为管理员，我需要查看谁登录系统的报告以及何时可以确保我的员工在他们上班时登录会生成方案：
如果我以具有管理员权限的用户身份登录并导航到“报告”部分，则用户登录报告可用，可以运行并生成正确的数据关于我使用的日期范围。


接下来，我看一下用户故事/用例所隐含的方案。上面的示例暗示了一些问题：


如果我以非管理员用户身份登录，则将看不到用户登录报告。
如果我不是登录后，将无法看到用户登录报告。
如果我以非管理员身份但具有管理员权限的用户身份登录（例如，超级用户），则可以查看和使用用户登录报告。


如果我认为这还不够或缺少某些内容，我会开始寻找优势和互动，例如：


如果我以管理员身份登录并且连接断开，则可以在“报告”页面上查看该报告，但将无法运行该报告：此外，我还会收到一条友好的错误消息。 br />

#5 楼

您可以使用Personas。

Personas用于市场营销，是虚构的字符，凝聚了用户类别的属性。每个角色都会有他/她独特的故事，需求和目标，并将使用一个应用程序来满足他们。

您应该为应用程序的预期受众的每个部分至少创建一个角色，您可以如果适用，还可以重用为其他应用程序定义的角色。

您集合中的角色要以哪种方式使用您的应用程序以满足他们的需求或目标，应该经过测试的场景。

#6 楼

也许这会有所帮助，看起来很有趣：

http://www.todaysoftmag.com/article/1702/acceptance-testing-driven-development-using-specflow-with-selenium-in-c