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

标签: 测试架构 | 发表时间:2011-05-03 19:54 | 作者:天彤 Ben
出处:http://qa.taobao.com

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

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

相关 [软件测试 知识库 管理] 推荐:

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

- Ben - Taobao QA Team
淘宝测试团队的知识沉淀发展到今天,经历了无数风风雨雨,到现在各个产品线的沉淀方式,仍然没有完全统一,处于群雄割据的局面. 我们先简单看看淘测试的知识沉淀的发展历史. 在混沌初开的年代,大家基本都是用MS Word来编写沉淀文档,然后放在一个共享目录下面. 后来wiki概念兴起,产生了很多这一类型的web应用程序,MS share point(SP)是被普遍使用的.

五款最佳个人知识库管理工具

- Yolanda - FeedzShare
来自: 帕兰映像 - FeedzShare  . 发布时间:2011年06月07日,  已有 2 人推荐. web2.0给我们带来了大量的信息,但并非每个人都能够很好的整理并消化吸收这些信息. 构建个人知识库,能够让我们更好的应对网络上的各类资讯. 本文Gevin向大家推荐5款个人知识库管理工具,这5款工具各有特色,也是目前Gevin用过的最好用的工具.

软件测试的原则

- - CSDN博客推荐文章
 在软件测试中有很多重要的指导原则,这些原则看上去大多是显而易见的,但是总是被我们忽略,作为虫师,我们当然应该把这些原则牢记于心,作为专业测试人员的基本素养. 原则1 测试用例中一个必需部分是对预期输出或结果的定义.  这条原则是软件测试中常犯错误之一,但是如果不按照这条原则进行,由于“所见即所想”这样的一个心里现象的存在,某个似是而非的错误结果可能会被当成是正确的结论.

文章: 软件测试转型之路

- - InfoQ cn
2010年12月31日,在网易从事了多年开发之后,依依不舍地离开,面临的是一个完全从零开始的全新职位:SQA,也就是tester. 保持某些系统的高可用性,是一些企业的重中之重,如何设计. 海量数据处理,海量视频分发,架构热点难点,尽在架构师峰会. ArchSummit全球架构师峰会报名启动. 当时对为什么被选择做软件质量保证,而不是继续在研发上进取,持有保留态度:凭什么要我转,不是别人.

软件测试中的心理学

- - 技术改变世界 创新驱动中国 - 《程序员》官网
软件测试是一项技术性工作,但同时也涉及经济学和人类心理学的一些重要因素. 在理想情况下,我们会测试程序的所有可能执行情况,而在大多数情况下,这几乎是不可能的. 即使一个看起来非常简单的程序,其可能的输入与输出组合可达到数百种甚至数千种,对所有的可能情况都设计测试用例是不切合实际的. 对一个复杂的应用程序进行完全的测试,将耗费大量的时间和人力资源,这样在经济上是不可行的.

软件测试用例编写建议

- - CSDN博客推荐文章
软件测试人员(SQA/SQC),做的最频繁并且最主要的活动之一就是编写软件测试用例了. 首先,请记住以下所有的讨论都是关于编写软件测试用例,而不是设计/定义/确认测试用例(TC).   这项主要活动有几个重要的关键因素,让我们先来大概了解一下吧.   A、软件测试用例要易于定期修改和更新.   我们生活在一个不断变化的世界,软件也不能免于变化.

8月AV-Comparatives杀毒软件测试结果出炉

- 建军 - cnBeta.COM
AV-Comparatives是来自奥地利的杀毒软件评测机构,在国际上享有盛名,是公认信得过的独立测试机构. 每月AVC都会更新动态测试结果,日前,8月份动态测试结果也出炉了. AVC的动态测试是测试恶意网站及其威胁拦截测试,所有杀软采用默认设置,并且当杀软弹出提示时采取的选择也是杀软默认给出的.

Web软件测试中数据输入的检查清单

- - InfoQ cn
检查清单(Checklist)可以帮测试人员节省时间,因为很多有效的方法并不需要每个测试人员重新发现,前人已经有了充分的总结,并做了大量的有效性验证,其次,检查清单可以帮助测试人员避免遗漏,人的记忆是有局限的,难免会有遗漏的地方,通过检查清单检查可以有效的防止遗漏. 最近,IBM工程师苏京刚 总结了Web软件测试中数据输入的检查清单,对Web测试人员提供了很好的参考.

如何开发高质量软件?及软件测试观点

- - 我的宝贝孙秀楠 ﹣C++, Lua, 大连,程序员
也许是因为我经常在twitter上鼓吹“代码质量来自code review和单元测试”,老赵的这篇文字 http://blog.zhaojie.me/2012/01/a-case-requirement-to-practice-unit-testing-or-tdd.html 也at我一下,抱歉的是最近欠债太多,正在着手完成答应侯伯薇的那篇关于appengine的文字.

Google软件测试之道之读书笔记

- - ITeye博客
以下是看完Google软件测试知道之后书中摘录以及整理的笔记.主要摘录自己认同的,有启发性,指导性的内容.并且适当对书中的内容做了一些整理,欲看全部内容请购买原版图书. 第一章:Google软件测试介绍. 1.Google的测试团队并非雄兵百万,我们更像是小而精的特种部队,我们依靠的是出色的战术和高级武器.