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

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

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

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

感觉是一个很好的规范用例，查漏验证点的工具。但具体实施起来有几点疑问：
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 天时间。

来看看

感谢讨论~
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 环节了。

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