51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

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

[讨论] 公司是否需要提供用例框架?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2011-3-28 19:01:47 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
下面是我们公司要求我们在写用例时的框架,就是我们写用例时就按照下面8条来分别进行考虑,你们觉得有必要吗?或者这个框架合理吗,比如UI测试、功能测试分得那么开做什么啊,还有就是关联测试,因为我们公司产品的耦合性巨高,修改一个地方关系N个地方,所以加个关联测试,其实与修改项关联的地方本来就是要测的地方,干嘛还要把它分出来?我在实际写用例的时候感觉很不爽,感觉思维受到限制,有的用例觉得是UI同时又是功能同时又是关联的东西,搞得不知道往哪里放,为什么要这么个框架?

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2011-3-28 19:18:13 | 只看该作者
自己下坐个沙发!!望大家回答下我的疑问啊?或者说下你们公司要你写用例的流程是怎么样的?谢谢了!!!
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2011-3-29 15:09:06 | 只看该作者
回复 1# yezhaohui520

首先,这个框架本身没有什么问题,也算是用例分类的基础框架之一。通过细致地分类用例组,让其更好的与用例评审/测试策略结合。
如,不同测试阶段选择的用例组不同。如,测试初期只需使用UI测试和基本功能测试用例组,而随着产品开发成熟,逐步加载关联测试、容错测试等用例组。

所以,若考虑此种用例分类存在 问题,还需结合你们公司的开发流程和实际项目需求。
————————————————————

接下来逐个说说你提出的疑问:

1.UI/功能 用例组
通常用例分类不会严格区分这两类用例,因为功能操作的实现本身就得依靠UI上的各个控件实现。所以,严格意义上,完美的功能测试用例组完全可以覆盖UI覆盖用例组。

但是在实际设计过程中,有多少团队能在功能用例中覆盖完UI检查点?
所以,你们公司分开UI/功能,其实是为了防止UI检查点漏测而已。

话虽如此,但是通常情况下,还是会将这两点组合在一起。究其原因,无非是两者都同属于最基础的测试。

故,若能保证基础功能测试用例对UI的覆盖率,则可考虑合并两者;否则,还是老老实实的细分他俩吧。

***********

2.关联用例组
针对你们项目实际耦合度高的情况,这个类别是有必要的。

若无此分类,将会导致1个问题:如A,B交互用例,应该把它放到A的功能用例组,还是放到B的用例组?
通常,系统用例由多个测试员共同设计,这类分工不清晰的用例,很有可能造成已知泄漏和冗余用例。

**********

3.复合用例组
“有的用例觉得是UI同时又是功能同时又是关联的东西”
LZ能举一个实例么?通常,这个问题的原因是此用例未在设计时未进行细分类,也就是用例本身存在问题。

**********
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-11 19:53 , Processed in 0.066642 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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