软件测试知识库管理方案 淘宝测试团队的知识沉淀发展到今天，经历了无数风风雨雨，到现在各个产品线的沉淀方式，仍然没有完全统一，处于群雄割据的局面。现在，该是做一个了断的时候了。 我们先简单看看淘测试的知识沉淀的发展历史。在混沌初开的年代，大家基本都是用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. ...
