其实我一般很少受到刺激的。

因为我care的东西真的很少。

我在ibm工作的时候，曾经因为项目的关系遇到一个测试很牛的人。是性能测试里面一个很牛的专家级别的人。

而且之所以说他牛，就是因为他一方面技术很牛，还是公司大中华测试圈子里唯一的性能测试金牌讲师，还是唯一一个敢对国内项目说不，只做国外项目的人。

也是北京上海测试项目出现问题，没有人搞定，才会出现偶尔救急得人。

技术上，我认识的了解的人中，无论经验比他多的还是少的，无人能出其右。

每次想到他，我都在想，这个毕业了不过7，8年的人，为什么跟我有这么大的差距，何以他在云端翘首，我在平地徘徊？

而最新的消息，就是这个牛了N久的家伙，技术移民澳洲了。

虽然不久之后，因为公事，我也会出现在他现在驻足的那片土地上。但是感觉真的受到了刺激。

或许自己已经很久都不知道努力了吧？

或许自己真得很久了都不曾真正的努力过吧？

所以想到这个人，觉得很惭愧。

加油，要成为这样的人。至少，提升现在的我。

路漫漫其修远兮，吾将上下而求索

这是一种执着的心理态度，有了这样的坚持和执着，很多东西才能成功。

这几日，给新毕业的公司同事做了几次培训，有了一些接触之后，他们开始向我诉说起他们现在的一些郁闷，让我不禁有感而发。

离开规范化的日企，欧美企业之后，我这一次选择了一个看起来很有前途的刚成立的小公司来做。刚成立，自然有着很多的不足，也体现在了方方面面。

这些职场新鲜人告诉我说，对他们来说，最郁闷的事情就是不知道该干什么，领导分配了好多任务让他们做，很多需要学习的东西，但是就他们个人而言，第一，不知道从何入手；第二，缺乏指导，做了不知道对与错。

我很了解这种感觉，虽然我的之前的工作单位都是正规的存在了几十年一百年之久的国际大企业。但是这样的感叹，我也曾经有过。

于是，我告诉他们，毕业之后，要变索求到主动去探求。可能很多人觉得这个经历没有必要。可能有人知道，马上就知道了事情，真的没有必要非要自己摸索得到一些结论。

让我想到了金蟾子不知道捻花一笑为何意，佛祖没有满足他的好奇告诉他原因而是让他苦行十世来求得解答的故事。

其实很像的道理。每个人都要养成良好的学习的心态。

当我们还是学生的时候，我们习惯去接受，接受书本的知识，接受老师的教授。我们习惯去索取，索取一些问题的答案。但是我们不习惯自己去寻找答案。。长期的习惯形成了我们只求结果不问过程的心态。

出了校门之后，没有人会手把手教你什么，更没有人会面对你的一个个问题，来给你解答。工作，人生的很多问题，必须自己学会思考，自己寻找答案，并且在寻找答案的过程中自我提高。

如果你真的有疑问，想找高人指点，首先要做到的，就是把自己能找到的资源耗尽，然后把抽象的迷茫幻化成一些直接的分类详细的问题来问，这样，才能使你的部分诉求得到满足。

我也这样分析给他们，这样说给他们听。看着他们，我突然意识到，毕业五年了，我还真是有点长大了。。或者说，沧桑了许多。

昨天，应老板的要求给刚毕业的大学生做了一个软件测试方面的基本培训。

回来后，想了很多。

那些大学生，是公司招来做开发的。

我该如何从测试与开发的角度来让他们有一个基本的整体的认识呢？

对于刚毕业的他们，我的人生经历，能给他们多少指导性的建议呢？

我个人的工作经验里面，觉得开发人员最欠缺，测试人员最需要的支持在哪里呢？

制作教程之前，除了必备的测试的基础知识之外，我反反复复在思量这些问题。

结合自己在日企，欧美企业的实际经验，讲一些生动的成功抑或失败例子给他们，以期有所启发。。

但是最后的效果，我觉得还是过于枯燥了。

回来后，反复看自己写的教程，还是不满意。

我该如何改进呢？

如何让自己的培训在能吸引人的同时，给他们不知不觉中打开一扇通往未来的门窗呢？

google,baidu一下，关于软件测试的误读，大家轻易的就会搜出一堆来。

但是这里，我要说的，是在我五年的软件测试经验里面，见识到的种种误读。

第一种：软件测试是用来测试程序员开发的产品满足功能要求

这一种，常常见于开发人员的认知。测试的理论中，我们会讲到异常测试和正常测试，实践过程当中，有很多测试人员会发现一些用异常类测试的bug,但是开发人员有的时候基于种种考虑，比如说终端用户是否会遇到，这种问题出现的几率，修改它可能会引起的其他模块的问题，以及开发人员的工作量的增加等等，不会很乐意去修改这样的bug.在很多通用的软件测试当中，测试的绝大部分也以为这样的环境都趋向于pass-to-pass测试。而这种缺少pass-to-fail的测试实践其实会引发很多潜在的问题和风险。

第二种，力求完美的测试人员，所有bug都能发现并且解决才能是成功的软件测试。

