● 生成器准备
■ 很复杂的数据需要使用代码来生成，这样可以很快的产生大量测试数据。
■ 比如说为了测试解码器，需要一个产生各种编码的编码器
■ 尽量多用现成的，少开发新的吧：你怎么确保这个生成器是没有bug的呢？
● 延迟准备
■ 一个测试用例可能在中途步骤就因为产品的bug验证失败，如果有些准备工作是后边步骤才需要的，那就没有必要一开始就做。
■ 这是解决测试执行性能问题的一个小技巧。
● 洋葱头准备
■ 原文叫做decorator，跟设计模式里面的decorator一个意思。准备工作也是存在继承关系的，某一组测试用例A要用到准备工作a，B则用到b，如果b包含了a，那么b直接调用a好了。
■ 举个例子，测试用例A用到数据库但不关心里面的数据，B则要求里面至少有某一条记录，那么B的准备工作就是一个洋葱，最里面是创建数据库，外层则是插入需要的记录，甚至C需要在具备这个记录的同时数据库还有一个备份，那就再包一层好了。
● 分组准备
■ 依赖同一种准备工作的测试用例都放在一个分组里面。
■ 这就是最终的解决方案，同类的放在一起处理就不会因为切换而花时间，调试的时候也容易分离症状。
所以就前面提到的例子来说，解决方案就是：
● 准备一个最基本的数据库，导出成为文件（最小准备，永久准备）
● 根据准备工作的不同对测试用例分类（分组准备）
● 提取可以共享的准备工作实现相应的代码，如果发现有继承关系可以用继承的方式组织这些类（共享准备，洋葱头准备）
● 确保导入数据库文件的代码是洋葱头的最里面，除非某些测试用例需要延迟导入（延迟准备）
有准备就有清理，下次我们谈谈清理环境
