51Testing软件测试论坛
标题:
测试用例设计指导原则之一:完备性 VS 执行高效性
[打印本页]
作者:
ahhuang
时间:
2008-2-28 21:54
标题:
测试用例设计指导原则之一:完备性 VS 执行高效性
你刚刚接手一个这样的项目:
左手一份暴简单的需求说明(网站现在要变更整个sorting的缺省方式,让所有来访者(注册的,匿名的,曾来过的,首次来的),只要在此之前没有设置过sorting值,统统都变更为新的缺省sorting方式),右手是一份开发员写的相当详细的技术流程图(查cookie...查DB...查cookie的版本...查DB的时间戳...)。
一句话,左边是少言寡语的鸡,右边是严谨高深的鸭,在同你讲同一个事儿,你却没法很好的核对两者的每句话。
--针对这类项目,我们来如何完成一次高性价比的用例测试呢。
在我们通常的设计当中,有两个设计指导思路:
1. 基于需求说明,以客户需求(操作流程)为主线索,展开测试用例的设计。
2. 基于技术流程图,就按照这个流程,展开测试用例的设计。
若简单的采用#1或#2,都会有问题:
. 前者的问题在于--设计出来的case也可能太巨了:由于需求说明太简单,导致即使是依据经验进行等价类删剪,分析下来的case也很多。完备性能够保证,但执行很痛苦。
. 后者的问题在于--有难同当:当QA和开发的思维方式一致时,可能是有漏洞,一块儿掉。另外如何将cookie,db变更之类的转换成具体的实际执行还得另花脑筋。
在实际的实施当中,尤其是对于开发转职QA的人员,会面临的诱惑通常是使用方案2;或者以#2为主,#2和#1交替思考设计cases。而这种思路危害性是比较大的。因为相对于#1需多劳些力来说,遗漏了某个功能或场景,通常很可能意味这公司的资产的损失(至于自己,可能被点名批评,撤职查办之类的,又或是几个项目下来总是有这类问题,会被老大质疑你的责任心和能力)。
所以,建议按如下方案来糅合两者:
以#1为主:先以客户需求(操作流程)为线索,case的设计展开以此为基础,先枚举出用户所有可能的使用途径,每个途径或场景,就是一个case。
而#2,或者说技术流程图在case设计中当承担这样的责任。一是用来删剪合并等价类case,二是拆分演化出一些原以为是整体的case(实现中的一些边界等价类),三是通过设计一定的执行序列,来提高每一次执行的效率(多个cases的结果可以一次性检查掉)
[
本帖最后由 ahhuang 于 2008-2-28 21:57 编辑
]
作者:
tjj006
时间:
2008-3-4 19:43
在我们通常的设计当中,有两个设计指导思路:
1. 基于需求说明,以客户需求(操作流程)为主线索,展开测试用例的设计。
2. 基于技术流程图,就按照这个流程,展开测试用例的设计。
我们基本都用#1,因为开发不愿意写文档,也没有什么流程图。。。
作者:
haohaoxuexi
时间:
2008-3-6 15:51
标题:
回复 1# 的帖子
同意
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2