这一种，一般是刚入门的测试人员会有的想法。测试人员希望竭尽全力的发现软件所有的问题。但是实际上，我们知道，因为不能对软件进行穷举测试，而实际上无论是成本的考虑还是效率的分析，这种全面的覆盖也是不可能的。所以才会有，软件测试只能证明软件有错误而不能证明它没有错误这个论断。所以对于软件测试人员来说，要在有限的时间内，基于成本效率的综合分析，把测试的任务分轻重缓急，并且做好风险分析和风险控制，依据测试的计划，完成阶段性的测试，并且测试覆盖到应该覆盖的程度，检测出重要的软件缺陷，并且促使他们最终能得到解决的测试已经算是很有效的很成功的软件测试。

而且做一个接近完美的产品无论从成本考虑还是从企业的利益来考虑都是不可能的一件事情。某跨国公司曾经有过一句名言，就是100%满意的产品等于自杀。对于测试人员来说，我们的目标应该是追求完美但是不能苛求。尽到自己的责任就可以了。有些未发现的或者未解决的问题都将会在后续的版本中陆续的被解决，只要它们值得被修复。

第三种，开发人员拒绝了我的bug,是忽视我的劳动成果，不尊重我的表现。

这种往往反映在现实的测试生活中，开发人员和测试人员的很多矛盾也是因为这个而导致。毕竟，现实的生活中，开发人员的有效业绩是极少的bug检出率，而测试人员的业绩很大一部分来源于测试过程中挖掘出了多少有价值的bug.

实际当中，作为测试人员首先要树立的就是对事不对人的态度。不能因为种种原因和开发人员对抗。不团结的开发测试队伍没有办法很有效地做好沟通，自然就没有办法保证最后的质量。

然后要站在客户的角度上衡量自己被开发人员拒掉的bug的价值，可能给系统带来的风险级别，以及开发人员可能不修复的原因。如果觉得对其的修复非常必要，则应该更好地进行沟通的同时，取得更为有利的证据来证明自己的判断。而不是一味的吵架，僵持或者自我贬低。

第四种，测试人员应该保证产品的质量

这个问题，其实在以前的一个帖子里面我曾经写过。这里，摘抄一下当初的内容

看了很多同行的日志。

成就者有之，努力者有之，苦恼者有之，抱怨者亦有之。

很多人都在抱怨自己的测试工作没有头绪，比如说公司不重视测试，比如说测试系统的不熟悉而且没有人给他们相关的文档，比如说测试的不规范。。

我们在当初学习测试理论的时候，都会理所当然的把软件生命周期，测试生命周期看成一个有序的规范的流程。其实流程化工程化的软件管理和软件开发测试流程也正是软件工程的目标。既然说是目标，就是因为它跟理想其实还是有差距的。像我们的同行，包括我们自己在每个项目，每个公司遇到的测试环境一样。

大家都知道，测试介入越早越好，最好在立项之后，需求分析之初就介入到项目里面，跟着开发，需求的脚步，一点点排除阻碍，发现缺陷，保证“尽早测试”的顺利进行。但是实际上，我们这些人中，又能有多少真正的能从那个时候开始介入呢？不说有没有机会的问题，让你介入了，系统架构，需求定义，开发的研讨，代码的走查。。这些环节你都懂吗？能从系统的高度给出多少有价值的建议和意见呢？

来自外企的同行，会有着跟我一样的抱怨，对于测试的流程的了解虽然是优点，但是我们没有全程参与的机会。大家基本就是依照流程在进行测试执行，没有人有机会去触摸需求以及更深层的东西。来自国内企业的同行，会抱怨测试的流程不规范，测试中只是开发人员的附属，打杂的，什么都要干，什么都懵懵懂懂。。

这其实就是中国软件目前发展的现状。其实你看招聘信息就能看得很清楚。但凡外企招聘，外语是第一要求，然后就是测试经验，对于测试流程的熟悉和把握，测试工具，然后才是测试的其他技能比如说coding,db,protocol这些东西。而有些没有这些要求。但凡国内企业的招聘，基本没有外语的要求，主要的是测试的coding,db,protocol这些东西，然后是测试的经验，流程，工具，方方面面，不要一个神人誓不罢休。

等你信心满满的进入企业，你会发现理想和现实的差距居然如此之大。其实很正常。用看人的态度看待工作，一样有效。人无完人，工作也一样，不可能方方面面都能符合你的胃口。

对于现实中进行测试的我们，面对复杂的抑或烦乱的测试环境，能做的其实只有一点，尽我所能得去履行我的职责。

比如说，没有需求文档，我们可以把测试软件当成需求文档，尽快地去熟悉它的功能，然后自己寻找它的workflow,把握数据流向，然后，需要做的是，不要盲目的进行分析和用例设计。一定要把你了解东西跟开发和需求去确认。因为一旦你理解的方向偏了，你的努力将功亏一篑。确认之后，再进行测试用例的设计以及进一步的执行。

比如说你对业务不熟悉，公司也不重视，很苦恼。。我觉得首先，你要检讨自身。为什么对业务不熟悉，有没有努力的去研究？虽然说人不可能一开始什么都懂。但是基于成本和效率的考虑，很多公司还是不会贸然把测试的重头戏放手给不懂得业务，不懂得规范测试的测试人员的。这一点，建议就是，一定要把公司的被测产品学明白。从产品测试的角度来看，它的具体功能，它的业务逻辑，它的数据流..不知道的，自己摸索，摸索不明白的，就去问开发和需求的。（不能打扰人家的工作时间，否则没有人愿意给你好好回答。多交一两个开发的朋友，茶前饭后的偶尔问问，大家应该乐意告诉你），然后利用你学习的测试方法，用开发人员不可能想到的测试策略来进行测试。如果有一天，你发现了很严重的问题，如果有一天，你的这种举动和测试的成果，对于开发，对于进程，对于产品的质量提高起到的作用越来越大了。你们的地位，作用，随之就大了。
说句通俗的话，自己的地位是自己建立的，所以做事情之前不要攀比，不要盲目抱怨，首先要想的是，怎样解决现在的问题，打破这种僵局，让他们重视你。不是吗？

