最近亲自在跟两个重要项目，感受很多，明天准备写其中一个项目的项目测试总结在组内分享，有一个还在背后默默关注。

在深圳工作1年了，每当组内的测试人员出现一些很常识的问题和面试过的测试人员回答的一些问题；非常明显的感觉到南北测试人员工作水平和对测试工作理
解的差异，在深圳想找到有共鸣的人好难啊。

今天写这个文章，只是把工作中的一些片段和场景与大家分享，希望测试新人在做测试工作中多一些执着、多一些思考和多问为什么？

故事1：搜索列表页的一个神奇bug

问题现象：一个已经测试通过并上线的商品搜索列表页，页面功能很简单、有搜索的筛选项、商品展示、商品翻页功能。通常大家在测试翻页功能时，基本测
试点都是测试上一页、下一页、具体页数、页数输入框（正常、异常）；有意思的是这个搜索列表结果有500多个商品1百页，我就一直点击下一页、一页一页的浏
览商品，当浏览到第24页时，发现浏览器访问报错提示连接不上；访问其它网站或该网站的其它功能就正常。

问题分析：此处的点击下一页的翻页程序代码，每翻一页，URL请求就会多加一串字符“swIFRPIDUwMH0gcHJpY2VfQ05ZOjUwMDxKaW1pPnByaWNlX0NOWTp7MCBUTyA1MDB9IHByaWNlX0NOWTo1MDA8SmltaT5wcmljZV9DTlk6ez
AgVE8gNTAwfSBwcmljZV9DTlk6NTAwPEppbWk+cHJpY2VfQ05ZOn”；这串字符出现6次以上后，url访问长度超过2k浏览器请求就会参数丢失，导致页面访
问报错

5个思考点：

思考1：为什么测试的时候没有发现呢？其中一个测试人员说，这个场景很少有人想到。

思考2：测试人员如何能测试出这种问题呢？我在想，聪明的办法那就是对设计实现熟悉了解，了解开发是如何实现的，应该可以想出来这个地方会有问题。另
一个办法就是增加这样的测试点，用自动化测试脚本来测试这种大数据量的功能极限测试。

思考3：对比其它网站，为什么别的网站没有这种问题呢？开发在设计上没有考虑这种情况？

思考4：为什么开发没有自测发现这个问题？我在想，开发没有考虑到URL会有问题

思考5：我们如何改进和提高呢？我在想，测试除了要补充测试用例；开发要整理出搜索结果列表页的一些设计规范，同时要参考和同行对比；开发要对系统的
实现逻辑加强极限测试。

最后我想，还好这个场景不常见，影响范围没有很大的杀伤力。

故事2：两个bug还是1个bug

现象：一个问题是：商品买满打XX折，从购物车进入到订单提交页中，商品总结算金额显示不正确；另一个问题是：商品买满减XX元，从购物车进入到订单提
交页中，商品总结算金额显示不正确。开发认为这是1个bug，因为都是商品总结算金额显示不正确；我认为是2个bug，因为是两个不同的测试用例场景得出的问
题，不能因为现象一样就认为是一个bug，同时怀疑代码里面的处理逻辑是不一样的。

分析：为什么这种问题在我过去工作8年的公司和开发团队，没有开发管理人员认为这类bug是1个，而认为是2个；而这位开发管理人员认为是1个；我在
想：原因是这位开发管理人员很害怕bug？还是这位开发管理人员很不喜欢看到很多的bug，因为今天我们测试两个页面，4小时报了35个bug让人心情很不爽？答
案不知道，只要解决就好。

5个思考点？

思考1：站在用户角度，如果是用户发现的，我们告诉用户是1个问题？用户能明白吗？

思考2：站在开发设计角度，需要知道那个地方的实现逻辑都是一个类或方法吗？即使是一个类或方法，当参数不一样时内部处理逻辑一样吗？找个时间问具体
写代码的开发人员问问就知道了？

思考3：下次碰到此类开发管理人员该如何相处？我在想：只要改了就行，不能和这类人去纠结1个还是2个，因为道不同不能理解；但是测试工作总结时要算成
2个。

思考4：为什么不能报成1个bug，因为当把多个bug放到1个bug里报时，如何有效跟踪？（比如：开发修改转测后，测试验证有一部分没有修改好，这个bug会
来回修复、打开）；如何有效做bug分析？（测试任务结束后，如何分类分析bug的错误类型及开发工作改进建议数据分析）。

思考5：为什么这么明显的bug开发没有自测出来？开发做自测了吗？这样的开发管理人员管理的开发团队，转测出现这样低级的bug，消耗了多少不必要的测试
成本（测试环境部署+bug报告跟踪和验证时间）和开发修复版本成本？降低了多少工作效率？这类bug有多少？

最后我想：我要通过什么方法来改变？

    生活还在继续、工作也在继续，世界之大、无奇不有，每天都有不同的见闻和收获，活着真好！

1944年冬，盟军完成了对德国的铁壁合围，法西斯第三帝国覆亡在即。整个德国笼罩在一片末日的气氛里，经济崩溃，物资奇缺，老百姓的生活陷入严重困境。

    对普通平民来说，食品短缺就已经是人命关天的事，更糟糕的是，由于德国地处欧洲中部，冬季非常寒冷，家里如果没有足够的燃料的话，根本无法捱过漫长的冬天。在这种情况下，各地政府只得允许让老百姓上山砍树。

    你能想像帝国崩溃前夕的德国人是如何砍树的吗？在生命受到威胁时，人们非但没有去哄抢，而是先由政府部门的林业人员在林海雪原里拉网式地搜索，找到老弱病残的劣质树木，做上记号，再告诫民众：如果砍伐没有做记号的树，将要受到处罚。在有些人看来，这样的规定简直就是个笑话：国家都快要灭亡了，谁来执行处罚？

    当时的德国，由于希特勒做垂死挣扎，几乎将所有的政府公务人员都抽调到前线去了，看不到警察，更见不到法官，整个国家简直就是处于无政府状态。但令人不可思议的是，直到第二次世界大战彻底结束，全德国竟然没有发生过一起居民违章砍伐无记号树木的事，每一个德国人都忠实地执行了这个没有任何强制约束力的规定。

    这是著名学者季羡林先生在回忆录《留德十年》里讲的一个故事。当时他在德国留学，亲眼目睹了这一幕，所以事隔五十多年，他仍对此事感叹不已，说，德国人"具备了无政府的条件却没有无政府的现象"。

    是一种什么样的力量使得德国人在如此极端糟糕的情况下，仍能表现出超出一般人想像的自律？答案只有两个字：认真。因为认真是一种习惯，它深入到一个人的骨髓中，融化到一个人的血液里。因了这两个字，德意志民族在经历了上个世纪初中叶两次毁灭性的世界大战之后，又奇迹般地迅速崛起。

    再讲一个关于德国人认真的小故事。

    熟悉柴油机制造业的人都知道有这样一个说法：中国制造的柴油机，噪音在数公里外都听得见，柴油机周围数十平方米都是油迹；而德国人生产的柴油机则可以放在办公室的地毯上工作，根本不会影响隔壁房间的人办公。

    于是，1984年，武汉柴油机厂聘请德国退休企业家格里希任厂长。
 
    格里希上任后开的第一个会议，市有关部门领导也列席参加了。没有任何客套，格里希便单刀直入，直奔主题："如果说质量是产品的生命，那么，清洁度就是气缸的质量及寿命的关键。"说着，他当着有关方面领导的面，在摆放在会议桌上的气缸里抓出一大把铁砂，脸色铁青地说："这个气缸是我在开会前到生产车间随机抽检的样品。请大家看看，我都从它里面抓出来了些什么？在我们德国，气缸杂质不能高于50毫克，而我所了解的数据是，贵厂生产的气缸平均杂质竟然在五千毫克左右。试想，能够随手抓得出一把铁砂的气缸，怎么可能杂质不超标？我认为这决不是工艺技术方面的问题，而是生产者和管理者的责任心问题，是工作极不认真的结果。"一番话，把坐在会议室里的有关管理人员说得坐立不安，尴尬之极。

    两年后，格里希因种种原因卸职时，武汉柴油机厂生产的气缸杂质已经下降到平均一百毫克左右。回国后，格里希有几次来中国，每次都要到武汉柴油机厂探望。在厂里，他有时拿着磁头检查捧发现气缸有未清除干净的铁粉时，忘了自己已经不是厂长，仍然生气地向周围陪同的人大声咆哮："你们怎么能这么不认真！"

    如果说强大的德意志是一个可怕的民族，那么，认真也是一种可怕的力量，它大能使一个国家强盛，小能使一个人无往而不利。我们实在该好好学习德国人认真得近乎刻板的精神，将认真贯彻到自己点点滴滴的行为中。一旦认真二字也深入到自己的骨髓，融化进自己的血液，你也会焕发出一种令所有的人，包括自己，都感到害怕的力量。

最近一直在讨论招人的事情，如何判断一个人的水平，怎么样才算是没有bug，等等等等。也看到一些并不怎么有趣的反对意见，比如：

不要出来搞笑说：

没有bug的程序？????????
靠，站着说话不腰疼。那个公司可以做出没有bug的软件来？
当然，没有写过程序的人不出bug!!
估计这位同志不会写代码，是个理论专家。
还是不要这么狂的好。
我估摸按你的标准，你是肯定不会被别人录用的！

123说：

你是编程的吗？
无“BUG”搞笑吧你
测试是不能查出所有BUG的
而且不是所有测试都能穷举的
只能是测试覆盖率达到一个标准
BUG出现的概率达到标准
才算产品
“ZERO-BUG”做梦去吧

说实话，这两个名字我看都不是用户名，而且很可能是同一个人，就是所谓的troller。我说的没有bug，是交给我的demo没有bug，这样的要求很高吗？我还没有出算法题，要求应聘者的算法效率呢？仅仅要求一个正确实现简单功能的程序，很过分吗？

在JavaEye还看到另外一篇帖子《大伙能进来讨论下“跳槽”的问题》，有一个小伙子，对自己的代码有感情，对人有感情，对公司有感情，所以当公司遇到困难的时候，一时间舍不得走。这样正常的事情，居然颇遭到不少人的冷嘲热讽，和各种“善意”的劝诫。

我就觉得非常奇怪，一个程序员，如果对自己写的代码没有感情，怎么可能写出漂亮的代码来？同样的道理，如果一个程序员，对自己的工作质量没有追求，又怎么可能成为高水平的程序员？一个前来应聘的人，为了得到offer而写的demo，就这种情况下，在寄出代码之间都不认认真真的检查检查，这样粗心大意的家伙，我怎么敢招？

总而言之一句话：“对代码有感情，对质量有追求”，这是成为好程序员的基本前提。

一篇有点意思的文章，在此收藏。

文章出处：http://blog.china.alibaba.com/blog/startstudy/article/b0-i5673859.html

