测试管理想请教下如何高效进行用例评审

野原 · 2022年02月15日 · 最后由一个小花花回复于 2022年06月08日 · 7208 次阅读

楼主所在公司为初创公司，公司前几次用例评审下来，都发现了一些问题：
1.公司开发人员参与度不高（可能认为就是形式会议）
2.测试用例过多，评审时间长效率低（是否可以筛选出部分用例进行评审）
3.无法感知到评审用例给整个团队带来什么（收效甚微）

9 个赞

共收到 11 条回复时间点赞

野原 #1 · 2022年02月15日 Author

想请教下各位大佬

CKL的思考 #13 · 2022年02月16日 15 个赞

参考我司的几点做法：

聚焦：每次用例评审不超过 1 小时，只评审核心内容及测试设计思路，不对具体的每条用例展开评审，实际上这个意义确实不大，只要测试思路没什么问题，大体上也不会有偏差；
事先准备：事先和研发及产品沟通，让他们提前阅读文档。在评审的时候，不需要拉上所有的人，只需要相关人员即可
持续反馈：测试用例并不是一成不变的，哪怕是评审完。不能让测试用例成为一个借口（很多测试人员经常对其它人说为会不在评审的时候提出来，这种做法很不推荐，别人只是帮你 check，而不是让他来替你思考）
给出行动项：需要修改的内容，及时修改并反馈，让大家有参与感，同时表示感谢。
要注意测试用例的颗粒度，在评审时，不需要逐条过，评审测试思路即可。本质上测试用例也是一个测试思维可视化的过程，除非你们的测试团队特别年轻（哪怕真的都是刚入行的人，也不应该在评审时去逐条过，那是测试主管应该做的事，不要拉上整个团队）
关于评审能给团队带来什么，个人的理解是这是又一次三方对齐需求理解的机会。可以保证大家对同一个需求的理解是一致的，避免更多可能出现的返工浪费。

Ouroboros #3 · 2022年02月16日 1 个赞

业务专家参与 + 大家都有认可用例评审的态度 + 测试用例质量高
别高效变成搞笑了，哈哈。

测试用例过多，评审时间长效率低：可以通过分模块分次进行评审，每次只邀请干系人来，非干系人说实话参与度不高，且提不出有价值的东西。
无法感知到评审用例给整个团队带来什么：通过评审视为开发认可测试范围，如果有漏测，开发测试共同检讨。
公司开发人员参与度不高：这个可能是多方面的，资源进度紧张；评审耗时过长；测试用例质量低，看得人昏昏欲睡；可能都是原因。针对性解决吧。

王德法 #11 · 2022年02月16日 1 个赞

针对第一点：测试人员需要在开发工作进行初始阶段就提出评审，此时开发已经有了大概的思路，但是可能会忽略一些细节或者隐形需求。此时拉上产品、开发进行用例评审，就能够给开发的思路查漏补缺，防止提测时才发现一些关键功能都被忽视了。
针对第二点：如果人手足够，工作分配不畸形的话，正常用例评审差不多半小时到 1 小时就能完成。开发只需要参加自己的需求用例评审就行。至于筛选用例，需要好好斟酌。
针对第三点：如果用例编写的足够好，除非开发水平非常高，否则开发人员肯定能在评审过程中，发现自身思维缺陷与盲区

王稀饭 #5 · 2022年02月16日 1 个赞

公司开发人员参与度不高（可能认为就是形式会议）

大概率是参与各方不理解用例评审的价值，这里影响因素很多，一方面是参与方意识和理解不到位导致对这个会议不重视，另一方面是主持人主持得不好让大家犯困了。个人感觉很重要的点，这个会议不能开太久，最好控制在半小时内，一小时已经有点难顶了……
在技巧上，可以把这次会议当成与研发的交流会，在会上问研发对本次测试最关注的点在哪里，他们希望测什么以及为什么这么想，再反过来去补充用例或调整优先级，让各方参与进来的一些小技巧。（产品一般好像没什么必要参加，至少我参与过的评审都没有产品）

测试用例过多，评审时间长效率低（是否可以筛选出部分用例进行评审）

这个是要筛选的，用例评审不是流水账，重点是体现测试思路，其次才是曝光测试执行过程。一些很常规的、共识性质的测试用例就没必要啰嗦，比如核心路径和普通异常测试等。也不用啰嗦你每一步是怎么操作（除非真的很复杂有信息量在里面），大家也不是傻的，自行看一下就能理解。
至于如何才叫重点测试用例，就要看需求来说了。