采用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
跟绩效挂钩容易引发太多的事务，项目顺利还好说，不顺的时候扯皮，推脱责任等等都会发生，而且还容易形成个人主义，一言堂这样的情形发生，不利于团队的合作及发展。
个人认为，公司要有一套对员工的评价是正确的，这样对个人的升迁、加薪都有个标准，方法上能否多考虑下多方面的因素，例如各自公司的目前规模，项目规模，部门职能重要程度等等。
具体的标准就是不能太限制搞技术的员工，毕竟我们都是脑力劳动者，每天都想着绩效绩效，担心被这扣被那扣，那还有时间跟精力去创造更美好的事务。
把‘温饱思淫欲’这句有点不得体的话放在这吧，要让马儿跑的欢就要先让马儿吃草。
当然，以上因人而异。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
