个人网站 数据库如何上传到空间,360优化大师,珠海科技网站建设,jquery+js网站模板免费下载测试用例评审是QA日常工作流程中的关键一环#xff0c;是QA同学完善测试用例、交流测试经验的好机会。 负责组内测试用例建设以来#xff0c;作者对于评审流程做了一些优化工作。本文作者将整个优化过程中的心得体会做了一个总结#xff0c;希望能给大家带来帮助。 01 原始流… 测试用例评审是QA日常工作流程中的关键一环是QA同学完善测试用例、交流测试经验的好机会。 负责组内测试用例建设以来作者对于评审流程做了一些优化工作。本文作者将整个优化过程中的心得体会做了一个总结希望能给大家带来帮助。 01 原始流程 1. 原始流程 首先介绍一下我们组原本的用例评审流程 1、通知用例评审会议大家到会议室集合。
2、用例负责人现场讲解用例同时记录大家提出的问题。
3、会后用例负责人根据自己记录的问题修改用例。
2. 存在的问题 按照这个流程执行下来用例评审的效果并不理想整理了一下存在的问题
1、评审开始前用例缺乏预审。如果遇到质量不太理想的用例直接在会议上展示评审效率会变的很低甚至出现过一轮评审结束后的结论是“建议回炉重造”。
2、有时评审来的很突然参加评审的同学可能没有时间充分了解待评审模块评审时无法充分发现问题导致评审效果不理想。
3、评审现场用例负责人讲解自己用例的同时还需要处理其他同学提出的问题。这时候如果花时间做详细记录或者修改用例那么将会影响会议效率如果只是草草做一笔记录会后很可能就忘记当时想记录内容的具体含义甚至还可能根本找不到那些做了标记的待修改用例。
4、评审现场可能会有一些同学总是保持沉默参与评审的积极性不高。
5、评审会后评审问题会根据一个测试自主任务单跟进但是单子的描述往往不会涵盖会议提出的所有问题因为上面提到用例负责人记录问题存在的弊端。有时可能连单子都忘记开了整个评审不是闭环流程。
02 流程改进 可以看到我们原始的流程存在诸如“评审前准备不充分”“评审效率不高”“评审参与不积极”“评审后问题跟进不闭环”等问题。针对这些问题逐一分析了背后原因对评审流程的各个环节做了优化具体改进措施以及改进原因如下
1. 会议前 1.1 安排评审总负责人 评审需要有一个总负责人主要负责选取评审内容会前预定会议室、邀请与会人员会议中把握会议节奏注意每个环节都走到会议后跟进问题处理情况。
我们组内一般是我来担任这个角色也可以安排其他有经验的QA同学轮流担任。
1.2 合理规划用例体量 每次评审用例的体量不易过大过大的模块建议拆分多次进行评审。当然也可以安排几个体量小的模块在一次会议中评审。
根据经验每次会议控制在一小时内最好如果超过一个半小时大家就会很疲惫专注力明显下降后面的用例得到的有价值建议数量减少。与其这样不如将模块拆分或者至少安排一下中场休息。
1.3 增加用例预评审流程 会议前安排一个QA同学对待评审的用例做预审工作发现用例中明显的规则、逻辑、格式问题避免将这类问题带到会议上提升评审效率。
预审过程中两人之间可能会出现一些争议对于这些争议不必深究可以记录下来放到评审会议中讨论。
建议安排用例负责人的导师来做这个工作也可以安排相关模块的负责人来做这个工作。
1.4 通过集中测试让其他QA同学事先熟悉待评审模块 恰好我是组内集中测试负责人想到可以把用例评审与集中测试相结合。在计划发起某个模块的用例评审时如果之前没有针对这个模块组织过集中测试那么可以先安排一次集中测试让组内的QA同学事先熟悉一下这个模块。这么做可以避免出现部分同学在用例评审会议上才第一次接触这个模块导致大家因为不熟悉模块而无话可说。
2. 会议中 2.1 安排记录员 安排用例负责人之外的另一个QA同学作为会议记录员专门负责记录大家提出的问题。
记录员可以安排负责预审的QA同学、导师、徒弟或者往常提问不积极的同学来做。
这样做的好处
1、用例负责人就可以专心讲解用例不再会因为需要记录问题而耽误评审流程。
2、问题可以被详细记录下来会后过很久也可以被很好的理解。
3、评审记录员是一个很好的机会可以观察学习其他同学的评审技巧。
2.2 邀请策划/程序同学参加用例评审 根据实际情况我们会选择邀请策划/程序同学来参加用例评审这么做的好处有
1、原本需要会后确认的设计问题或者代码逻辑问题可以在会上就得到确认提升效率。
2、策划/程序同学往往会从不同于QA的角度给出评审建议。
3、可以让策划/程序同学更好的了解QA日常都是从哪些角度进行测试他们在日后工作中也会更加注意这些方面减少设计/开发阶段的问题。虽然效果不一定会立竿见影但是确实有帮助。
4、可以消除职能间的隔阂有一些策划/程序同学在参加用例评审后会发现我们的QA同学其实非常专业会增加对产品测试质量的信心。
决定邀请哪些策划和程序同学后要事先通知评审时间和地点。评审结束后我们还会对他们贡献建议表示感谢不用很正式轻松愉快一些就好。这都有助于下次的再邀请他们来参加评审。
2.3 提升用例讲解效率 评审效率低不仅耽误时间而且过长的评审时间会让大家专注力下降影响评审效果。对比多次用例评审我发现体量与完成度差不多的两份用例分别由不同的QA同学讲解会议效率并不相同。用例负责人奖需要掌握一些讲解技巧来提升评审效率详见3.1。
此外评审负责人需要注意每次讲解的情况遇到问题可以会后与用例负责人单独沟通便于下次讲解过程更加高效。如果是首次讲解用例的新人评审负责人也需要在会前将基本技巧传授给新人。
2.4 提升用例评审中发言的积极性 我这边总结一般大家发言积极性不高的原因主要有“不好意思提出自己的看法”、“缺乏评审技巧”、“对于待评审模块不熟悉”、“专注力下降”这四点。下面逐一介绍一下这些问题的解决建议
1、 不好意思提出自己的看法——这个情况多出现于新人如果发现这种情况会后我会去找他或者安排导师与他单独沟通提升新人的自信心。新人的可塑性很强越早发现这个问题越容易解决。
2、 缺乏评审技巧——这个情况也是多出现于新人。除了会后指导外还会安排他作为下一次评审会议的记录员记录员可以更好的观察学习其他同学的评审技巧。3.2中整理了一些基本的评审技巧。
3、 对于待评审模块不熟悉——
a) 像上面说的尽量在评审前组织一次集中测试让大家熟悉模块。
b) 评审开始用例负责人先介绍一下自己设计用例的思路以及用例的大体框架。
c) 负责人可以事先准备一些视频用于主要玩法的介绍。
d) 需要提升QA同学的用例评审技巧。实际评审过程中发现有经验的QA同学对于陌生模块也能很快熟悉并积极参与到讨论中。
4、 专注力下降——
a) 与会人员自己需要排除干扰专心听讲。
b) 负责人控制讨论范围避免无关的发散。
c) 合理安排会议内容对体量大的模块进行拆分。
d) 提升讲解效率适当通过发起讨论或播放视频等其他手段引起大家注意。
e) 对于无法拆分会议时间较长的评审安排中场休息。
评审负责人可以观察每次评审中每人的提问次数针对发言较少的同学分析原因单独沟通。但是需要注意避免让这种方法“强迫”大家提问无效的评审建议反倒会影响评审效果。目前我们组发言积极性提高了很多已经不再用这个方法了。
2.5 问题记录回顾 评审结束前还有一个重要环节记录员需要逐一展示一下自己记录的问题与大家进行确认。避免出现记漏记错的情况。
2.6 优化用例管理平台 设计了用例评审工具需求并在雷火MTL同学的支持下用例管理平台已经支持用例评审功能可以很方便的记录并跟进评审问题统计评审数据等。
3. 会议后 3.1 跟进评审问题解决 借助用例管理平台可以很方便的对每个问题进行跟进让流程形成闭环。
修改用例——用例负责人借助用例管理平台针对记录的问题逐条修改。
验收修改——用例复审员借助用例管理平台针对修改的问题逐条验收。未通过的话可以打回修改用例阶段。通过的话就可以进行归档完成整个用例评审流程。
3.2 复盘本次评审流程 评审负责人需要在每次评审结束后对本次评审进行复盘
分析存在的问题——针对本次流程存在的问题与QA同学沟通或者思考流程改进方法。
评估所做改进的效果——如果本次流程中做了新的优化尝试那么也需要在会后进行评估分析方法是否可行是否需要调整。
03 用例讲解与用例评审技巧 上文提到了对于用例评审流程的优化帮助我们的用例评审工作可以更好的开展。但是归根结底对于用例的“讲解”与“评审”才是最核心的部分所以除了优化流程我们的QA同学也需要掌握一些基本的讲解与评审技巧。
1. 用例讲解技巧 用例评审中用例负责人的职责并不只是详尽的把自己的用例讲完就够了。讲解效率低除了会消耗更多的时间外大家的专注度也会被逐步消耗随着会议的持续有价值的建议会越来越少评审效果也会大打折扣。
对比多次用例评审我发现体量与完成度差不多的两份用例分别由不同的QA同学讲解会议效率并不相同。这里分享一些简单好上手的讲解技巧
1、评审开始后不要匆忙开始直接就“现在开始给大家讲解我的用例首先是一个部分……”。在开始之前可以先简单介绍一下模块基础玩法模块设计目的用例设计思路以及用例框架这些基础信息。简单介绍就好不用花费太多时间。这么做的好处和会议PPT最开始的目录效果类似一方面大家会对评审内容有一个初步的概念另一方面大家可以估计一下会议时长做好心理准备。
2、不要误解用例评审的目的
用例评审不是为了介绍模块琐碎的细节讲解可以简略带过。
用例评审不是为了展示负责人对于自己模块有多么熟悉用例覆盖有多么全面。对于自己很有把握的部分可以简略带过。
3、用例评审主要是为了让大家帮忙发现问题提升用例覆盖率。对于自己不太有把握的部分、涉及核心功能的部分、模块间交叉的部分等负责人可以多花些时间讲解。还可以抛出问题引发大家思考与讨论比如“这个玩法掉落的道具可能涉及到数值培养与生产制造相关模块的同学可以看看有我的用例或者你们的用例没有什么要补充的内容”。
4、就像开始说的会议持续时间越久大家专注度下降越多。所以重点部分无需作为压轴节目放在最后在不影响逻辑的前提下可以不按照用例结构顺序讲解将重点部分放在前面讲。
5、可以事先准备一些视频用来辅助展示玩法内容用例管理平台支持上传多种格式的视频文件。视频表现能力强效果往往会胜过口头表达或者图片展示。而且视频可以很好引起听众的注意力恢复对会议的专注度。
控制视频的时长与数量针对重要流程准备一下就好了。
非必要情况不是很推荐真机展示事先准备不充分的话可能会受到环境或者BUG的影响阻碍展示导致评审中断需要重新恢复评审氛围。
2. 用例评审技巧 用例评审不是用例负责人的独角戏各位参与者提出的评审建议的价值与数量直接决定了评审会议的效果。各位参与者需要在会前先熟悉一下模块内容在会上保持专注积极参与讨论贡献有价值的建议。下面主要介绍一些常用的评审角度除了评审时可以用于提出有价值的建议日常自己做测试设计时也可以用到
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 总结 最后从人员分工的维度再对整个用例评审流程做一下回顾
用例负责同学写好用例后发起用例评审申请修改预审阶段发现的问题掌握用例讲解技巧提高会议效率会后及时处理评审问题完善用例。
用例评审同学会前熟悉待评审模块会上保持专注积极参加讨论掌握评审技巧贡献有价值的建议。
用例预审同学会前预审用例发现用例设计中明显的规则、逻辑、格式问题记录下预审中存在争议的部分评审会议上进行讨论。
会议记录同学负责记录现场提出的评审建议会议结束前回顾记录的问题。
用例复审同学会后用例负责人修改完用例后负责确保问题完全解决。
用例评审负责人如果组内预约不积极可以主动出击寻找适合安排评审的模块评估用例体量考虑是否拆分两次评审安排会议时间通知与会人员根据实际情况提前安排集中测试会议中把控会议节奏防止讨论过分发散适当插入中场休息会后分析评审效果进行改进。
下面是流程图 用例评审流程图
以上是我对组内用例评审流程优化过程的总结希望能给大家带来帮助。当然用例评审也不一定需要局限于会议形式以文档或者结对互审等其他形式也是可以的如果各位朋友有什么想法也欢迎一起讨论谢谢。
总结
感谢每一个认真阅读我文章的人
作为一位过来人也是希望大家少走一些弯路如果你不想再体验一次学习时找不到资料没人解答问题坚持几天便放弃的感受的话在这里我给大家分享一些自动化测试的学习资源希望能给你前进的路上带来帮助。 软件测试面试文档
我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。 视频文档获取方式 这份文档和视频资料对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你以上均可以分享点下方小卡片即可自行领取。
