51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 10916|回复: 11
打印 上一主题 下一主题

[原创] 测试过程中的一些疑问(缺陷发现率、测试结束标准等)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2011-7-16 15:05:41 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
已进入测试行业两年,测试过程中一直存在以下几个疑问:
1.测试过程中怎样才能提高缺陷发现率,使测试的问题尽量在第一、二轮发现,降低每轮层出不穷的bug数?
2.怎样才算一轮测试结束,可以达到测试结束标准?
3.对于对于比较隐蔽的缺陷,怎样才能尽早发现?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

  • TA的每日心情
    奋斗
    昨天 07:58
  • 签到天数: 3634 天

    连续签到: 86 天

    [LV.Master]测试大本营

    2#
    发表于 2011-7-16 18:45:08 | 只看该作者
    随便说说自己的看法,仅作参考。
    1.测试过程中怎样才能提高缺陷发现率,使测试的问题尽量在第一、二轮发现,降低每轮层出不穷的bug数?
    缺陷发现率,更多的要了解程序和业务,换句话说,你是否了解开发的软件和开发的人。如果有单元测试、集成测试等,到测试人员手里,大部分的问题应该都解决了的,但是现在很少能做到,更多的是开发人员做完了就给测试,前期缺少甚至没有文档,开发人员的水平也高低不同,责任心更是天差地别。
    在这样的条件下,测试人员能做的,只能保证自己的部分,比如更多的研究已有的文档,更细致的了解需求,收集曾经有过的问题,等等。
    提高缺陷发现率,更多的不在测试这里,是一个整体流程才能更好的保证。测试人员不保证软件质量,那是QA的事情,测试的责任在发现程序存在的缺陷。
    其实大部分情况下,软件开发完,质量就固定了,测试只是在到处漏水的桶上,告诉做桶的哪里有洞,到处打打补丁而已。

    2.怎样才算一轮测试结束,可以达到测试结束标准?

    一轮测试结束和测试结束是两回事的吧。通常有用例,把用例执行一遍,就可以说一轮测试完毕了;没有测试用例,把各个模块测试一遍也算一轮。
    测试结束标准看公司的规定。比如没有致命的缺陷,剩下的缺陷不影响软件功能等等,看公司的标准。没有标准的,测试和开发扯扯皮,通常在进度的压力下,手松松有问题的软件也就那么过去了。反正大部分的软件,有问题也大多能对付过去。实在不行,客户的压力比测试有效很多,测试通常没有很大的权力去控制软件的走向。

    3.对于对于比较隐蔽的缺陷,怎样才能尽早发现?
    还是第一个的问题一样,既然隐藏,那么就需要了解需求和软件。没有发现就不不知道,发现了也就没什么隐藏一说了。其实感觉隐藏的缺陷更多的是测试人员自己爽一下,说看看,这么曲折的问题I find it。测试人员都觉得隐藏的问题,客户发现的几率会更小的。
    隐藏的问题,通常测试用例等方法不很有效,用探索性这样的测试方法,对付这样的问题应该更有效率。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
     楼主| 发表于 2011-7-17 09:35:32 | 只看该作者
    回复 2# luming


        其实我问的这3个问题还是归于一个项目的测试引发的,测试了四五轮,问题数虽有递减的趋势,但总有新问题出现,领导说我们测试不仔细,有些问题是可以在第一、二轮就可以发现的,现在发现的晚,还影响项目进度。
       还问我们怎么判断一轮测试可以结束的?我们现在做的项目比较多,测试人员比较少,一般一轮测试就是修复问题的验证,再加相关联问题的随机测试
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    昨天 07:58
  • 签到天数: 3634 天

    连续签到: 86 天

    [LV.Master]测试大本营

    4#
    发表于 2011-7-17 12:36:27 | 只看该作者
    本帖最后由 luming 于 2011-7-17 12:39 编辑
    回复  luming
        其实我问的这3个问题还是归于一个项目的测试引发的,测试了四五轮,问题数虽有递减 ...
    amy1985 发表于 2011-7-17 09:35


    有新问题是正常的,咱们先不提修复问题引起的新缺陷,只说因为随着测试的进行,测试人员对系统更多的了解,才能发现更深层次的问题。
    还是前面说的,是否测试可以做前期的工作,比如存在需求、设计文档,测试人员可以预期做测试计划、测试需求分析、测试用例编写;或者进一步的测试是否从需求阶段就可以接触到项目,不奢望需求阶段测试方面参与评审,测试至少应该对项目的进度、内容等进行了解。
    没有上面的那些,软件直接提交到测试,测试只能在测试过程中不停的进行摸索,了解需求、了解软件,当然会花费更多的时间,因为前期的时间集中到最后了。这是任何一个人都无法解决的问题,只能等待随着测试人员对业务的了解,对下一个项目才能更快的进行测试。
    通常情况下,没有上面说的前期阶段直接测试的条件下,第一轮就发现发现表明的问题,让软件能跑下去而已。第二轮才能了解程序整体的走向,比如数据的流转。第三轮测试才能真正的了解软件,明白软件到底需要达到什么样的目的,到底内在需要什么样的功能。没有5轮以上的测试过程,系统测试很难结束的,所以你说的问题根本不称为问题,这是大环境决定的,测试方面无能为力。
    测试是良心活,开发至少要拿出能用的东西,测试测没测过只有自己知道。测试用例其实就是保证测试人员的工作进程的;没有测试用例,测试完毕后发现问题顶多说自己马虎了,一些地方没有测到。开发有进度压力,可能开发出很糟糕应急的软件;测试也一样,没有时间只能马虎的测试一下,没有大概的问题也就那样。

    嗯,上面的是测试方面的理由,自己知道就行了,和领导没有必要这么说,上面一般不会接受这些东西的,因为这么说责任和压力就在项目经理和领导头上了。只能潜移默化的影响领导,比如知道要测试什么东西,随时和项目经理要需求设计文档,没有的话,在不经意间和上面说说,说因为没有这些文档,测试不好开展。不要直说,因为直说如果真的让上面让项目经理补这些文档,项目经理一定会抓狂的,对测试也会有看法,说这些仅仅说明测试工作不好做而已。有时间写写测试用例,给上面领导看看,说明除了测试,我们还开展的正规的工作,能让项目经理评审一下就更好了,这个是推脱责任的利器,以后客户方面发现问题,只要说测试用例中忘记了,下次补充上,就能推卸不少的责任,至少态度在那里不是。
    测试进度忙,多加加班,至少样子在那里,领导说测试不仔细,就回答时间实在太急,测试的项目太多,每个都详细测试没有时间,嗯,随便拿两个自己测试发现的缺陷说一下,说开发那边的进度也一样,太急了,很多东西都没做太好就拿过来了,当然了,只说问题,千万别提具体的项目或具体的人。
    领导问如何判断一轮测试结束,告诉他,明天来一个新项目,无论如何,测试这边今天必须结束,否则测试项目就堆积了。工作找借口是件最容易不过的事情了,很多时候,领导也只是找个借口,说明他在起作用,确实在管理而已,并不在乎你的回复是什么。

    嗯,大概就是这些了,不是很理论化,但是我想实际工作应该理解和用得到,也许和你们公司的实际情况有差别,但是我想大多数的测试人员都无法避免这些事情的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
     楼主| 发表于 2011-7-17 17:09:54 | 只看该作者
    回复 4# luming


        谢谢,学到不少东西,至少同事不会跟我说这些
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2011-7-19 11:57:00 | 只看该作者
    165403315
    该群可能 有人知道
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2011-7-19 17:37:52 | 只看该作者
    本帖最后由 Carl_Lew 于 2011-7-19 17:41 编辑

    1.测试过程中怎样才能提高缺陷发现率,使测试的问题尽量在第一、二轮发现,降低每轮层出不穷的bug数?

    请有经验的测试工程师,事先对测试案例进行审阅,按照测试案例的重要程度进行分级,可以分为:关键的,重要的,一般的。把关键的重要的放在最前面测试。通过渐进的方式保证严重问题可以第一时间发现,绝对要避免不分轻重的“地毯式轰炸”。

    2.怎样才算一轮测试结束,可以达到测试结束标准?
    测试前要制定测试计划,也就是说要目标导向,对每轮测试目标进行定位,只要达到这个目标就可以进入下一轮,也可以说达到一个里程碑。比如说,第一轮要保证功能完整,消灭功能缺失问题;第二轮要保证功能实现细节正确;第三轮。。。。。个人认为不能以BUG多少去衡量。

    3.对于对于比较隐蔽的缺陷,怎样才能尽早发现?
    之所以隐蔽,一般可分为两种情况:一是测试人员技能欠缺,对被测试对象缺乏深入了解;二是模块相互作用时才会出现。第一种情况就是尽量使用有经验的人、细心的人,第二种情况是尽量避免配置单一化,测试过程多变换配置,并且测试人员间要加强沟通和信息发布。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2011-7-19 22:10:33 | 只看该作者
    1.缺陷发现率:如果要严格来说,缺陷发现率是跟测试用例关联的,如果测试用例不完整,或者发现的BUG不在测试用例范围内,那这个缺陷率也就不好衡量;这里的缺陷发现率,我觉得更多是是从测试用例上着手,先从测试用例的覆盖需求上评估,评估玩后再关联BUG,从而达到所谓的缺陷发现率;
    2.测试结束标准:我个人也做过测试执行,我发现在跟踪版本,特性的时候,有时候测试结束的并没有标准,这里不能用一个点去衡量,而应该用度去衡量,测试完成了,那就要review 提交BUG剩余多少,剩余BUG是否都需要解决、可不可结束这些可由pm、产品、测试一起讨论决定;
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
     楼主| 发表于 2011-7-20 21:40:53 | 只看该作者
    回复 8# andyfly_001


        我们测试前会根据需求、设计写用例,测试过程中也会根据发现的问题再补充用例,但还是每轮都会再发现那么几个问题,老是感觉结束不了测试
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2015-12-11 09:58
  • 签到天数: 38 天

    连续签到: 2 天

    [LV.5]测试团长

    10#
    发表于 2011-7-26 18:02:15 | 只看该作者
    1、尽量熟悉业务,细化业务,已经业务行业知识;项目代码实现工作原理,每个流程都细化了解
    2、一般按计划完成测试预订的测试任务即可
    3、细化广泛思维业务
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2011-7-28 14:03:18 | 只看该作者
    受益了,新手上路
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-8 05:47 , Processed in 0.072683 second(s), 26 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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