业务用例场景分析,通过分析用例角色场景和技术

通常以正常的用例场景 分析开始 , 然后进行到另一个场景分析 。业务 用例反映了需求 , 业务 用例系统的区别用例业务用例用于捕捉功能需求 , 由actor做出,不同类型的软件项目可能有不同的方法,但一般来说 , 信息管理软件项目通常从这几个方面入手分析:功能角色分析,业务 process 。

1、谈谈需求的描述- 用例(UseCase 用例(UseCase)是一种描述系统需求的方法 。用用例来描述系统需求称为用例建模 。用例也是UML规范中标准化的需求表达式,著名的RUP(RationalUnifiedProcess)就是由用例驱动的 。值得一提的是 , 尽管RUP被视为重量级的软件管理过程,但越来越多的软件开发人员开始采用敏捷方法来应对不断变化的需求 。

在表达方式上,用例比时序图和流程图更具有面向对象和设计的特点 。通常情况下,用例更容易被没有经过专业训练的人接受 。用例可以作为与用户或外人陈述需求的方式 。用例是一种描述需求的方法,用例描述了系统在不同条件下对参与者请求的响应 。用例通常通过演员(谁?)向系统提出请求,系统根据参与者的请求(做什么?

2、黑盒测试- 用例设计(下第一部分主要记录等价类划分、边界值分析和错误推断方法 。接下来我们将学习其他常见的黑盒测试:因果图-决策表、场景 method等 。因果图是一种适合描述各种输入条件组合的测试方法 。根据输入条件的组合、输出条件的约束关系和因果关系以及分析输入条件的各种组合,设计了用例的测试方法,适用于检查程序输入条件所涉及的各种组合 。因果图一般与决策表结合使用,通过映射同时相互作用的多个输入来确定决策条件 。
【业务用例场景分析,通过分析用例角色场景和技术】
利用因果图方法可以帮助我们按照一定的步骤选择一组高效的测试用例 Cause(原因):输入条件结果(结果):输出结果因果图:即输入条件(原因)与输出结果(结果)之间的关系用绘图表示 。1.关系①恒等式:如果ci为1 , 那么ei也为1;否则ei为0 。② Not ~:如果ci为1,那么ei为0;否则ei为1 。③或V:若c1、c2或c3为1,则ei为1;否则ei为0 。

3、什么是测试 场景评价者设定一定的情境和标准,观察被评价者在该情境下的反应 , 并根据预先规定的标准评价被评价者道德发展的一种方法 。模拟在特定场景边界发生的事情,通过事件触发一个动作 , 观察事件的最终结果,从而发现需求中存在的问题 。通常以正常的用例场景 分析开始 , 然后进行到另一个场景分析 。该方法通常包括基本流和备份流 。从一个进程开始,通过描述它所经过的路径来确定进程,通过遍历所有的基本流和备份流来完成整个场景 。

    推荐阅读