51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 5842|回复: 9
打印 上一主题 下一主题

[讨论] 【讨论】如何提升测试充分性,避免缺陷遗漏?

[复制链接]
  • TA的每日心情
    郁闷
    2023-11-7 09:36
  • 签到天数: 38 天

    连续签到: 1 天

    [LV.5]测试团长

    跳转到指定楼层
    1#
    发表于 2013-12-14 09:45:58 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    欢迎大家探讨以下两个问题:
    1、为什么会出现下个版本才发现上一版本缺陷的问题?
    2、怎样提升测试充分性、避免缺陷遗漏?

    大家在测试工作中,肯定也碰到上述的问题,项目要发布了,却发现了上几个版本就一直都有的问题,现在才发现,导致项目负责人的指责,发出了“为什么会出现下个版本才发现上一版本缺陷的问题?”
    不知大家如何面对这样的问题,并如何需找原因?

    正因出现上述问题,导致需要想方法或改进当前流程,测试管理等来提升测试充分性、避免缺陷遗漏,不知大家对这方面有什么好的看法或想法?
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

  • TA的每日心情
    慵懒
    15 小时前
  • 签到天数: 3439 天

    连续签到: 49 天

    [LV.Master]测试大本营

    2#
    发表于 2013-12-15 01:54:16 | 只看该作者
    这些从根本,都是测试设计的问题。

    1、为什么会出现下个版本才发现上一版本缺陷的问题?
        看看这个问题,是否在测试用例范围内。
        1.缺陷发生在测试用例范围内。
            1.1 测试用例本身写的不清楚
            1.2 测试执行的时候,测试执行人员没有按照测试用例执行。
        2.缺陷不在测试用例范围内
            2.1.测试设计的时候,是否忽略了什么。
                2.1.1 测试设计的时候,没有考虑到
                2.1.2 测试用例评审的时候,忽略了
           2.2 就是需要探索性测试等才可能发现,测试设计很难考虑到
    2、怎样提升测试充分性、避免缺陷遗漏?
        上面的就是基本的脑图,当然了,大家也可以按照上面的思路补充。
        知道发生的原因,再向前追溯就容易了。
        1.1 找写测试用例的人,下次注意。
        1.2 批评执行测试用例的人,要认真干活。
        2.1.1 下次设计,考虑相关的内容
        2.1.2 既然评审的时候没有发现,责任是大家的。
        2.2 谁都不愿,只能怪老天。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    15 小时前
  • 签到天数: 3439 天

    连续签到: 49 天

    [LV.Master]测试大本营

    3#
    发表于 2013-12-15 02:02:24 | 只看该作者
    上面的是正式的回复内容,下面是吐槽,不要当真。

    其实说什么都是P话,项目负责人应该问问开发人员,为什么开发的东西有问题啊。
    测试用例最大的好处,其实不是指导测试用的,而是测试人员推卸责任的大杀器,测试用例一定要评审,评审的时候一定要拽着开发,一定要让开发人员做确认。就和需求一样,客户需求完成了,再变更责任就是客户的了;用例评审了,之外的问题责任就均摊了。传说中的办公室政治就是这样。当然了,测试几乎做不到这些,所以常常黑锅是背定了,习惯就好了,既然开发负责人能问出这样的问题,就说明对测试没有什么了解,所以你解释什么都是白扯。恶上司就和开发扯皮,好上司就直接认错。反正下面的该怎么做还怎么做,有很多事情,知道有更好的方向可以做,但是你也要有时间、资源、上级的支持不是。
    方法、流程、管理提高测试,从理论当然能说得通,书本上就一向描绘的很好,但是据传说,RUP、CMMI、SCRUM等还能提高软件成功率呢,实际看效果都不好。
    所以测试仅仅需要做好自己的工作,问心无愧即可,有时间就学习学习,争取自己当领导,最后你就可以说,你的程序咋怎么多的问题尼,嗯,也许就会有别人来写这些吐槽东西了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2013-12-17 17:07:59 | 只看该作者
    楼上讲得太好都没人敢回答了。
    以我们公司的现状,木有测试用例这种东西,能做的其实也一样,先分析遗漏的bug属于什么性质,是否系统主要功能或者关键流程,如果是的话,那没得说,就是测试人员做得不好,粗心大意或者水平不够,根本性解决方法就是建立测试用例制度;如果是环境或兼容性问题,那只能当作经验积累,确保下次不犯同样的错误。就我个人而言,喜欢测试前建个checklist,列出功能点,也算是测试用例和随机测试的一个折衷了
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-8-25 10:21
  • 签到天数: 661 天

    连续签到: 1 天

    [LV.9]测试副司令

    5#
    发表于 2013-12-18 15:26:45 | 只看该作者
    版主一论,都是实质,赞一个!!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2016-4-2 12:39
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    6#
    发表于 2013-12-18 20:57:32 | 只看该作者
    肯定要反思原因的,是自己思维不够,没有想到?还是时间不够?还是高危功能,使用方式覆盖不足?。。

    而且,应该整个团队一起来考虑怎么解决这种漏测的问题。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2013-12-19 15:19:35 | 只看该作者
    这个问题太经典了。面试时也总能被问到。说实在的,对一些隐藏的较深的bug的确是难以发现的。目前还没有什么好的办法来‘充分’的测试,只能是在工期里尽可能‘充分’的测试。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2013-12-19 15:36:07 | 只看该作者
    版主确实说出了很多事情,不过有一点不赞同,责任均摊不能说是办公室政治。这是正规的流程,评审的目的就是为了让所有人都产生对产品负责的意识,让所有人都认识到质量是所有人的责任。出问题也容易从各个点进行审查。只不过这种评审除非流程健全,不然无法有效执行,最后就变成了扯皮的条件,不过只会让评审变得更不愿让人参加,最后只能失去原本的作用
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2013-12-20 10:09:23 | 只看该作者
    回答你自己的问题前,你自己能先思考几个问题吗?
    1,谁应该为软件质量负责?测试人员吗?如果是测试的话,仅限于测试阶段吗?
    2,如何度量软件测试的充分性?
    3,在测试充分性与测试成本之间,我是否已经明确懂得平衡之道。
    4,我是否已经非常熟悉测试的理论与方法?非常遗憾的是,黑测里面有个方法叫做error guessing,既然是guessing,漏就漏掉了吧。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2015-12-23 11:47
  • 签到天数: 3 天

    连续签到: 3 天

    [LV.2]测试排长

    10#
    发表于 2014-1-23 13:42:59 | 只看该作者
    本帖最后由 路边的仙人掌 于 2014-1-23 13:45 编辑

    一个软件不可能做到100%测试,每个项目都是有时间与资源的限制,测试就要在有限的时间和资源下对软件进行最大化测试。前期的用例评审真的很重,一个人思考跟大家思考是不一样,评审时最不能少的就是开发人员,他们是更懂得软件那个地方容易处错误。开发人员能够更好的辅助测试人员。要想最小化的减少软件的测试遗漏,只能提高自身经验与测试技术水平。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-4-20 23:59 , Processed in 0.074022 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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