zoukankan      html  css  js  c++  java
  • [转载]聊聊测试管理

    转载自“山丘的测试之道” : 聊聊测试管理(管事篇)

     

    管理:管人+管事。

    说到管理,其实就是团队,没有团队,就谈不上管理。个人理解,对个人而言,更多应该是计划,而非管理。做管理的时间并不长,或者说很短,可能很多地方理解的有问题。写这篇文章也是为了能更多的与大家交流,也是记录下在目前这个阶段我的理解。(本文均以在创业型公司工作为背景),全篇分为管事篇跟管人篇。

    管事篇

    一、测试的工作流程。

    关于这个点,其实网络上一搜一大堆,大体都差不多,需求分析,测试计划,设计测试用例,评审用例,执行测试,缺陷管理,定版,发布。但是,我认为作为一个测试leader,在一个创业型公司,并不是出一个这样的流程这么简单。我觉得更多应该考虑的是适合公司的。在我制定我们团队的测试流程时,与我们的项目经理,架构师甚至产品经理都有过很长时间的沟通,测试活动离不开产品,开发,所以在测试的工作流程中,应该包括如何去产品,开发更高效的去协作。下面讲讲我整理的测试工作流程。

    1、需求分析

    黑盒测试离不开需求分析,所有的测试都是基于需求,如果对于需求的理解不够透彻,测试的质量也就可想而知。所以在这个阶段,我会花很大量的时间去做。我团队的需求分析主要包括:两图一文档。

    两图:业务流程图,思维导图。

    一文档:需求分析文档。

    业务流程图,是对于需求从流程(整体)去理解。思维导图,是对需求所包含的各项功能点去理解。需求分析文档,是对思维导图中的功能点去发散成为测试点。这样下来,一个需求所表达的内容,基本不会漏掉。而更高层次的隐性需求,就需要对业务有着很深的理解,这点可以在工作中慢慢去引导团队成员去做。流程上很难去控制。

    2、测试计划

    网络上的测试计划,都是一个文档,一大堆形式上的东西,可能对于大公司而言,有这个必要,我目前所见识的,基本都没有必要。

    我认为测试计划主要给出以下几点:

    (1)、测试类型:黑盒测试,接口测试,UI自动化测试,接口自动化测试,性能测试等等

    (2)、测试时间:需求分析起止时间,设计测试用例的起止时间,执行测试的起止时间

    (3)、测试执行人:创业型公司由于人员少的情况,很可能以项目(模块)划分测试负责人,也可以根据设计和执行来划分测试负责人

    一个测试计划,有这三点,我个人认为就可行了。

    3、测试用例

    关于设计测试用例,可能很多在创业型公司工作过的小伙伴会说,时间很紧,压根没时间来做这个事。

    这一点,我用了两个月做了一个调研,前一个月不写测试用例,大家就按照自己的思路去测试;后一个月,严格写测试用例,执行测试集去测试。调研结果是:前一个月在测试开始时,测试速度稍微快点,在进入测试中后期,测试速度就很慢很慢,因为常见点已经测试完了,测试工程师自己都不知道哪些东西测试过了,哪些还没?哪些没有问题,哪些还有问题?不能很直观的去管控。后一个月在开始时,由于写测试用例的时间,速度会稍微慢点,但是在中后期,测试效率明显比前一个月要好很多,测试工程师对于项目的把握也更清楚。两者整个花的时间基本差不多。质量就更不用说了,肯定后者更有保证。

    探索性测试,我觉得在业务能力以及测试经验都很充足的情况下,可以结合编写测试用例,去执行测试。一味的追求探索性测试,其实对于大多数测试工程师来讲,很难。

    目前,我的团队是,测试工程师编写好测试用例,先组内评审,然后导入到QC,测试人员根据QC测试集去执行测试,而我也能很直观的把控测试进度,以及当然存在的问题。

    4、测试用例评审

    用例评审很重要,毕竟测试工程师也是人,也会有很多点是想不到的,所以用例评审就是一个查漏补缺的环节。用例评审不是找人茬,而是在这个过程中,补充测试思路,提升测试质量。

    年前,这一项,我们没有做,因为当时我们的测试工程师写的用例还达不到评审的水平,所以只是组内评审。目前已经启动用例评审。效果还待观察中。

    测试用例评审方法:

    (1)、提前邮件提醒评审相关人员(开发负责人,产品负责人,测试负责人,项目经理等),附件上测试用例。

    (2)、1-2天后,组织用例评审会议,由于事前有看过需求跟用例,所以会议时间不建议很长,只要是查漏补缺,每个人都会有一些测试思路,也会发现已有的测试用例的不足。

    (3)、根据会议记录,将没有考虑到的点维护成测试用例。定版。

    定版后的测试用例,就可以用来执行测试了。

    5、缺陷管理

    缺陷,最重要的是,清晰明了的说明问题,重现步骤,以及如何解决。

    效率的提高在于细节,缺陷管理工具上写的不明了,也可以通过实时沟通来解决,但是沟通就需要时间,如果缺陷管理工具上,写的很清晰明了,这沟通的时间成本就节省了。

    一个缺陷就是一个用例,这个思想很重要,我经历的公司,对于缺陷都是放在管理工具中,缺陷解决后,关闭,就没有然后了。其实每一个缺陷都是一个优秀的用例,这些用例你可能已经写了,也可能没有,而没有的话,就需要维护到测试用例中去,下次执行时,你就多预防一个点。

    6、验收测试

    通常,通过测试的功能就会准备上线。但是上线前,还需要产品或者运营,来验收需求。功能实现是否满足需求,有没有未考虑到的功能等等。产品或者运营做验收测试时,我会给一个EXCEL文档,作为他们记录问题的LIST,每天跟我反馈下进度跟结果。如果有缺陷,再安排时间去解决。如果有需求上的缺陷,会定会议评审,在这次发布修改,还是下次发布修改。最后,上线与否,需要他们的确定。

    二、测试时间

    1、争取测试时间

    创业型公司,产品版本迭代快,周期紧,往往压缩的是测试时间。而测试质量在一定程度上,与测试时间成正比,所以这点很矛盾。

    测试时间需要争取,因为项目时间很紧,资源更多的用于开发,上线时间确定后,基本上离上线时间只有2天时间才开发结束,才交付测试。而这么短的测试时间,要保证测试质量很大,并且可能还需要大量加班。而测试时间的争取,又需要测试质量作为依据。那么怎么来争取测试时间呢?我认为是这样的:

    (1)、尽量在开始时,哪怕加班也要做好质量保证,之后在争取时间的时候,可以尽量拿质量作为理由来说;

    (2)、平常要多跟项目经理,架构师等聊聊产品质量,输送质量意识,并多讲讲测试的重要性,不是每一个开发或者负责人,对于测试很重视的,尽管现在测试行业在快速发展。

    (3)、就是在测试时间上,坚决不让步。上线后,产品出现问题,很多时候,会让测试背锅,当然也有开发的原因,但是大家的想法是:这个问题怎么没有测试到?这个时候,你再说测试时间不够,意义就不大了。

    2、安排测试时间

    测试时间的安排,需要根据测试人员本身能力定。能力强的,当然需要的时间短。大体上而言,我对于测试时间的安排如下:

    (1)、模块内(模块间交互少)的功能,需求分析时间和设计测试用例的时间为1天,执行测试的时间为2天(主要是缺陷修复时间),最后验收时间为半天。

    (2)、模块间交互多的功能,需求分析和设计测试用例各1-2天,执行测试时间4-5天,最后验收时间为1天。

    (3)、系统级的功能需求,需求分析3天及以上,设计测试用例时间2-3天,执行测试时间一周以上,最后验收时间为2-3天

    主要策略是,需求分析的时间得保证,这个时间不能挤,毕竟这是测试最重要的部分。设计测试用例的时间可以稍微挤挤,这块最主要的时间是需要写文档。测试时间多考虑缺陷修复时间,测试一轮下来可能很快,但是缺陷修复的时间就可能很久。最后需要验收时间,产品或者运维对于该功能的验收,看是否满足产品需求。

    三、测试进度与质量

    1、测试进度

    测试计划确定后,接下来就是测试进度的把控了。进度的把握不是实时的要求测试工程师反馈,也不是自己想了解的时候就去问一下。需要有这么一个规则,既可以直观的查询到目前的测试进度,又可以接受测试工程师的反馈。而我们团队的规则如下:

    1、使用项目管理工具:Teambiton,任务板上有每一个测试工程师在这次发布前的任务,每一个任务都有详细的测试时间,能明了直观的看到任务的执行情况。

    2、执行QC测试集:QC测试集,是基于测试用例的执行,每一个用例的每一个步骤都有执行状态,这样在测试过程中,就能实时的查看到当前测试的进度。这个最为准确。有没有偷懒,或者是否是应付式的工作都能看出来。

    3、每天下班前,都会将今天的测试情况反馈给我。这一点准备改良,定为每天早上5-10分钟站会。每一个人都需要讲讲昨天干了什么,今天准备干什么。时间长了,站会可以提高整个团队的效率。

    4、每天早上跟每天下班前,都需要检查一次缺陷管理工具,查看今天已解决尚未验证的缺陷是否已经处理完了。

    如果出现测试进度很慢,跟预期严重不符,会先跟相关测试工程师讨论,是预期时间不够,还是测试工程师本身的问题,还是开发工程师的问题。这个时候就是需要测试leader来解决了。找到相应的问题并解决它。

    如果出现测试进度过快,也需要去确认,防止为了赶进度而忽略质量的情况。

    2、测试质量

    行业内有一句话:测试不能保证软件质量。我认为,虽然我们不能保证软件质量,但是我们可以保证测试质量,尽量提高软件质量。

    测试的质量,是测试活动最重要的一环,所有之前的一切都是基于提高测试质量为目标的。那么如何提高测试质量呢?

    (1)、充足的测试时间。并不是时间越长越好。

    (2)、全面的测试需求分析。

    (3)、充分的测试用例设计。

    (4)、测试人员的能力(管人篇详细聊)

    (5)、做好验收测试。

    (6)、风险控制

    等等。

    四、线上跟踪

    我一直都认为,不管测试多么精确,到线上后,都会存在问题。只是说测试可以尽量去减少这样的情况发生。

    如果产品上线后,出现问题,怎么处理?

    第一时间,在测试环境中,重现。能重现,则找相应的开发工程师解决,再评估上线时间。如果不能重现,就直接找项目经理,评估解决办法。

    而一般而言,出现问题后,责任我会担着(这是一种得人心的方法),事后会跟相关的测试工程师去探讨出现这个问题的原因,是由于他自己引起的,就总结为什么,争取别在同一个地方跌倒两次,对于他而言,是一种成长和进步。

    结语

    以上仅仅是个人的理解。希望大家能多探讨。

  • 相关阅读:
    LightOJ 1132 Summing up Powers(矩阵快速幂)
    hdu 3804 Query on a tree (树链剖分+线段树)
    LightOJ 1052 String Growth && uva 12045 Fun with Strings (矩阵快速幂)
    uva 12304 2D Geometry 110 in 1! (Geometry)
    LA 3263 That Nice Euler Circuit (2D Geometry)
    2013 SCAUCPC Summary
    poj 3321 Apple Tree (Binary Index Tree)
    uva 11796 Dog Distance (几何+模拟)
    uva 11178 Morley's Theorem (2D Geometry)
    动手动脑
  • 原文地址:https://www.cnblogs.com/miniren/p/5336219.html
Copyright © 2011-2022 走看看