比如说开发的周期很长，但是给你测试的时间很短。怎么办？那你就在等待测试的时间，琢磨你的测试软件。想办法了解测试软件的功能，掌握它的架构，然后运用你学到的东西，来分析我应该怎么入手测试，如何才更为有效？有人说，我没办法了解，没有机会。那么，只能说，你不善于跟开发的打交道。做测试，一定要善于跟开发人员打交道，而且要交几个开发的朋友，大家一起工作，相互了解，经常沟通才能把彼此的工作做得更好。你可以跟开发的人员要些资料，可以问问他们开发的进度，可以到开发的环境下去了解一下测试软件的面貌，可以问问开发人员哪些模块比较复杂（便于你测试的时候重点关注），哪些模块比较重要（如果你却是无从所知）。。经过前期的准备，当任务到手的时候，你自然就知道轻重缓急，可以有的放矢的进行测试了。

一路走下来，你就会知道，无论遇到怎样的情况，运用你的经验，技巧，沟通能力，都可以坦然地做好自己的工作。

发现自己不足的地方，要及时地学习，补充。发现自己跟开发很难沟通，听不懂他们说话，那么多沟通，没事多学点，总会好的~~

测试是一门艺术，一门学问。需要你具备的能力很多，对你的要求也很高。你有什么样的水平，就能站到什么样的高度，指点江山。。

本文出自tengmy的51Testing软件测试博客：http://www.51testing.com/?47068

版权声明：51Testing软件测试网原创作品，转载请保留链接，标明本文原始出处、作者信息和本声明，否则将追究法律责任。

最近因为辞职的关系，有了很多的闲暇时间。优哉游哉的闲云野鹤般的生活，让还在项目组里面苦恼奋斗的同事大为羡慕。我乐了，说，如果你愿意，今天提出辞职，明天我们俩就可以一道逛街了。她说，那不行。呵呵~~这就是现实的人生吧。

其实我能从原来的工作单位离开，也是很多客观和主观的因素构成。比如说欧美项目之前的摇摇欲坠，让项目里面的人岌岌可危，每个人都有点丑态毕露的样子，让我看了实在难受;比如说善于鱼肉员工的老板又打算从我身上压榨出些本来属于我的东西。。思前想后，决定离开，退一步海阔天空，忙碌而无序，因为很多原因不再有激情的工作让我厌烦。我觉得已经到了要收拾自己思想，学点什么的时候了。而且，经济危机，也是一个难得休息良机，不是吗？

这一段休息的日子，偶尔会有电话面试做为点缀。无奈，到2009年7月16日的今天，从工作的意义上讲，还没有真正的收获。从自我的角度上讲，算是小有乐趣了。从离职之前到现在，很有幸，每次看好的企业相邀面试，都很慷慨的报销了我的路费（一般都是飞机票），让我在面试之余可以欣赏一下祖国的大好河山，拜访一下久违了的在当地工作的朋友们，人生，对我个人来说，有多了一种体验和味道。

没有面试的日子，自我研发的小菜颇受好评，一向认为自己的厨艺天下无敌的姐姐，也不得不赞叹，这点让我足以笑到梦醒。偶尔难以相信，这还是当初那个煮面都能煮糊的我吗？呵呵~~

最多的时光，基本都用在了网络上，学习以前带队时老板要求但是总也弄不明白的excle报表设计，学一些已经逐渐生疏的数据库，java编程，了解一些用人单位要求must的东西（虽然我不一定去应征）..总体感觉，进步虽然不多，但是小有所获。对于未来的日子，值得期待。

最近在打造我自己测试论坛。目前处于初级构建发展阶段，希望在以后的日子里面，能更加丰富。

危机是灰暗的，总有一些踩错点的人，但是希望就在前方，不是吗？

我始终相信，人生，只要你寻找，就不缺乏方向，只要你努力，就不会不成功~~

我始终相信，乐观的看待人生，人生就会给你一个乐观的生活~~

4月末，因为有事，去了一趟天津，几天没有上网。

回来后，登陆我有空每日必去的51testing,便发现了多了一个板块，51testing五周年。。不觉间，它已经五岁了。呵呵~~，祝贺，祝贺~~

是啊，我也已经毕业马上五年了，人生，真是短暂不是？

记得，认识51testing的时候，是在05年，那个时候，我刚刚踏入软件测试这个行业没有多久，对于软件测试的一切，都懵懂无知。。

那个时候，它还叫做“无优测试”，我常常在登陆51job的时候想到它，曾经一度以为他们属于同一个公司呢：）

其实一直以来都很感谢51testing,也感谢其他的相关板块，比如testage,csdn.testcn，itbub,17test等等这些论坛，因为有网络的存在

因为有这些能够给我在测试道路上前行指路的明灯，我才一步步地走到了今天，平实而自信的相信着自己的明天，依然会为它而不懈的奋斗！

对日测试的日子很忙碌，更加可恨的是与世隔绝，我们公司内部没有也不允许使用外网，周末也常常加班，所以那个时候，登陆这些论坛的时间