我们生活在一个浮躁的年代里。

浮躁的社会，浮躁的企业，浮躁的人，浮躁的生活。

刚毕业找工作的阿飞浮躁地说：“现在的公司太过分了，聘人就要有工作经历，谁都不愿意出钱培训员工，又都想招好员工,难怪留不住人”。
才接到一份辞职申请的上官老板浮躁地说：“现在的年轻人也太过分了，到公司两年还没见给公司做出任何东西，学到东西就要跑了，难怪大家都不愿用新人。

“天下熙熙，皆为利来，天下攘攘，皆为利往”，区区蝇头小利尚且你争我夺，想不浮躁，谈何容易。
在浮躁的年代里，我们进取心太切，患得患失；虚荣心太强，战战兢兢。一心争强好胜，惟恐榜上无名。说起来夸夸其谈、头头是道，做起事来心中无数、手足无措。

在浮躁的年代里，我们哗众取宠,急功近利，惟名是图。于是我们盲目追赶朝流、投机取巧，不做实事、也做不出实事。

在浮躁的年代里，我们为达目的，不择手段。于是我们盗版，随意践踏别人的劳动成果，侵犯别人的知识产权。
在浮躁的年代里，我们随波逐流，没有主见，没有定力，人云亦云。于是我们只能整天围着Microsoft、IBM、SUN转圈。

因为我们浮躁，所以我们没有目标。

因为我们浮躁，所以我们没有发明C/C++、Java、Ruby，甚至面对Spring、Hibernate，我们也只有膜拜。

因为我们浮躁，所以我们做学问只得天天面对无趣的English，并美其名曰：“师夷长技以自夷”。

做官因为浮躁，所以成为庸官；做学问因为浮躁，所以一事无成；做人因为浮躁，所以为人浅薄。

最近几天又想到核心竞争力的问题，不觉也会为自己的所为汗颜一把。

到底哪个是我的核心竞争力？

有哪一样技术非常精通、达到专家级的水平？

抑或对哪个行业了解甚深？

答案都是No、No、No。

毕业4年有余，虽然暂时不算混得很差，但是总觉得有些方面相去甚远，有一些自己知道的瓶颈、又有机会克服的却一直没有提上日程，核心竞争力也连个雏形都没有，抑或是这几年的生活有点风平浪静？

一个人没有太多的被生活所逼迫的时候，是很难有危机感的，但危机感对于各个人又都是必须的。

一个公司，大到老板，小到普通员工，都需要这种危机感来促进公司和个人的进步。

往往，当事情的坏结果来临时，我们的危机感太突显，但是为时已晚。

在一个人的职业生涯中，个人觉得，培养自己的核心竞争力是需要提上日程的。

有的人在管理方面很有自己的一套，有的人在专业领域达到专家级的水平，有的人写作方面很在行，有的人具有优秀的组织能力等等。总有一些谓之“核心竞争力”的东西，让周边的人眼前一亮。在这些方面，在茫茫人海，你们是难以被替代的。

摘抄一下网上的这段话：

“那么，什么是个人核心竞争力呢？所谓个人核心竞争力，就是指不断提高自己核心能力的能力。所谓核心能力，是相对其他人而言的，这种能力能很好的实现自己在某方面的价值，且别人不容易模仿。核心竞争力不仅表现在所掌握的技术上，更重要的体现在所具有的独到思想或见解、对某个领域业务的综合把握。”

      综合考虑一下自己的情况，最近4年多的时间一直是做的电信行业，虽然以前主要做web，至于核心的一些协议什么的了解并不多，到新公司后，开始接触相对底层一些的东西，对培养自己的核心竞争力也是很有好处的。所以就领域而言，我当时选择我从事的也是我喜欢的电信行业。要对行业有一些独到的思想和见解，对行业本身都不够了解的基础上是不可能做到的，所以只是先广后精是个好路子。希望这一年的时间有所进展。

    今年的测试任务，开发工期非常紧张，导致开发提测的版本质量很差，每个月的bug总数都过百，对测试工作进度有一定影响；时间长了，对于这个现象突然觉的已经习惯了，对开发质量的改进工作已经不抱希望；但对测试工作的质量和效率改进还是很有期待。

这篇文章多少反馈了IT项目中的一些真实现象，在此收藏供以后查阅，题目我给改了！！

文章出处：http://www.blogjava.net/zbw25/archive/2005/11/07/20897.html

　　在探寻软件开发以往的方法论背后的假设之前，首先要指出的是，这些假设很难被发现，不是说它们不存在，而是这些加上很少被看成是假设，往往作为理所当然的一部分，被排除在常规的思考范围之外。让我们来看几段大家都很熟悉的文字吧。
　　“大多数大型软件项目都没有达到预期的目标，交付推迟，预算超支，功能不完善。许多软件项目彻底失败了。”
　　　　——FDD
　　“当前，软件开发的情况并不理想。很多系统最终不能交付，或者最终交付的系统经常性地发生延期或者超出预算；系统常常不能满足用户的需要，其结果是不得不一遍又一遍地开发。”
　　　　——AM
　　“许多软件项目，或许应该说大部分软件项目实际的开发周期比预期的要长，实际的花费比预期的要多，实现的功能比预期的要少。这造成了严重的质量问题。”
　　　　——某一本CMM的书籍
　　怎么样，是不是似曾相识？我敢肯定，你不只在一本书的序言部分，看到过类似的文字。无论这本书写于70年代、80年代、90年代还是21世纪。情况一直都是这么“糟糕”。有趣的是，这些书都会在“痛说软件开发现状”之后，转而兜售自己的方案。当然，在Brooks的《没有银弹》之后，他们兜售的语气谦虚了很多。作为一个文化现象来说，这非常值得细细品味。但是，我们需要追问的是：为什么？
　　难道软件开发是全世界最难的事情吗？为什么失败率如此之高？如果我们在使用了层出不穷的手段之后，还是不能提高成功率，我们应该怎么办？其实也很容易，当年我的一个老板就想出了一个绝妙的办法，绝对简单，就是将我自己的工作量估算乘2！我们的项目几乎从不失败，总是能够在计划时间内完成。于是我想，如果我们把全世界的软件项目估算都乘以2的话。也许软件开发这个行当，也能成为一个有尊严的职业。大家都会生活得更加幸福。
　　“这实在是太过分了！”也许有人会说：“你这是自欺欺人、掩耳盗铃、移靶就箭！”但是且慢生气，生气的人应该冷静下来反思：如果目标如此难以达到，会不会是目标有问题呢？当然，事情没有这么简单，如果把目标直接乘2来提高成功率，全世界的老板都会发疯的！我们要做的，是提高估算的准确性。
　　“啧啧，还以为是什么了不得的结论呢！这个问题早就有人研究了，不就是IT度量吗？”一定会有人站出来这么说。但是，IT度量的研究，提高了估算的准确度了吗？思路在这里被卡住了。直到有一天，我看到了量子力学中的“测不准原理”！
　　“测不准原理”告诉我们，在物理学中存在着很多对变量，当我们想要精确测量其中一个变量时，对另一个变量的测量误差就会越来越大。但是，在软件开发里，我们是进行估算，而不是进行测量，而且也不存在一个和工作量相对的变量，当工作量估算准确时，它会变得模糊。简单地套用物理定律是行不通的，思路又卡住了。
　　突然有一天，我问自己：“假设工作量已经估算精确到了99.9999％会出现什么情况？”“不可能！”“如果真的达到了这个精确度了呢？”我对自己穷追不舍。“那只有一种情况，就是项目已经接近完成了！”“我们估算完成时，项目接近完成，这意味着什么呢？”“这毫无意义，没有一个项目会花这个多时间来估算，而且如果要这样估算，估算本身要花多少时间都不知道。”停！我已经想通这个问题了。
　　估算工作量也是一种工作，同样也需要工作量。对于大多数任务来说，估算所花费的工作量，相对与总的工作量来说，几乎可以忽略不计，或者说：为了能够得到一个有指导价值的估算值，所花费的工作量，几乎可以忽略。但是，对于软件开发来说，这只是一个假设。我们假设对于软件开发的工作量估算，同样只需要花费极少的工作量。但事实上，当我们花费三五天时间得出结论，这个项目需要20个人月时，我们估算的误差，可能（甚至一定）会大于200%这就是我们这个行业显得如此失败的原因。
　　为什么这个行业与其它行业不同呢？在建筑行业，工程概预算的费用，不超过总费用的百分之一、甚至千分之一。为什么软件项目的估算做不到这一点？因为两个原因：
　　一是由于技术的复杂性，以及这个行业技术的飞速发展（也可说尚未定型），同样的需求，采用不同的设计，不同的技术实现，工作量相差极大。仅仅根据需求，无法估算出工作量。而随着概要设计、详细设计的层层分解，工作量估算的精确度的确会提高，但是对于软件开发来说，项目也越来越接近完成了。
　　二是由于需求的变动性以及不可预测性。早期的估算、设计甚至代码，都有可能作废。一个项目实际上重做了N遍，在软件开发领域也是常有的事。估算的误差，自然也就大到不可思议了。
　　然而，绝大多数人没有想过这个问题，大家都自然而然的根据最初的工作量估算，来评价以后的工作。
　　　　工作量/人员效率＝项目时间
　　　　工作量×单位成本＝项目成本
　　　　缺陷总数/工作量＝软件质量
　　我们根据最初估算的工作量，来推出项目的时间、成本和质量目标，我们假设工作量估算只花费可以忽略不计的工作量，我们依据这些目标来衡量项目的成败，然后我们发现大多数项目都失败了，然后我们研究技术、改进过程、寻找银弹！最终，我们发现自己还是这么失败！
　　是到了彻底反省我们的假设的时候了。

1、首先态度需要端正，做代码的自我审查并不是否定自己，而是给自己将工作做得更好的一次机会。在审查过程中要尽量将自己作为一个旁观者的心态去审查自己的代码，尽管这比较困难。

2、代码审查离不开重构，在审查过程中发现任何坏味道都请使用重构去改善，发现缺乏测试的地方要及时补充测试，不要让BUG遗漏。

3、代码的自我审查可能不是越早越好，隔一段时间之后回去看自己写的东西，对一些设计上的选择能有更客观的评价，在审查的过程中可能需要重新去理解代码，在此过程中可以检查自己代码的可读性，并思考如何改善可读性，切记代码首先是给人读的。

4、审查过程中需要记录下一些犯下的错误，以及当时为什么会犯下这样的错误，建立自己的bug数据库，并时常review，在以后的工作中避免同样的错误。

5、代码的自我审查应该是一个持续性的过程，而非特定时间的特定行动，时常审查自己的代码，不仅能辨析自己的得失，还能够进一步提高自己在未来工作中的设计能力和预见能力。

6、代码的自我审查跟团队成员之间的相互review并不矛盾，在相互review之前做一个自我审查，有助于提高review的效率，包括可读性的提高和一些一般错误的避免。

