快递测试法，是从ET学习中了解到的一种测试方法，顾名思义就是数据类似于那些通过联邦快递系统在这个星球上被不断移动的包裹一样，在软件中也不断的流动。数据从被输入后就开始了它的生命周期，先被存储在内部变量和数据结构中，然后再计算中被频繁操作、修改和使用。最后，这个数据作为输出被“递送”给用户或目的地。
在这个测试法中，测试人员必须关注于数据。应该确认那些被存储起来的输入数据并“跟随”它们走遍软件。例如，在购物网站输入一个地址后，它会显示在哪里？哪些特性会用到该地址？如果它被用于账单地址，要确保该特性被测试到了。如果它被用作发货地址，也要确保测试中使用了相应的特性。如果允许更新地址，那就应该修改它的值。该地址是否会被打印出来，是否在内部数据中被删除过，或者需要进一步处理？试着找到每个和数据有接触的软件特性，就像联邦快递处理他们的包裹一样，测试人员也应该参与数据声明周期的每个阶段。
这虽然是一种测试方法，我们的测试不会仅局限与这一种方法，但是我自己感觉在实际中，我们很多时候借助于这种思想，我们的测试会更简单，拿 SCM工具来说说我是怎么做的，我们了解该工具的整体业务如下：
1、输入初始话的数据
2、点击“开始初始化”会先做一些校验，如果不通过，则会弹出提示（我们可以记录下有那些校验，这样方便后面针对每一种校验来验证）
3、校验通过后，会首先到数据库的Task表中插入一条记录（我们可以了解生成记录的规则，然后细化成测试点）
4、记录插入成功后，分发服务会将该记录作为任务分发给Web服务、测试DB服务、开发DB服务 和TFS服务，并且在日志中记录分发的情况（我们可以考虑分发成功，或不成功的情况，是否做日志检查也可以考虑）
5、然后各个服务接到任务后，先在日志中做一个接受成功的记录，然后根据要求开始初始化（我们可以罗列出各个服务初始化的一个清单，作为检查点，比如TFS端先到给定的路径去获取源代码，然后解压后TFS中创建项目和分支，然后给项目赋予权限，添加人员，最后做相关设置，完成后在日志中有记录，并返回一个状态到数据库中）
6、各服务初始化完成后，会返回一个状态到数据库中，并更新数据库记录（我们可以考了是否能成功返回，返回更改那个字段）
7、web界面上可以查看到结果，当然中途初始化中也是可以查看结果的；
按照上面的快递思想，我们能很快获取大部分重要的测试点，也可以分析出一些设计的遗漏或者不合理的地方，并将这些分析的测试点记录下来 ，做成checklist或者写成脑图，都是不错的选择，虽然说ET没有强调测试用例，但是我们能够结合ET的思想，有一份测试cheklist的指引，将是不错的选择，这让我以前一直想根据开发实现的流程图来设计用例，应该是一个道理，我想这种测试应该就是所谓的灰盒测试吧；