淘宝测试团队的知识沉淀发展到今天，经历了无数风风雨雨，到现在各个产品线的沉淀方式，仍然没有完全统一，处于群雄割据的局面。现在，该是做一个了断的时候了。

　　我们先简单看看淘测试的知识沉淀的发展历史。在混沌初开的年代，大家基本都是用MS Word来编写沉淀文档，然后放在一个共享目录下面。后来wiki概念兴起，产生了很多这一类型的web应用程序，MS share point（SP）是被普遍使用的。淘测试因此把沉淀文档都转移到了SP上，也就是大家现在熟知的“测试人员站点”。

　　SP是非常好的wiki工具，不过有一点被大家诟病，就是SP无法用树形目录结构对文档进行分类。还有一点，当时淘测试有一个规定：每做一个日常（每周每产品线约有20个左右）以后，都要写一篇沉淀文章。时间久了，文章数量猛增，并且由于分类较弱，大量文章难以查询，渐渐的SP被大家冷落了。

　　后来有的团队意识到了这个问题，开始对沉淀规则进行改进，不是一味的增加文章数量，而是把同一产品的文章汇总成一篇，并且用结构化的标题来管理文章逻辑。文档的保存工具也从SP转移到了Confluence（CF）上面。CF也是非常好的文档管理工具，并且能管理目录层次结构，不过目录的展开折叠不是很方便。直到最近，又出现了一个新的工具“淘宝百科”，在易用性方面有了很大提高，有的测试团队已经把沉淀文档搬到淘宝百科里，另外很多团队也跃跃欲试。

　　关于淘测试的知识库发展历史我们先回顾到这里。

　　现在各个团队沉淀的文档，基本都是业务沉淀为主，这里有一个主要原因：互联网产品的需求变化极快，而需求文档的维护并没有跟上，因此促成了测试团队来沉淀业务的局面。不过除了业务逻辑，测试的文档沉淀还有很多重要的内容，这和测试的工作方式和工作内容有关。

　　1、业务逻辑：测试团队沉淀的业务文档，是绝对的重点。和需求文档不同，它是先进行功能点分解，然后分别描述，特别对一些“规则”会做集中描述；

　　2、测试逻辑：这是测试工作的核心，主要包括测试某个功能点前，需要做哪些准备工作，测试的逻辑顺序，先做什么后做什么，哪些业务是重点要关注的，等等；

　　3、测试用例：测试用例和测试逻辑的关系非常密切，测试逻辑是“方法”，测试用例就是具体的案例，一般体现为输入数据和校验点；

　　4、经典bug：每个模块都会出现很多bug，其中有一小部分的bug，特别有教育意义，值得我们收藏。新人通过学习以前的bug，也可以快速掌握住系统的要点；

　　5、开发运用的相关技术：比如淘宝主站开发常用的技术有JS、AJAX、JAVA、WEBX、MYSQL、TAIR等等，每个模块牵涉到的技术，都会不太一样，有的侧重前端，有的侧重后端。在学习业务的同时，也需要了解有关技术；

　　6、测试工具：在测试某个模块的时候，往往需要借助于一些测试工具，并且针对不同类型的模块，工具的用法也有区别

　　上面说了测试知识沉淀的六个类型，如果还有遗漏，没关系，后面我们可以用一种非常简单的方法来添加完善。

　　走访了几个测试团队，我们发现，大家对于第一类“业务逻辑”的沉淀做得非常好，不过，业务逻辑沉淀的文档，往往都单独保存在一个wiki工具里，并没有和测试用例放在一起，并且，沉淀文档的目录结构，和测试用例的结构几乎一模一样。换句话说，测试团队在两个工具里，维护了两套完全相同的树形目录结构。

　　现在很多测试用例管理工具并没有集成wiki的功能，于是测试团队不得不另辟蹊径，这样造成了一些资源的浪费，不过更重要的是，沉淀文档和用例没有产生关联，大大影响了阅读效率。在通常的工作场景下，测试人员阅读用例的同时，也希望能看到这个功能点对应的沉淀文档，反之亦然。除此以外，上面所说的那6个类型的文档，如果也能以业务逻辑为索引，互相交叉引用，那沉淀的读者将会得到最多的有用信息。