7、代码自我审查的一些常见注意点：
（0）自认为绝不会出错，并且从来没有审查过的代码。
（1）注意else语句，if条件下的子语句通常可能是个正常的流程，而else意味着异常的情况或者特殊的场景，你可能特别注意怎么处理正常的情况，却忽略了else子句的实现细节，如该释放的锁没释放，该递减的计数没有递减，该赋予特殊值却没有赋予等等。
（2）注意空的方法，没有方法体的方法，是不需要实现？还是忘了实现？
（3）注意switch语句，有没有忘了break？这种错误通过findbugs之类的静态代码检查工具都能避免。
（4）注意大块的注释，为什么这么多注释？是代码写的很糟糕？还是遗留的注释？遗留的注释会误导人，要及时删除。
（5）注意一些看起来“不合常理”的代码，这样的代码很多都是基于所谓性能考虑而优化过的代码，这样的优化是否还需要？是否能去除这些“奇怪”的代码也能实现正常的需求？
（6）对客户端的使用有假设的代码，假设用户只会这么用，假设用户只会用到返回对象中的某些属性，其他属性一定不会用到？不要对客户代码做假设！这个客户代码包括外部用户和调用这个模块的内部代码。
（7）标注了FIXME、TODO之类task标签的代码，是否忘了修复BUG，实现功能？
（8）任何超过15行以上的方法，这些方法是否能拆分成更细粒度的方法，并保持在同一个抽象层次上？
（9）任何在代码中出现的常量值，是否应该提取出来成为单独的常量，常量的默认值设置是否合理？
（10) 任何持有容器的代码，提供了放入容器的方法，是否提供了从容器中移除对象的方法？确保没有内存泄漏的隐患。
（11）重构中提到的其他坏味道，别放过它们，但是也不要追求完美，OO不是圣杯，如果能简单的实现一个算法，你不要引入3个对象和4个接口。
（12）在review最后能列出一张清单，开列下该项目面临的风险点，并提出解决办法，然后按照这张清单去review关键代码，着重检查异常情况下的处理。风险点的review，我建议可以放在后面，在一般性错误解决之后进行，此时你对代码也将再度变的熟悉。

去年带了几个新人，越来越觉得软件开发这行还是需要一定的"天份"的，其实每行都需要一定的"天份"，每个人都有自己最为适合的行业，特别是技术行当而言，如果真的希望在软件的技术领域有所发展的话，勤奋、吃苦的精神固然是必须的，但以下的几点素质却是基本的，而有些我觉得完全是靠天生的，或者后天小时候的努力才能培养出来的，如果不具备的话，我觉得这样的人就不是很适合从事软件技术行业：

1、逻辑思维能力
      这点非常非常的重要，而且我觉得这点在等到大学毕业后再培养真的非常难，从这点上去看就会发现数学对于软件行业的人来说是非常重要的，为什么这么说呢，数学正是能表现出一个人逻辑思维和举一反三能力的最好的考试，而逻辑思维和举一反三刚好是软件技术行业最为基础和重要的两点基本素质，为什么这么说呢？
      软件的开发其实和数学的解方程是个非常类似的过程，都是对某个问题求解，有些问题甚至完全不懂软件开发其实也应该是能解决的，如果不懂具体的如何写代码的话顶多差的就是把解决问题的方法转化为代码而已，而这个培养起来我觉得并不是什么难事，这个只要多写写代码就行了，举一个简单的例子，在培养新人的时候曾经出现过个这样的问题：要生成一个九位的字符，字符由流水号构成，当不足九位的时候补足九位，例如1就形成000000001，9999就形成000009999，不需要写代码，只需能说明会怎么做就是了，我觉得具备了一定逻辑思维能力的人这样的问题都是很简单的。
      在将来我自己面试新手的时候，这方面的面试需要重点加强，以前我忽略了对于这个方面的考量。

2、举一反三能力
      举一反三的能力对于软件技术行业来说更是非常非常的重要，其实软件开发日常的工作中通常你所做的东西都是有类似的东西的，只是会稍有变化，这个时候就需要具备举一反三的能力。
      这项能力在将来的面试中也需要重视，需要让面试的人当时学习一个以前的未知领域，首先给面试的人员一个解决方案，然后将问题稍加改变，看看面试的人是否可以做出解决方案来。

3、自学、独立解决问题的能力
      自学、独立解决问题的能力我觉得这是为什么一定要读大学的原因，读大学就是培养自学、独立解决问题的能力的。
      在做软件开发的过程中，不论是新手、老手都会碰到各种各样的问题，这个时候一定要学会有效的解决问题，在perl界有一篇给新手写的解决问题方法的建议的文章非常的不错，http://www.perlchina.org/archive/archive.php?action=archive&page=6，建议做软件开发行业的人应该都读读。
      个人比较推崇的解决问题的方法：
       3.1、在时间较为充裕的时候，google--->看原理---->问身边的人---->问IM上的人--->找相关的专业论坛---->学习相关的知识
        3.2、在时间紧张的时候，问身边的人---->问IM上的人--->google--->找相关的专业论坛---->看原理---->学习相关的知识
        不过即使在时间紧张的时候，当时间闲下来后，都应该整理下问题的解决方案和学会隐藏在问题后的本质。

4、对软件开发的兴趣
      这点呢，还比较难说，因为新手来说无法判断自己是否有兴趣，很多人也许是向着软件行业所谓的高薪而进入这个行业的，兴趣而言，我觉得判断的标准就是能否为了一个开发上的问题废寝忘食，:)
      另外一个方面来说，做软件开发必然会面临很多重复性质的工作，这个时候只有有兴趣的人才会继续的对技术坚持下去，才会继续的去钻研相关的技术，从而提升工作的效率、质量。

      当然，除了上面说的几点外，其实象承受压力的能力、沟通交流能力、团队合作能力、责任心、上进心等等都非常的重要，但这些能力我觉得相对而言是可以培养或用公司制度等方式来控制的，但以上说的4点基本素质我觉得非常的难培养，尤其是1、2、4这三种能力，对于希望一直从事软件技术行业的人来说我觉得是否具备以上几点非常的重要，否则还是早点转行比较好，哈哈。

产品开发和项目开发有部分的类似之处，毕竟都是软件开发过程，^_^，不过产品开发较之项目开发来说更加的不易，下面就从产品的整个开发过程来讲讲产品开发的不易。
    一个公司在经过N多的项目并对项目进行总结或对市场的情况进行N多的分析后发现了做成产品的潜在可能性，往往这时需要成立一个产品规划小组来进行产品的规划，包括对于：

Ø         产品的定位

Ø         产品的市场切入点

Ø         产品的功能的策划

Ø         产品理念的编写

Ø         产品优势的规划（市场现有类似产品的研究，竞争对手的优势，竞争对手的走向，产品的卖点）

Ø         产品允许的开发周期

Ø         产品的成本以及利润的估计

这可以列为产品的第一个阶段：产品可行性分析阶段，这个阶段的不易之处显而易见。

首先需要有明确的产品的定位，这个就有一定的难度了，然后产品的卖点，最难的地方在此了，毕竟还得估计在你进行产品开发周期的同时也会有其他竞争公司在进行，而且往往一个产品会是比较的庞大，需要划分为几个周期来进行，所以这个时候又得同时估算好产品允许的开发周期以及每个版本的延续性、产品的成本以及利润的估计，毕竟商业化的公司，总不能一直投入而没有利润，还得考虑好产品开发完毕后市场切入点在哪，总不能等到产品开发完毕后才去想该怎么去卖这个优秀的东西呢，这个阶段至关重要，很大程度上决定了产品的将来。
    经历过产品可行性分析之后，觉得这个产品可行，值得投入那么就进入了下一个阶段：技术可行性阶段。

这个阶段主要就是组建一个产品设计团队，根据之初产品的第一周期的规划对其技术可行性进行评估，在这个阶段设计团队成员更多的应该是考虑怎么样去设计一个稳定而又快速的架构，并需要对可能出现的技术风险进行评估，作为企业级的产品的话，这时在架构上更需要考虑到企业级的需求，高并发、稳定性、高响应等等，架构上的掌握也是同样的关键。

这时应该更多的是采用成熟的技术体系，并尽可能采取产品设计团队成员都熟悉的体系结构，如确实需要采用不熟悉的体系结构，则需要进行一定时间的对于此体系结构的了解，以预计将来的技术风险，并尽量多的采取已有的较好的东西，不重复发明轮子是关键，当然，不是说去买N多贵的产品来组装自己的产品。这个阶段同样的至关重要，技术架构的把握对后期整个产品的研发都有至关重要的影响，设计团队需要确实的做到对于整个架构体系的把握和掌控(包括在将来体系结构不够完整时的调整的进行)以及技术风险的评估、避免和响应策略，记住产品的技术先进性不是关键的，何况一般的公司根本就没法去做什么先进的东西，而且客户也不会关心你的技术有多么的先进，重点在于产品的稳定、高效。
    在经历过技术可行性分析后，如果技术上评估可行的话，那么就正式进入团队的研发阶段，此时需要组建产品的设计团队、研发团队、测试团队、规划团队、管理团队、策划团队(用户团队)，各团队的协同工作至关重要，并要制定一系列的产品研发阶段制度，产品的质量保证体系，产品开发过程采用何种软件工程，产品团队的激励制度，各团队的协作制度。

研发阶段中最为重要的是保证产品的研发始终处于突出产品卖点的中心问题上，不可偏离此方向，并首先保证产品卖点部分的完成，而研发阶段的不易就更不用说了，做过开发的都知道，技术难度，软件过程的管理，质量的保证，各团队之间的协作，由于软件开发难以量化，但同时又得保证开发周期的有限，更是增加了这整个过程的难度。
    终于，经过了这些漫长的阶段，产品的第一周期完毕，此时需要同时加入进来的就是产品宣传团队和销售团队了，只有通过这个阶段才能使得产品的开发变得有意义，产品的效益才得以产生，而同时产品的策划团队则需要继续考虑产品的后期发展方向的细节规划等等，又重新轮循的进入整个产品开发周期。
    上面其实也只是较为简单的描述了产品的周期，在实际的产品周期过程中，所碰到的难度只会超过上述的，毕竟产品的整个过程有很多难以把握的因素，诸如产品的未来走势(这个需要良好的市场分析的眼光)、技术走势(需要良好的技术掌控能力)、产品的市场切入(这个可是产品变得有实际意义的关键)、产品整个过程的团队的协作、人员的协作、人员的稳定、公司整体的坚定(在产品的过程中保持坚定的方向)。任何一个环节都对产品产生重大的影响，在任何一个环节上都不能松懈。感觉在做行业标准化的软件会稍微好一些。
     产品化的过程是一个风险较高的过程，但同时也是一个利润高的过程，产品化能使得一个公司得到质的提升，得到发展上的一个飞跃。

