从outline到checkpoint，再到case

假如没有详细的需求文档

假如需求文档内容粗糙

假如需求文档从未来过这个世界

总之，需求是现实的，那就是我们要测试，公司产品要发布。而实际工作中，需求文档却五花八门的，只有想不到。

当我们无法根据需求来编写测试用例，该怎么办呢？我们先来梳理一下测试任务的来源，测试任务90%是来自开发，因为我们是软件开发的下一环节。让我们来看看开发老哥提测了什么，如下短短一封邮件，寥寥几行记录了developer的更新内容。

看一眼，哇，这个版本改动的不多，好测 (๑*◡*๑)

第二眼，啊，影响的都是主要业务功能，重要 (ΘΘ)

再看，啥？今天就发布 o(╥﹏╥)o

没产品需求、没测试计划、没可用的测试用例，并且还要快速完成测试发布，说实话，即便有详细需求，此刻再看怕是也来不及了。这个时候最好的办法无疑是和开发去沟通，依据业务的实际使用场景和自己的经验开展测试工作。那么，测试用例呢，可以不写了吗，这样的项目发布，没有问题还好，一旦在用户那里出现重大bug，追究起来，测试都讲不清自己测了什么，哪些没测。所以，此刻要快速的整理出测试用例。

还是回归到任务的来源上，我们逐一分析提测内容，每一项更新内容都是一个outline，我们将它的格式做个简单变更

业务	Outline	类型
登录	用户登录支持微信登录	新增功能
浏览	修复bug，商品为空时不能浏览商品列表	Bug修复
购买	优化购买流程	优化

先看第一条，影响的是登录业务，这是一个新增的功能，支持微信登录，这个功能很容易理解，我们要测试哪些项呢，除了微信账号登录，原有的登录方式显然也得测试，登录成功后就会衍射到修改密码，也有必要覆盖到，以及不同登录方式之间的切换。下面我们把这些罗列为checkpoint

Name	checkpoint
微信账号登录	测试：  - 微信账号正常登录  - 微信账号异常登录
用户账号登录	测试：  - 已注册账号登录  - 新注册账号登录  - 未注册账号登录  - 异常登录
修改密码	测试：  - 微信账号修改密码  - 用户账号修改密码
登录方式切换	测试：  - 退出登录  - 切换微信账号、用户账号登录

第二条outline，影响的是商品浏览功能，这是一个bug修复，第一步就要验证bug是否正确修复，并衍射其他类型的商品浏览，我们也列出checkpoint

Name	checkpoint
商品为空时，浏览商品列表	测试：  - 原有商品类型下，商品为空，浏览商品列表  - 新建商品类型，商品为空，浏览商品列表  - 商品不为空时，删除所有商品，浏览商品列表
浏览商品不为空时，浏览商品类别	测试：  - 商品不为空时，浏览商品列表  - 点击商品，进入商品详情页面  - 返回
改变商品	测试：  - 添加商品  - 删除商品  - 修改商品

接下来我们看第三条outline，优化购买流程，有过网上购物经验的童鞋都知道，购买的入口往往有多个，用户登录、未登录都可以发起购买操作，商品列表页、商品详情页也都可以发起购买操作，等等，越大的网站支持的功能越多，并且有购买，就会涉及到订单的一系列操作。我们也将checkpoint列出来

Name	checkpoint
用户未登录，购买商品	测试：  - 用户未登录，商品列表页，添加商品至购物车，结算  - 用户未登录，商品详情页，添加商品至购物车，结算
用户已登录，购买商品	测试：  - 用户已登录，商品列表页，添加商品至购物车，结算  - 用户已登录，商品详情页，添加商品至购物车，结算
取消订单	测试：  - 订单未支付，取消订单  - 订单已支付，取消订单
查看订单	测试： - 订单未支付，查看订单 - 订单已支付，查看订单
删除订单	- 订单未完成，删除订单（是否可以删除） - 订单已完成，删除订单
修改订单	测试：  - 修改订单信息

至此，我们要将checkpoint要发给开发进行确认，确认是否覆盖全面，有无遗漏。

到了此步骤，有项目经验的人根据checkpoint基本可以开始测试了。追查起来也算是有根有据了，至少测了什么我们自己讲的清楚，developer也清楚。

项目研发的过程中，测试是被动的，研发提测之后测试才算真正的介入，虽然现在提倡测试从立项、定需求就开始参与，并且大部分公司也是这样做的，但在阿狸看来，这些只能算前期参与，了解项目，制定测试规划，当然越早参与越好。而当用户使用过程中出现bug的时候，问题是先回到测试的，测试要去复现、验证，并将详细操作过程反馈给developer，当然也有个别的不经测试。这一过程可能也会有其他部门人员参与，质控、运营或是技术支持等，每家公司的情况都不同。假如测试完成后，质控人员要参与质量检查，或是出现问题后，前线人员要先操作一遍，他们很可能会参考我们的case，当我们只提供一份checkpoint，想想他们会怎么说？这写的是什么呀，连个步骤也没有，我们怎么知道结果对不对，这么操作有什么条件吗，有账号吗......

一份完美的测试用例，不仅能方便非测试人员，也能方便其他测试人员，所以测试人员在条件允许的情况下，要将checkpoint完善为case，即测试用例。测试用例就是写出来操作步骤、前提条件、预期结果、输入数据等，我们将微信登录相关的checkpoint补充为完整的case

执行结果，是由执行人员操作后进行标记的，现在有很多好用的测试管理系统或项目管理系统，可直接在系统中标记执行结果。