测试场景用例编写步骤:1、确定业务场景分析的范围;2、业务流程梳理;3、场景串联。确定业务场景分析的范围是指根据业务的目标(价值)、类别、技术等输入,确定业务场景分析的范围,业务分析就是需求分析的过程。
一、测试场景用例怎么写
1、确定业务场景分析的范围
根据业务的目标(价值)、类别、技术等输入,确定业务场景分析的范围。业务分析就是需求分析的过程。这里不仅仅考虑需求的功能逻辑,还需要结合不同业务类型,根据历史业务经验沉淀和风险沉淀进行综合考虑。
2、业务流程梳理
将需求说明转化为业务流程,完成事件流(基本流+备选流)以及业务分析过程和技术分析过程的梳理。细化出原子级别的场景分支。
- 事件流:同一事件不同的触发顺序和处理结果形成事件流,事件流分为基本流和备选流
- 基本流:程序从开始执行直到成功结束所经过的最短路径。
- 备选流:一个备选流可能从基本流开始,在特定条件下执行,然后重新加入基本流中;也可起源于另一个备选流,执行后加入基本流或终止用例。根结点的备选流要具备原子性。
3、场景串联
通过第二步中拆解的场景,根据沉淀后的场景集,用组合,合并等方法梳理出所有的事件流。事件流必须100%覆盖所有的基本流+备选流组合。
二、测试场景用例与测试用例的区别
- 测试用例(Test Case):是一组输入、操作或条件,以及相应的预期输出和结果,用于验证软件系统或组件的特定功能或行为是否符合预期要求。通常,测试用例由测试人员编写,并根据软件需求规格说明书或功能规范进行设计。
- 测试场景用例(Test Scenario):是一组步骤或事件,描述了在特定环境下执行的测试任务或测试计划。每个测试场景可以包含多个测试用例,用于验证系统或组件在各种情况下的整体性能和稳定性。测试场景通常由测试管理人员或测试架构师创建,并基于软件需求规格说明书,系统架构图或其他相关文档进行设计。
因此,测试用例更侧重于验证软件系统或组件的具体功能或行为,而测试场景用例则更关注整个测试流程和测试计划的设计与执行。
三、测试场景与场景测试的区别
场景测试方法应该具备的一些特征:
- 测试是基于一个用户如何使用程序的场景,其中包括使用人员是如何被鼓励参与到程序的使用当中的。
- 场景是具有激发性的。利益相关者可能会给开发人员压力去改变程序。但这些改变恰恰会使测试失败。
- 场景是可信的。它不仅仅可能发生在现实世界里,它还要使利益相关者相信像这样的事情会发生。
- 场景包含了程序的复杂使用或者一个复杂的环境或者一个负责的数据集。
- 测试结果容易被评估。这点是对所有的测试都意义重大,但是它对情景测试尤为重要,因为情景测试用例相对复杂。
测试场景是可以测试的任何功能。它也称为测试条件或测试可能性。作为一名测试人员,您可以将自己置身于最终用户的角色,并找出真实世界的场景和使用中的应用程序案例。创建测试场景的原因:
- 创建测试场景可确保完整的测试覆盖率。
- 测试场景可以得到业务分析师,开发人员,客户等各种利益相关方的批准,以确保对测试中的应用程序进行全面测试。它确保软件适用于最常见的用例。
- 测试场景可以作为确定测试工作量的快速工具,从而为客户创建提案或组织员工。
- 测试场景有助于确定最重要的端到端事务或软件应用程序的实际使用。
- 为了研究程序的端到端功能,测试场景至关重要。
延伸阅读
为什么引入用例场景
现在的软件几乎都是由事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中,生动的描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时测试用例也更容易的得到理解和执行。
文章标题:测试场景用例怎么写,发布者:Z, ZLW,转载请注明出处:https://worktile.com/kb/p/48718