文章出处：http://www.blogjava.net/cenwenchu/archive/2009/12/08/305083.html

其实想说这句话很久了,和很多同事接触,有时候或多或少的都会发现大家会陷入在自己的一亩三分地里面。

主要表现得症状：

1.         PD的需求就是目标，踏实的实现，不懂的就猜。

2.         经验盖过一切，设计系统就是要够完备够复杂。

从开发人员角度来看

第一种人多半比较有自己的想法，同时也有不少的工作经验，同时可能对技术比较着迷。

另一种人多半是刚刚工作或者经验不足，要么就是习惯性把工作当任务，而不是爱好，写程序也就是一份赚钱的活。

但看起来其实各自都在自己的一亩三分地上捣鼓，忘记了作为一个开发人员最基本的原则：“满足客户需求”。

先说1类型吧，在我们的Team有一个刚毕业一年多的同学，很勤奋，不论从学习以及工作，实实在在，踏踏实实。我们这边来需求，通常大需求我们都会全体过一下，一些小点的需求他就自己考虑一下就作了。那天正要上线，突然说了一下设计修改的内容，发现不仅满足不了PD原有的需求，而且给系统带来了缓存暴增的隐患。然后找来PD一谈，其实他要的功能已经在现有系统中已经实现，只是需要做部分的修改，而不需要新的去建立一套机制。这样的情况其实在前前后后出现了不少次数了，但其实一直没有和他细谈。后来我下班时候和他一起回家的时候说：“很多时候， PD为了让你理解，从开发的角度想要去描述一个需求，但其实最终失去了他自己想要的东西。因此对你来说第一步不是急忙的去考虑如何实现PD的想法或者和他争论他的设计是否合理，而是需要先问他：你想要什么，想要实现的东西最终目的是什么，能满足客户的什么需求？当他能够说清楚他想要什么，也知道要的东西能给客户带来什么价值的时候，我们再回过头来看，究竟应该怎么做？”

这其实和我每次和同学分享一些设计的时候步骤是一样的，首先为什么要这么做，然后才是考虑如何从我的目标去寻找行动的方法方式，不然你会发现你和别人讨论了许久的东西，实现出来的时候已经背离了你的目标很远。

因此在做任何需求或者设计的时候第一个问题就要问自己为什么要做，作的过程中时刻要记得我的目标是什么。这让我想起了我在离开阿软的那些日子和王坚博士谈话以及听他的一些对于设计的理念，很多时候还没有到规模化的情况下，先解决客户的需求，在解决客户需求以后，逐步的去考虑规模化问题的设计。（当然不是说第一版设计就可以随便作，良好的基础能够提升后续改进的速度）。

2类型的就比较多了，其实是很多开发人员的通病，包括有时候我自己也会陷入这样的误区。通常情况下有两种场景会陷入这样的误区，同时当事人却又不愿意改变。

第一种情况就是觉得自己有不少的经验，同时对技术很执着，希望设计出来的都是很完美的，一次发布就可以满足个1，2年，但其实从这些年的设计角度来看，首先系统都是不断迭代进化的，因此一步到位的说法基本上不靠谱（除非就是一模一样的场景代码重复使用），其次系统的架构要做的足够灵活，通常情况就需要先做核心功能，预留出足够的空间和切入点，这样对未来扩展和需求变化有足够的适应度。

从这两点来看，其实设计初期就是要求找到客户最想要的，扩展可以实现客户可能要的，防范客户没有估量到的。但这其实就需要和我们的产品设计师有充分的交流，好的产品设计师不会告诉你怎么去实现，但是他会告诉你我想要的是什么，这些能给客户带来什么，这时候你可以告诉他我能够通过什么方式来满足你的需求。这样的开发和产品设计交流的结果才是技术化的产品，大家各司其职，同时也通晓对方领域的一些情况，对对方领域的只能给出建议，不是指导，这点在TOP我很庆幸有很好的黑羽同学，我们的交流就是这样产生良性互动。

这有点撤远了，刚才说了第一种场景，然后说说第二种场景，就是初期其实大家都没有明确细节，但是在实施过程中开发人员会根据自己的接触面来选择一些技术和架构设计，最后看起来很复杂，很完美，但其实越是复杂的设计背后有越多的隐患。但是此时因为已经设计好了，就不愿意再去简化，也不愿意听任何人的意见，其实这是很危险的。我过去也犯过类似的错误，但是其实当你冷静下来，想想那句话，我们的目标是什么：“满足客户需求”，这时候你就会考虑，这么复杂的系统会不会给客户带来更多的不稳定以及复杂度，其实客户不关心你背后如何实现的，但是你需要满足客户的最基本的需求，用起来方便，高效，实实在在提供了解决问题的手段。

今天下午面试了一个外部的同学，工作年限比我长，看了简历也经历了很多项目，同时在描述的时候写了对高并发，分布式等等都很熟悉和热衷，我开始看了简历就担心，可能我这边不一定要他，因为我怕他开口就是说一大堆如何做高并发和分布式的内容。

在我看来如果你没有搞清楚你什么时候要用牛刀，什么时候要用剪刀的人，和你谈论牛刀的构造其实没啥意思，因为在我看来，技术只要你肯花时间去学，没什么学不到的，但是做事方式和项目设计经验却是长时间积累的。幸好今天和他一谈，他对于技术的态度以及架构设计的思想都和我想的比较接近，不是为了技术而技术，不是为了过程而过程，了解如何从简如繁，再从繁入简，最终能够找到自己的目标。

当然后来还是谈了很多技术细节的问题，毕竟干活还是要一个好手，作了那么多年如果没有经验和技术积累也是很可怕的事情。最后我问了他两个问题：

1.你学习一个新技术的过程是怎么样的？

2.你和你同事如果在设计方案上有冲突你怎么解决？

他告诉我他学习新技术首先会去考虑这个技术的特点是什么，和其他技术的差别，他的擅长领域是什么，这样才能够用到实处。

第二个问题他和我说就是开会讨论，最后大家群体决定。

我对他第一个问题感到很满意，因为我就需要这样的同事。

第二个问题我给了他一个建议，其实在很多时候，将别人的架构设计的优点融入到自己的设计中，不再以方案作为边界，那么大家最终就很容易达成一致，因为你在接受别人的思想时其实能够看到自己的不足，同时对待别人不是用否定的态度，会让你更容易得到认可和接受。（这点作起来需要不断的改变程序员自身的好胜个性，我起码还是出于变化中…）。

我记得我小时候上政治课的时候，老师给我们划分了三种人：

1)      有能力但是没有道德的人是危险的人；

2)      没有能力但是有道德的人是对社会无害的人（觉得像葛优说的那个对社会无害的海龟一个概念）；

3)      有能力同时也有道德的人是对社会有益的人。

我觉得其实程序员也就可以从两个纬度看：

1)      有能力，有经验，对技术有追求

2)      对产品化和客户没有任何感觉

拥有了素质1但是没有素质2，那么最多也就只能说是试验室的花朵，在大学搞搞研究还不错，实际要做出产品来可能就是纸上谈兵，好钢始终用不到刀刃上，有力没地使。

素质1有所欠缺，素质2很明晰，对自己目标不断追求，其实这样的人，有时候笨鸟也会飞的比聪明的鸟更高。

拥有1，2的人，当然就是最好的人，只需要学会做人那么就可以发挥自己的能量。（程序员有时候就是很难改变自己的个性，去学会如何沟通和理解）。

最后一类就是自以为有1和2的人，这类人最怕就是面试的时候被考官通过，那么后续的问题就大了。

说了这么多，其实也无非想说出一个程序员这些年的经历，从做开发到做基础平台，到做业务平台，该怎么踏实做事，该在什么时候找到自己的瓶颈，该在什么时候改变自己的状态，都需要自己好好的让自己冷静下来想想。

做基础平台需要耐得住寂寞，同时也要知道自己是有客户的，服务不好客户，那么基础组件平台就是玩具。

做业务平台需要学会去分析和沟通，需要去了解每一个层次的设计如何协作，同时在兼顾业务需求的同时满足隐性需求（稳定性，可用性，响应速度，规模化等等）。

但归根到底，能给开发人员不断能量的不是技术本身，而是你用技术给你的客户带来的价值，对你的认可是长期做事的一个最基本的动力，因为当你现在觉得纯做技术能够支持你不断向前走的时候，其实在不远的将来你会体会到原来过程和目标是同样重要的。

走出自己的一亩三分地，给自己多一点的空间，会让自己看得更远，走的更高。

文章出处：http://www.blogjava.net/BlueDavy/archive/2006/01/01/26282.html

昨晚看切尔西的比赛的时候突然联想到了软件开发，呵呵，来看足球赛：
1、根据比赛双方的实力、主客场、天气等等各方面因素来比赛双方都会制定自己的目标，战平、胜或别的目标。
2、需要在有限的时间内(90分钟)达成目标。
3、多种角色构成。(守门员、后卫、中场、前锋)
4、一定的阵型(4-3-3、4-4-2)和战术(防守反击、短传渗透、长传冲吊)。
5、多变的形式以及多种不定因素(裁判、球员状态等)。

   球赛的整个过程需要由整个队共同努力去完成，而教练负责对于全局的把握、战术的调整等。
软件开发和足球赛有很多类似的情况，也是在一定的时间内由多人协作共同去完成目标，在完成目标的过程中会碰到多种不定的因素和多变的需求，通过架构来制定开发过程的阵型，通过引入模式来作为实现目标的战术。

   软件开发和足球赛一样，人是其中至关重要的因素，一样的阵型、战术在不同的球队中就会产生完全不同的效果，你不能去要求甲级联赛的球员拥有和超级联赛的球员同样的水平，也不能去要求一个球员永远保持良好的竞技状态，同时，阵型、战术直接影响到个体，也许个体的实力很强，但在一个不适合的阵型和战术中是无法发挥的。

   从架构层次去看，球赛依靠4-3-3、4-4-2这样的阵型构成其架构，在实现目标的过程中需要保持阵型，在进展的过程根据实际情况进行调整，但不会频繁变化，教练就象一个优秀的架构师，会根据情况来决定出最佳的架构。

   从实现角度去看，在球赛进展的过程中球员会采用多种协作模式，撞墙式配合、下底传中等，同时个体也会采用多种模式，穿档过人、人球分过、变向、踩单车等，好的球员能够纯熟的应用模式到合适的环境中去。

   从团队管理角度去看，球赛需要多种角色的球员的共同合作，球员的合作是影响目标达成的重要因素。

   从个体角度去看，个体的能力、状态以及对于架构的理解将会影响架构的实现和目标的达成。

   某种程度上来讲，足球比软件开发更具难度，极为有限的时间，更多角色的合作，更多不定的因素。

职场中五个人对你最重要

　　第一个，导师，教练。他教给你实用的技巧、一定的工作经验，虽不是知识，但它可以给你指明方向。这个人可能是你的上司、前辈、学长。

