checklist 编写指南

checklist 编写工具

checklist文档格式推荐使用思维导图。比如 MindMaster 和 processon。我喜欢用这些平台或者软件的思维导图大纲模式来编写 checklist。

checklist 需要包含的内容

checklist 最重要的当然是测试用例，除此之外，附上相关依赖文件和测试数据，包括：prd，技术文档，测试账号，测试数据，测试平台，测试环境，图例（用红色背景标记出 P0 的冒烟 case，蓝绿色标记 checklist 评审时新增的 case ，疑问用黄色背景标注，深蓝色标记checklist 评审后决定删除的 case ）等等。

完备的测试用例设计

1.直观的边界值设计。这种一般是参数的取值存在范围，边界值是最可能出现问题的地方；

2.每种情况或者场景的枚举。比如某个参数包含几种枚举值，在数量不多的情况下对每种枚举进行测试验证；再比如某个网站有多个页面和组件，需要对每个页面或者组件进行验证；

3.操作直接结果的验证。比如一个审核操作，最直接的结果就是会把审核结果落库，所以需要验证数据库是否新增一条审核结果或者审核结果是否更新；

4.由于操作的直接结果产生的影响验证。比如一个审核操作直接结果是产生一个审核结果，这个审核结果产生的影响可能有两个：一是是产品上架售卖，这时需要验证产品上架这个操作的直接结果（数据库商品状态变成可售或者下架）和直接结果产生的影响（站点能搜到这个商品）；二是给商品的提交者发送一条审核通过的邮件，这时需要验证各种邮箱后缀的邮件能否正常发送且收到的邮件格式不乱码，邮箱找不到情况下服务端不panic

注意：

多想想需不需要验证数据库或者查询日志关键字来验证链路节点的正确性，而不仅仅是关注黑盒入口数据和返回数据，这种是冒烟 case 的测试过程，但是对于正式测试来说这不够精细。

编写checklist 的一些好习惯

1. 附上文档依赖（PRD、技术文档和其他背景解释文档）

2. 附上测试账号、测试平台、测试环境、数据准备方式

3. 高亮标记疑问点、准入case

4. 测试过程中如果有记录测试数据，把测试数据文档也放到这个checklist中

注意：

附上这些文档依赖和测试数据可以方便自己来回反复找各个文档和数据，同时也能方便后续回顾这个需求的测试过程时能很清楚知道这个checklist 是属于哪个需求的，各种文档依赖有哪些，使用哪些测试账号测试的，测试结果是怎样的，让其他人看了有种一目了然的感觉，利人也利己。

一个 checklist 开头 demo：

 checklist 编写时间

如果上个需求测试过程中开发同学改 bug 的时间较多，导致我们需要断断续续地测试，那可以在闲暇时间熟悉下个需求并输出 checklist，如果上个需求开发同学改 bug 的时间较少，对我们来说主要是连续的测试，可以在上个需求的测试过程中暂停半天或者一天，输出 checklist，尽量在需求提测前写好 checklist，这样主要是为了不让写 checklist 的时间占用提测之后的测试时间。

相关文章：怎么确定自己的测试准备工作已经做好了？

欢迎关注公众号 TestDevelop , 我在这里分享各种测试开发技术知识、沟通技巧、职场感言。欢迎后续与我共同成长。