很少很少，偶尔总是忘记了密码，导致很长一段时间都无法登陆。

51testing,就是如此。不记得什么时候开始，我就想不起来自己的登陆密码了。已经多方查找，终于想起了自己的注册邮箱：）不过，使用51testing密码寻回功能，居然也没有找回我的密码，原因是，系统会告诉你，把密码发到了你的注册邮箱，让我去收取，但是我总是收不到那封

我最应该收到的信。为此也惆怅过很久。。很久之后，我更换了常去的测试论坛，由51testing换到了testage,随着时间和经历的不断累积，也最终

由一个知识的索取者，变成了一个提供者和分享者，我也成为了那个论坛的几个板块的斑竹，偶尔发发帖子，帮新人的根据自己的经验，指点一二，日子也觉得乐趣无限。

然后陆续我又流连于testcn,csdn,并且在csdn发表了自己的《由国内项目的软件测试流程感悟到的》以及若干小文，不经意间，发现了它被转载到了

51testing的精品文章区。或许也是因为这样，我再一次有了寻找回51testing密码的冲动。

好在，我常常使用的密码摆脱不了若干组合，终于有一次试验成功了。于是，我重新回归了51testing的生活。

然后，我在这里，也申请成为了斑竹，虽然因为同样忙碌的工作，不太发帖子，但是偶尔也会书写一二，更多的时间，都在各区转悠，偶尔能回答一两个问题，感觉甚慰。

随着时间的不断流转，这里成为了我只要有空，一定会来的地方。

也希望在以后日子里，它能不断的走好属于自己的路。

PS:我还想有朝一日，在我所在的城市，开设一个类似于51的培训中心。只为软件测试的同仁们提高自己。而不是那些打着培训的旗号，骗取钱财，实际上连教授者都不知道软件测试为何物的培训中心。

呵呵~~我在努力中期待，希望有一天，梦想成真~~

当然，如果51可以在这里发芽，我定会助绵薄之力哦~~

51Testing软件测试网：http://www.51testing.com

08-09年哪一个词最为流行？

抄底！

从巴菲特言之凿凿的说抄底全球股市，中国股市，到中国的企业包团云游四国，去抄底国外的房子，企业。。

到。。华尔街“抄底人才”。。抄底已经变得有点可笑了。

在经济危机的时刻，国内也有太多的企业也在酝酿着人才的超底，想以很低廉的价格，搜罗到更多有才学的人，难免有趁火打劫之嫌。

近期，看到很多人力资源，猎头的言论也在说，这个时期对于人才招聘来说，最好的事情，莫过于可以用很低的成本去招揽那些高素质的人才。。。云云。
不过，股市，楼市如果真的有底可抄，那也是因为那东西是死的。但是，人，是活的，也是有感觉，有情绪，有想法的。

如果因为经济危机，某些人被抄底了，他心里面不晓得吗？不知道自己的价值应该几何吗？这样的危机下，为了生计，勉强被招揽，过了危机，如果是你，你不会跑吗？谁愿意呆在一个恶意压榨劳动力的公司里面卖命。。

这样的企业，也应该三思而后行。。

我觉得真正的企业家，还是需要把眼光放的长远一点，对于人才有着长远的规划，人才，是企业活的资源，发展的动力。没有见过耍心计，挖空心思从员工身上省成本的企业能做大作强的。

本周看到这样一个问题：  当前问题:在进度较紧、资源也不是十分充足的情况下，如何开展测试工作?

其实这个问题在每一个公司，每一个项目中几乎都能遇到，算不得一个很大的问题。而每个公司处理起来的方式都会遵循一般的原则，当然也要看每个公司以及客户的利益取向问题。

如果进度比较紧张，资源也不充足，这样的测试工作如何开展呢？

首先，无论怎么紧张，你都需要抽出时间来了解你的项目，你的测试系统的测试需求，你只有对测试需求把握住了，对于测试系统的功能以及相关的东西作了一个了解，才能走下一步。

当然，也有很多的项目，明明在进度紧张，资源不足的情况下，却没有什么需求或者需求陈旧，含糊不清，这就需要在可控的情况下，对于需求的了解做更多地了解。

此外，还有，对于测试实施环境的确认，对于开发进度的了解，对于测试需求可能变更的把握。这些看起来跟测试无关，但是往往会成为测试中最严重的问题。尤其是测试进度比较紧张，测试资源不足的情况下，缺乏对这些东西的把握，往往会功亏一篑。。

在这个阶段，最好能清晰的作出系统功能的体系框架出来，比如，数据和业务流程图。作为一个测试执行人员，都只有铁路警察，只管一段的本领，都不晓得数据从哪里进入，到哪里去了。。这个测试严格意义上来说，是不成功的。

自己根据对需求的了解，了解了业务结构和数据流向之后，需要跟需求方，开发方进行确认，除非真的没有必要，否则这一点是必需的，因为一旦测试人员对于业务的理解是错误的，将导致整个测试工作的偏离。

其次，得到确认之后，就是要分析这些功能，哪些功能是客户比较关注的，哪些功能是最容易出现问题的，哪些功能是系统比较常用的等等，然后把这些功能按照轻重缓急分列出来。做成check list.

之后的事情，就是进行测试设计和执行以及bug的管理阶段。这一阶段需要测试人员量力而为，但是无论面对什么样的测试环境，都不能因为其他的原因而干扰了对于测试的全程把握和监控以及测试的执行，也不能因为时间紧，就放弃对测试用例的设计，否则，测试到最后，覆盖率如何，测试的深浅度以及测试功能等等都无据可查，而且也会越忙越乱，最后测试结果也是一团糟。

