美文网首页
迭代内测BUG分析记录

迭代内测BUG分析记录

作者: 唐T唐X | 来源:发表于2018-04-19 22:46 被阅读54次

    作为一个测试人员,我们平时的工作其实是很多的,包括以下但不限于:


    测试工作.png

    当然这不是最全的,有些牛逼的测试人员能够做比这些还多的工作。也会有没有这么多的,那原因应该无外乎几种:

    1. 测试人力充足:人力足够就可以把测试的工作进行细分,不用一个人去负责很多的任务,有钱就是任性。
    2. 自动化&测试工具成熟:这个很厉害了,把能够自动化的全部自动化、测试内容工具化,减少人力的浪费,但需要很高的测试技术底蕴。
    3. 加班:这个不说了就...

    在这里,我们就说第二种,因为我们都希望我们的测试团队是往这个方向发展的。其实以前发过很多关于测试自动化还有测试工具的文章了,也就是要在这个方向上行进的证明。但是,想归想,一个团队,尤其是小型公司的互联网测试团队,往往都承受着测试人力紧缺的压力。就拿我们来说,目前我们对于技术部门开发人员和测试人员的比例控制是5:1,也就是1个测试人员在1迭代时间内要能够具备承受5个开发人员交付物测试的压力。以目前的迭代速度,再进行自动化或者测试工具等项目的开发的进度会很慢。所以,我们要找到能够争取时间的点,来让我们有更多的时间做测试的改进优化。

    接下来就是找能够争取时间的点了。在这个上面我们采用了测试流程记录的方式,就是把测试在一个迭代中做的工作的每一步的开始时间&结束时间记录下来,发现除了测试本身时间占比很多外,本迭代内测BUG验证也是很吃时间的。而内测BUG验证的时间又直接受BUG数量的影响,所以,分析后我们就把希望放在了减少迭代内测BUG的数量上。

    测试小伙伴们应该知道的,想降低迭代内测BUG的数量,不简简单单是测试人员想想就可以的,因为BUG的产生原因多种多样,或源于产品需求的不确定,或源于开发的不认真,或源于测试用例的不正确,或源于各方信息的不对称等等等等。所以,解铃还须系铃人,如果想降低BUG数,那就需要好好地分析BUG的产生原因,而分析的数据就来源于我们的迭代BUG中。

    下图是我们这几个迭代的内测BUG数量统计:


    BUG.png

    可以看到吧,每迭代的BUG下降趋势还是蛮明显的。需要说明下,正是迭代v1.1让我决定了需要做BUG分析,因为BUG数在这个迭代中达到了骇人的314个,致使测试人员在整个迭代中一直在报BUG和验证BUG,凶猛的吃时间怪兽。

    有问题不怕,就怕视而不见。面对v1.1这314个BUG,我们做了第一次BUG分析,分析结果如下:

    1. 本迭代由于需求过多,只能分3期开发,每期2周(我们之后的迭代就是2周),而且只能在3期全部完成开发测试后才能发布。所以造成BUG总数多
    2. 开发执行提测准入case(后文统一称呼为AC,Acceptance Criteria)不合格,一些提测的交付物甚至连流程都走不通
    3. AC粒度太粗,只是主流程,分支流程覆盖不够,即使开发通过也会出现很多明显BUG
    4. 分期开发,模块开发每期拆分不合理,耦合度较高,造成后期的开发影响了前期的功能,造成回归BUG增多
    5. 技术评估时漏了一个功能模块,导致临上线才发现并开发,由于时间紧,慌乱中又贡献了很多BUG
    6. 服务环境配置问题

    针对v1.1的分析结果,我们采取了一些措施:
    对产品经理:提供需求时需要考虑成本,尽量将需求控制在2周之内,需求需要和开发&测试一起评估,如有超出需要根据情况减少或更改需求。
    对开发人员:合理拆分需求,进行技术评估,人员分配任务时尽量解耦,避免冲突发生;加大自测的力度,每次提测需要严格通过AC;保证服务质量,完善服务监控。
    对测试人员:编写AC时实时反馈产品问题;缩小AC粒度,增加AC中分支流程覆盖。

    那之后实践的结果怎么样呢?从v1.2和v1.3上我们可以发现确实有改观,但是在2周内产生大于60个BUG还是很多的,所以我们在这2个迭代也做了BUG分析,主要的结论是:

    1. 自测不够,AC里面明确的点提测后并没有通过
    2. 原型缺少某些共识的说明,比如输入框中文本格式的样式及规则等,导致开发的交付物存在各种不一致

    针对v1.2和v1.3的分析结果,我们采取的措施是:
    对产品经理:提供高保真的产品原型;对于产品设计共识,输出共识文档供开发和测试使用
    对开发人员:加大自测的力度,每次提测需要严格通过AC

    好了,那就可以再实践了。v1.4结果出来后,有点失望,还是不低。没办法,继续分析吧。

    1. 自测不够,AC里面明确的点提测后并没有通过

    好吧,看来我们能够入手的点就是开发自测了。所以v1.4之后我们的措施是:
    技术负责人负责提测前和相关开发一起过一遍AC,通过后才能提测;在过AC的过程中技术负责人要将遇到的问题记录下来,方便日后在开发团队中提高自测质量。

    在此之后,我们可以很明显的看到,v1.5 - v1.7的BUG数量有了非常明显的减少。当然,这些版本的需求量其实是有些下降的,但是我要说的是,其实我们的迭代时间也在下降,也就是从2周降到了1周,甚至在v1.7时是3天。当然有些小伙伴要说了,开发做了自测,那不是测试的本职工作吗?对不起,我对于这一点实在不能苟同,请记住,作为提供产品中的一环,开发是要对自己的交付物负责的。

    再说下v1.8,这也是一个很好的案例收集。因为我们在v1.8进行了技术优化(解决了前期迭代中没有时间解决的技术债),但是由于没有给开发提供相应的AC,导致了回归BUG数量很多。所以对于未来再有技术优化时,开发需要先定义好需要优化的模块,然后由测试给出AC,开发自测通过后再提测。

    从实践的结果来看,通过BUG分析来降低迭代BUG数量的方法还是非常有效的,而且测试团队也已经感受到了它给我们带来的红利,让我们在测试团队改进提升的道路上能够走得更稳更远。

    相关文章

      网友评论

          本文标题:迭代内测BUG分析记录

          本文链接:https://www.haomeiwen.com/subject/cgxgkftx.html