　　第二个，陪练，同路人，任何人的成长都不是学出来的，而是学而习，习而成习惯练出来的。这个练的过程，是一个很苦的过程，是一系列简单动作的重复重复再重复，由量变成质变的过程。在这个过程中，一个人很难坚持下来，这时你需要一个同路人。他可以是和你有共同兴趣，共同目标的朋友，最好是你生命中所爱的人。

　　第三个，榜样。他是你人生的标杆。在你一生中，在不同阶段，会有不同的标杆，你向他学习，受他鼓舞，一步一步向他靠拢。最重要的是那个你看得到摸得着的人，你知道，不需要通过机遇，只需要通过努力就可以达到的榜样。

　　第四个，敌人，看不起你的人，拒绝过你的人。人不到绝境是不会有斗志的，你要证明他是错的，他会给你真正的动力。

第五个，最重要的人是你自己。这个世界上，失败的人除了天分太差之外，只有以下几点：懒，方向不对，方法不对，没有坚持。如果你自己做不到，就不要怪别人。

说话要用脑子，敏事慎言，话多无益，嘴只是一件扬声器而已，平时一定要注意监督、控制好调频旋钮和音控开关，否则会给自己带来许多麻烦。讲话不要只顾一时痛快、信口开河，以为人家给你笑脸就是欣赏，没完没了的把掏心窝子的话都讲出来，结果让人家彻底摸清了家底。还偷着笑你。

遇事不要急于下结论，即便有了答案也要等等，也许有更好的解决方式，站在不同的角度就有不同答案，要学会换位思维，特别是在遇到麻烦的时候，千万要学会等一等、靠一靠，很多时候不但麻烦化解了，说不准好运也来了。

要学会大事化小、小事化了，把复杂的事情尽量简单处理，千万不要把简单的事复杂化。掌握办事效率是一门学问，要控制好节奏。

对小人一定要忍让，退一步海阔天空，实在不行把属于自己的空间也送给他们，让他们如莺歌燕舞般陶醉吧。俗话说大人大度量，不把俗事放在心里，小人鼠肚鸡肠，惹着小人就等与惹了麻烦，天底下顶数小人惹不起。直到现在我也没想出更好的办法战胜小人，不知道敬而远之是否可行。

这世道没有无缘无故的爱，也没有无缘无故的恨，不要参与评论任何人，做到心中有数就可以了。所谓盖棺论定的道理多简单，就是有***之过急。谁也没有理论依据来介定好人与坏蛋，其实就是利益关系的问题。小平三七开了***，说明伟大的人也不一定完整。

只有花掉的那部分钱才是真正属于你的财富，你就是家缠万贯，生时舍不得吃、舍不得穿，俩眼一闭，剩下的钱你知道谁花了才怪，冤不冤。还有那些省吃俭用的贪官，好好的高官不做，结果因贪返贫，一分钱没花着还搭上个人财产全部没收，惨不惨。

做事情一定要事先设立道德底线，小偷也清楚有些东西是绝对不能偷的。所以说事情万万不可做绝，落井下石的事绝对不要干，给别人让出退路就等于自己前进了。

对于那些经常找你麻烦甚至欺负你的人，能忍则忍，没必要时刻与莽夫过不去，但一定要给他攒着,新仇旧怨积累起来,正义和真理就属于你了,那么瞅准机会一定要彻底教训他一次,在法律赋予的权限以内，往死里整,往死里揍,让小子永远记住：除了你爹,没人会惯你这些臭毛病.

有些人习惯了占你小便宜,小人小肚肠,大人大度量,有机会坑他一把大的,出一次大血，同样让他记住:天下根本就没什么免费的午餐，哪有白拣的便宜让你赚。

明枪易躲，暗箭难防，背后算计你的小人永远不会消失，这是中国特色，小人不可得罪，同样小人也不可饶恕,这是万世不变的真理，说到底小人也有心小的一面，对待这种人要稳准狠，你可以装做什么也没发生，天下太平，万事大吉,然后来个明修栈道，暗渡陈仓，以毒攻毒，让小子知道：小人也不是谁都可以做的，做好人要有水准，做小人同样有难度．

对待爱你的人一定要尊重，爱你是有原因的，不要问为什么，接受的同时要用加倍的关爱回报，但是千万不要欺骗人家的感情，哪怕你对人家没兴趣，哪怕人家长得丑一点，这是你用钱买不来的财富。记住：轻视人家付出的情感就等于蔑视自己,玩物丧志，玩人丧德，爱人是一种美德.

背后夸奖你的人,知道了,要珍藏在心里,这里面很少有水分.当面夸奖你那叫奉承,再难听些叫献媚,你可以一笑而过,就当什么也没发生,也许不久就有求于你.对于那种当众夸奖你的人,就疏忽不得了,也许你转过身去,就用指头戳你.掌握一条原则:逢人多贬自己,少夸别人,选先评优的时候除外.

小恩小惠攒多了就是一个大窟窿，只要接受就一定要找机会回报，行下春风望夏雨，付出就是为了收获，其实就是一个简单的种子与果实的关系。千万别让天真给害了，记住：人生如戏，都在寻找利益的平衡，只有平衡的游戏才有可能玩下去。

患有心理疾病的人是不负法律责任的，可以没有理由的咬你一口，所以对待疯狗级的人物要敬而远之，保持不来往，不交流，退一步，海阔天空，相信疯狂也是一种人格，虽不值得尊重，但自有其存在的道理，生物链少不了这一环。

做一个人生的观光客吧，说到底只要与人为善，以德服人，离是非远点，靠家人近点，便有了心安，有了惬意。

乐观的心态来自宽容,来自大度,来自善解人意,来自与世无争.

坏心情是失眠时折磨出来的，其实现实并没有你想的那样糟糕，生命有高峰也有低谷，根本没有一帆风顺的人生,邓小平怎么样,三起三落,最后还不是凡事他说了算.

所谓的缘分无非只有善恶两种，珍惜善的，也不要绝对排斥恶的，相信擦肩而过也是缘吧，全世界近60亿人口，碰上谁也不容易,所以遇到恶缘,也要试着宽容,给对方一次机会,不可以上来就全盘否定.

不要让事业上的不顺影响家人，更不要让家庭的纠纷影响事业。那样做很不划算,家人和事业都受影响,甚至损失.男人要善于扛事,要把眼泪咽下去.

待人接物要摆正自己的位置,不可以老把自己当人物,老拿自己当领导,老把自己当富翁,老以为自己是情圣,老是自我感觉良好,即便真是小有作为,业绩斐然,也要谨慎,要虚怀若谷,要大智若愚,其实人的最终结局都是一样的,只是你把自己看复杂了.说句俗话:千万别把自己当回事.

骗你一次的人绝不会放弃第二次骗你的机会,对骗子不要抱任何幻想.

靠贬低别人提高自己的身份，其结果就暴露自己的无知与贫乏。

编写背景：

今天北京是个阴天，最近这两周工作强度非常大，很多事情都堆到了一起、看着一堆堆的事情没弄完，心里那个烦。在那么忙的时候会写这个文章，是因为遇到了一件让我觉的非要记录下来不可的事情，因为感触太深了，不是一般的深刻，是相当的深刻；深到我必须停下手中的工作，整理一下情绪和心情，好好透个气。

管理者：你的言行举止将代表着别人怎么看你所带领的团队形象！！！

故事是这样发生的，中午吃饭回来开始处理邮件，先从重要的开始，其中有一封邮件是部门老大发来的，通知要公司非北京员工没有办理暂住证的要办理，因为今年国庆大阅兵管理非常严格。

情节1：由于来公司还没有经过新员工培训，具体流程不清楚就问了一下部门老大公司是否能帮忙办，老大给了我回复。

情节2：我在老大回复的邮件上相应联系了相关HR负责人，邮件内容如下：

Hi，XXXX：

              你好，想向你咨询一下我要办暂住证该找谁，需要给咱们HR提供什么资料。

情节3：很快，过了5分钟HR给我回了邮件，邮件内容如下：

问问现居住地派出所。

情节4：看完这封邮件，当时脑袋嗡的一下，被雷倒了；被雷倒的原因主要有：

1） 这是公司的一个HR负责人回的邮件

2） 邮件正文没有称呼和详细讲解，就一句话

3） 这个公司的HR很牛逼、很恐怖，没事少搭理这个部门的人

4） 之前的小公司和大公司这事情HR都能帮忙办理，为啥现在这个号称XXX公司的HR就不能办理，这实在是悲哀啊

5） 谁让我给这个公司打工啊，忍了

情节5：考虑到是部门老大发的通知，我也没给HR回邮件直接把这封邮件转给了部门老大没有给HR，告知什么原因暂时不能办理暂住证了，到此该事情暂告一段落。

这个事情很小，非常非常的小，但是给我的触动很深，为什么呢，主要有这么2点：

我是抱着寻求帮忙和友善的心态去问公司的HR负责人，结果沟通过程很不好，导致整个公司的HR形象在我心中留下了阴影，更进一步的说是我对公司的HR部门失去信任。以后HR组织的一系列XXXX问卷调查和建议，我将不会热心参与和真心表达；因为做这些事情的目的是不是真的为员工考虑实在是让人怀疑啊

换位思考，我现在正在带领着一个很小的测试团队；如果其它团队的人员来寻求我的帮助，如果我也像这个HR负责人这样回复，我将会把整个团队的形象在这个人的心中留下不好的现象，同时也很难从其它团队人员口中获取到团队改进的意见和帮助。

最后总结为一句话：管理者，你的言行举止将代表着别人怎么看你所带领的团队形象。

最后我在心中感慨：公司的HR部门，想让你给些服务好难好难啊！！！！

最近在忙着招聘新员工的同时，也在带新的徒弟；为了让她们能在心态上从学校转变到上班，在一次部门例会的话题讨论中，组织了这么个话题：公司的优秀员工是什么样子的，需要具备什么样的要求？希望她们在这个讨论的过程中在思想上能够得到一些成长和收获。把讨论的内容进行了总结，放在这里和大家分享，同时希望自己能够和刚毕业的学生一样，开始新的成长。

