51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3960|回复: 2
打印 上一主题 下一主题

[讨论] 测试用例设计指导原则之一:完备性 VS 执行高效性

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-2-28 21:54:48 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
你刚刚接手一个这样的项目:
    左手一份暴简单的需求说明(网站现在要变更整个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 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

3#
发表于 2008-3-6 15:51:28 | 只看该作者

回复 1# 的帖子

同意
回复 支持 反对

使用道具 举报

该用户从未签到

2#
发表于 2008-3-4 19:43:33 | 只看该作者
在我们通常的设计当中,有两个设计指导思路:
1. 基于需求说明,以客户需求(操作流程)为主线索,展开测试用例的设计。
2. 基于技术流程图,就按照这个流程,展开测试用例的设计。

我们基本都用#1,因为开发不愿意写文档,也没有什么流程图。。。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-15 02:18 , Processed in 0.073929 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表