现在我们有了自己的测试管理平台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进行评审，大家有想法直接找我聊。我想知识沉淀应该是很多人心中的痛，现在机会来了，大家一起努力构建一个科学的测试文档知识库吧。