我参加了关于软件测试最佳实践和测试设计的课程。在内容中,他们有一个模型,该模型基本上表明这三个项目是通过这种方式导出的:前三个之间的差异?用例似乎与需求和场景具有相同的定义,或者至少来回反弹。我无法找到一个清晰的示例来显示:


这是一个需求声明这是需求的用例这是用例的场景


有人可以解决这个问题并举个例子吗?

评论

您能为我提供流程示例吗?需求>用例>场景>测试用例>测试脚本

#1 楼

需求通常是一般性陈述,而用例通常是隐含或从需求中得出的特定陈述。需求可以映射到多个用例。场景可能是一组将用例放在上下文中的背景假设,也可能是用例的分组。要求是提供一个将CSV文件转换为制表符分隔文件的API。一个场景可能是,“约翰是一名Java开发人员,负责处理可能为空的潜在大型CSV文件”。用例可能是“如果输入文件为空,则输出文件也将为空”或“在处理500Gb文件时API不会耗尽内存”。

最后,SQA得到很多“这些术语之间有什么区别”这类问题。如果您听到某人说出一些模棱两可的短语,并且了解它们的含义(例如,由于同事或您的老板使用了它们)很重要,请询问他们的含义。在有理智的人中,总是可以说:“不同的人使用该短语来表示不同的事物,那么您能更清楚地表达自己的意思吗?”如果您以前从未听过这些短语,或者您缺乏信心,则可以先进行Google搜索,首先找到它们的含义,然后请该人弄清楚它们的含义。

评论


是的,在某个地方提出一个通用的,已达成共识的定义可能很有用,这样当您在队友之间交谈时,您会知道自己都在同一页面上。

–山姆·伍兹(Sam Woods)
13年5月22日在18:56

好答案。我要强调“问他们的意思”这一点。通常,SQA通过尝试确保每个人的意思相同,从而为项目增加了可观的价值。当我们可以使产品经理,项目经理,业务分析师,开发人员和质量保证人员都具有相同的含义时-那么我们就有更好的机会避免在提交代码之前出现一些错误。那总是一件好事。

–乔·斯特拉泽(Joe Strazzere)
13年5月23日在11:42

#2 楼

考虑到您的描述,可以给出以下澄清:
要求:开发团队在开发产品时试图满足利益相关者不断变化的需求
用例:明确要求,然后可以设计/确定用例,这将首先清除系统向开发人员的总体流程,然后他们可以相应地设计系统。一旦他们了解了流程,就可以通过质量检查对系统进行某种程度的简单测试。各种故障(如果有)。因此,我们通常说的是真实场景。
示例:对于特定项目,业务分析师首先明确要求。在文档和SRS部分中,可以找到用例,并据此将开发任务分配给各个开发人员。当用户使用系统时,它将成为一个场景。

#3 楼

就我个人而言,我将对前3个实体的解释如下:限制访问特定人群的数据和操作。
使用案例/用例UC1:作为销售人员,我希望能够访问分配给我的客户列表,以便查看他们的订单
验收标准UC1-AC1:假设我以销售人员身份(已分配10个客户)的用户身份登录,则单击“向我显示客户列表”菜单项,然后单击分配给10个客户的列表。
接受标准UC1-AC2:鉴于我是作为销售人员分配了10个客户的用户登录的,所以当我单击“向我显示客户列表”时,菜单项将消失
使用案例/用例UC2:作为区域主管,我希望能够访问具有以下条件的客户列表:属于我的区域,因此我可以查看他们的订单
接收标准UC2-AC1:鉴于我已经以用户身份登录,该用户是区域A的区域主管,因此当我单击“显示客户列表”时项目然后应显示属于区域A的客户列表。
接受标准UC2-AC2:假设我以用户身份登录,并且是区域A的区域主管,则单击“显示我”客户列表菜单项然后,不应该显示不属于区域A的任何客户。

#4 楼

场景是通过用例的一条路径的特定实例或一组步骤。用例是系统完成的面向目标的过程。

#5 楼

在软件行业中,需求定义了我们最终目标是客户真正需要的东西,以及使我们公司增加业务的因素。它可能是在各种软件领域生产软件产品或提供服务的产品或服务公司,最重要的是

在Waterfall模型下,由于整个产品是在一个阶段中实施的,所以需求文档是巨大的文档。但是,对于敏捷/ SCRUM而言,情况并非如此,因为在逐步开发产品的过程中,对这些小功能或特性提出了要求。写下一两行,最多最多5行的任何功能或特性的要求。用户故事通常是最简单的可能需求,大约只有一项功能(或一项功能)。

它将由Business Analyst根据需求规范进行开发。
它是带有实时场景的简化版本的规范的详细说明。
下面介绍了创建用户故事的最常用标准格式:

作为(用户角色/客户),我想要(要实现的目标)以便我可以(达到目标的目的)。例如,创建用户。创建用户的方式可能有多种,例如通过向导或通过上传用户集来创建用户。
这些都是我们可以作为场景调用的东西。

基于用例和场景,测试用例将由软件测试公司的测试人员编写。

还有一件事,用户故事不仅仅是单句话的事务。产品负责人还编写了接受标准,该标准定义了用户故事的边界,并用于确认故事何时完成和按预期工作。

接受标准是功能或功能必须满足并满足的一组接受条件或业务规则,以便被产品所有者/利益相关者接受。

深刻理解用户故事及其接受标准非常重要,即使在“测试开始”时也没有一个疑问。

#6 楼

如果您正在为软件测试解决方案提供商工作,那么了解需求,用例和方案之间的区别非常重要。
需求是要在当前尚不存在的应用程序中引入的新功能或更新功能。当前。
例如:一种功能,供客户通过表格提交清单并根据满足其要求的最佳标准接收电子邮件。
例如:客户能够提交清单,后端系统根据客户的要求提供解决方案。
场景是正在执行的特定流程,用于检查系统是否
例如,用户应该能够通过Mac系统和safari浏览器提交清单,其结果与通过Android手机和chrome浏览器提交时的结果相同。

#7 楼

在常见的软件测试过程中,用例并非源于需求。但是事实恰恰相反:通过识别用例,可以定义软件需求。
场景是对一个或多个需求进行测试的设置或状态的定义。
示例
使用案例:未经身份验证的用户可以访问知识库,但只能访问公共区域
要求:匿名用户级别的主菜单应填充知识库公共区域标签
场景:访问系统作为匿名用户,然后对reqx1,reqx2等执行测试...