软件测试心得
以下是我在网上看到的一篇文章，读了后发现对我自己的工作有很大的启发，给大家分享技术类思考
软件工程的任何一个部分——从需求分析、架构设计到最后的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，如果没什么重要事情，到点就走人——不然你的组员会碍于面子而陪着你。你有没有想过他还有可能要陪父母、妻子和儿女呢?如果你经常这么干，建议你看一看《二十美元的故事》这则小寓言。
要做权威，不要做学霸。我想说的是：下属进谏的速度和广度决定于你的心胸与宽容度。正因为大多数初级管理人员心胸狭窄、宽容度低，才导致了团队习惯性的“绝对上下一致”。据我所知，印度程序不是这样的风格，属下和领导、新手和权威可以心平气和地讨论分歧而不必面红耳赤。我的建议是：在团队中，不要等级观念，要平等;不要讽刺刻薄，要尊重;不要放不下架子，要宽容;不要目中无人，要谦虚。总之一句话：大家都是普通人，谁能跟谁差哪儿去呢? :) 不错 谢谢分享 不错 up! 我们每个人都是白痴，在某一方面，不要不懂装懂，这是不对的。 好。。。。。。。 “作为Lead，如果没什么重要事情，到点就走人——不然你的组员会碍于面子而陪着你。你有没有想过他还有可能要陪父母、妻子和儿女呢?如果你经常这么干，建议你看一看《二十美元的故事》这则小寓言。”
觉得这句话挺有意思的。
回复 8# 的帖子
那确实！不过现实中也确实是这样的，Lead没走大家都会觉得不太好意思走 说顶是水..那我就支持... 受用 支持
页:
[1]
