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

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

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