51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 7778|回复: 23
打印 上一主题 下一主题

[原创] 还没有做完测试,不同的版本又来了,这种情况下测试该怎么办啊?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-1-11 00:50:48 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
假设软件系统有100个用例,刚执行完10个用例,有了3个bug,开发看到了,然后就马上改了,然后他就把改过的版本又发给测试,测试按照新版本的软件又开始了测试,前面的10个又重新执行了一遍,然后执行了25个用例,又发现了5个bug,发觉开发自己调试软件也发现了,开发又开始修改,又将新的版本的软件系统发了过来,测试那边又重测,执行到了50个用例,又有bug,开发又是同步改的,改完又过来新版的软件系统,……

就这样循环着……测试人员测试工作难道又重新开始吗?是按照新的版本的软件系统测试吗?前面的50个用例还要重新执行吗?

为了节省项目时间,要求发现bug马上改正的做法也能够理解,甚至公司要求同步执行,那这样的情况,测试人员如何解决呢?有什么还的办法吗?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2008-1-11 09:35:47 | 只看该作者
深有同感,我们的测试经常这样,不知怎么办???
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2008-1-11 09:35:59 | 只看该作者
做版本控制
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2008-1-11 09:55:36 | 只看该作者
同上,做版本控制
或者让测试经理与开发经理沟通好后,进行协调

比如,每周什么时候进行修改,什么时候发布新版本。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2008-1-11 09:58:32 | 只看该作者
个人认为应该等到测试人员将测试用例全部执行完一遍后才允许开发人员发布新的版本
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2008-1-11 10:22:31 | 只看该作者
有很多测试人员都有这样的同感,这样会使测试人员变得很被动,测试与开发应该采取一个平衡点, 测试人员可以把每天测到的BUG发给开发人员改,但改完后不要马上更新到测试环境中,等到测试人员把测试用例都测试完毕后,才允许开发人员发布新的版本进行回归测试
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2008-1-11 10:28:37 | 只看该作者
在版本无法控制的情况下,可以按照自己的进度测试,继续执行剩下的测试用例,当用例执行完之后再进行回归。

同时告诉开发,测试是需要有计划的,不是你们想回归就回归
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2008-1-11 11:56:37 | 只看该作者

回复 1# 的帖子

很简单,这个时候就是测试负责人拿出威信的时候了
一,直接返回给开发人员进行基础的自测问题。
二,版本控制。保证执行完一遍用例之后,在做相应的回归测试。然后再执行一遍用例(以防改出新的Bug)
三,如果无法解决,测试应该有责任心为质量负起不能承受的质量保证之重量。测试发现问题,登记,但是不保存(即不通知维护人员),等待第一遍测试完成时,在告知全部问题。
如果我们遇见你说的情况,10个用例就3个Bug,毫无疑问,直接返回给开发人员自测。测试要有自己的一篇天地,不能被动做事。
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2008-1-11 12:06:57 | 只看该作者
在最新的Build基础上,继续测试。比如测到TC#10了,来了新的Build,测TC#11时就在新的Build上测试。依次类推。不能因为新的Build而影响工作进度。至于修复的Bug是要进行回归测试的,所以来了新的Build也不用从TC#1开始测。
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2008-1-15 14:25:37 | 只看该作者
这就说明测试部门对测试软件没有做版本控制
在测试过程中,版本控制也是一个很重要的概念
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    11#
    发表于 2008-1-16 09:49:21 | 只看该作者
    看来版本控制的确很重要
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2008-1-21 17:58:35 | 只看该作者
    建立代码测试基线;一轮测试完成后才考虑dev修改缺陷后的代码进行验证
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2008-1-24 10:58:22 | 只看该作者
    建议沿用原来版本继续测试,等测试活动结束后,对新版本进行回归测试。当然,这是很无奈的作法,但是一定要按照一定的规则去进行相应的工作,否则测试活动会很乱。

    当然,如果你是一个TL,那你最好还是和PM进行协商,严格进行版本的控制,采用正确的流程。这样能够更好的展开工作。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2008-1-24 12:06:13 | 只看该作者
    建议你们的项目加强版本控制,不然测试人员可就惨了,会做很多无用功的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2008-1-24 16:47:35 | 只看该作者
    一般情况下测试人员不该在一遍用例没有执行完成之前就申报了bug,可能用例很多,而且需要及时修改,那么这个时候作为私下沟通测试人员可以跟程序人员达成协议,bug我报给你,你有时间的话可以先修改,但是先不急出版本,等完整测试一遍后再出一个新的版本。这就是单服所做的事情吧。系统过小且进度不大赶的时候就可以遍历完测试用例再提交给程序统一修改。程序不可能只做一个功能,测试也同样。千万不能因为个别bug的存在而停止了测试的进度。但是同时有一点很重要,你必须了解系统,清楚了解功能的某个bug不会对其他内容产生不良影响,以便不要在错误的版本上面进行浪费时间的测试。如果是影响其它功能的bug,那也是重大bug了。就必须第一时间处理了。处理完再继续测试。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2008-1-24 19:31:19 | 只看该作者
    原帖由 hotsu 于 2008-1-11 00:50 发表
    假设软件系统有100个用例,刚执行完10个用例,有了3个bug,开发看到了,然后就马上改了,然后他就把改过的版本又发给测试,测试按照新版本的软件又开始了测试,前面的10个又重新执行了一遍,然后执行了25个用例,又发现了5个b ...

    身有同感阿!!做版本控制有点?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    17#
    发表于 2008-1-25 12:08:21 | 只看该作者
    增强版本控制控制力度。

    否则永远无法结束。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2008-1-28 11:07:33 | 只看该作者
    最讨厌这种情况了。
    我现在遇到,就是即使开发提交了修改,但在我这边所有的测试用例没过完之前,都压着不更新。
    测试完成后统一提交报告再接受反馈。
    他们提交就提交,但不会生效。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2008-1-29 12:52:26 | 只看该作者
    下把手头的版本测试好了,记录下bug,然后拿到新版本去回归,然后再对新版本,可能新加的功能进行测试。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2008-1-29 15:48:50 | 只看该作者
    一般情况下提交给测试组一个测试版本,在测试进行过程中,如果本轮测试未执行完,测试负责人是拒绝接收新版本的,这样做至少能够保证每一轮的测试质量,不止于使测试的结果失控!
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-5-5 04:53 , Processed in 0.077970 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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