请教象这样的需求测试用例该怎么设计？
本地写卡功能：界面：
号码、产品、副号、空SIM卡
号码和空卡为可输入框
1、号码不能是一卡双号的副号，可以是：全球通普通号码，全球通一卡双号主号（若有副号，直接把副号赋给副号输入框处）、神州行、动感地带
2、号码状态必须是正使用状态
3、SIM卡状态是可用状态
4、动感地带号码只能用“28动感地带空白SIM卡”，神州行只能用“29 神州行空白SIM卡”，全球通用“26全球通空白SIM卡”和“27 一卡双号空白SIM卡”；如果输入该号码有副号则只允许写“27 一卡双号空白SIM卡”；
符合1、2、3、4 写卡成功
若号码状态不对， 提示请用正使用的号码
若卡状态不对，提示请用可用状态的卡
若不符合1，提示副号不能写卡
若不符合4,提示卡类型不正确
[ Last edited by kasad on 2005-9-26 at 09:25 ] 如果用因果图，该怎么画因果图？ 这个版有几篇关于因果图的文章，多看看，多实践吧。 我问这个问题 主要是想知道 强制的关系是不是要单独分开来画？
我看了所有论坛中的有关因果图的帖子都没有讲到强制 的例子
共同考虑考虑
嗨，先要声明我对这项远程写卡业务并不熟悉。是否是指通过在营业厅建立写卡终端，由远程写卡服务器与BOSS服务器之间进行数据传递，借助BOSS系统网络进行远程申请写卡的业务呢？若只是探讨方法，你看这么来考虑是否合适呢？
“强制的关系是不是要单独分开来画”其实你已经有思考一种基于图的测试方法。基于图的测试需要标识对象和对象的属性（节点和权值）。那设计这个测试用例时需要考虑节点的覆盖和连接的覆盖。每个节点意味你需要考虑它等价类情形和对象属性状态，每个连接关系可能形成环，也可能是因果路径。
节点分“号码状态”、“卡状态”、“操作界面状态”，前两个节点处都提示对否的属性（提示错误时还可以计次数），后一个节点处属性可以更多些。随后确定因果路径可能有多条，一个写卡成功的环。除了你所提出写卡流程的用例设计，应该还会涉及比如“不同角色的定义”、“不同角色的访问权限”、“实卡的定单处理流程”、“空卡的定单处理流程”、“IMSI数据的定单处理流程”
[ Last edited by addvalue on 2005-11-2 at 23:28 ] 谢谢 addvalue
受益匪浅 ：） 受益
页:
[1]