另外要说的是，要随时对测试进度进行监控而且对于已知的风险进行分析，有必要的话，需要和客户方，开发方对于风险以及测试质量进行随时的沟通，大家一起努力，在有限的资源，有限的时间情况下，把测试做到最好。

一转眼，春天又来到了这个靠海的城市。走到海边，发现人也渐渐多了起来，林地里的花也盛开了。又是一个明媚的春季。

是啊，春天是播种的季节，无论遇到了怎样的年景，我们亲爱的农民兄弟们总要进行播种的，因为他们知道，没有播种，就绝对没有收获。

对我来说，何尝不是如此？

其实说起来，倒是应该很感谢这场在无形中继续蔓延的经济危机。它倒是给了我一个很好的契机来了解自己，来再一次让我有时间翻腾一下放在故纸堆的东西。温故而知新，有收获才不会觉得空虚。

php,linux,shell,apache，软件工程以及就要被自己遗忘的日语。。这些在实际中用过却一知半解，一直想有个机会系统学习一下的。这次也总算找到了一个不错的机会。雄关漫道真如铁，而今迈步从头越。。

测试之路，漫漫而修其远兮，吾将上下而求索。

昨天是植树节。很久没有时间来思考这个节日了。

开心上我附言，给自己一点时间，在09年的春季，也种上一棵树，播种我09年的新的希望。

是的。人的一生中可能会遇到各种各样的困难。有天灾，有人祸。不可能期许一辈子平安，虽然对别人的祝福，我们都希望如此。可是对于自己的人生来说，多了一点波折，其实走过去才会觉得有味道。否则，人生如白驹过隙，居然没有什么事情能留下痕迹，岂不是可惜。

困难是一所不错的学校。我一直就这么觉得。或许是因为自己比较直率的性格，在很多时候比较容易得罪人。所以从上学到现在总是会有各种不断的或大或小的难题在等着我。好在我除了直率之外，还比较乐观，我很喜欢各种各样的挑战，也深信自己可以像仙人掌一样，插哪儿都能活，而且活得很好。也幸运的遇到了一些情趣相投的朋友，一起相伴长大，如今虽然分布在天涯海角，却如相隔咫尺，时时牵挂。人生得友如此，也算不枉此生！

经济危机来到了中国，2008年我在平安中度过，本来以为与之无缘了。现在看来，它还是眷顾了我。或许我应该觉得有点颓丧，因为这场经济危机，还不知道什么时候是个头。或许我也将要体验失业的日子了。

但是，我依然相信，风雨终会过去，阳光总会到来。在这个经济的冬天，能有一个机会可以调整一下自己的状态，找一找自己的短板，并且将之提高，也是不错的选择。

未来，谁也不知道会发生什么，只是我知道。我的明天一定比今天更加灿烂。因为，我相信我自己的脑袋，也相信自己的努力。。

加油吧。。

和我一起处在危机中的兄弟姐妹~~让我们在努力中期待明天！

---谨以拙文献给面临危机和已经处在危机中的xdjm

2008年开始到现在的经济危机，没有人知道它会蔓延多久。太多的人成为了这次经济危机下的弱者，时刻面临着降薪和失业的危险。

面对这样的危急，你该怎么办呢？

每个人都有不同的境遇，所以做法也不会相同。

对于每一个漂在外面的人来说，在这场经济大潮中，太多的人比较可悲的不得不再次涌入到求职大军中，希望能找到一个能让自己在这个城市安身立命的工作，安度目前的危机。

当你走出来找寻工作的时候，你发现，你和一颗白菜的价钱已经差不了多少。趁火打劫的企业不再少数。他们拼命的压低工资，提高要求，希望在这场经济下，能够以土豆的价钱，挖到一些能力很强的人。

有人说，能力高的人，不会成为这场经济危机的受害者。之所以失业，是因为物竞天择，优胜劣汰的结果。其实，看看现实的华尔街，看看倒闭的毕博，或许更多的人知道，这已经不是能力，公平两个字能说明的问题了。

面对这些，你能怎么办呢？

面对危机唯一不可取的，就是抱怨，抱怨周围的人，抱怨给你的亲朋好友。现时生活，每个人都不容易。不要把自己的这点苦难，也转移到别人的身上。其实，任何一场危机，在你年轻的人时候到来，总比老的时候来要好的多。至少年轻，我们还有资本，我们还有精力去奋斗，去改变。

要从思想上，深刻地理解并且分析这场灾难。了解一下，并且预测自己的人生，到底该往哪里走。也算给你一个机会，让你审视自己的未来。看看过去，想想未来。

要从行动上，真实地面对这场经济危机。要知道，尺有所短，寸有所长。无论在哪个环境里面，混了这么久。只要你不是随波逐流的人，总有自己的优势存在。不要因为目前没有适合你的，就觉得自己命运不济，就怨天尤人，就强迫自己去做自己不擅长也不喜欢的事情。因为人生的每一次选择，就是对未来的很长一段时间其他选择的拒绝。选择了不适合自己的工作，只是浪费了自己的人生而已。到头来，得不偿失。

如果实在没有办法避免这场危机，如果已经在危机中，没有办法去找寻替代的工作。那么，给自己一段时间，让心情放个假。自己去梳理一下平时因为不太常用而被遗忘的知识，去学习一下平常因为项目忙而可望而不可学的知识。去锻炼一下很久不曾锻炼的身体。。也是一种不错的选择。