这篇随笔就起名为：成为公司的优秀员工需要具备什么，大家看完后有什么想补充和交流的可以留言。^_^。

                                成为公司的优秀员工需要具备什么

   职业素养

  Ø       工作目标清晰，和公司、团队目标一致。

  n         分清楚工作的重要性和紧迫性，目标，要明确自己的目标。

  n         能够给公司带来价值

  Ø         工作态度

  n         好的责任心、勤奋、出现问题，不推卸责任，积极解决

  n         工作负责、追求卓越（处理问题，工作目的不只是解决问题，而是进行总结和学习，提高工作效率。）

  n         有诚信，讲信用，按时完成工作

  n         主动积极向上、乐观开朗

  n         注重团队合作、集体荣誉感

  n         团结（乐于助人、乐于分享、关心别人、带动整个团队成长）

  n         好的上进心、学习能力

  n         模范带头作用，带动整个团队的成长

  n         善于思考并要有深度

  n         少说多干

  n         遵守公司规章制度

  Ø         工作技能

  n         善于沟通、交流，发现学习别人的优点，提高自己的能力

  n         很好的业务能力

  n         好的工作习惯、好的工作方法、充分利用资源

  n         善于做总结和计划，总结自己的成长、缺点、目标，有目标就有动力

  n         清楚了解自己目前工作所需要的工作技术能力要求、并具备相应能力

  n         对自己所做工作在行业内所使用的技术，进行学习并在工作中实践，提高工作效率

 延伸思考话题：

  自己和优秀员工要求对比，还存在哪些差距？阻碍自己成为优秀员工的困难有哪些？

总结完了这次的讨论话题，在网上看了一些相关资料，其中有一篇写的不错，可惜记不起网址是多少了，只能把文章中描述的内容记录在这里，具体见下面：

在企业的运营过程当中会用到很多人，有人品人缘好的，有专业能力强的，有好学上进的等等。笔者认为依重要程度，优秀的员工应该具备：

一是忠诚度高，对公司忠诚不二，认同企业的价值观，能同甘共苦，共同发展；

二是态度端正，积极主动，好学上进，肯干并愿意干，知道自己是干什么的，那些事该做和不该做，很有发展潜力；

三是专业能力强，能独挡一面，拥有一技之长，且能不断提升。三个要素都很重要，缺一不可。

　　以前有个老员工，人很好，但却被解雇了，什么原因呢？笔者认为专业程度提升得不够，长进太慢，几年了和刚进来差别不大，跟不上时代（客户和公司）发展的速度，一定要被淘汰，所以只好“挥泪斩马谡”。

　　评论一个员工是否优秀社会上有很多标准，但我认为最根本的就是他（她）能否给公司创造价值？创造多大的价值？是物有所值，物超所值，还是“物低所值”？其它的都是假的。人缘再好也没用。公司不养人，只是搭建一个平台，让演员在上边唱戏，演好自己的角色。如果演不好这个角色，观众不买帐，只好让这个演员下台换人，其它别无选择。只有演好自己扮演的角色，尽心尽力做好自己份内份外的事，大家齐心协力把工作做好，把戏唱好，公司效益才能搞上去，观众才能买戏班的帐，生意才会越来越红火。戏班主和演员是一个利益共同体，相辅相成。大家只有同心同力，才能在竞争激烈的市场大潮中乘风破浪，所向披靡。

　　把“好人”、专业技能一般、跑得慢、业绩差的“演员”“杀掉”，让企业轻装上阵。拥有一流的演员队伍，你的戏才会唱的更好，更长久。

　　董冰，你们犯了一个几乎所有创业者都会犯的错误，也没什么大不了。商业社会其实是个很复杂的社会，但是我觉得只有一样东西，能够让自己把握起来就是诚信。因为诚信所以简单。越复杂的东西，越要讲究诚信。

　　第二 你今天讲的很多都是，作为一个企业家，我相信在座的很多人，包括我自己，我也在反思。我想成为这样的企业家吗？我们是企业家吗？企业家、商人和生意人有什么样的区别？生意人唯利是图、有钱就赚；商人有所为、有所不为；而企业家必须承担社会的责任、创造价值、完善社会。

　　但是你要想做好一个优秀的生意人，一个优秀的商人，一个优秀的企业家，你必须有一样同样的东西，那就是诚信。诚信是个基石，最基础的东西往往是最难做的。但是谁做好了这个，谁就路可以走得很长、很远。

　　再一个，我想在听你讲述的过程中，你说你有过九大戒律、八大戒律，说我这一辈子，再也不会让别人来欺骗我，再也不会上当。你知道人为什么会上当？上当不是别人太狡猾，而是自己太贪。

　　跟你一样，我是大学里出来开始创业，有四个人骗过我。那时候比我大多了，每次他们讲的故事非常好听，但是每一次我都上当。今天我活下来了，骗过我，当时比我大得多的企业，这四家企业都关门了，而我们还存在着。骗别人的人，一定会有一天会倒霉。而要不上当，就是让自己能扛得住诱惑，扛得住压力，扛得住贪。

　　再你刚才说是竞争的压力。竞争，我认为在商业过程中，它是场游戏，可它更是一门艺术。第一点，是要向竞争者学习。只有向竞争者学习的人才会进步。

　　如果在你竞争过程中，你自己觉得越来越累，一定是你出了问题。应该让对手越来越累，你越来越开心。但得到的结果是，让对手心服口服地说，我输了，你比我厉害。这样的竞争者才是我们倡导的竞争者。     

什么妨碍我们进步

北京宅急送快运公司总裁 陈平

       我熟悉的一位调度，非常虚心好学，为了不断的进步，三十好几了也不结婚，把积蓄全用在了就读各种培训班上。

　　有一次，大冬天的，凌晨五点，他把睡的正香的司机、速递员叫了起来，让他们马上出车。司机速递员火速赶到取货单位，只见大门紧闭，门卫借着灯光很不耐烦地仔细看了看工作单，原来取货时间是下午五点。这位调度遭司机速递员指责的“惨景”就可想而知了。

　　类似这样的事常常发生，领导帮助他时，他总是使劲拍打自己的脑袋，痛骂自己，发誓改！改！改！
　　半年过去了，大家仍没有看到他提高进步的迹象。于是戏称他“勤勤恳恳犯错误，踏踏实实不改正。”

　　人们常说：“虚心使人进步”“学习使人进步。”为什么这位调度既虚心又好学可就是不进步呢？这就是我想和大家探讨的一个重要问题。人们为什么要虚心？那是为了听取别人好的意见。人们为什么要好学？那是为了丰富自己的知识。好！问题就出在这里。听取意见和丰富知识在“虚心使人进步”这个过程中只是一个阶段性的目的，它从中间这么一插，“使人进步”的这一最终目的就被常人忽视了。人性的弱点往往是达到了一个目的，就失去另一个目的，阶段目的不是虚心好学的原本目的。因此，严格来说，虚心好学是不能直接使人进步的，在虚心好学与成长进步中间还存在着一个重要环节，那就是改变。虚心好学应该说是进步的前奏、铺垫或者说是一个积累。改正是虚心好学到进步整个过程中的一个转折点，或者说是一个飞跃，也是一个由量变到质变的分水岭。如果没有改变就不会有进步的结果，前面的虚心好学也就成了摆设和无用功。有很多人一辈子很注重学习，到了五六十岁还不注重改变，终身就这样荒废了。

　　虚心好学要一辈子，改变可能只需几小时。别看这几小时，决定着进步与不进步，成功与不成功，对于每一个人来说，改变是何等的重要啊！

　　有人会说，我天天都在改变，过去我抽烟，现在不抽了，过去我开车快，现在不快了等等。不可否认，不良习惯和做错了的事，大家都在改变，有些是自己吃了亏，栽了跟头，有了沉痛的教训，不改不行。我们称之为“被动改变”。有些是外部环境的影响，规章纪律的约束，上级领导的处罚，我们称之为“强制改变”。总之，这样的改变还不能使自己发生质的改变，最有效的改变和改变的最高境界是发自主观的冲动，改变自己性格中的不肯改变。这句话有点绕嘴，反复读几遍，理就通了。

　　今年春节，我去给一位老同事拜年。他告诉我住2单元306室，我找到后看见门上写的是206。不敢相信自己，便辗转到了3单元找到了306室，因不知道哪个是正确的，便用手机与他确认。他到楼下迎接我时，还在强调自己住306，其实他住的就是206。因为他住3层，所以他就定势为306。住3层就是306的定势使他十一年对门上的号码206视而不见。事隔半月，我授意其他同事再次询问他家的门牌号，他还是脱口而出：“306。”

　　这件小事使我深刻地懂得了一个人需要改变的是什么，最难改变的又是什么。人的一生，改变的东西固然很多，但最难改变和最根本的改变应该是性格中不肯改变的思维定势，只要这一点能够改变，其他方方面面的改变才能奏效，才能使人不断进步。

　　那么，障碍人改变的因素还有哪些呢？
　　一、不善于倾听。不听别人说话的人一定是只顾自己说话的人。与人交流，自己说个不停，压根儿不给别人说话的空隙，别人的话还没说完就被打断。你不倾听别人的意见，怎么能校对自己的行为是对是错？对错都拿不准，改变肯定无从谈起。

　　二、不知道什么是“悟”。有些人虽然很善于倾听，但不走脑子。左耳朵进，右耳朵出。没有把改变自己需要的有效信息在脑子里过滤沉淀，知识再好，意见再对，不悟就不是自己的。悟的越深，改变的就越迅速，越彻底。不悟什么都白搭。

　　往进步一面的改变不易，往落后一面的改变相对易，不管你是变好还是变坏，内因是变化的根据，外因是变化的条件。内因起决定作用。假如认识到了这一点，如何改变，改变到什么程度，内外因的平衡关系就不难掌握了。　　三、不敢承认错误。你要说不改变是因为不知道错了还情有可原，问题是许多人明知道错就是不承认自己错。这样的人，一类是固执，“厕所里的石头——又臭又硬”，另一类是虚荣，“鸭子死了——嘴还硬”。唯恐承认错了被别人看不起或受到批评，更怕承担责任。殊不知，这是在放弃和拒绝进步的机会。

公司人员流动向来是正常的事。俗云“铁打的营盘流水的兵”，在唯利是图的商业社会，一个人即使想为公司服务一辈子，也可能是不太现实的事。因为你除了要不时忍受外界的诱惑，还有一个公司要不要你的问题。今年初我在分公司任职的时候，亲历了一位员工离职的过程，了解了他的辛酸和无奈。他的离职感言让人唏嘘不已。

　　这位员工是我到分公司任职前被原来的总经理炒掉的。据他讲，他到公司工作了近四年，当时来的时候，刚刚大学毕业，准备在公司干一辈子。然而一个半月前，因他操作市场思路和原来的总经理不合拍，总经理要求他改，他以自己业绩不错为由拒绝，结果总经理大为恼怒，未经任何协商，第二天他来公司上班时，被明令告知，他被免职了。

　　我来到分公司任职的时候，正值分公司也换了主，按惯例，他本来是要被列入下岗名单的，考虑到他的业绩的确做得不错，分公司新班子决定让他继续回来做，但事经一个多月，他已找到了新东家。我通知他来公司办离职手续，最开始他的态度很强硬，要求公司至少补偿1.5万元，否则上劳动局告。他说，我们都是打工者，公司不要他做，完全可以诚恳地和他沟通，他不会赖着不走，也不会非要什么赔偿。然而，令他没想到的是，他在公司做了三年多，一直很努力，一心一意想做好业务，从来没想过要离开公司，可是，仅仅因为操作市场的思路与领导分歧，领导不经任何商量就把他从事实上开除了。这是他做梦也没想到的，他觉得好惨，好伤心。最后他说：“我将自己最宝贵的青春献给了公司。我爱公司，公司却不爱我。”不知何故，他一说完这话，我就心潮起伏，被深深感动了。

