如何建立测试部门的知识库体系

领测软件测试网对于一个部门来说，如何积累项目经验，如何提高成员的知识水平是非常重要的，每个企业都有自己的企业文化，每个部门应该也要有自己的氛围，这里讨论下如何建立
测试知识库体系
架构。下面是我的构思：

采用BBS进行建立知识体系，也可以采用WIKI，重要的两点就是能够发布信息，并可以让大家进行参与，发表评论。

1、测试概念，基础知识

可以参照书籍目录，进行测试专业词语解释，比如
软件测试生命周期，
白盒测试，
黑盒测试概念等

2、项目
测试总结（这点非常重要）

主要是对公司项目，产品的测试总结，包括文档整理，各个模块测试报告，BUG分析等。以及在项目测试得到的一些经验总结，个人对项目的测试心得。方便新员工快速了解项目，以及一些教训。

3、个人心得经验（这点非常重要）

—可以是对测试方面产生的心得体会，比如说总结出编写
测试用例的经验等

—也可以是
学习其他知识方面的体会，比如学习
数据库，VC等

4、测试部门意见提交

—每个测试部的人员，都可以对现有的测试体系结构进行提出自己的意见，比如提出要实行
自动化，引入好的工具。都可以，然后大家可以进行开会讨论是否可以接受提出的意见，只有集中大家的智慧才能有好的团队。

5、例会与
培训

—部门例会可以根据具体情况进行，比如一个星期，半个月开一次。培训，可以叫其他部门的同事进行培训，比如
开发部，工程部等，也可以是测试内部进行，比如规定部门每个人业余学习一门新
技术或工具（并不强调熟练，精通），然后一个月后对部门其他同事进行培训，这样做主要是为了知识面的拓宽。时间也可以自己规定，半个月，一个月等。

6、
网络好文收集

—-收集网络的一些精彩文章

7、测试部门规范建设

—-部门流程规范文档，各种测试文档编写模板，包括
用例模板，计划模板，测试报告模板等

—-测试部门的新人培训计划文档

—-测试部门常用工具的使用说明文档，比如
VSS,
SVN，
bug缺陷管理JIRA使用等

—-还有一些其他方面，只要是大家统一认为是规范性的东西都放在这里

8、测试书籍

—每一个月测试部门出钱购买相关书籍，或者申请公司购买书籍

—每个员工看完书籍后必须写一份看书报告，心得

关于和绩效挂钩在一起重要是为了提高部门员工的积极性，当然也可以是进行奖励，不和绩效挂钩：

这个分数比较难规定：

1、测试概念，基础知识整理—1篇1分

2、项目经验总结—–每个人必须书写，组长书写的必须是整体的。如果一个项目完成后，没有进行经验总结，那么相关人员就进行扣分

3、个人心得体会—每篇需测试部人员进行打分，最后得出一个分值

其他部分也是一样，培训这块是重分区；

具体怎么进行并入到绩效中考核还没有想好，希望大家多多提出想法。

阳光

我觉得你写的东东，是一个大的框架，如果更好的做还需要再去考虑一下，并且觉得做的很小家子气，应该做的更宏观一点。另外有些归类也不是很清晰，例如：例会跟培训为什么归到一类呢，另外下面是我给你的两个小的建议：

1）测试概念和基础知识部分，我觉得应该做的更大一点，不能只包括测试方面的，还应该包括其他技术方面的，比如操作系统，网络协议、数据库等等，可以叫做技术专栏；

2）项目总结部分，建议用
TD，或者其他
测试管理工具进行管理，这样更专业化，并且管理起来更方便。

关于考核部分，我觉得除了这些条条框框的东西以外，还要增加人文的管理，更人性化的实施才是重要的，并且在实施的过程中你要写你的监控流程，和维护流程。

dulong
跟绩效挂钩容易引发太多的事务，项目顺利还好说，不顺的时候扯皮，推脱责任等等都会发生，而且还容易形成个人主义，一言堂这样的情形发生，不利于团队的合作及发展。

个人认为，公司要有一套对员工的评价是正确的，这样对个人的升迁、加薪都有个标准，方法上能否多考虑下多方面的因素，例如各自公司的目前规模，项目规模，部门职能重要程度等等。

具体的标准就是不能太限制搞技术的员工，毕竟我们都是脑力劳动者，每天都想着绩效绩效，担心被这扣被那扣，那还有时间跟精力去创造更美好的事务。

把‘温饱思淫欲’这句有点不得体的话放在这吧，要让马儿跑的欢就要先让马儿吃草。

当然，以上因人而异。