这场危机总会过去，风雨过后阳光一样会再来。养精蓄锐之后，在新的天地里面，一定会找到新的机会，然后开始你风雨过后新的人生。

   绩效考核是一个团队的管理比较重要的一个方法和手段。合理适度公平的绩效考核对于团队的良好发展有着积极的影响作用。每个行业的团队考核和管理都会因为行业的特殊性以及公司的制度而有着很多的不同。也对于软件测试这个行业来说，也有着很多的区别。

  从业四年多来，经过了日企，美企两大不同风格的公司的具体实践，对于测试团队的绩效考核，有些自己一些浅薄的认识。写在这里，留给自己深思，也希望给过路的同行一点启发。

一，绩效考核的一些片面的做法。

  日企和美企从很大程度上来讲，属于两种不同思想的碰撞，在各自的绩效考核上也各有一些在实践过程中，让人觉得不甚妥当的地方。在这里列举出来。

1.过分的强调了bug数量在绩效考核中的作用。

  诚然，把发现bug的数量和质量作为一项重要的对测试人员的绩效考核标准是没有错误的，而且如果同时伴随着必要的奖励机制，会在一定程度上刺激测试人员对于寻找bug的热情。

  但是，这个作用不可以过分的被强调。因为在实际的测试过程中，每个测试人员承担的测试模块的情况都是有区别的。比如有些人承担新开发的功能模块的测试，而有些人承担的则是旧有继承的模块的测试。bug的检出率对于新增模块来说自然要多于稳定的旧有模块。

  还有，如果对bug的作用过分强调，也会使得测试人员在承担测试任务的时候挑肥拣瘦，都争着抢着去测试那些容易出问题的功能，在很大程度上会打乱测试计划和测试进度的正常进行。

一些国内的企业，包括我曾经工作过的日企，在实际的绩效考核过程中就过分的看重了bug的比重。“过犹不及”这句古语在现代的企业管理和项目管理中也发挥着它的作用。

2．只看测试用例的数量和客户对于测试的反馈而忽略了bug在绩效中的作用。

  这一点在美企体现的是比较深刻的。对于很多在欧美外企工作的测试人员来说，工作量没有日企卡的那么严格，也不需要像测试leader整日的汇报动向。在既定的时间内完成测试需求的分析-测试用例的设计-测试的评审-测试的执行以及后期测试的结果汇报就可以了。如果当前测试的版本发布之后，没有其他的不良反馈，就算顺利的完成了测试任务。而也正因为这种文化的存在，在欧美企业的绩效考核中，测试case的设计质量和完成的多少以及客户的反馈成为重中之重。

  这个根据应该说在很多程度上是有隐患的。可能根据这个release版本所重点关注的问题，测试员没有测试出相关的问题。但是却找到了其他的一些问题。因为绩效考核不在于考核测试人员对于bug的发现量，而且在一个跟本身release版本无关的问题上纠缠会造成一些额外的麻烦，比如说开发人员不予修改，比如说提交延迟，比如说及时你额外测试了，付出了，却没有任何的后续效果。。很多测试人员在长久的这种状态影响下，就如猫在火中取栗被烫伤了爪子一样，逐渐的把目光从全局放回了局部。及时bug就在脚边，甚至跘了自己一跤，也会因为这种影响，视为无物。那么长此以往，从这样的开发，测试团队中流出的产品的质量，可想而知。

3．对于测试人员发现的问题没有有效的评审机制。

  测试人员要及早的连续的测试，要在发现问题后及早的报告。这是每一个从业人员都耳熟能详的原则。很多测试团队也在绩效考评中侧重于对测试人员发现bug量的考察。但是在实际的考评执行中，因为没有有效的bug评审机制，所以对于问题的质量的度量缺乏一定的衡量标准。

  发现测试系统设计方面的缺陷和能引起测试系统出现异常的bug的意义要远远大于发现几个图形界面的小bug。所以，实际的测试中，要根据bug的严重程度和意义来给与合理的考评。

4．不重视测试人员的综合能力.

  在很多测试团队中，绩效考评一般只限于两点，第一，测试用例的考察，包括书写的效率和质量；第二，测试缺陷量的考察。而对于其他，涉及很少。

  测试团队的巩固和成长是一个长期的实践活动。对于测试人员的技能，素质以及其他相关的培养也是必要的。所以，在一个测试团队的绩效考核，也是需要针对综合的能力进行全面的考察。比如说，测试人员对于相关领域技能的学习能力，对于所学知识的分享能力，对于技术难题的攻克能力，外语能力，沟通能力等等。都应该是考察的一方面的内容。

二，绩效考核的几点建议。

1．综合素质的考察

1）考察测试人员的职业操守，对于公司规章制度的一些遵守（如果需要）

2）考核测试人员的工作态度（是否认真，积极，努力）

3）考察测试人员的学习能力（对于边缘技术的学习能力，对于较难课题的学习和攻克能力）

2．测试成果的考察

1）考察测试人员的对于测试需求的理解

2）考察测试人员对于测试用例的设计（检查点的覆盖，业务的熟悉和掌握，测试用例的书写效率和质量）

3）考察测试人员的bug的检出率（bug的质量<严重程度，该bug的功能性影响>，确认，发行bug的工作是否到位，bug report书写的质量

3）和相关人员的沟通。包括和相关开发人员，其他人员的工作中的交流情况。

