2024年软件测试最新测试用例评审流程优化,附架构师必备技术详解

img
img
img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!

由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新

需要这份系统化的资料的朋友,可以戳这里获取

2.4 提升用例评审中发言的积极性:
我这边总结一般大家发言积极性不高的原因主要有:“不好意思提出自己的看法”、“缺乏评审技巧”、“对于待评审模块不熟悉”、“专注力下降”这四点。下面逐一介绍一下这些问题的解决建议:

1、 不好意思提出自己的看法——这个情况多出现于新人,如果发现这种情况,会后我会去找他或者安排导师与他单独沟通,提升新人的自信心。新人的可塑性很强,越早发现这个问题,越容易解决。

2、 缺乏评审技巧——这个情况也是多出现于新人。除了会后指导外,还会安排他作为下一次评审会议的记录员,记录员可以更好的观察学习其他同学的评审技巧。3.2中整理了一些基本的评审技巧。

3、 对于待评审模块不熟悉——

a) 像上面说的,尽量在评审前组织一次集中测试,让大家熟悉模块。

b) 评审开始,用例负责人先介绍一下自己设计用例的思路以及用例的大体框架。

c) 负责人可以事先准备一些视频,用于主要玩法的介绍。

d) 需要提升QA同学的用例评审技巧。实际评审过程中发现,有经验的QA同学,对于陌生模块也能很快熟悉,并积极参与到讨论中。

4、 专注力下降——

a) 与会人员自己需要排除干扰,专心听讲。

b) 负责人控制讨论范围,避免无关的发散。

c) 合理安排会议内容,对体量大的模块进行拆分。

d) 提升讲解效率,适当通过发起讨论或播放视频等其他手段引起大家注意。

e) 对于无法拆分,会议时间较长的评审,安排中场休息。

评审负责人可以观察每次评审中每人的提问次数,针对发言较少的同学分析原因,单独沟通。但是需要注意避免让这种方法“强迫”大家提问,无效的评审建议反倒会影响评审效果。目前我们组发言积极性提高了很多,已经不再用这个方法了。

2.5 问题记录回顾:
评审结束前,还有一个重要环节,记录员需要逐一展示一下自己记录的问题,与大家进行确认。避免出现记漏记错的情况。

2.6 优化用例管理平台:
设计了用例评审工具需求,并在雷火MTL同学的支持下,用例管理平台已经支持用例评审功能,可以很方便的记录并跟进评审问题,统计评审数据等。

  1. 会议后
    3.1 跟进评审问题解决:
    借助用例管理平台,可以很方便的对每个问题进行跟进,让流程形成闭环。

修改用例——用例负责人,借助用例管理平台,针对记录的问题逐条修改。

验收修改——用例复审员,借助用例管理平台,针对修改的问题,逐条验收。未通过的话,可以打回修改用例阶段。通过的话,就可以进行归档完成整个用例评审流程。

3.2 复盘本次评审流程:
评审负责人需要在每次评审结束后,对本次评审进行复盘:

分析存在的问题——针对本次流程存在的问题,与QA同学沟通或者思考流程改进方法。

评估所做改进的效果——如果本次流程中做了新的优化尝试,那么也需要在会后进行评估,分析方法是否可行,是否需要调整。

03 用例讲解与用例评审技巧
上文提到了对于用例评审流程的优化,帮助我们的用例评审工作可以更好的开展。但是归根结底,对于用例的“讲解”与“评审”才是最核心的部分,所以除了优化流程,我们的QA同学也需要掌握一些基本的讲解与评审技巧。

  1. 用例讲解技巧
    用例评审中,用例负责人的职责并不只是详尽的把自己的用例讲完就够了。讲解效率低,除了会消耗更多的时间外,大家的专注度也会被逐步消耗,随着会议的持续有价值的建议会越来越少,评审效果也会大打折扣。

对比多次用例评审,我发现体量与完成度差不多的两份用例分别由不同的QA同学讲解,会议效率并不相同。这里分享一些简单好上手的讲解技巧:

1、评审开始后,不要匆忙开始,直接就“现在开始给大家讲解我的用例,首先是一个部分……”。在开始之前,可以先简单介绍一下模块基础玩法,模块设计目的,用例设计思路,以及用例框架这些基础信息。简单介绍就好,不用花费太多时间。这么做的好处和会议PPT最开始的目录效果类似:一方面大家会对评审内容有一个初步的概念;另一方面大家可以估计一下会议时长,做好心理准备。

2、不要误解用例评审的目的:

用例评审不是为了介绍模块,琐碎的细节讲解可以简略带过。

用例评审不是为了展示负责人对于自己模块有多么熟悉,用例覆盖有多么全面。对于自己很有把握的部分,可以简略带过。

3、用例评审主要是为了让大家帮忙发现问题,提升用例覆盖率。对于自己不太有把握的部分、涉及核心功能的部分、模块间交叉的部分等,负责人可以多花些时间讲解。还可以抛出问题,引发大家思考与讨论,比如“这个玩法掉落的道具,可能涉及到数值培养与生产制造,相关模块的同学可以看看有我的用例或者你们的用例没有什么要补充的内容?”。

