51Testing软件测试论坛

标题: 公司是否需要提供用例框架? [打印本页]

作者: yezhaohui520    时间: 2011-3-28 19:01
标题: 公司是否需要提供用例框架?
下面是我们公司要求我们在写用例时的框架,就是我们写用例时就按照下面8条来分别进行考虑,你们觉得有必要吗?或者这个框架合理吗,比如UI测试、功能测试分得那么开做什么啊,还有就是关联测试,因为我们公司产品的耦合性巨高,修改一个地方关系N个地方,所以加个关联测试,其实与修改项关联的地方本来就是要测的地方,干嘛还要把它分出来?我在实际写用例的时候感觉很不爽,感觉思维受到限制,有的用例觉得是UI同时又是功能同时又是关联的东西,搞得不知道往哪里放,为什么要这么个框架?
[attach]72169[/attach]
作者: yezhaohui520    时间: 2011-3-28 19:18
自己下坐个沙发!!望大家回答下我的疑问啊?或者说下你们公司要你写用例的流程是怎么样的?谢谢了!!!
作者: Jackc    时间: 2011-3-29 15:09
回复 1# yezhaohui520

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

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

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

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

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

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

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

***********

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

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

**********

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

**********




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2