51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2810|回复: 3
打印 上一主题 下一主题

[讨论] 测试用例的规模问题

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-4-24 10:35:55 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
想和大家探讨下一个系统的测试用例的规模问题:
我们公司的测试主要是界面和功能的测试:将一个大系统划分成10多个子模块。我负责的模块的测试用例有300多个。觉得有点太细了。(功能需求说明书中大功能是两个,细分下来的功能点是20多个。UI说明书的界面有38个。)
大家的测试用例一般多大的规模?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-4-29 11:09:59 | 只看该作者
看代码量来,华为的标准,以每千行代码来确定用例数量
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2009-4-29 15:46:27 | 只看该作者
1个模块300多?有点多吧
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2009-4-29 17:19:54 | 只看该作者
这个问题要根据你的实际情况来的,并不是用例写的越多越能发现问题,有些人设计200个用例也发现不了几个问题。有些人设计几个用例就能发现很多问题。一个好的测试用例能发现迄今为止尚未发现的问题。
我们在实际的工作中。设计用例的大体原则应该是这样的,首先设计的第一批用例是每个用例都能覆盖到需求的。保证每个功能点的需求都被覆盖到。再进行同行评审时,有其他人对你设计的用例进行查漏补缺。
其次,在执行过程中,你会不断的发现bug,这时也会发现一些并非用例指导的步骤而发现的bug,此时你要及时将这些能复现的bug经历的步骤设计成用例,补充到测试用例库中。
再次,你要针对出现bug问题多的用例,再次设计新的用例,以完善没有覆盖到的路径,(尤其要对模块与模块连接或穿越数据时的用例)因为bug都有集群现象哦,即2080原则。
第四:执行回归测试,在此过程中如再发现新问题,及时更新测试用例库。
总之,测试用例就是要这样一遍遍被更新来不断的发现bug,同时也要将不适用的测试用例删除或置为不通过。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-16 09:57 , Processed in 0.068315 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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