4、就像开始说的,会议持续时间越久,大家专注度下降越多。所以重点部分无需作为压轴节目放在最后,在不影响逻辑的前提下,可以不按照用例结构顺序讲解,将重点部分放在前面讲。

5、可以事先准备一些视频用来辅助展示玩法内容(用例管理平台支持上传多种格式的视频文件)。视频表现能力强,效果往往会胜过口头表达或者图片展示。而且视频可以很好引起听众的注意力,恢复对会议的专注度。

控制视频的时长与数量,针对重要流程准备一下就好了。

非必要情况,不是很推荐真机展示,事先准备不充分的话,可能会受到环境或者BUG的影响阻碍展示,导致评审中断,需要重新恢复评审氛围。

  1. 用例评审技巧
    用例评审不是用例负责人的独角戏,各位参与者提出的评审建议的价值与数量,直接决定了评审会议的效果。各位参与者需要在会前先熟悉一下模块内容,在会上保持专注,积极参与讨论,贡献有价值的建议。下面主要介绍一些常用的评审角度,除了评审时可以用于提出有价值的建议,日常自己做测试设计时也可以用到:

2.1 针对用例覆盖:

1、 根据我的经验,待评审用例覆盖率最低的是模块之间交叉的部分,这也是召集大家在一起评审用例最希望补充的内容。所以各位评审同学针对待评审模块,首先需要思考:

a) 与其他模块,尤其是自己负责的模块之间是否有可能发生交叉?如,抽卡与战斗模块,立刻装备新抽到的卡用于战斗。

b) 这些发生交叉的可能是否会引入风险?如,玩家战斗时更换时装。

c) 如果无法与自己负责模块发生关联是否也是问题?如,生产制造需要使用材料A,需要确保采集玩法可以获得材料A。

2、 遇到数值/数量相关内容,需要关注各类边界情况。如,拾取物品超过堆叠数量,发送空消息,刷新时间跨月跨年,奖励领取次数达到上限等。

3、 穷举玩法触发条件的各种可能,确保这些触发条件可用,且无逻辑问题。如,活动副本可以通过活动宣传页面进入,可以通过常规副本面板进入,可以与NPC交互进入等。

4、 尝试重复相同操作。如,连续点击UI,副本续杯功能等。

5、 检查数值是否合理。如,技能伤害,奖励投放等。

6、 尝试在主流程中加入新的操作。如,工会战期间被踢出公会等。

7、 记得考虑手机操作。如,锁屏、多指操作、分辨率等情况。

8、 考虑删号、断线重连、重启服务器、更换设备顶号等情况。

2.2 针对用例规则

1、 除了考虑用例覆盖是否有不足,还要考虑用例是否冗余,是否可以被执行。如,“零点前操作”,“零点整操作”与“零点后操作”这三条用例中,“零点整操作”本身就不具备可执行性,通常来说只能让操作无限接近零点。

2、 注意用例是否方便执行。如,“抽卡抽到某张ssr”,虽然这条用例是可以执行的,但是执行时比较考验QA同学的欧气,建议可以附上调整概率的操作,让用例更容易执行。

3、 用例结构是否合理,是否符合逻辑,可以提升用例执行效率。

4、 用例中描述用词与游戏内正式包装保持一致。

5、 注意用例格式,用例分级是否合适。

04 总结
最后,从人员分工的维度,再对整个用例评审流程做一下回顾:

用例负责同学:写好用例后发起用例评审申请;修改预审阶段发现的问题;掌握用例讲解技巧,提高会议效率;会后及时处理评审问题,完善用例。

用例评审同学:会前熟悉待评审模块;会上保持专注,积极参加讨论;掌握评审技巧,贡献有价值的建议。

用例预审同学:会前预审用例,发现用例设计中明显的规则、逻辑、格式问题;记录下预审中存在争议的部分,评审会议上进行讨论。

会议记录同学:负责记录现场提出的评审建议;会议结束前回顾记录的问题。

用例复审同学:会后用例负责人修改完用例后,负责确保问题完全解决。

用例评审负责人:如果组内预约不积极,可以主动出击,寻找适合安排评审的模块;评估用例体量,考虑是否拆分两次评审;安排会议时间,通知与会人员;根据实际情况提前安排集中测试;会议中把控会议节奏,防止讨论过分发散,适当插入中场休息;会后分析评审效果,进行改进。

下面是流程图:

用例评审流程图

以上是我对组内用例评审流程优化过程的总结,希望能给大家带来帮助。当然用例评审也不一定需要局限于会议形式,以文档或者结对互审等其他形式也是可以的,如果各位朋友有什么想法也欢迎一起讨论,谢谢。

总结:

感谢每一个认真阅读我文章的人!!!

作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。

img
img

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化的资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。**

需要这份系统化的资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

  • 17
    点赞
  • 29
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值