3．测试培训成功的考察

1）对于既定的测试小组的培训的学习情况。

2）对于给出的技能点的培训任务的担当和完成情况。

  总结：

注意点：对于测试人员的绩效考评，要全面，公平。数据说话。也就是说，不能因为个人的亲疏远近关系而放宽或者严苛的对相关人员进行考核。不能因为个人的主观印象而要采取能拿出服众的数据给与合理的考评。

  对于被考核者的评价要客观，通过考核，要让他们了解考核的意义以及对于测试人员本身使命的认知。对于被考核者的主观情绪，要把握好，并且适度的单独给与疏导，让其能够更加有效的投入到新的测试工作当中。

2008年的经济危机，在09年继续蔓延，加深。终于在春节之后，这股台风真实的刮到了我所居住的大连。

这一次，我真的不知道，我的2009年，会是什么颜色。

但是唯一知道的事情，就是，我不会停下努力的脚步。

我会继续努力，不断地努力，希望在这样的天空下，可以努力的飞翔，飞到一个适合自己发展的地方。

危机，有的时候蕴藏着机会。而机会，总会留给有准备的人。

暴风雨中，我也要努力飞翔。。

2008年过去了。这个年头，我探索过，努力过，彷徨过，失落过，也曾开心过，自豪过。。种种情愫。。

面对新的2009，俯瞰2008年的一切，感慨良多。

2008年，最开心的事情是参加了《超越时空-虚拟紫禁城》项目的测试。不仅仅是因为这项目让我成长，不仅仅是这个项目后来引起了我没有想象过的似乎也在情理之中的轰动，不仅仅是因为这个项目让我体验了glable community test中的help desk的味道..更多的事，因为这个项目我认识了很多新的朋友，通过他们，我学到了更多的东西。

感谢md.cheng的热心帮助，指出了我很多的毛病。感谢她对我工作的认可和协助，否则我的热情不会从头保持到最后。感谢她对我的关怀，常常出人意表的给我很多的惊喜。和她一起工作，常常觉得周身有一种短短的感动。。

也真心感谢这个项目，能够一再的延期（）否则在这多灾多难的年头，我可能会成为第一个沉默的羔羊，因为没有项目而被踢出去。。

2008年，最成功的事情是和老公一起全程筹划了我们的婚礼，从家庭的装修，到酒店的选择，礼仪等等。。虽然初次面对这些事情，我们有过无数次被宰被黑的惨痛经历，这些经历虽然也曾让我无数个日夜辗转反侧。。虽然我们这样白手起家的人来说，代价还是不小的。但是我很开心。或许这将是一辈子的美好回忆吧。

2008年，最失败的事情是装修的时候卖暖气片。。结果引来一场水灾，还惹来了不大不小，至今想起来心有余悸的楼下邻居的不依不饶，最终虽说赔钱了事，却让我觉得这个楼宇，少了那么一点当初的温暖。。

2008年，最幸运的事情，哈哈~~就是在在装修期间租到了一个很便宜的房子，而且出租的房子，再次因为洗衣服闹出水患的时候，楼下居然没有人住。。天可怜见~~

2008年，最累的事情是最后两天，几千公里的路程去温州参加姐姐的婚礼。累啊。。但是没有什么意外，虽然也没有什么惊喜。或许本来就没带什么好心情去，所以也没有什么好的心情回来。唯一的祝愿，就是姐姐姐夫以后可以快快乐乐的生活。最大的希望就是他们一定要安家在沈阳，那样我就可以隔三差五去沈阳聚会了。。努力吧~~

2008年，最惊讶的事情就是八年多没有联系的高中同学找到了我。想起了很多的往事。发现自己还是跟当时没啥长进，依然那样活的很开心，很自我，也很格路。不过格路的人生中，有几个知心的朋友，还算不错~~

2008年，最无法相信的事情居然是中国和世界如此多灾多难，从2月份可以属到12月份，从物质上的灾难到意识形态的灾难，此起彼伏。。以至于常常想，是不是人类太过逍遥？

2008年，太多的事情发生了，很多或许不翻翻自己的日志，已经要忘记，但是，无论如何。我都觉得将来，2008年会是最让人记住的一年，太多的惶恐，伤心，感动，太多的灾难，勇气，互助。。2008年，对于任何人，都是置之死地而后生的一年。

2008年过去了。2009年，我想，大家不需要祈祷，相信吧，只有自己的努力，才能换来09年的美丽。只有不断的努力，才能让以后的路走得更好。2009年，我们应该告诉世界，我们可以~

近日有些许闲暇，跟测试中国msn群的网友们有了一些交流的时间。

也收到了一些刚入门的迷茫中的学弟学妹的一些需要解答的困惑。

思忖再三，决定在这里说上一二，算是一个浸泡了四载岁月的菜鸟的一些感言吧！

有些话，已经在别的帖子里讲过，这里不再提及，如果感兴趣，可以看看我之前的帖子，尤其是：

软件测试人员的自我修养-沉下去
http://www.51testing.com/?47068/ ... e_itemid_81672.html
由测试需要多少编程知识想到的。。。
http://www.51testing.com/?47068/ ... e_itemid_81817.html
从电子产品的国货PK不过外国货看软件测试的重要性
http://www.51testing.com/?47068/ ... e_itemid_81834.html
由国内项目的软件测试流程感悟到的
http://www.51testing.com/?47068/ ... e_itemid_80640.html
感悟软件测试
http://www.51testing.com/index.php?uid-47068-action-viewspace-itemid-80716

