51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 13904|回复: 22
打印 上一主题 下一主题

[讨论] 大家在项目的测试过程中进行交叉测试吗?效率好不好?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-5-28 16:54:43 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
交叉测试我觉得是一种很好的方式,因为在一个测试员在长时间测试一个模块的过程中,很可能被模块开发者的思想所同化,从而产生了思维定势,虽然在某种条件下可以依据对系统的熟悉程度下发现流程性以及业务性的bug,但由于对某一系统操作熟悉,却很少能发现一些易用性、校验、数据等方面的错误,有时候在这种情况下有些测师人员也懒得在去动自己的脑子去发现此类问题,觉得只要流程正确,其他的都是小问题,其实不然!
   在这种情况下进行交叉测试时提高测试质量的一种很好的方法,同时也是提高士气的一种有效错误,由于对新接手的模块进行测试,首先,最少可以让测试人员可以积极的发挥自己的想象力,充分的对新模块进行测试。其次,新的测试者或许跟以前的模块测试者占的角度不一样,关注点不一样,也能发现很多以前没有发现的错误。
   所以,我觉得在一定条件下进行交叉测试也是一种很好的方法。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2008-5-28 18:05:02 | 只看该作者
没有。
原因:
好像是忙、也好像是懒、好像公司没有这样要求、好像怕影响关系 。。。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2008-5-28 21:39:51 | 只看该作者
其实交叉测试还是很不错的,有一个前提就是测试用例要步骤详细,否则是浪费大家的时间,步骤详细也不是那种繁琐型的,这个也是因人而异,团队的水平(指的理解能力)都不错的话可以稍稍的简单一点;交叉测试可以集多个人的思路去考虑某一个模块,使测试更加完善
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2008-5-29 09:18:16 | 只看该作者
先前的项目中确实有过交叉测试,但是好像最后起的作用不是很大,要是每个人负责的模块比较多的情况下,大家交叉起来光熟悉的时间就会很长,所有效果也就不是很明显了
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2008-5-29 12:52:41 | 只看该作者
在我们测试组中,我就实施过交叉测试,一个测试员在一个测试模块中,已经形成了固定思维,很难发现新bug,而且容易造成厌倦心里,觉得枯燥乏味,没新鲜感,甚至有时候有些测试用例结果直接填写pass的情况,所以我会让测试其他模块的测试员跟这个测试员交换测试,两个人都能发现新的bug,也可以检验出test case的不完善,很有用的方法。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2008-5-29 13:54:17 | 只看该作者

有利有弊

时间富裕的情况下,可以实现交叉测试;时间金基德情况下,根本来不及;
交叉测试 容易让人推卸责任,但有利于发现更多的Bug, 利弊各半
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2008-5-30 00:18:25 | 只看该作者
我们没有实施这个。

为什么不在需求评审、测试用例review方面多下功夫呢?

另外,交叉测试的责任后逃逸的BUG 该谁负责呢?什么时候让B交叉测试A 的工作呢?

呵呵,项目本身是短、急的、且2个人不是互相熟悉业务的,这个交叉测试意义不大。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2008-6-10 14:19:44 | 只看该作者
时间充足的情况下可以这样做,但是时间紧迫的情况下,一般没有做交叉测试。
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2008-11-9 20:00:54 | 只看该作者
交叉测试,如果时间允许的话,我想还是可以发现原测试人员不能发现的缺陷的,毕竟测试时间长了,测试人员就有同化现象嘛
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2008-11-9 23:14:05 | 只看该作者
最好把重点模块和功能的地方进行交叉测试,而相对不重要的模块和功能可以不用交叉测试。这样对于时间来说也不会相差很大,而且测试的也会比较充分点。
回复 支持 反对

使用道具 举报

  • TA的每日心情

    2015-9-10 15:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    11#
    发表于 2008-11-9 23:34:25 | 只看该作者
    1  会    2 好
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2008-11-12 17:55:05 | 只看该作者
    我一直像在流程中增加交叉测试环节,如果测试时间够的话。新项目开始了,我压缩了系统测试时间,留时间做交叉。不知道效果如何。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2008-11-13 15:24:11 | 只看该作者
    完全同意LZ的看法,就是实施的时候花费昂贵了点......
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2008-11-26 13:37:58 | 只看该作者
    确实会出现4楼说的清楚,交叉测试后,新接受的人熟悉功能也需要花一段时间~
    交叉测试,还是需要在合适的时机运用吧~~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2010-5-20 17:05:04 | 只看该作者
    会进行交叉测试的 这样是对产品的负责 是对公司的负责
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2010-6-4 14:21:08 | 只看该作者
    会进行觉得有必要;
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2010-6-9 16:23:28 | 只看该作者
    这也是我们团队Q3打算开展的,前提是人力和时间充分
    互相可以backup
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2010-6-9 16:36:24 | 只看该作者
    我认为,要在时间比较充裕,测试人员对系统的每个模块的业务流程都比较熟悉的情况下,交叉测试是一个很不错的测试方法。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2010-6-12 15:54:10 | 只看该作者

    交叉测试

    首先我们这里是有选择性的开展交叉测试,测试力度也不会同等于正常测试。大部分软件公司进度都是很紧张的,真没时间做完全相等测试力度的交叉测试。

    是否需要开展交叉测试首先要了解交叉测试的优缺点。这个不用细讲大家都清楚。当优点大于缺点的时候,那肯定要开展交叉。反过来同理。
    我举几个,符合开展交叉的时机。1:测试组中有新员工或者能力比较偏地的测试人员时。2:某轮测试中发现比较多的BUG漏测时。3:某模块需要重点测试时(逻辑比较多或者报表较多,关系复杂常用)。

    交叉测试人力可以采用1对1或者多对1. 测试时间分配我们一般用4:1(即5天一轮的测试任务4天测试完成一轮,最后一天交叉) 或者 5:1 5:2 ,这个主要看测试时间与测试力度;

    另外大家说,交叉测试还有BUG遗漏的话,算谁的责任,我也任为这事没有一刀切地。如果是比较明显的BUG,按照测试用例走一定会出的BUG,那两个测试人员都应该负责。如果是那种跳跃测试出来的,或者需要一定经验才可以测试出来的,就没有责任问题。

    最后开展交叉测试结束后,一定要做交叉测试出来的BUG分析。进行总结。主要是为测试人员提高测试水平。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2010-6-13 00:00:39 | 只看该作者
    原帖由 金子快来 于 2010-6-12 15:54 发表
    首先我们这里是有选择性的开展交叉测试,测试力度也不会同等于正常测试。大部分软件公司进度都是很紧张的,真没时间做完全相等测试力度的交叉测试。

    是否需要开展交叉测试首先要了解交叉测试的优缺点。这个不用细 ...


    非常有道理,值得借鉴
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-22 02:44 , Processed in 0.082434 second(s), 26 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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