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

我们先简单看看淘测试的知识沉淀的发展历史。在混沌初开的年代，大家基本都是用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个类型的文档，如果也能以业务逻辑为索引，互相交叉引用，那沉淀的读者将会得到最多的有用信息。

现在我们有了自己的测试管理平台twork，那么把这些功能集成到一起，就不再是梦想。下面我描述一下理想的沉淀文档的管理方式和使用场景。

首先，当一个project刚开始的时候，测试团队会进行需求功能点分解，然后产生一个目录树，基本的原则是遵照“项目、模块、功能点”这样的层级来组织，目录树层级不宜太深。这棵“树”，就是以后测试组文档管理的主干，在主干的每个分支（也就是目录）上，我们可以添加各种类型的沉淀文档，这些文档都以独立的对象形式，保存在数据库里，并不是作为目录的description，它们有本质区别。在twork里，这些目录有一个全新的概念：“测试集”。

在测试集下，首先是可以管理“测试用例”，这个功能现在已经实现了，本文不再细说，重点说说另外几个类型。业务逻辑、测试逻辑、测试工具，开发用到的技术，这几个类型的沉淀文档，比较类似，都是比较独立的一篇一篇文章，一般每个测试集下，会有大约10篇左右的文档，当你选中某个测试集，就可以在一个列表页面看到这些文档。

经典bug是一个比较特殊文档类型。在每个project空间，都会有bug管理功能，每一个功能点下，都会出现很多bug，不过这些bug并不需要全部出现在对应的测试集下，而是要有选择。当测试人员觉得某一个bug具有代表性，有一定的借鉴意义，可以把这个bug上升为“经典bug”，然后写下一些bug的分析说明，其实就是给这个bug打一个标记，同时产生一个沉淀文档（不知不觉说到物理设计上了）。在测试集里需要用不同的展示方式来显示“经典bug”。

到此为止，各种文档仍然是按照“业务逻辑”的目录结构来组织的，这样能够满足一部分读者的需求，但是沉淀文档库的作用还没有被完全发掘出来，因为文档之间的关系，不仅仅是业务，还有很多其他的索引方式。比如说，很多测试工具和经典bug，都和前端JS有关，那么把这些文档放在一起阅读，就能得到更多的信息。因此，需要我们为沉淀文档库建立网状的关系结构，具体的设计可以参考微博的标签功能，比如当用户在标签里写下“音乐、篮球、动画”这些标签以后，那么系统就可以找到跟他拥有相同或者相似标签的人，然后推荐给他。

在测试沉淀文档中，主要有四类标签。一是文档所属的project，比如“购物车”、“收藏夹”这些都是project；第二类是开发技术，比如“JS”、“Oracle”、“Spring”；第三类是测试类型，比如“性能测试”、“安全测试”、“回归测试”；第四类是测试工具：“QTP”、“firebug”等等。其实除了这四类，大家可以随意定义标签类型，因为标签的填写是全开放式的，不像业务的分类那样，需要有比较严格的目录层级。不过需要注意的是，同一类标签的值需要统一，比如QTP和quick test pro其实是一回事。

下面举个例子，比如我在看一个bug的时候，发现这个bug很典型，需要沉淀下来，那么就先保存为经典bug；这个bug跟购物车和收藏夹这两个项目有关，就加上这两个标签，另外bug主要原因是前端JS的逻辑错误，那就再加一个JS标签，发现这个bug需要用到firebug的一个功能，那就再加一个firebug标签。好了，对这个bug的沉淀就做完了。下面我们看看这个bug会在哪些场景里出现。

假设刚才那个bug是出现在A测试集中的一个测试用例上，那么当读者选中A测试集时，会看到这个bug；如果读者想看看近期“购物车”出现的经典bug，她可以直接输入“购物车”，系统就会把这个bug搜出来；如果读者想学习JS相关技术，想知道淘宝出过哪些JS的bug时，也能看到这个bug；如果用户想学习使用firebug这个工具，想看看这个工具能发现哪些具体的bug，他也能看到。

不仅仅是经典bug，其他类型的沉淀文档，都有标签功能。标签可以让沉淀文档产生类似于神经网络的关联，当你阅读一篇文章的时候，系统可以根据这篇文档的标签，找出关联的文章，推荐给你，推荐的先后顺序，有一定的算法，比如说，访问最多的文章，排前面；作者和读者在同一产品线，那么文章排前面，等等，这些算法需要慢慢思考，完善，今天不再说了。标签功能可以说是知识库的核心，它能够摆脱传统的关系型数据库的关联关系，让信息完全活起来，方便读者找到需要的文章。

到这里我心目中理想的知识沉淀模式都说完了，其实这篇文章也是一份产品的PRD，一会我就发给twork组和各位leader进行评审，大家有想法就直接找我聊。我想知识沉淀应该是很多人心中的痛，现在机会来了，大家一起努力构建一个科学的测试文档知识库吧。