飞测说：最近很多朋友问如果没有需求文档，我该怎么测试？我自然想起了探索测试，今天来说说自己在探索测试路上的一点点感悟-------快递测试法，让我们在探索中感悟，在摸索中前进……

快递测试法，是从ET学习中了解到的一种测试方法，顾名思义就是数据类似于那些通过联邦快递系统，在这个星球上被不断移动的包裹一样，在软件中也是不断的流动。数据从被输入后就开始了它的生命周期，先被存储在内部变量和数据结构中，然后再计算中被频繁操作、修改和使用，最后，这个数据作为输出被“递送”给用户或目的地。

在这个测试法中，测试人员必须关注于数据。应该确认那些被存储起来的输入数据并“跟随”它们走遍软件。例如，在购物网站输入一个地址后，它会显示在哪里？哪些特性会用到该地址？如果它被用于账单地址，要确保该特性被测试到了。如果它被用作发货地址，也要确保测试中使用了相应的特性。如果允许更新地址，那就应该修改它的值。该地址是否会被打印出来，是否在内部数据中被删除过，或者需要进一步处理？试着找到每个和数据有接触的软件特性，就像联邦快递处理他们的包裹一样，测试人员也应该参与数据声明周期的每个阶段。

这虽然是一种测试方法，我们的测试不会仅局限与这一种方法，但是我自己感觉在实际中，我们很多时候借助于这种思想，我们的测试会更简单，拿 SCM工具（主要是从需求提交，到开发、测试环境的自动部署、版本管理、发布，客户更新等一些列流程半自动完成的工具，可以理解为持续交付工具）来说说我是怎么做的，我们了解该工具的整体业务如下：
1、输入初始话的数据
2、点击“开始初始化”会先做一些校验，如果不通过，则会弹出提示（我们可以记录下有那些校验，这样方便后面针对每一种校验来验证）
3、校验通过后，会首先到数据库的Task表中插入一条记录（我们可以了解生成记录的规则，然后细化成测试点）
4、记录插入成功后，分发服务会将该记录作为任务分发给Web服务、测试DB服务、开发DB服务 和TFS服务，并且在日志中记录分发的情况（我们可以考虑分发成功，或不成功的情况，是否做日志检查也可以考虑）
5、然后各个服务接到任务后，先在日志中做一个接受成功的记录，然后根据要求开始初始化（我们可以罗列出各个服务初始化的一个清单，作为检查点，比如TFS端先到给定的路径去获取源代码，然后解压后TFS中创建项目和分支，然后给项目赋予权限，添加人员，最后做相关设置，完成后在日志中有记录，并返回一个状态到数据库中）
6、各服务初始化完成后，会返回一个状态到数据库中，并更新数据库记录（我们可以考了是否能成功返回，返回更改那个字段）

7、web界面上可以查看到结果，当然中途初始化中也是可以查看结果的；

按照上面的快递思想，我们能很快获取大部分重要的测试点，也可以分析出一些设计的遗漏或者不合理的地方，并将这些分析的测试点记录下来 ，做成checklist或者写成脑图，都是不错的选择，虽然说ET没有强调测试用例，但是我们能够结合ET的思想，有一份测试cheklist的指引，将是不错的选择，这让我以前一直想根据开发实现的流程图来设计用例，应该是一个道理，我想这种测试应该就是所谓的灰盒测试吧；

好了，本次到此，更多分享下期再会，给你带来更多价值，是我们期待的方向，有更多兴趣的欢迎切磋，加入我们微信订阅号，联系方式如下：