51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 2500|回复: 0

[资料] 测试用例评审,他们是这样做的。

[复制链接]
  • TA的每日心情
    开心
    2020-5-23 09:40
  • 签到天数: 101 天

    连续签到: 1 天

    [LV.6]测试旅长

    发表于 2019-9-8 23:46:26 | 显示全部楼层 |阅读模式
    本帖最后由 chenjianlin 于 2019-9-9 00:06 编辑

    摘要:
    关于用例评审,你是否了解用例评审前的准备工作有哪些 ?
    需要几轮评审 ?
    需要哪些人参加 ?
    评审时长 ?
    评审形式 ?
    评审结束后,还需要做哪些 ?

    关于用例评审,多数团队都有这个流程,很多书籍上也有提过,网上充斥着各种文章;那么,各企业团队实际的执行流程是怎样的?如何落地的 ?
    今天一起来看看这篇文章。
    首先明确两个概念。

    什么是用例评审?
    用例评审主要是产品、开发和测试人员,针对测试用例能否用于项目的测试而做的工作。
    用例评审的目的
    为了减少测试人员执行阶段做无效工作(执行无效case,提交无效问题)
    为了避免三方需求理解不一致;
    为了每个测试人员的质量标准与项目要求标准达成一致。

    测试用例评审加入测试流程规范并试用2个多月了,期间根据各方人员的反馈,及为了提高用例评审的效率,特制定以下用例评审规范:

    一、评审前需要做哪些准备工作
    1、需求评审结束后,就可以着手把需求拆分为功能点 。
    工具:建议用XMind,需包含预期结果和测试结果,Android和iOS测试结果可用标签区分标注。
    优点:用画思维导图的方式,逻辑清楚,便于评审人员(产品和开发人员)快速查看,评审效率高。
    这里需要说明的是,很多测试者喜欢用Excel设计用例,我也不例外,但是根据一段时间的试验,和开发产品沟通后,大家都觉得用XMind写思维导图的方式更好,看起来更便捷。
    所以具体用什么工具方法,大家可依个人爱好而定,不过目标是一样的,让用例评审高效快捷的开展,并产生价值。
    2、把功能点再分解为具体的测试用例 。   
    这里需在思维导图上补全预期结果和实际测试结果,便于测试结果跟进。
    3、用例写完后,自己先做好自检,自检中,针对有疑问的点罗列出来,可事先跟产品开发讨论,确定结果后完善用例,仍有疑问的可先做标记,评审会上抛出一起讨论。
    4、和评审人员(开发和产品)确定好具体的评审时间并提前把测试用例发给参会人员查看。


    二、用例评审参加人员
    主要是产品、开发(客户端和后端)、测试、项目负责人、运营。
    注:以上人员为必须参加人员,其他和项目质量、进度有关人员,根据实际情况可邀请参加。

    三、用例评审时间
    对于敏捷开发项目,建议控制在半小时以内。
    如果你认为需求复杂,功能点太多,半小时讲不完,那么建议你对功能点划分优先级,优先评审优先级高的用例,再针对疑问多的用例评审,最后对于功能简单的用例可简单带过。时刻记住我们用例的评审目标,不能流于形式。

    四、用例评审的形式
    1、对照测试用例,从上而下,从左到右,逐条念。
    这是目前很多公司的做法,如果你也这么做过,相信你并不一定喜欢这种方式,因为它费时,不分主次,参会人员的热情与注意力逐渐降低,整个用例评审效率低,作为主持人也讲的口干舌燥,事倍功半。

    2、先对功能复杂,优先级高,疑问多的用例进行评审,再评审功能简单,优先级低的功能点。
    对于评审过程中,一时半会没有结论的问题,可以记录下来,作为会后讨论跟进的重点。
    这种做法,有很多优点,评审刚开始的一段时间,大家注意力集中,参与激情高,这段时间讨论有难度有疑问的问题,效率高。最重要的事最先做。
    另外,整个评审会主次分明,有高潮有缓点,可以更高效的达到我们评审的目的。

    五、正式评审
    正式评审过程中需要注意几个细节,如果你都做到了,那么可以说整个评审是成功的,有价值的。
    1、评审要按用例的优先级,功能的复杂程度进行;
    2、评审过程中尽量做到,思路清晰,用最简洁的语言阐述每一个功能点;
    3、超过5分钟无法确定结果的问题留作会后讨论跟进。

    六、评审结束后需要做些什么事?
    不是说评审会结束了,就完事了,其实对于整个用例评审,这才做了一半。     
    评审结束后,第一时间整理测试用例,把修正的内容重新整理补全。
    会上未确定的内容,会后继续跟进,直到确定结果。
    没有任何有疑问的地方了,再做个简单的用例评审会议总结(如修正了哪些功能点,补全了哪些?哪些模块功能有变动?哪些功能推迟到下一期做?等),
    这个总结是给自己整个用例评审工作总结,同时需同步给项目组其他成员,做好信息共享,这点很重要。
    好了,整个完整的用例评审及需要注意的地方大概就是这些,希望测试组人员认真去看,并落实到具体的工作中。
    个别地方根据项目实际情况可灵活变动。
    最后,有问题欢迎随时交流沟通。  

    关于用例评审,补充:
    一般的做法是用例评审至少两轮,先进行测试团队内部的专业评审,再进行项目组团队的三方评审。
    很多团队也在走用例评审这个环节,但是只是流程而已,没有任何价值,只是浪费时间。参照如上的做法,扣细节,微创新,落地(流程,一定是用来落地的,很多流程看似花俏,却无法落地执行)。

    欢迎底部留言讨论。
    回复

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-3-29 01:28 , Processed in 0.062670 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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