　　是啊，我们都是打工者，即便是我现在坐在主管人力资源的位置上，我能保证自己绝无可能有一天会有他今天的遭遇吗？我想，我们谁也无法保证。我们都曾怀过美好的理想，想为公司服务一辈子，可是，理想归理想，理想再好，也难免有分手的时候。好比两个人谈恋爱，最开始因为共同的利益走到一块，彼此同甘共苦，有一天，其中一个人飞黄腾达了，或碰到更心仪的了，或因为其他什么原因，突然不声不响把对方一脚给蹬了，这种分手方式的确让人难受，会让人悲痛欲绝。

　　虽然如此，我仍只能站到公司的角度推心置腹地对他说，如果他真告公司，肯定是他不合算。因为从法律的角度，公司并没有要他下岗，只是免职，而且现在要他上班，真要打官司，输的会是他。即使他侥幸赢了，拿到一点赔偿，对他也未必是好事，因为哪一家公司会对一个以前告过自己东家的人有好感呢？我建议他与公司协商解除劳动合同。不知是我的诚恳打动了他，还是他想到了打官司没有赢的把握，最后接受了我的建议。我长长吁了口气。

　　联想的一个员工曾写了篇《公司不是家》的文章，披露联想处理下岗员工的方式，在网上引起了强大的反响。这篇文章我曾经也读过，感受不是很强烈，如今面对这些不得不来办离职手续的同事，我强烈地感受到，公司真的不是家。我觉得，不光是我所在的公司，而且包括几乎所有国内的企业，对待“分手”的员工，都有点自私和残酷。大家只想着如何维护自己的利益，甚少想对方的利益，我虽然主管行政和人力资源，对这些离职员工提出的本来正当的要求，却无能为力。

最近心态不是很好，外婆去世了，妈妈非常的伤心，我是很痛心；年底工作事情一堆堆；租的房子要涨价，要重新找房子，还要重新搬家；老天爷让事情都一块来了，也许是想考验我心里承受压力的能力，伤心、疲惫、操心全来了，我就统统的一起享用吧。与这些事情相比，还是有些值得开心的事情，工作表现优秀，公司给予奖励和表扬；顺利的参加了中国的第一届中国质量年会，很高兴中国的测试也有了属于自己的盛会； 11 月 23 日 ，做测试就 3 年了，是个值得纪念的日子。嘿嘿，写到这，有些文不对题了。本来是想把这篇文章命名为“这是谁的错？”后来觉的不太合适，就选择了这个题目 --- 测试管理之责任。

写这篇文章的来由是：一个我的大学同学开始做测试管理工作了，开始带徒弟了，在管理上出现了一些问题，想知道我是怎么处理的，我觉的很有必要记录和大家分享，因此就写了。

我思考整理了一下我这个同学遇见的问题：

1.         多次沟通，开发人员不承认 BUG

2.         开发组不会修改 BUG

3.         测试人员发现 BUG 非常少，工作效率低

我是这样回答她的：

问题一：多次沟通，开发人员不承认 BUG

对策：在测试环境再现 BUG ，把问题统计、记录成文档，直接书面提交领导，面对面的和领导以及开发负责人沟通，解决还是不解决，要解决，什么时候解决，说清楚，不解决，发布了，不要说是测试的不负责任，没有报告， 不要到了后面不认账。

问题二：开发组不会修改 BUG

对策 1 ：帮助开发人员分析查找 BUG 出现的根本原因，找到后，共同协商想办法解决；这一方法只对开发和测试人员能有效沟通，测试人员能力和开发人员能力相当的情况才适用。

对策 2 ：通过网络资源寻找解决办法；再不行就把问题反馈给上一级领导或其它同事，共同寻求解决办法。

问题三：测试人员发现 BUG 非常少，工作效率低

对策：测试负责人应分析测试人员发现 BUG 少，工作效率低的原因，而不是指责测试人员，造成沟通上的不愉快；更不是测试负责人把测试任务一分，测试文档模板给了、测试文档编写例子给了、所测试的软件业务也讲解了就行了；这样就去埋怨测试新人发现这么少 BUG ；更不是期望测试新人按照参考给的例子照葫芦画瓢就行。

在这第三个问题里，让我思考很多：

面对测试管理上出现的问题，测试负责人第一时间应该更多的是问问自己：我哪个地方做错了呢？为什么会出现这样的现象呢？而不是第一时间去指责当事人和向她们发火，这是不协调的管理行为。

每个人都是从公司的新人走向老员工，都是从一个应届毕业生走向一个社会。测试新人，她们需要正确的指导。

Ø         在分配任务之前，作为师傅，首先应该了解自己带的徒弟能做什么、适合做什么、有哪些测试特长；做到恰当的分配工作。

Ø         在工作分配时，还要让徒弟能明白你让她做什么，要的东西是什么，她是否能真正明白；做到有效的沟通。

Ø         在工作过程中，多提醒徒弟，碰到问题，先思考，想出自己的方法或想不出方法都要积极的问师傅，师傅再回答问题的过程中，要引导徒弟的思维方式，培养她独立思考、解决问题的方法和思路。

Ø         在工作过程中，要时常检查、关心徒弟工作的情况，发现问题，及时进行指正，这样可以避免能否顺利完成工作的风险。

Ø         刚毕业的学生思维单纯、要教会她们为人处事，要教会她们怎么去学习，没有了师傅，自己怎么能更好的生存。

我做测试新人的时候，在领导面前，被指责得哭过一回，我至今仍然记得；我很辛苦、很认真的工作、但由于没有和领导有效的沟通，以至文档写的不好，影响产品评审。也就是在没有好师傅指导的环境里工作了两年，经历了很多事情，让我明白了好师傅应该怎么做，做一个好师傅有多么的困难。

我也知道，作为新人，面对恶劣的社会竞争，要学会生存，工作上不但要认真、要努力、而且还要积极的发问；环境很重要，人本身的心态和责任心更重要。

做测试管理，对待这个工作的态度很重要；责任心更更重要！！！！！！！！！！

作者：崔启亮
原文URL地址：http://www.51testing.com/html/68/1076.html
URL 地址： http://www.testage.net/bbs/dispbbs.asp?boardid=23&id=3197&star=1#30792
很想找写这篇文章的作者，想认识这位测试同行。

    软件项目开发是个分工明确的系统工程，不同的人员扮演了不同的角色，包括部门经理、产品经理、项目经理、系统分析师、程序员、测试工程师、质量保证人员等。可见，软件测试工程师只是软件项目开发中的一个角色而已。
    戏剧舞台上的生、旦、丑是不同的角色，其表演方式具有明显的特征，这是由于角色决定的。同样，软件测试工程师的角色，在软件项目开发中也存在如何定位和表现自身的行为和责任的问题。
    此处讨论测试工程师的角色并非毫无意义。须知，角色不明，责任不清，行为就失去了参照目标，结果就可能很不理想了。轻则降低了工作质量和效率，重则被视为工作能力低下，可能要退出软件项目组的舞台了。

1、   软件测试工程师承担的任务
角色决定工作内容和承担的任务。测试工程师的角色应该承担什么任务呢？

这没有统一的答案。因为，这与软件公司的规模，软件项目管理制度，公司领导和项目经理的管理风格，以及具体软件项目自身的特点有很大关系。而且，测试工程师也有普通和高级之分。
    笼统的答案列举如下：
   1 ）设置软件测试环境，安装必要的软件工具。
   2 ）运行软件，发现和报告软件缺陷或错误。尤其需要快速定位软件中的严重的错误。
   3 ）对软件整体质量提出评估
   4 ）确认软件达到某种具体标准
   5 ）以最低的成本，最短的时间，完成高质量的测试任务
    ......
    在这其中，最重要的是要明确，程序员的责任和目标。在执行任何具体测试任务前，都要在项目组内对于责任和目标达成共识，以免带来后续工作的相互推诿。

2、   提高测试质量的要诀
另外一个值得注意的方面就是工作效率和质量，或许高级测试工程师与普通测试工程师的主要区别在

于高级测试工程师可以更快地发现更多软件中的严重错误。对此，有什么可以借鉴的诀窍吗？请尝试以下方法，保证不会是您失望。
    1 ）首先测试程序的核心功能，然后测试辅助功能。
    2 ）首先测试功能，然后测试性能。
    3 ）首先测试常见情况，然后测试异常情况。
    4 ）首先测试经过变更的部分，然后测试没有变更的部分。
    5 ）首先测试影响大的问题，然后测试影响小的问题。
    6 ）首先测试必须测试的部分，然后测试可选或没有要求测试的部分

3、   软件测试工程师是项目团队中的服务员
需要强调的一点是，无论你是多么高级的测试工程师，都要明白无论测试需要的工具多么复杂，测试

步骤多么冗长，测试工程师在软件项目开发中始终都是扮演服务员的角色，这是由测试工作的特点决定的。任何服务都有被服务对象 — 客户，软件测试工程师的服务对象有哪些呢？
    1 ）最重要的客户是软件的用户。测试工程师需要站在客户的使用和需求角度测试软件，报告问题。
    2 ）项目经理也是客户。测试工程师需要报告测试工作进度和发现的问题，尤其是严重的问题。
    3 ）程序员是最经常打交道的客户。为了便于程序员重复报告的错误，尽量提供良好的软件问题报告，

以便程序员可以更快的修复软件错误。
   4 ）技术文档工程师、市场开发人员和技术支持工程师也都是测试工程师的服务对象。

4、   软件测试工程师避免犯的几个错误
前文已经指出测试工程师应该明确角色，明确任务和责任。知道哪些是自己份内的事，哪些是不属

于自己的事。一定要尽最大努力完成份内的事，不要做不属于自己的事情，以免弄巧成拙。为了更好的扮演软件测试工程师的角色，尽量避免犯下面的错误：
      1 ）承诺完成测试的软件没有质量问题。
      2 ）软件测试只是保证质量的一种方法，软件测试工程师的工作不会直接提高软件质量，因为绝大多数  

软件错误都需要程序员修复。软件测试只能证明软件存在错误，不能保证软件没有错误，不可能找

出全部软件错误。个人的能力和对质量的影响范围很小，软件质量的提高要靠软件项目团队全体成

员的共同努力。 　
3）   承担软件的发布权利

不要因为软件中存在还没有修复的错误，而试图提出更改软件发布的计划。也不要认为已经完成了

