干测试也有一年多了，偶尔也会静下心来思考一些问题，但很多思考的结果都似灵光一现——过后就忘掉了，实在可惜，以后就记在这里吧。

　　技术类思考

　　软件工程的任何一个部分——从需求分析、架构设计到最后的Debug——都能引入Bug，有时候是单个引入，而有时候则是一窝一窝地引入。所以，优秀的测试员理应掌握丰富的软件工程知识。很难想象一个不懂材料力学和结构力学的工程师能够验收刚刚建好的大厦。

　　测试员不但需要学习编程，而且需要学习各种编程。初级测试员可以站在用户的角度上去观测和使用软件，以期找出Bug所在，但高级程序员更需要借助程序的原理来剖析更深刻的东西。毫不夸张地说：如果想深度测试Web程序，你应该学学Hacker;如果想研究.NET的程序，你应该学会MSIL;如果想深度Debug原生代码，你应该学习汇编、了解PE文件格式;如果想深度测试软件的安全性，你应该学学破解;如果……总之，理想的测试员应该比程序员更深一个层次。

　　保持对软件的喜欢和热情。小到FlashGet大到3DS Max，如果有机会都要上手玩一玩。这样做好处多多，一来可以丰富你的软件使用经验、无形中建立你对软件逻辑的把握;二来丰富你的行业软件知识，比如你让一个长期测Outlook的人去测Photoshop，那测试出来的结果肯定和一个长期使用Photoshop作图的人测出来的结果相去甚远。

　　深入理解操作系统，包括Windows系列(包括.NET平台也可以理解为是操作系统的一部分)，Linux系列(JDK算是操作系统的一部分)，Macintoch系列。一来，软件其实就是扎根在操作系统上的树木和花花草草(通过系统开放给程序员的API与系统血脉相连);二来，很多软件是跨平台的，要求你有丰富的多平台操作经验才能玩转，比如Adobe公司的很多优秀产品就是跨Windows和Mac平台的，这两个平台的API完全不同，为什么软件“看上去”却一模一样呢?再比如IBM公司的很多产品是跨Windows和Linux平台的等等。

　　行为类思考

　　软件测试不是万能的，所以测试员也不是万能的。测试员不是救世主。这至少说明两个问题：一，一个设计很烂、编码很烂的软件，你再怎么测试它也成不了优秀的软件。二，测试员(或者说软件质量保证人员)没有权利在团队里趾高气扬、四处挥动粘满Bug的大棒以图通过测试结果证明自己的英明神武——大家都是平等的。平等的观念在中国人的思想中尤其缺乏，特别要注意。

　　测试员应该是一个冥想者。所以，测试团队应该有一间独立的，安静的，没有计算机的屋子，以供进行深度而缜密的思考。

　　管理类思考

　　不要不懂装懂。你不懂不会，不足以让组员瞧不起你;你不懂装懂，所有组员都会瞧不起你。管理就是管理，是把项目做好，不是让你练擒拿格斗，一定要制服组员。勇于上问、不耻下问，快速学习，这才是团队学习之道。

　　作为Lead，如果没什么重要事情，到点就走人——不然你的组员会碍于面子而陪着你。你有没有想过他还有可能要陪父母、妻子和儿女呢?如果你经常这么干，建议你看一看《二十美元的故事》这则小寓言。

　　要做权威，不要做学霸。我想说的是：下属进谏的速度和广度决定于你的心胸与宽容度。正因为大多数初级管理人员心胸狭窄、宽容度低，才导致了团队习惯性的“绝对上下一致”。据我所知，印度程序不是这样的风格，属下和领导、新手和权威可以心平气和地讨论分歧而不必面红耳赤。我的建议是：在团队中，不要等级观念，要平等;不要讽刺刻薄，要尊重；不要放不下架子，要宽容；不要目中无人，要谦虚。总之一句话：大家都是普通人，谁能跟谁差哪儿去呢?

下一篇：2007年全国软考图书购买指南

　　目前，市场上关于软考的图书很多，但绝大部分均系假冒伪劣书籍，请考生谨慎选择。

　　1.在选购书籍时，凡是没有具体作者姓名的，均系抄袭和拼凑的图书。例如，一些出版社出版的图书的作者是“软考研究院”、“软考研究中心”、“软考命题研究组”、“软考命题研究中心”等。这些都是假冒的，根本就不存在这些组织。这些图书的质量低劣，根本就不想负责任，连作者姓名都没有!

　　2.某些出版社拿历年试卷做全真模拟试题，这些组稿者根本就不了解软考，没有读过考试大纲。例如，某出版社的软件设计师全真试题中竟然...[查看详情]