不论这几个帖子说的是否权威，是否为大家之言，都是我自己工作的一些感慨和所得。对于高手来说，或许不屑一顾，对于和我的曾经一样，正在迷茫中的人们，或许真的是一种启发。

那么，这里我要说什么呢？

我要说的是，软件测试，不是如芝麻开门般神奇，进入了之后，可以从此精彩不断，美丽人生。

软件测试，这个行业与其他的行业没有什么不同。有适合从事它的人，也有不适合的。

不要轻易为了一些宣传而选择错了自己的路。

有些人问我说，我不知道自己该不该走这条路，因为，除了这条路之外，我也不确定是否还有别的路适合我。

那么，请你不要轻易的下决定，利用一点时间，去找一本软件测试的书籍，好好地研读。看看作为一个软件测试人需要会什么，懂什么，关注什么；看看他们的工作都是怎样的过程；看看论坛上的诸位深浅不一的软件测试人，他们都在想什么，你是否真的能融入他们之中。。

如果你觉得，你对他们的世界，没有什么兴趣，在你的眼睛里，这样的工作只是为了糊口，那么，如果有别的选择，就不要走到这个道路上来。因为，或许它不是真正适合你的工作。

三百六十行，总有一行适合你，因为你选择了一个的同时，也等于拒绝了其他。当你还有资本随便玩转世界的时候，无可厚非，每一个行业的从业历程，都会成为你丰富人生的一种方式。

但是如果你真的是想成为一个只在某一个行业上有所成就的人，那么在决定之前，还是要好好的冷静一下。

这也正所谓“知己知彼”的另外一个含义吧~

或许有些人觉得我的想法有些古怪，但是如果你见到不停在换行业，却越换越迷茫的朋友；如果你见过跟你一样从事软件测试，却每天苦不堪言的同事；如果你见过从事了好几年的软件测试，最后失望的说，这个没有技术行量的行业，再呆下去，只有浪费了我的青春，最后选择它行的同事。。你会如何？我心痛，不适合就不要走到这里来。人生本来短暂，挫折已经够多，何苦自己再为自己设伏？

人生在世，需要为你的每一个决定去负责。如果你选择了，那么，你要做的就是要融入进来，成为一个真正的软件测试人，而不是雾里看花，走马观花，最后什么都没看明白，感叹，不过如此的人。。

测试人员需要为产品质量负责吗？
这句话其实可以这样问
医生需要为病人的病情负责吗？
答案是肯定的。
一个产品从测试人员手中走过，测试人员需要对它进行有目的的有效的测试，确保尽早的发现产品内在的缺陷，从而在最短的时间内促使开发人员完成对产品的修复，减少企业因此而将要承受的损失。
这需要测试人员的责任心。面对一个测试任务，需要的是细心，耐心以及自我的分析。知道成本和效益的关系，了解客户最大的需求，知道面对的这个任务，自己的轻重缓急在哪里，不能磨磨蹭蹭，以至于耽误了最佳的测试时间。
如果测试产品从测试人员手中流过，却没有被检测出隐含的最大的问题，那么就是测试人员的失职。就如同一个医生面对一个病人，经过一番检查，却没有任何的诊断抑或遗漏了最大的病患。。
但是反过来讲，测试人员不能对产品的任何瑕疵都负责任，不可能为产品的质量去100%买单。测试人员只对测试的质量去买单，只为测试的成果负责。
测试人员虽然尽心尽力的对产品进行了最为有效的测试，但是因为客户的决定，或者开发人员的推委，导致产品的已发现的重大的问题没有被解决掉。面对这部分，测试人员不需要去负责。

但是也不要因此就影响了士气。虽然，很多时候，人们总说，一个软件做好了，是开发人员的功劳；做得不好，使测试人员的不是。也有很多人，因为这个原因而离开了测试队伍。因为觉得自己跟“替罪羔羊”一样的无奈和无辜。
其实，很多时候，任何角落，都有一些前台的和幕后的英雄，并不是站在领奖台上的人才是最光荣的。无论是设计者，开发者还是测试人员，都是软件生命周期中不可或缺的重要组成人员，大家共同的努力才成就了软件的上市以及企业的盈利和良好信誉。每一个都要为自己的存在而感到自豪。自己的地位靠自己的努力来不断的得到证明，自己的能力不需要别人的证明。金子在沙地也是金子，沙子在金堆也总是沙子。如果你觉得自己被轻视了，那么，不要放弃，请你努力！相信吧，自己今天的努力一定会换来你更美好的明天。

测试人员在面对测试任务之前一定学会思考，从客户，从市场，从软件本身的特点去方方面面的思考，知道自己该如何把握，该怎样策划你的测试用例。该如何更加有效的去发现更有价值的bug.
很多测试人员都觉得很郁闷，当他们的bug被开发的以不需要修复为由而拒掉。但是这个时候抱怨没有用的。开发人员这样做，你要找到理由。开发人员绝对不会贸贸然把一个可能导致软件崩溃的bug置之不理。如果是这样的bug，那么，可能时间已经不够，修复的风险太大，这个时候你要理解，而且要帮助他们出主意，看看怎样解决才是最好。如果你的bug无足轻重，而还有一大堆的问题你都没有去发掘，那么，坐冷板凳是应该的。这个时候，你能做得最好的事情就是，自己多去想，有效地发现出更多更有效的更重要的bug来。