测试计划，自己决定可以发布软件。因为，改变软件发布计划可能要失去进入市场的良机和很多客户，对此造成的经济和公司市场的损失将不是测试工程师能够承担的。另外，软件发布后，如果用户发现了新的软件错误，公司领导或项目经理可能将过错加在软件测试人员的头上，因为他们同意发布软件。通常软件发布的权利由产品经理、项目经理、测试经理、市场经理共同集体讨论决定。 　

4 ）扮演过程改进成员的角色
软件测试工程师必须报告错误，有时也要分析错误的类型、特征和产生错误的原因。但是，不要主动提出改进软件过程的具体改进措施，更不要直接干涉程序员的工作方式，以免出力不讨好，影响今后的愉快合作。软件过程改进的方法是软件质量控制部门的事情，这是他们的本职工作。

编写背景：

    所租的房子到期了，又要开始搬家咯，在整理书和笔记的时候，发现自己曾经写过的一些测试工作感想，突然觉的该记录一下，因此就放到 BLOG 里了，还起了个特别的名字“软件的食物链”。

一个软件研发公司通常有这么几个部门组成：

研发部门、测试或质量部门、技术支持部门、销售部门、行政或人事部门，其中我把研发、测试或质量、技术支持、销售这几个部门的关系用食物链来理解和描述。一个公司，从内部来看，投入合适的开发和测试成本，就会节约技术支持的成本，促进销售。具体表现在：软件的开发和测试投入高成本获得高质量的软件后，技术支持人员将会有更多的时间去做售前支持工作而不是售后支持维护工作；销售人员用高质量的软件能够更好的去向客户销售以及发掘新产品的需求。从外部看，软件的销售情况由市场决定、由客户类型决定。在南方，生意人都说“要做有钱人的生意”。

目前，在中国做测试，会碰到如下现象：

1 、测试人员没有办法了解所测系统的用户需求。

具体表现：没有用户需求文档；测试人员不需要了解也没有权力知道用户需求。

2 、测试人员在项目组中工作职责和内容不明确。

具体表现：测试人员要记录整理需求变更，进行新需求确认，培训用户，系统维护支持，培训文档、维护手册的编写，测试的执行以及问题的跟踪，测试文档的编写。

3 、测试人员要在短时间内测试改动很大的软件，同时软件更新很频繁。

具体表现：版本更新频繁，需求变更管理不友好。程序发生了变化，测试人员是看到所测试的软件才知道发生了什么变化。由于时间短，人力资源短，测试很难做到更深一层和更完善。

4 、测试人员和开发人员的沟通有效问题。

这让我想起华为一位测试工程师所说的，测试和开发就像两个部队在打仗，谁都有胜负的时候，互相都在提高各自的战斗能力，刚开始做测试的第一年我很能理解这个比喻。测试做了两年后，突然感觉是开发人员开发出来的软件是病人，测试人员是医生。医生不能头痛医头脚痛医脚，要治本，但是那会花很多钱。在中国的 IT 公司做软件测试，测试所花费的成本怎样才算是正确有效的，这是没有一个固定的定律，因为影响的因素太多。

5 、测试吃力不讨好。

在客户那里，当用户使用软件感觉很好时，它们会说:"嗯，这个公司的开发技术不错，做的很好啊。"从来不会想到里面会渗有测试人员的工作！当用户使用软件感觉不好时，它们会说：“这是什么东西啊，一点都不好用，一用就出问题，你们试用、测试过么？”。唉，我做过现场给用户技术支持，因此很能感受到，程序出现问题后的辛苦，就像救火队员救火一样。碰上没有责任心的开发搭档，那更惨，测试这边着急上火，开发那边不紧不慢，甚至是推卸工作，什么这不是我的问题，那不是我的问题。也许时间长了，习惯了，产生免疫力了，测试也就不会在着急上火，就顺其自然了。测试人员、开发人员的工作态度、责任心是保证产品质量的关键因素之一。

写着写着，又有些偏离主题了，就这样吧，这才是我真实的记录。

                  一个测试部负责人给总经理的一封信
**总：

本来很想面对面地与您聊一下测试部成立以来遇到的一些问题、现状、还有未来的发展，我怕一谈到我们的测试部，我可能就会有情绪。因为我对测试部投入了一腔热血，也付出了我全部的精力，但目前的测试部将要走的走，离的离，如果全部走了，留下来“服役”最长的也超过不了一年，我面对现状，倍感凄楚！不仅仅是一个***的离职让我有此感慨，是这种现象逼得我不得不去反思。测试部为什么留不住人？我为测试部做了些什么？测试部要不要留住人？为什么要？如果需要留住人，我们该如何去做？与其他公司比我们的测试哪些做得好，而哪些又有不足，是什么原因导致的？今后的测试部该走向何方？

A：测试部为什么留不住人？
1、 对测试了解的人较少。目前国内相关人士有95％以上的人对测试这个行业还处理不了解的状态（包括当初我自已），这种不了解表现在“测试人员技术素质低、测试比开发要低一个档次、测试只是东点点、西碰碰的活……”，但现实又何尝不是如此？！我不得不承认目前国内的情况与此相差无几。网上的BBS还有一些热血青年在高喊“我们要翻身做主人，我们要与开发平起平座！”的论调，我看过心想：要实现这种想法，还必须要有漫长的路要走。首先是观念的改变，公司全体都要有充分的认识。从人员的任用标准，开发、测试的投入比例开始考虑；再者就是测试从业人员自身专业素养，必须要掌握世界先进的测试管理工具及自动化测试工具。只有这样，才能与之平起平座。

2、 测试部工作负荷较重。现在我们公司存在***123、***Pro、***Net等版本，还区分简繁体、中英文，***Pro一直以来都在不断地加新功能，不断地反复测试，加上还要写手册，支援一些培训任务、制作演示数据。

3、 薪资待遇问题。目前的薪资制度很难找到或留住优秀人才，一般从没经验到测试部，一年学成后不管调到那一个部门，或者另找工作，待遇可能都比呆在测试部要好，这种情况大多数人都愿意离开。

4、 学习机会。当初进来对BKD可能有新鲜感，但一年后，对大部分功能都会比较熟悉，对个人而言就没有更多的激情。

5、 大环境因素。远在北仑，想学点东西还真有点困难。

B：测试部要不要留住人？为什么要？
1、 我们的软件发布之后存在一些无法预知的BUG，不能说全是测试部的责任，但有的责任却不可以推辞。有时看到客户反映的一些问题，很想冲着测试负责人指责一顿，但静下来想，他才来几个月这种深层次的问题叫他如何能找出来。心想，如果是老员工去负责可能就不会存在此问题了。

2、 老员工的存在能够凭着自已的经验去带领新人成长，并能抽出身来研究新的测试方法及技术，对测试部的实力的提高有帮助，实际上就是产品质量保证的重要条件。

3、 一个部门都是新秀，无法建立起组织层次，让谁去做小组负责人，其他人都不会服。

C：如果需要留住人，我们该如何去做？
1、 我自已要加强新知识的吸纳、传授，人员的管理；
2、 减少工作负荷。
3、 力所能及的提供一些培训机会。
4、 在薪资制度，或者人员异动制度有所改善。

D：我为测试部做了些什么？
1、 说句心里话做测试也是我当初无奈地一种选择（当初的无奈也是我对测试不了解的一中表现），但我负责了测试之后，在各个方面存在很多不足，但一心一意、尽心尽力地想把他做好。不断地从网上、书本学习软件测试方法，与网友交流，也了解了许多自动化测试工具。现在测试部所有的成员都能够对测试有个很清楚的认识。
2、 培训了多名实施顾问及服务人员。
3、 2000年是我起步的一年，2001年是我技术成长的一年，2002年是我管理进步的一年。

E：与其他公司比我们的测试哪些做得好，而哪些又有不足，是什么原因导致的？
1、 黑盒测试做得较好，对商业逻辑的理解能力强。
2、 人员的凝聚力强，都敢于担当重任。
3、 对白盒测试未曾涉及。
4、 对自动化测试只停留在探索阶段。
5、 测试用例做得不太好。
6、 没有全面掌握、使用各种测试方法。
7、 对微软提供功能，而我们软件又会使用到该功能的知识了解的少。

F：今后的测试部该走向何方？
1、 测试部为纯技术部门，所有的商业逻辑等知识只要能看懂文档即可，商业逻辑是否正确应该在需求阶段就应该定义下来，而不是靠测试部来发现，因为改需求的成本极高。
2、 从黑盒向黑盒加白盒，再转向白盒方向，这就要求所有的测试人员必须掌据源代码读写的能力。
3、 一部分人必须掌握自动化测试的技术，以便提高工作效率。


可能占用了您的很多时间，但事关到测试部的未来，我不想看一个架构完善的开发部旁边是一个弱不禁风的测试部，这样的开发处的效能也会大打折扣，我们产品的质量也会受影响，我不认为产品质量是测试部测出来的，但测试也是保证质量的手段之一。
唠叨至此！

1、不重视测试，产品质量有问题，卖不出去，或者大量退货，或者大量的售后服务，导致成本上升，企业效益下降或亏损，卖得越多损失越大

2、企业信誉和品牌受损，产品更加卖不出去，更加严重的效益下降和亏损

3、公司现金流脱节，离关门也就没几天了

     公司测试管理、我的测试职业人生道路，我在这两点进行思考和分析着！

   我所在的部门是技术支持部，从事的工作是：测试。
   今天是部门的新领导就测试工作开的第一次小会议。今天开的这个会议很是郁闷很是难受。
首先，会议的目的不明确，开一个没有目的的会议对于我来说是在浪费工作时间，让我很不开心。
因为最 近好忙，浪费了工作时间，就相当于我要加班补充回来这些时间。

其次，在会议上关于面对测试任务，怎么工作，我不是很认同，然而我又不能在会议上说服他。
因为从主观判断，既然是在会议上说了，那么意思就是定了的。如果开会前和我沟通，我还有说话的机会，还有机会提意见。这也说明了一点，他不想知道我这个人对测试工作的想法，而是重视我能不能按时完成任务。

最后，宣布了一个让我特别难受的消息，我一直跟着测试的一个任务，停了，当时我就像是一个开发人员在编写自己的程序，写到一半的时候，领导告诉我不用了。
心里好难过，然而旁边的同事却还很是高兴，我可以理解，我知道他是高兴工作任务减轻了。
而我好心痛。因为我和这个用户关系非常好，前期也是在那边做的现场测试。互相都建立了很好的信誉，在工作上都给了很好的配合，大家都做的很不错，一下子就这样停了，真是无脸面对他们。面对他们，我就是一个失去了信誉的测试工作者。这是我不想要的结果和现象，很后悔，很后悔，当初就不应该参与进去。

在最后，会议没有结束，我直接说没有意见，气冲冲的出了会议室。

我想我的怨气一部分原因来源于我：
   1、我不太看好一个不会管理测试、没有做过测试的领导来管理测试的工作。
   对于这点，我应该好好去观察一个不会管理测试、没有做过测试的领导怎么来管理测试工作，从中学习好的方法和手段。