软件测试知识库管理方案——大结局

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

我们先简单看看淘测试的知识沉淀的发展历史。在混沌初开的年代,大家基本都是用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进行评审,大家有想法就直接找我聊。我想知识沉淀应该是很多人心中的痛,现在机会来了,大家一起努力构建一个科学的测试文档知识库吧。

你可能感兴趣的:(测试架构)