研发效能 如何有效的进行用例评审

京东云开发者 · 2023年03月13日 · 最后由 沫沫sir 回复于 2024年03月05日 · 8076 次阅读

作者:京东科技 刘刚

用例评审对于质量同学是再熟悉不过的一个重要环节,用例评审也是非常有效的保障测试质量的手段,但我们质量同学做了这么多次的评审,有没有去思考怎样去进一步提升用例评审的质量,使用例评审更加有效呢,这里呢抛砖引玉,总结一下我个人对用例评审的思考,希望能给大家带来一些启发。

用例评审的意义

对于用例评审,我们要首先要想清楚通过用例评审可以带来哪些价值和收益,而不只是停留在表面和流程上,要持续的去思考和提升用例评审效果,这样大家专门花时间进行用例评审才能更有意义,这里我提出四点价值:

共识需求

• 开发、测试、产品碰撞自己理解需求是否正确的过程,进一步排除分歧,达成共识。

• 帮助开发进一步理清需求,补充开发未考虑到的场景。

补全场景

• 帮助测试发现用例中存在的场景欠缺,避免需求遗漏,并补全测试场景。

• 引导产品进一步思考,补全考虑不周之处。

风险规避

• 对测试重点、风险点、测试范围团队共识

附加价值

• 引导团队质量意识提升

• 体现测试价值

前置准备

在正式评审前,我们需要提前做些准备工作,这样才能有效保障我们的用例评审效果。

用例评审前的准备工作

有质量

• 如果本次需求较为复杂或自信心不强,强烈建议在正式需求评审前进行一轮测试内部评审,使用例达到比较完备的条件。

划重点

• 适合评审会上共同讨论的需求中疑问点和优化建议,提前在用例中做好标记(注意大部分疑问点应线下提前沟通明确,避免会上过多讨论)

• 用例要有逻辑清晰的结构呈现,并且提前划分好用例优先级和评审重点。

降成本

• 用例较多时,将用例按前端用例、后端用例做好分类,以便用例评审时可分开 review,节省时间。

• 建议提前一天,将用例提前发给相关人员查阅,并提前发出会邀,预约好时间。

• 评审前五分钟,提前去会议室准备好,并将相关用例、需求页面、开发设计页面、原型图打开。

用例评审时机要求

为保障用例评审效果最大化,最迟应该在开发提测前进行评审,最佳评审时间为开发中后期,这时开发对需求已有较为全面理解,程序架构也基本成型,用例评审时开发可给出较多建议和补充。

用例评审人员要求

不同角色的人员到场要求如下:

• 前后端开发(必须)

• 产品(必须)

• 设计(看情况)

• 其他(如:量化、运营同学)

评判标准

好的用例评审具备哪些特点

怎样的用例评审才算好的评审,这里我提出三点,供大家参考:

共识需求

• 共识需求细节,排除疑惑,避免需求理解分歧

补全场景

• 业务/测试场景及技术方案考虑周全,能够给产品、研发较多有效输入

• 引导产品和研发思考,促其提出有效建议和补充

高效评审

• 能够提高用例评审效率和效果

流程规范

用例评审流程

这里绘制了一下用例评审的流程环节,清晰展示用例评审相关的各个节点和动作,共大家参考。

用例评审补充建议

会前准备

• 用例设计,结构思路要清晰,表达要准确 (尽量采用开发/标准的表述),避免有歧义的语句

• 对有歧义的问题,最好是在评审前找对应的开发/产品确认下

会议阶段

• 评审会议时长最好控制在 1H,若东西太多,可以分多次评审

• 评审时可视化结合,比如针对页面用例,可先打开对应的 UI 页面/原型/设计图

• 用例陈述时,要有主题和层级,若主题/层次切换,要有对应的过渡

• 评审过程中,参与人员会存在视觉和听觉疲劳,主讲人要抓住重点和重要人员,并做好引导和提醒

• 评审过程中的问题,要及时做好标记

会后阶段

• 用例评审后,需对用例评审中的问题,跟进/补充用例/告知大家已完善

• 用例修改后,需对用例进行管理更新

最后,补充一下,对于用例评审,我们质量同学要注意结合团队特点,做出相应的调整,没有固定不变的流程,只有不适合团队的流程。只要我们用心去做评审,用心思考过程中遇到的问题,真正的从整个团队维度去思考解决,并有持续改进的思想,相信我们质量工作会越做越好,在整个产研团队中也更有价值。

共收到 5 条回复 时间 点赞

没有用力评审的路过

用例的形式也很重要,平常的 excel 用例看一会就没兴趣了,xmind 分解功能点相对来说可读性比较高

用例评审还是很有必要,可以提前对齐各方对产品的理解,降低后期的沟通成本;另外,也可以规范测试用例的编写与完善。

难,很多时候评审期处在上一个迭代的关键测试阶段

最难过的就是测试内部评审,自我认为

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册