一个采购流程，用场景写的用例，请大家和版主多批评、指正，跪谢！

19801106

以前几乎没有采用 用例场景编写测试用，第一次写，让大家评审下，多提意见、多批评，谢谢！！！
采购流程：1. 由用户申请，并填写申请表
               2.提交到工作人员进行审核（审核是否符合“自主采购”要求，【单个<2K,批量<5K】）,工作人员审核通过就OK；如审核不通过休要申请修改。



场景用例如下：
1.1.
采购基本流

流程名称	流程步骤
自主采购基本流	1. 申请人填写申请表并提交    2. 工作人员进行检查并审核该申请是否可以通过。    3. 用户自行采购(线下操作)

1.2.
自主采购备选流

流程名称	流程内容
备选流1--申请人无权限	在基本流步骤1中，验证申请人权限,无权限,系统会给出提示信息.
备选流2—申请人提交采购申请	当申请人有权限后，触发此事件
备选流3—已提交申请不能修改	当工作人员未审核前，触发此事件。
备选流4--工作人员设不通过	在基本流步骤 2中，当申请人采购单台>=10W或批量>=20W，则触发此事件流。工作人员审核不通过,状态变更,并给出修改意见,申请人出提示审核未通过,显示修改意见.
备选流 5--申请人修改采购申请	当工作人员审核不通过，则触发此事件流。    在基本流步骤 2 中，申请人收到修改提示，修改后提交,工作人员重新进行审核.
备选流 6—工作人员审核通过	在基本流步骤 2 中,工作人员审核通过。申请人选择政府采购目录内货物，触发基本流A步骤3事件。    申请人选择政府采购目录外货物，触发基本流B步骤3事件。

1.3.
采购流程场景

场景编号	基本流	备选流
场景1-工作人员审核通过	基本流A	无
场景2-申请人无法申请采购	基本流	备选流1
场景3-申请人无法修改申请采购	基本流	备选流2    备选流3
场景4-申请修改采购申请	基本流	备选流4    备选流5
场景5-组合场景	基本流	备选流1    备选流2    备选流3    备选流4    备选流5    备选流6

1.4.
采购流程用例

用例编号	场景/条件	采购货物	采购数量及金额	预期结果
CW1	场景1	采购目录内、外货物	单台<2或批量<5	工作人员审核通过
CW2	场景2			申请人不能申请采购
CW3	场景3	采购目录内、外货物	单台<2或批量<5	申请人无法修改申请采购
CW4	场景4	采购目录内、外货物	采购单台>=2或批量>=5	1.工作人员审核不通过    2. 申请人可以成功修改采购申请
CW5	场景5	采购目录内、外货物	采购单台>=2或批量>=5	1.工作人员审核不通过
			单台<2或批量<5	1.工作人员审核通过

19801106

请版主和大家指正啊！！！！！！！！！！！！！！

19801106

测试流程的用例，大家指正啊

Jackc

回复 1# 19801106

只针对LZ用例中的设计方法提出几点建议，而对用例检查点的补充以后再说。
————————————————————————————————————————————————————
1.首先，从LZ提供的备选流来看，现有的流程图不能覆盖完整需求。（LZ的一部分备选流应该是来源于需求文档和测试经验判定吧）
所以，需要对现有流程进行修改，如下是加入了LZ所有备选流的新流程图：



————————————————————————————————————————————————————
2.场景流第一次设计的用例一般不包括测试经验判定用例。如：流程图中未加入“修改已提交申请”的判定时，则不会在第一次设计用例时，设计“备选流3—已提交申请不能修改”的用例。

常规的设计规则是在第一次设计用例完成后，依据其他信息进行用例/场景流补充设计。

其主要原因是：往往需要补充的场景流用例检查点不只一两个，可能会比较多。所以，统一清理检查点，再逐一评估新增检查点对整个用例结构造成的影响，有利于清晰用例架构的设计。
而所谓，想到哪里写到哪里，则不容易控制设计用例框架的清晰结构。

————————————————————————————————————————————————————

3.场景流用例设计方法中，虽然允许一条场景流可能出现多个用例，但建议尽量细分每条场景流，特别是对一条场景流仍包含多个判定时，是有必要拆分的，如将“单个<2K,批量<5K”再次分割为“单个<2K”和“批量<5K”。

——————————————————————————

希望能对LZ以后设计用例有所帮助。

19801106

万分感谢版主