测试基础 大家在进行测试用例设计时,会有一个 checklist 模板吗?

Gikagou · 2024年04月08日 · 最后由 又活了一天 回复于 2024年04月10日 · 4855 次阅读

背景

部门内每个测试人员的测试用例设计水平不一,有时会出现场景遗漏的情况,仅通过测试用例评审有的用户场景依然可能会遗漏,希望通过一个 checklist,规范测试用例设计思维和设计角度,大家的公司内有类似的实施吗?

如果有的话希望分享一下,以下是我分享的 checklist 实例:





共收到 11 条回复 时间 点赞

我是新人,想问一下 checklist 主要是记录一些什么东西,和用例区别在哪

704280139 回复

checklist 是设计测试用例的模板,设计完测试用例后对照一下 checklist 检查有没有遗漏的

Gikagou 回复

原来如此,类似于设计用例的思路了,谢谢😀

我们会有类似的通用测试用例

感觉是一个很好的规范用例,查漏验证点的工具。但具体实施起来有几点疑问:
1、checkList 由谁去编写?(谁来保证 checkList 的覆盖性)
是由负责对应模块的测试人员去编写吗? 如果是的话,我理解可能 checkList 本身也会有遗漏。理论上需要考虑测试点校验的时候,也相当与在编写测试用例雏形了
2、checkList、用例都写完了,是由谁来进行检查,什么时间进行检查
这个问题本质上还是在询问怎么去确保 checkList 结果的正确性。
3、在楼主已有的执行记录来看,checkList 的验证性和遗漏点的比例是多少,有效性如何?
4、可以分享执行这个 checkList 过程中需要注意的点吗

编写的一般是非常高级的测试,不过也会存在写的 checklist 有可能会过于通用,或者很多方面和具体的业务其实关联不上的情况

我也来参与讨论一下,欢迎大家指正!
1、checkList 由谁去编写? ---测试经理或者高级测试工程师(类似的岗位)
答:checklist 里面记录的是新开发的功能当中,需要 check 的点。首先这个人选应该是一名测试 title,其次应该拥有几年的测试经验,对新开发的功能有相对完整的了解。一些公司可能没有类似高级测试工程师的岗位,所以一般也可以由测试工程师来编写。至于 checklist 的遗漏问题,那么就来到的第二个问题。
2、checkList、用例都写完了,是由谁来进行检查,什么时间进行检查?---测试组(项目组成员),checklist 完成后 2-3 天。
答:不管 checklist 是由谁来编写,也有一定概率导致 check 点遗漏。所以,需要 checklist review 环节。以我们之前敏捷开发举例,team 中有 1 个 Scrum master, 4-5 developers, 4-5 testers。checklist 完成后,即刻通知组内,每个人 review 一遍,问题少,则私下沟通,保留痕迹。问题多,则 book meeting,统一过一遍。 至于时间嘛,当然越早越好,但是也要给 team member 一点时间,让他们也先 review 一遍,所以我们一般留有 2-3 天时间。

8楼 已删除
Duke 回复

感谢讨论~
checkList 由谁去编写,如何保证覆盖性这个问题 @ 沫沫 sir 确实说出了我心中的疑问 --【不过也会存在写的 checklist 有可能会过于通用,或者很多方面和具体的业务其实关联不上的情况】
我更为关注的也是这个问题,我认为这是最基本的问题:既当你想推动一项新的变化事项时,如何去向大家证明新事项的有效性。
当然,我考虑的问题会基于目前的项目情况:迭代频率大概 3 个星期 1 次,迭代范围广。且项目深度、广度都有,团队的测试人员很难有一个能够知悉全部业务细点的人存在。
1、所以像第一点中您的回复,我认为在项目中需要一个对全局业务都能了解,并且能对版本迭代新功能都有了解的人来学 checkList,才能保证覆盖性。 如果不存在,可以由负责对应模块的测试人员来写。 那问题就来到了第二点(哈哈哈)
2、如果每个人只熟悉自己的模块的时候,即使进行团队 checklist review 环节, 成员之间应该也很难发现彼此 checkList 覆盖不全的问题。
需要说明一点的是,我所在的团队不是敏捷开发模式,我本人也未曾长时间呆过敏捷开发的团队,因此对这个流程是缺乏实际感受的。但看到您提出来实际的操作流程来看,这个 checkList 应该是行得通并且可持续的。
因此还是想得到答案(哈哈哈):3、在楼主已有的执行记录来看,checkList 的验证性和遗漏点的比例是多少,有效性如何?
另外还有一个疑问:checkList 的推广对团队成员的要求是啥,或者说 checkList 的推广是否存在局限性

checkList 的推广对团队成员的要求是啥,或者说 checkList 的推广是否存在局限性?--要求:规范的模版和成员的认可/应该也有局限性吧。
答:(1)checkList 的推广对团队成员的要求是啥?我个人的理解哈。首先,要推广 checklist 这个环节,势必会增加一定的工作量,如何让大家能接受这个事情,就要告诉大家 checklist 在工作中,为大家带来的好处、便捷,让成员了解对 checklist 的付出,是有积极的回报的(例如便于梳理逻辑,梳理思路,大功能点拆分小功能点),让大家享受到 checklist 带来的红利。其次,就是一个规范的模板,设计一个通用的模板,填写的内容不冗余还可以清晰表达 check point,让测试工程师只需要填写内容,而不需要太关注形式(因为模板就是规定好了形式,让大家填写即可)
(2)checkList 的推广是否存在局限性?我个人的理解哈,可能是有局限性的。 例如楼主提到的 3 星期一次迭代,一次功能迭代,测试工程师要做的事情大致有:需求学习与分析 -- 测试环境准备 -- 编写测试用例(checklist&review)-- 测试执行 -- 测试 bug 管理 -- 回归测试 -- 测试 report--产品发布。 如果 3 星期不能完成这些环节的话,checklist 可能就是一个鸡肋的环节了,因为来不及做这么规范的一个测试环节。再有一个我能想到的就是,产品!如果说产品很单一,很简单,迭代的功能大多数很相似,例如 Page One 有个 button, 迭代 Page Two 加个 button,这种的话就可以仿照之前的测试用例修修改改直接拿来使用了, 就没必要搞 checklist 环节了。

Duke 回复

感谢回复~
我再次返回头来理解,checkList 为梳理测试点, 测试用例是具体执行步骤。
我尝试在新的迭代版本中使用一下这个模式

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