将字符串中的数字转换为浮点数的函数，如果不事先声明，则转换有问题。

　　1)strcat

　　char *strcat ( char *to, const char *from );

　　功能：链接两个字符串。

　　例子：

　　这个例子是用strcat链接字符串：Cheers_Lee和 @hotmail.com

　　脚本如下：

char test[1024], *a = "@hotmail.com"; strcpy(test, "Cheers_Lee"); strcat(test, a); lr_output_message("We can see %s",test);

　　运行后在executon　log中看到如下语句：

Starting action Action. Action.c(16): We can see Cheers_Lee@hotmail.com

　　2)strchr

　　char *strchr ( const char *string, int c );

　　功能：返回字符串中指定字符后面的字符串。

　　例子：

　　这个例子是返回第一个出现e字符以后所有的字符，和最后一次出现e字符以后所有的字符。

　　脚本如下：

char *string = "Cheers is a tester"; char *first_e, *last_e; first_e = (char *)strchr(string, 'e'); lr_output_message("We can see the first occurrence of e: %s",first_e); last_e = (char *)strrchr(string, 'e'); lr_output_message("We can see the last occurrence of e: %s", last_e);

　　运行后在executon　log中看到如下语句：

Starting action Action. Action.c(12): We can see the first occurrence of e: eers is a tester Action.c(14): We can see the last occurrence of e: er

　　3)Strcmp＆stricmp

　　int strcmp ( const char *string1, const char *string2 );大小写敏感。

　　int stricmp ( const char *string1, const char *string2 );大小写不敏感。

　　功能：比较字符串。

　　例子：

　　按是否区分大小写对比两个字符串，并打印出它们的大小关系。

　　脚本如下：

int result; char tmp[20]; char string1[] = "We can see the string:Cheers"; char string2[] = "We can see the string:cheers"; result = strcmp( string1, string2 ); if( result > 0 ) strcpy( tmp, "大于" ); else if( result < 0 ) strcpy( tmp, "小于" ); else strcpy( tmp, "等于" ); lr_output_message( "strcmp: String 1  %s string 2", tmp ); result = stricmp( string1, string2 ); if( result > 0 ) strcpy( tmp, "大于" ); else if( result < 0 ) strcpy( tmp, "小于" ); else strcpy( tmp, "等于" ); lr_output_message( "stricmp: String 1 %s string 2", tmp );

　　运行后在executon　log中看到如下语句：

Starting action Action. Action.c(22): strcmp: String 1  小于 string 2 Action.c(33): stricmp: String 1 等于 string 2

4)strcpy

　　char *strcpy ( char *dest, const char *source );

　　功能：复制一个字符串到另一个字符串中。

　　例子：

　　复制一个字符串到字符数组中，并打印出来。

　　脚本如下：

char test[1024]; strcpy(test, "what can we see?"); lr_output_message("%s", test);

　　运行后在executon　log中看到如下语句：

Starting action Action. Action.c(10): what can we see?

　　5)Strdup& strlwr

　　char *strdup ( const char *string );

　　复制一个字符串。

　　char *strlwr ( char *string );

　　转换成小写字母。

　　例子：

　　在这个例子中，Vuser的组名被转换为小写字母。但是lr_whoami把组名作为静态buffer返回。这样的buffer不能被操作。如果有操作需要，就复制这个静态buffer。

　　脚本如下：

int id; char *groupname_static, *groupname; lr_whoami(&id, &groupname_static, NULL); lr_output_message("groupname=%s", groupname_static); groupname = (char *)strdup(groupname_static); groupname = (char *)strlwr(groupname); lr_output_message("lower case groupname=%s", groupname); free(groupname);

　　上述脚本用vugen保存为：CHANGE

　　在controller中运行（设置为总是发送消息）

　　运行后在log中看到如下语句：

Starting action Action.  [MsgId: MMSG-15919] Action.c(11): groupname=CHANGE       [MsgId: MMSG-17999] Action.c(16): lower case groupname=change  [MsgId: MMSG-17999]

　　6)Strlen

　　size_t strlen ( const char *string );

　　功能：返回字符串长度（bytes）.

　　例子：

　　这个例子很简单，就是得到一个字符串中的字符的个数。然后打印出来。

　　脚本如下：

Starting action Action.  [MsgId: MMSG-15919] Action.c(11): groupname=CHANGE       [MsgId: MMSG-17999] Action.c(16): lower case groupname=change  [MsgId: MMSG-17999]

　　运行后在log中看到如下语句：

Action.c(13): The  sentence has 18 letters

7)Strncat

　　char *strncat ( char *to_string, const char *from_string, size_t n );

      管理是在特定的环境下，对组织所拥有的资源进行有效的计划、组织、领导和控制，以便达成既定组织目标的过程。因此要进行小组管理，首先得清楚手中拥有的资源以及要完成的目标，简而言之，管理分为理事和管人，理事是为了使得工作有计划，有组织，安排合理，而管人则是如何领导团队成员达成目标。理事需要做到的方面有：

明确目标 
     整个团队所要达成的目标需要和部门的整体规划保持一致，领导希望团队的工作能够达到什么效果，出哪些成绩，需要事先沟通，并予以明确。管理者首先从明确目标方面保证团队管理的大方面没有偏离，这样工作计划才能制定合理，成员的付出才不会导致浪费。
做好分工 
      团队的管理要学会科学分工，要让团队每位成员都能清楚了解自己的职责，这样才能避免在合作过程中出现推诿、扯皮等现象，另外也需要注意根据成员的能力和心态对每个人的工作任务做出相应调整，在每天或每周的特定时间内进行任务讲解、分配、听取组员们的意见，保证工作任务的合理、监督工作任务的进度。 
     另外团队中也需要注意那些积极性不高、有抱怨情绪的成员，因为团队里面负面的传递要比正面传递快得多，对于这样的成员，需要进行单独的沟通，虽然可能无法真正获取成员的想法，但可以表示关注的态度，如果是因为压力，则通过调节任务和积极鼓励，让成员丢下包袱，如果是因为懒散，则需要通过工作给予一定的压力，使得任务具有一定的挑战性。
制定标准 
     让员工明白工作好坏的标准，也是团队管理中必不可少的事情，目的是让员工明白考核依据和行为指南，并且工作标准要做到数字化，具有可操作性。如果缺乏工作标准，往往会导致员工的努力方向与公司整体发展方向不统一，造成资源浪费，而缺乏参照物，时间久了员工容易形成自满情绪，导致工作懈怠。 
     制定好标准，也同时要做好奖惩，但大多数公司只注重罚，不注重奖，作为团队领导，虽然无法改变整个公司的制度，但要注意做到奖惩平衡，不能参杂个人情绪，惩罚可以是一句警告或提醒，奖励可以是一句关心的话语，都要做到透明公开。
做好示范 
     管理者要明白以身作则的力量，如果遇到事情的做法是推卸责任的话，下属往往会推卸得更加厉害，因此学会去做好示范。 
     遇到工作中产生的错误，管理者应当先从自身去反省，组织小组会议进行讨论，提高团队的质量意识，而不能去将大部分责任推给下属或其他部门人员，对待问题的态度一定要严肃认真，一旦通过表率树立起在团队成员中的威望，将会上下同心，大大提高团队的整体战斗力。

 

编写背景：

　　工作所在的部门启用了新的绩效考核制度，也开始了我参与对测试人员的工作进行绩效考核这一管理活动，第一次的考核结果让我有很多的感想，因此今天把它记录下来，也许突然有一天回头看这一感想，又会是另外一份心情。

　　思考：给测试人员进行绩效考核的目的是什么？

　　经过思考，我总结的答案是：

　　1、为了了解工作情况，如：工作进度、工作状态。

　　2、对每个人的工作进行评比，夸奖好的，批评差的。这个看起来有点像在学校上学时候的考试。

　　思考：有了这样的绩效考核目的，要用什么样的方式、方法去实现呢？

　　怎么样的绩效考核方式是最有效的呢？

　　对于现在的我，在现在这个小公司要想做好这个绩效考核，真是要好好思考。

　　1、不同的工种，不能用同一种考核方式。如：测试人员的考核方式就不能和开发人员的考核方式相同。

　　2、不同工种的考核结果是没有可比性的。如：测试人员的考核结果和开发人员的考核结果进行对比是没有意义的。

　　以上这两点不知道我的领导是否认同，还需要等到下一次考核的时候和他沟通沟通。

　　这是工作以来，第一次站在一个管理角色去思考、去做绩效考核这个工作。这第一次的考核工作让我不知道用什么语言来描述我的感受。

　 　考核的结果是：测试组整体的分数都比开发的低，从排名和等级划分上可以说是包尾了。从分数上看，我的第一感觉是：难受。第二感觉是：生气。在和领导进行 一系列沟通后，在回家的路上一直在思考、分析着这个结果，问题出在那里呢？问题出在那里呢？？？？？冷静的思考后，自己安慰自己，原因应该是这些吧：

　　1、这次开发人员和测试人员使用的工作考核方式是同一种考核方式。

　　2、这次把开发人员的考核分数拿来和测试人员的进行排名对比。

　 　很显然，一直这样下去，测试人员的工作即使在怎么努力、分数超过开发人员的机率会很低很低，这样的对比规则，对测试人员来说，很不公平。这样的对比规 则，很没有意义。更让我郁闷的是，面对这样的现象，我想不到很好的解决方法，目前只能鼓励测试人员加强自己的综合能力，自己给自己争气，对我来说，在测试 人员的管理工作上，无形中出现了一个困难，只能是乐观面对了。

　　唉，工作种类不一样，放在一起作对比，永远说不清。

　　测试人员的工作，开发能作么？开发人员能写好测试需求、测试计划、测试用例、测试分析报告文档么，先不说写好，先说会写么？开发人员知道怎么样去执行测试么？知道发现 bug 应该怎么有效正确的去描述么？怎么快速有效的发现程序的问题么？能把握好整个软件测试的质量和进度么？测试，说的简单，真正做好没有这么简单。就拿黑盒测试举例，测试项有：业务流程测试、功能测试、安全性测试、性能测试、 数据测试、用户友好性测试、配测试、兼容性测试。这些测试项所使用的测试方法、测试点，都能想全了、想到重点了么，想到了还只是第一步，真正要去执行测试 的时候，测试环境的搭建、测试用例的编写与执行、 bug 的描述以及错误等级的正确划分、 bug 的回归、用测试工具进行测试，对测试工具正确有效使用的把握，这些对开发人员来说，会做么，能做好么？测试工作也有很大的工作压力，面对一个不熟悉的软 件，面对一个什么说明文档都没有的大软件，要在最短的时间内，最有效的完成测试，要保证产品在发布后，不出现严重的问题，想尽一切办法的发现严重问题。这 种对软件质量上的责任压力是很重的，还有其它我就不举例了。

　　开发人员的工作，测试能作么？测试能看懂开发人员的代码么？测试能写代码测 试开发人员的程序么？测试能明白理解开发人员是怎么开发的么？测试能明白开发人员所说的工作术语么？测试能看明白开发人员的开发成果么？开发人员的工作也 有很大的压力，要在最短的时间内编写出质量高的代码，实现功能，还要进行一遍又一遍的调试，需求一变，又要修改代码，自测时，发现问题，要进行调试找原因 和解决方法，容易么？不容易。测试人员发现的问题，还要去找原因要想最好的解决方法。容易么？不容易。

　　我很同情那些把测试和开发放在一起作对比行为的人，因为他们对这两个工作中的其中之一理解有所欠缺从而导致这样的结果。说了那么多，好像扯远了。

　 　最后，我得出这么个结论：这样的绩效考核方式，对测试人员来说，起不到激励作用。如果碰到不能正确心态去理解的测试人员，反而会起反作用，很打击工作积 极性。因此领导在问我意见的时候，在不适合的说话时间、说话场合我只能说“无所谓”，心不甘情不愿的无所谓！！！！！！！！！！！！！！

“团队活动，我觉得吃饭挺好的，容易组织，参与人多，大家都觉得吃饭挺好的。”真的是这样么？

1、虚假同感偏差（false consensus bias）
　　我们通常都会相信，我们的爱好与大多数人是一样的。如果你喜欢玩电脑游戏，那么就有可能高估喜欢电脑游戏的人数。你也通常会高估给自己喜欢的同学投票的人数，高估自己在群体中的威信与领导能力等等。你的这种高估与你的行为及态度有相同特点的人数的倾向性就叫做“虚假同感偏差”。有些因素会影响你的这种虚假同感偏差强度：
（1）当外部的归因强于内部归因时；
（2）当前的行为或事件对某人非常重要时；
（3）当你对自己的观点非常确定或坚信时；
（4）当你的地位或正常生活和学习受到某种威胁时；
（5）当涉及到某种积极的品质或个性时；
（6）当你将其他人看成与自己是相似时。

“小王总是这么粗心大意，这项工作完成情况估计也好不哪去。”评价下属时，你有过类似想法么？
2 、晕轮效应
　　俄国著名的大文豪普希金曾因晕轮效应的作用吃了大苦头。他狂热地爱上了被称为“莫斯科第一美人”的娜坦丽，并且和她结了婚。娜坦丽容貌惊人，但与普希金志不同道不合。当普希金每次把写好的诗读给她听时。她总是捂着耳朵说：“不要听！不要听！”相反，她总是要普希金陪她游乐，出席一些豪华的晚会、舞会，普希金为此丢下创作，弄得债台高筑，最后还为她决斗而死，使一颗文学巨星过早地陨落。在普希金看来，一个漂亮的女人也必然有非凡的智慧和高贵的品格，然而事实并非如此，这种现象被称为晕轮效应。
　　所谓晕轮效应，就是在人际交往中，人身上表现出的某一方面的特征，掩盖了其他特征，从而造成人际认知的障碍。在日常生活中，“晕轮效应”往往在悄悄地影响着我们对别人的认知和评价。比如有的老年人对青年人的个别缺点，或衣着打扮、生活习惯看不顺眼，就认为他们一定没出息；有的青年人由于倾慕朋友的某一可爱之处，就会把他看得处处可爱，真所谓“一俊遮百丑”。晕轮效应是一种以偏概全的主观心理臆测，其错误在于：第一，它容易抓住事物的个别特征，习惯以个别推及一般，就像盲人摸象一样，以点代面；第二，它把并无内在联系的一些个性或外貌特征联系在一起，断言有这种特征必然会有另一种特征；第三，它说好就全都肯定，说坏就全部否定，这是一种受主观偏见支配的绝对化倾向。总之，晕轮效应是人际交往中对人的心理影响很大的认知障碍，我们在交往中要尽量地避免和克服晕轮效应的副作用。

当你对下属有认可、期待的时候，下属也许就表现的特别好。这可能是因为：

3、罗森塔尔效应（皮革马利翁效应、期待效应）
　　美国心理学家罗森塔尔等人于1968年做过一个著名实验。他们到一所小学，在一至六年级各选三个班的儿童进行煞有介事的“预测未来发展的测验”，然后实验者将认为有“优异发展可能”的学生名单通知教师。其实，这个名单并不是根据测验结果确定的，而是随机抽取的。它是以“权威性的谎言”暗示教师，从而调动了教师对名单上的学生的某种期待心理。8个月后，再次智能测验的结果发现，名单上的学生的成绩普遍提高，教师也给了他们良好的品行评语。这个实验取得了奇迹般的效果，人们把这种通过教师对学生心理的潜移默化的影响，从而使学生取得教师所期望的进步的现象，称为“罗森塔尔效应”，习惯上也称为皮格马利翁效应（皮格马利翁是古希腊神话中塞浦路斯国王，他对一尊少女塑像产生爱慕之情，他的热望最终使这尊雕像变为一个真人，两人相爱结合）。
　　教育实践也表明：如果教师喜爱某些学生，对他们会抱有较高期望，经过一段时间，学生感受到教师的关怀、爱护和鼓励；常常以积极态度对待老师、对待学习以及对待自己的行为，学生更加自尊、自信、自爱、自强，诱发出一种积极向上的激情，这些学生常常会取得老师所期望的进步。相反，那些受到老师忽视、歧视的学生，久而久之会从教师的言谈、举止、表情中感受到教师的“偏心”，也会以消极的态度对待老师、对待自己的学习，不理会或拒绝听从老师的要求；这些学生常常会一天天变坏，最后沦为社会的不良分子。尽管有些例外，但大趋势却是如此，同时这也给教师敲响了警钟。

分配工作的时候，你会发现，当一项工作很多人负责的时候，就没人负责了。

4、责任分散效应

　　1964年3月13日夜3时20分，在美国纽约郊外某公寓前，一位叫朱诺比白的年轻女子在结束酒巴间工作回家的路上遇刺。当她绝望地喊叫：“有人要杀人啦!救命!救命!”听到喊叫声，附近住户亮起了灯，打开了窗户，凶手吓跑了。当一切恢复平静后，凶手又返回作案。当她又叫喊时，附近的住户又打开了电灯，凶手又逃跑了。当她认为已经无事，回到自己家上楼时，凶手又一次出现在她面前，将她杀死在楼梯上。在这个过程中，尽管她大声呼救，她的邻居中至少有38位到窗前观看，但无一人来救她，甚至无一人打电话报警。这件事引起纽约社会的轰动，也引起了社会心理学工作者的重视和思考。人们把这种众多的旁观者见死不救的现象称为责任分散效应。
　　对于责任分散效应形成的原因，心理学家进行了大量的实验和调查，结果发现：这种现象不能仅仅说是众人的冷酷无情，或道德日益沦丧的表现。因为在不同的场合，人们的援助行为确实是不同的。当一个人遇到紧急情境时，如果只有他一个人能提供帮助，他会清醒地意识到自己的责任，对受难者给予帮助。如果他见死不救会产生罪恶感、内疚感，这需要付出很高的心理代价。而如果有许多人在场的话，帮助求助者的责任就由大家来分担，造成责任分散，每个人分担的责任很少，旁观者甚至可能连他自己的那一份责任也意识不到，从而产生一种“我不去救，由别人去救”的心理，造成“集体冷漠”的局面。如何打破这种局面，这是心理学家正在研究的一个重要课题。

一个团队，如果不好的行为没有被及时纠正，很快，这个坏行为会蔓延开，而且，每个人都做的心安理得。

5、破窗效应
　　心理学的研究上有个现象叫做“破窗效应”，就是说，一个房子如果窗户破了，没有人去修补，隔不久，其它的窗户也会莫名其妙的被人打破；一面墙，如果出现一些涂鸦没有清洗掉，很快的，墙上就布满了乱七八糟，不堪入目的东西。一个很干净的地方，人会不好意思丢垃圾，但是一旦地上有垃圾出现之后，人就会毫不犹疑的拋，丝毫不觉羞愧。这真是很奇怪的现象。
　　心理学家研究的就是这个“引爆点”，地上究竟要有多脏，人们才会觉得反正这么脏，再脏一点无所谓，情况究竟要坏到什么程度，人们才会自暴自弃，让它烂到底。
　　任何坏事，如果在开始时没有阻拦掉，形成风气，改也改不掉，就好象河堤，一个小缺口没有及时修补，可以崩坝，造成千百万倍的损失。
　　犯罪其实就是失序的结果，纽约市在80年代的时候，真是无处不抢，无日不杀，大白天走在马路上也会害怕。地铁更不用说了，车厢脏乱，到处涂满了秽句，坐在地铁里，人人自危。我虽然没有被抢过，但是有位教授被人在光天化日之下，敲了一记闷棍，眼睛失明，从此结束他的研究生涯，使我多少年来谈虎变色，不敢只身去纽约开会。最近纽约的市容和市誉提升了不少，令我颇为吃惊，一个已经向下沉沦的城市，竟能死而复生，向上提升。
　　因此，当我出去开会，碰到一位犯罪学家时，立刻向他讨教，原来纽约市用的就是过去书本上讲的破窗效应的理论，先改善犯罪的环境，使人们不易犯罪，再慢慢缉凶捕盗，回归秩序。
　　当时这个做法虽然被人骂为缓不济急，“船都要沉了还在洗甲板”，但是纽约市还是从维护地铁车厢干净着手，并将不买车票白搭车的人用手铐铐住排成一列站在月台上，公开向民众宣示政府整顿的决心，结果发现非常有效。
　　警察发现人们果然比较不会在干净的场合犯罪，又发现抓逃票很有收获，因为每七名逃票的人中就有一名是通缉犯，二十名中就有一名携带武器，因此警察愿意很认真地去抓逃票，这使得歹徒不敢逃票，出门不敢带武器，以免得不偿失、因小失大。这样纽约市就从最小、最容易的地方着手，打破了犯罪环结(chain)，使这个恶性循环无法继续下去。

随着组织的不断扩张，你可能发现，同样一件事，过去我用半个小时就能搞定，现在我用半天还没有搞定。为什么？是工作本身确实膨胀了，还是我们的效率出现了问题？

6、帕金森定律
　　英国著名历史学家诺斯古德·帕金森通过长期调查研究，写出一本名叫《帕金森定律》的书。他在书中阐述了机构人员膨胀的原因及后果：一个不称职的官员，可能有三条出路，第一是申请退职，把位子让给能干的人；第二是让一位能干的人来协助自己工作；第三是任用两个水平比自己更低的人当助手。这第一条路是万万走不得的，因为那样会丧失许多权利；第二条路也不能走，因为那个能干的人会成为自己的对手；看来只有第三条路最适宜。于是，两个平庸的助手分担了他的工作，他自己则高高在上发号施令，他们不会对自己的权利构成威胁。两个助手既然无能，他们就上行下效，再为自己找两个更加无能的助手。如此类推，就形成了一个机构臃肿，人浮于事，相互扯皮，效率低下的领导体系。这条定律又被称为“金字塔上升”现象。

     帕金森定律实际是时间管理中的一个概念。它表明：只要还有时间，工作就会不断扩展，直到用完所有的时间。工作会自动地膨胀，占满一个人所有可用的时间，如果时间充裕，他就会放慢工作节奏或是增添其他项目以便用掉所有的时间。

     如何消灭帕金森定律的负作用是我国各级政府及国有企业面临的紧要问题。建国初期，一个县的行政管理人员只有几百人，而现在则有上千人乃至几千人。庞大的行政管理开支必然落到每个纳税人身上，过多的行政干预必然制约经济的发展，还会给下面没事找事。在计划经济时代，有的公社连每株玉米的间距多少厘米都要制订计划，还要层层落实，确实大大地辛苦。然而，由于土壤肥瘠、气候旱涝等诸多因素，谁也不买领导的账。

有时候员工不需要多么优越的工作环境，只要你对他们足够关注、关心，他们一样干的很卖力。

7、霍桑效应（Hawthorne effect）

　　心理学上的一种实验者效应。20世纪20-30年代，美国研究人员在芝加哥西方电力公司霍桑工厂进行的工作条件、社会因素和生产效益关系实验中发现了实验者效应，称霍桑效应。
　　实验的第一阶段是从1924年11月开始的工作条件和生产效益的关系，设为实验组和控制组。结果不管增加或控制照明度，实验组产量都上升，而且照明度不变的控制组产量也增加。另外，有试验了工资报酬、工间休息时间、每日工作长度和每周工作天数等因素，也看不出这些工作条件对生产效益有何直接影响。第二阶段的试验是由美国哈佛大学教授梅奥领导的，着重研究社会因素与生产效率的关系，结果发现生产效率的提高主要是由于被实验者在精神方面发生了巨大的变化。参加试验的工人被置于专门的实验室并由研究人员领导，其社会状况发生了变化，受到各方面的关注，从而形成了参与试验的感觉，觉得自己是公司中重要的一部分，从而使工人从社会角度方面被激励，促进产量上升。
　　实验结论：

    1、改变工作条件和劳动效率没有直接关系；

　　2、提高生产效率的决定因素是员工情绪，而不是工作条件；职工是“社会人”。

　　3、关心员工的情感和员工的不满情绪，有助于提高劳动生产率。
　　4、企业来除了正式组织，还存在非正式组织。“非正式组织”对组织既有利，也有弊。管理人员要想实施有效的管理，要注意在非正式组织的感情逻辑和正式组织的效率逻辑之间保持平衡。

如果你的下属感到在这个团队里长期没有提升，绩效长期不好，长期不爽，那么接下来，他就是有机会改变，可能也不会努力了。

8、习得性无助

　　习得性无助效应最早有奥弗米尔和西里格曼发现，后来在动物和人类研究中被广泛探讨。简单地说，很多实验表明，经过训练，狗可以越过屏障或从事其他的行为来逃避实验者加于它的电击。但是，如果狗以前受到不可预期（不知道什么时候到来）且不可控制的电击（如电击的中断与否不依赖于狗的行为），当狗后来有机会逃离电击时，他们也变得无力逃离。而且，狗还表现出其他方面的缺陷，如感到沮丧和压抑，主动性降低等等。
　　狗之所以表现出这种状况，是由于在实验的早期学到了一种无助感。也就是说，它们认识到自己无论做什么都不能控制电击的终止。在每次实验中，电击终止都是在实验者掌控之下的，而狗会认识到自己没有能力改变这种外界的控制，从而学到了一种无助感。
　　人如果产生了习得性无助，就成为了一种深深的绝望和悲哀。因此，我们在学习和生活中应把自己的眼光在开阔一点，看到事件背后的真正的决定因素，不要使我们自己陷入绝望。

如果在绩效评价启动时才做360度调查，那时候相关评价人的意见真的那么可信么？

9、证人的记忆
　　证人，在我们的认识里，通常都是提供一些客观的证据的人，就是把自己亲眼看到、亲耳听到的东西如实地讲出来的人。然而，心理学研究证明，很多证人提供的证词都不太准确，或者说是具有个人倾向性，带着个人的观点和意识。
　　证人对他们的证词的信心并不能决定他们证词的准确性，这一研究结果令人感到惊讶。心理学家珀费可特和豪林斯决定对这一结论进行更深入的研究。为了考察证人的证词是否有特别的东西，他们将证人的记忆与对一般知识的记忆进行了比较。
　　他们让被试看一个简短的录象，是关于一个女孩被绑架的案件。第二天，让被试回答一些有关录象里内容的问题，并要求他们说出对自己回答的信心程度，然后做再认记忆测验。接下来，使用同样的方法，内容是从百科全书和通俗读物中选出的一般知识问题。
　　和以前发生的一样，珀费可特和豪林斯也发现，在证人回忆的精确性上，那些对自己的回答信心十足的人实际上并不比那些没信心的人更高明，但对于一般知识来说，情况就不是这样，信心高的人回忆成绩比信心不足的人好得多。
　　人们对于自己在一般知识上的优势与弱势有自知之明。因此，倾向于修改他们对于信心量表的测验结果。一般知识是一个数据库，在个体之间是共享的，它有公认的正确答案，被试可以自己去衡量。例如，人们会知道自己在体育问题上是否比别人更好或更差一点。但是，目击的事件不受这种自知之明的影响。例如，从总体上讲，他们不大可能知道自己比别人在记忆事件中的参与者头发颜色方面更好或更差。　　

想要什么，就牵引什么。如果导向太多，就相当于没有导向。。。

10、手表定律

手表定律是指一个人有一只表时，可以知道现在是几点钟，而当他同时拥有两只时却无法确定。两只表并不能告诉一个人更准确的时间，反而会使看表的人失去对准确时间的信心。
     手表定律在企业管理方面给我们一种非常直观的启发，就是对同一个人或同一个组织不能同时采用两种不同的方法，不能同时设置两个不同的目标，甚至每一个人不能由两个人来同时指挥，否则将使这个企业或者个人无所适从。

  在这方面美国在线与时代华纳的合并就是一个典型的失败案例。美国在线是一个年轻的互联网公司，企业文化强调操作灵活、决策迅速，要求一切为快速抢占市场的目标服务。时代华纳在长期的发展过程中建立起强调诚信之道和创新精神的企业文化。两家企业合并后，企业高级管理层并没有很好地解决两种价值标准的冲突，导致员工完全搞不清企业未来的发展方向。最终，时代华纳与美国在线的世纪联姻以失败告终。这也充分说明，要搞清楚时间，一块走时准确的表就足够了。

如何鼓励下属改进工作？其中一点，当下属提出一个不同以往的新想法时，注意，不要陷入以下效应：

11、鸟笼逻辑
　　鸟笼逻辑来源于一个故事。甲对乙说：“如果我送你一只鸟笼，并且挂在你家中最显眼的地方，我保证你过不了多久就会去买一只鸟回来。”乙不以为然地说：“养只鸟多麻烦啊，我是不会去做这种傻事的。”于是，甲就去买了一只漂亮的鸟笼挂在乙的家中。接下来，只要有人看见那只鸟笼，就会问乙：“你的鸟什么时候死的，为什么死了啊？”不管乙怎么解释，客人还是很奇怪，如果不养鸟，挂个鸟笼干什么。最后人们开始怀疑乙的脑子是不是出了问题，乙只好去买了一只鸟放进鸟笼里，这样比无休止地向大家解释要简单得多。

       鸟笼逻辑的原因很简单：人们绝大部分的时候是采取惯性思维。所以可见在生活和工作中培养逻辑思维是多么重要。这种被别人用习惯思维的逻辑推理误解，并且最终屈服于强大的惯性思维的事情，生活中并不少见。一些创新、改革碰到的阻力大多数就是来自于传统和习惯。突破习惯思维，才能获得进步，我们应该少用“鸟笼逻辑”去推断别人，也不要使自己陷于“鸟笼逻辑”中，成为一个墨守成规、顽固不化的人。要以敢于变通，尝试新举措，突破传统观念，逻辑思维与逆向思维相结合从不同角度进行推理，已达到更好的效果。

12、蝴蝶效应

上个世纪70年代，美国一个名叫洛伦兹的气象学家在解释空气系统理论时说，亚马逊雨林一只蝴蝶翅膀偶尔振动，也许两周后就会引起美国得克萨斯州的一场龙卷风。

蝴蝶效应是说：初始条件十分微小的变化经过不断放大，对其未来状态会造成极其巨大的差别。有些小事可以糊涂，有些小事如经系统放大，则对一个组织、一个国家来说是很重要的，就不能糊涂。
13、青蛙现象

把一只青蛙直接放进热水锅里，由于它对不良环境的反应十分敏感，就会迅速跳出锅外。如果把一个青蛙放进冷水锅里，慢慢地加温，青蛙并不会立即跳出锅外，水温逐渐提高的最终结局是青蛙被煮死了，因为等水温高到青蛙无法忍受时，它已经来不及、或者说是没有能力跳出锅外了。　　
    青蛙现象告诉我们：一些突变事件，往往容易引起人们的警觉，而易致人于死地的却是在自我感觉良好的情况下，对实际情况的逐渐恶化，没有清醒的察觉。
14、鳄鱼法则

其原意是假定一只鳄鱼咬住你的脚，如果你用手去试图挣脱你的脚，鳄鱼便会同时咬住你的脚与手。你愈挣扎，就被咬住得越多。所以，万一鳄鱼咬住你的脚，你唯一的办法就是牺牲一只脚。
   譬如在股市中，鳄鱼法则就是：当你发现自己的交易背离了市场的方向，必须立即止损，不得有任何延误，不得存有任何侥幸。
15、鲇鱼效应

以前，沙丁鱼在运输过程中成活率很低。后有人发现，若在沙丁鱼中放一条鲇鱼，情况却有所改观，成活率会大大提高。这是何故呢?
   原来鲇鱼在到了一个陌生的环境后，就会“性情急躁”，四处乱游，这对于大量好静的沙丁鱼来说，无疑起到了搅拌作用;而沙丁鱼发现多了这样一个“异已分子”，自然也很紧张，加速游动。这样沙丁鱼缺氧的问题就迎刃而解了，沙丁鱼也就不会死了。
16、羊群效应

头羊往哪里走，后面的羊就跟着往哪里走。羊群效应最早是股票投资中的一个术语，主要是指投资者在交易过程中存在学习与模仿现象，“有样学样”，盲目效仿别人，从而导致他们在某段时期内买卖相同的股票。
17、刺猬法则

两只困倦的刺猬，由于寒冷而拥在一起。可因为各自身上都长着刺，于是它们离开了一段距离，但又冷得受不了，于是凑到一起。几经折腾，两只刺猬终于找到一个合适的距离：既能互相获得对方的温暖而又不至于被扎。刺猬法则主要是指人际交往中的“心理距离效应”。

18、二八定律(巴莱多定律)

19世纪末20世纪初意大利的经济学家巴莱多认为，在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的。　　社会约80%的财富集中在20%的人手里，而80%的人只拥有20%的社会财富。这种统计的不平衡性在社会、经济及生活中无处不在，这就是二八法则。
    二八法则告诉我们：不要平均地分析、处理和看待问题，企业经营和管理中要抓住关键的少数;要找出那些能给企业带来80%利润、总量却仅占20%的关键客户，加强服务，达到事半功倍的效果;企业领导人要对工作认真分类分析，要把主要精力花在解决主要问题、抓主要项目上。
19、木桶理论

组成木桶的木板如果长短不齐，那么木桶的盛水量不是取决于最长的那一块木板，而是取决于最短的那一块木板。
20、马太效应

《圣经?马太福音》中有一句名言：“凡有的，还要加给他，叫他有余;没有的，连他所有的，也要夺过来。” 社会学家从中引申出了“马太效应”这一概念，用以描述社会生活领域中普遍存在的两极分化现象。

批评总是让人不舒服的，如何让被批评者不感到疼？呵呵，可以考虑先涂一些肥皂水~

21、肥皂水效应

　　管理学上有一个著名的肥皂水效应。是由美国前总统约翰.卡尔文.柯立芝首先提出的。约翰.卡尔文.柯立芝于1923 年成为美国总统，他有一位漂亮的女秘书，人虽长得很好，但工作中却常因粗心而出错。一天早晨，柯立芝看见秘书走进办公室，，便对她说：“今天你穿的这身衣服真漂亮，正适合你这样漂亮的小姐。”这句话出自柯立芝口中，简直让女秘书受宠若惊。柯立芝接着说：“但也不要骄傲，我相信你同样能把公文处理得像你一样漂亮的。”果然从那天起，女秘书在处理公文时很少出错了。一位朋友知道了这件事后，便问柯立芝：“这个方法很妙，你是怎么想出的？”柯立芝得意洋洋地说：“这很简单，你看见过理发师给人刮胡子吗？他要先给人涂些肥皂水，为什么呀，就是为了刮起来使人不觉痛。”

　　这个故事后来被管理学界称之为“肥皂水效应”：就是将批评夹在赞美中。将对他人的批评夹裹在前后肯定的话语之中，减少批评的负面效应，从而使被批评者愉快地接受对自己的批评。以赞美的形式巧妙地取代批评，以看似简捷的方式达到直接的目的。林肯说，“人人都喜欢受人称赞”，“人类本质中最殷切的需求是渴望被肯定”。人类与生俱来就有一种正常的心理防卫机制。当受到批评时，第一反应是：“我真的错了吗？”紧接着，他的心理就会开始在找理由为自己辩解。所以，批评者后面所说的话几乎都无法进入被批评者的耳朵。肥皂水效应正是遵循并迎合了人类这种最本能的心理需求与反应。这告诫我们，在批评别人时，哪怕是正确的批评，一定要考虑对方的心理，要善于应用对方接受的方式来表达。

当一个员工各项工作表现有好有差，你会选择表扬他的好，还是批评他的差？

22、保龄球效应

      两名保龄球教练分别训练各自的队员。他们的队员都是一球打倒了7只瓶。教练甲对自己的队员说：“很好！打倒了7只。”他的队员听了教练的赞扬很受鼓舞，心里想，下次一定再加把劲，把剩下的3只也打倒。教练乙则对他的队员说：“怎么搞的！还有3只没打倒。”队员听了教练的指责，心里很-全球品牌网-不服气，暗想，你咋就看不见我已经打倒的那7只。结果，教练甲训练的队员成绩不断上升，教练乙训练的队员打得一次不如一次。

　　心理学家研究证明，积极鼓励和消极鼓励（主要指制裁）之间具有不对称性。受过处罚的人不会简单地减少做坏事的心思，充其量，不过是学会了如何逃避处罚而已。常常有这样的议论：“干工作越多错误越多。”潜台词就是：为了避免错误，最好的办法是“避免”工作。这就是批评、处罚等“消极鼓励”的后果。而“积极鼓励”则是一项开发宝藏的工作。受到积极鼓励的行为会逐渐占去越来越多的时间和精力，这会导致一种自然的演变过程，员工身上的一个闪光点会放大成为耀眼的光辉，同时还会“挤掉”不良行为。

　　“我认为，我那能够使员工鼓舞起来的能力，是我所拥有的最大资产。而使一个人发挥最大能力的方法，是赞赏和鼓励。”“再也没有比上司的批评更能抹杀一个人的雄心。我赞成鼓励别人工作。因此我乐于称赞，而讨厌挑错。如果我喜欢什么的话，就是我诚于嘉许，宽于称道。”这就是美国历史上第一个超过百万年薪的著名经理人史考伯做法。史考伯说：“我在世界各地见到许多大人物，还没有发现任何人——不论他多么伟大，地位多么崇高——不是在被赞许的情况下，比在被批评的情况下工作成绩更佳、更卖力气的。”史考伯的信条同安德鲁.卡耐基于出一辙。卡耐基甚至在他的墓碑上也不忘称赞他的下属，他为自己撰写的碑文是：“这里躺着的是一个知道怎样跟他那些比他更聪明的属下相处的人。”

别以为那些躲在暗处的BUG不会冒出来，对于质量，任何时候我们都要：战战兢兢，如履薄冰。

23、墨菲定律

        爱德华·墨菲(Edward A. Murphy)是一名工程师，他曾参加美国空军于 1949年进行的MX981实验。这个实验的目的是为了测定人类对加速度的承受极限。其中有一个实验项目是将16个火箭加速度计悬空装置在受试者上方，当时有两种方法可以将加速度计固定在支架上，而不可思议的是，竟然有人有条不紊地将16个加速度计全部装在错误的位置。于是墨菲作出了这一著名的论断，并被那个受试者在几天后的记者招待会上引用。

       几个月后这一“墨菲定律”被广泛引用在与航天机械相关的领域。经过多年，这一“定律”逐渐进入习语范畴，其内涵被赋予无穷的创意，出现了众多的变体，其中最著名的一条也被称为 Finagle's Law(菲纳格定律)，具体内容为：If anything can go wrong, it will.(会出错的，终将会出错。)。这一定律被认为是对“墨菲定律”最好的模仿和阐述。

为什么我们的任职晋升条件是“达到拟认证级别的关键贡献要求”，而不是“达到本级别关键贡献要求”？也许这样可以规避彼得原理。但实际工作中，彼得原理确实是无处不在。。。

24、彼得原理（The Peter Principle）

     管理学家劳伦斯·彼得（Laurence．J．Peter），根据千百个有关组织中不能胜任的失败实例的分析而归纳出来的。其具体内容是：“在一个等级制度中，每个职工趋向于上升到他所不能胜任的地位”。彼得指出，每一个职工由于在原有职位上工作成绩表现好（胜任），就将被提升到更高一级职位；其后，如果继续胜任则将进一步被提升，直至到达他所不能胜任的职位。由此导出的彼得推论是，“每一个职位最终都将被一个不能胜任其工作的职工所占据。层级组织的工作任务多半是由尚未达到不胜任阶层的员工完成的。”每一个职工最终都将达到彼得高地，在该处他的提升商数（PQ）为零。至于如何加速提升到这个高地，有两种方法。其一，是上面的“拉动”，即依靠裙带关系和熟人等从上面拉；其二，是自我的“推动”，即自我训练和进步等，而前者是被普遍采用的。

　　彼得认为，由于彼得原理的推出，使他“无意间”创设了一门新的科学——层级组织学（Hierarchiolgy）。该科学是解开所有阶层制度之谜的钥匙，因此也是了解整个文明结构的关键所在。凡是置身于商业、工业、政治、行政、军事、宗教、教育各界的每个人都和层级组织息息相关，亦都受彼得原理的控制。当然，原理的假设条件是：时间足够长，层级组织里有足够的阶层。

搞不定的事情，先放一放，没准解决办法就能自己冒出来。是好运气？呵呵，不一定。

25、酝酿效应
      在古希腊，国王让人做了一顶纯金的王冠，但他又怀疑工匠在王冠中掺了银子。可问题是这顶王冠与当初交给金匠的一样重，谁也不知道金匠到底有没有捣鬼。国王把这个难题交给了阿基米德。阿基米德为了解决这个问题冥思苦想,他起初尝试了很多想法，但都失败了。有一天他去洗澡，一边他一边坐进澡盆，以便看到水往外溢，同时感觉身体被轻轻地托起，他突然恍然大悟，运用浮力原理解决了问题。不管是科学家还是一般人，在解决问题的过程中，我们都可以发现“把难题放在一边，放上一段时间，才能得到满意的答案”这一现象。心理学家将其称为“酝酿效应”。阿基米德发现浮力定律就是酝酿效应的经典故事。

      日常生活中，我们常常会对一个难题束手无策，不知从何入手，这时思维就进入了“酝酿阶段”。直到有一天，当我们抛开面前的问题去做其他的事情时，百思不得其解的答案却突然出现在我们面前，令我们忍不住发出类似阿基米德的惊叹，这时，“酝酿效应”就绽开了“思维之花”，结出了“答案之果”。古代诗词说“山重水复疑无路，柳暗花明又一村”正是这一心理的写照。心理学家认为，酝酿过程中，存在潜在的意识层面推理，储存在记忆里的相关信息在潜意识里组合，人们之所以在休息的时候突然找到答案，是因为个体消除了前期的心理紧张，忘记了个体前面不正确的、导致僵局的思路，具有了创造性的思维状态。因此，如果你面临一个难题，不妨先把它放在一边，去和朋友散步、喝茶，或许答案真的会“踏破铁鞋无觅处，得来全不费功夫”。

当与员工进行绩效反馈的时候，到底是先贬后褒好，还是先褒后贬好？？

26、阿伦森效应
     阿伦森是一位著名的心理学家，他认为，人们大都喜欢那些对自己表示赞赏的态度或行为不断增加的人或事，而反感上述态度或行为不断减少的人或事。为什么会这样呢？其实主要是挫折感在作怪。从倍加褒奖到小的赞赏乃至不再赞扬，这种递减会导致一定的挫折心理，但一次小的挫折一般人都能比较平静地加以承受。然而，继之不被褒奖反被贬低，挫折感会陡然增大，这就不大被一般人所接受了。递增的挫折感是很容易引起人的不悦及心理反感的。
【实验】分4组人对某一人给予不同的评价，借以观察某人对哪一组最具好感。第一组始终对之褒扬有加，第二组始终对之贬损否定，第三组先褒后贬，第四组先贬后褒。
【结果】此实验对数十人进行过后，发现绝大部分人对第四组最具好感，而对第三组最为反感。
【应用】阿伦森效应提醒人们，在日常工作与生活中，应该尽力避免由于自己的表现不当所造成的他人对自己印象不良方向的逆转。同样，它也提醒我们在形成对别人的印象过程中，要避免受它的影响而形成错误的态度。
【实例】
1、有效利用
在宿舍楼的后面，停放着一部烂汽车，大院里的孩子们每当晚上7点时，便攀上车厢蹦跳，嘭嘭之声震耳欲聋，大人们越管，众孩童蹦得越欢，见者无奈。这天，一个人对孩子们说：“小朋友们，今**们比赛，蹦得最响的奖玩具手枪一支。”众童呜呼雀跃，争相蹦跳，优者果然得奖。次日，这位朋友又来到车前，说：“今天继续比赛，奖品为两粒奶糖。”众童见奖品直线下跌，纷纷不悦，无人卖力蹦跳，声音疏稀而弱小。第三天，朋友又对孩子们言：“今日奖品为花生米二粒。”众童纷纷跳下汽车，皆说：“不蹦了，不蹦了，真没意思，回家看电视了。”
分析：“正面难攻”的情况下，采用“奖励递减法”可起到奇妙心理效应。
2、反例
小刚大学毕业后分到一个单位工作，刚一进单位，他决心好好地积极表现一番，以给领导和同事们留下非常好的第一印象。于是，他每天提前到单位打水扫地，节假日主动要求加班，领导布置的任务有些他明明有很大的困难，也硬着头皮一概承揽下来。
本来，刚刚走上工作岗位的青年人积极表现一下自我是无可厚议的。但问题是小刚的此时表现与其真正的思想觉悟、为人处世的一贯态度和行为模式相差甚远，夹杂着 “过分表演”的成分。因而就难以有长久的坚持性。没过多久，小刚水也不打了，地也不拖了，还经常迟到，对领导布置的任务更是挑肥拣瘦。结果，领导和同事们对他的印象由好转坏，甚至比那些刚开始来的时候表现不佳的青年所持的印象还不好。因为大家对他已有了一个“高期待、高标准”，另外，大家认为他刚开始的积极表现是“装假”，而“诚实”是我们社会评定一个人所运用的“核心品质”。

为什么我们经常会觉得“星座”、“生肖”、“算命”之类很准？？呵呵，也许是因为以下这个心理效应。

27、巴纳姆效应

        巴纳姆效应是由心理学家伯特伦·福勒于1948年通过试验证明的一种心理学现象，它主要表现为：每个人都会很容易相信一个笼统的、一般性的人格描述特别适合他。即使这种描述十分空洞，他仍然认为反映了自己的人格面貌。这个效应是以一位广受欢迎的著名魔术师肖曼·巴纳姆来命名的，他曾经在评价自己的表演时说：他的节目之所以受欢迎，是因为节目中包含了每个人都喜欢的成分，所以每一分钟都有人上当受骗。

       有位心理学家曾经针对这种一效应做过一个实验，他给一群人做完明尼苏达多项人格调查表（MMPI）后，拿出两份结果让参加者判断哪一份是自己的结果。事实上，一份是参加者自己的结果，另一份是多数人的回答平均起来的结果。参加者竟然认为后者更准确地表达了自己的人格特征。

       巴纳姆效应多少解释了为什么有些星座或生肖书刊能够“准确的”指出某人的性格。原因在此，那些用来描述性格的词句，其实根本属“人之常情”或基本上适用于大部分人身上的。换言之，那些词句的适用范围是如此的空泛，以至往往说了等于没说。

       要避免巴纳姆效应，客观真实地认识自己，有以下几种途径：

       1、学会面对自己。

       2、培养一种收集信息的能力和敏锐的判断力。

       3、以人为镜，通过与自己身边的人在各方面的比较来认识自己。

       4、通过对重大事件，特别是重大的成功和失败认识自己。

如何为我们的组织培养继任人？也许每个组织的领导者都需要一点“贝尔纳精神”。

28、贝尔纳效应

      英国学者贝尔纳是一位著名科学天才，但贝尔纳一生未能获得诺贝尔奖金。贝尔纳的同事和学生们都相信，按创造天赋讲，贝尔纳是可以不止一次地获得诺贝尔奖金的。然而，他一生中最高的荣誉不过是获得英国皇家学会勋章和国外院士之职。贝尔纳为什么没有获得诺贝尔奖金有一种公认的回答是“他总是喜欢提出一个题目，抛出一个思想。首先自己涉足一番，然后，就留给他人去创造出最后的成果。全世界有许许多多的其原始思想应归功于贝尔纳的论文，都在别人的名下出版问世了，……他一直由于缺乏‘面壁十年’的恒心而蒙受了损失”。

　　这句话提出了一个关键问题，即兴趣过于广泛、思维过于发散，对科学创造是非常不利的。后人就将这种现象成为贝尔纳效应。

        贝尔纳效应要求组织的领导者具有伯乐精神、人梯精神和绿叶精神，以组织的大局为先，以组织的发展为重，以工作的需要为急，慧眼识才，潜心育才，放手用才，大胆提拔任用能力比自己强的人，积极为有才干的干部创造脱颖而出的机会和环境。

作为团队管理者，要善于激发团队力量，依靠团队作战，每个人都不是单兵作战的。

29、安泰效应

     安泰效应源自于，古希腊神话中有一个大力神叫安泰，他是海神波塞冬与地神盖娅的儿子，他力大无比，百战百胜。但他有一个致命的弱点，那就是他一旦离开大地，离开母亲的滋养，就失去了一切力量，他的对手刺探了这个秘密，设计让他离开大地，把他高高举起，在空中把他杀了。后来，人们把一旦脱离相应条件就失去某种能力的现象称为“安泰效应”。
      “安泰效应”启示，人不能失去力量的源泉，不能失去赖以生存和发展的必要环境。在企业建设管理中，企业领导管理者，应善于建设集体，让员工有一个必要的环境，并通过教育员工的集体观念，从而使员工明确：组织是肥沃的大地，而自己是生长在这大地上的一株小草，离开了大地，他将枯萎。如果组织凝聚力不强，刚不能给员工的安全的依靠。因此，要学会依靠大家、依靠集体，“我为人人”才有可能“人人为我”。失去了力量和源泉，你纵有“力拨山兮气盖世”的能耐，也终有失败的时候。

下属接手一项任务的时候，他是否充分理解和认可了这个工作的目标和意义？如果不认可，那就要小心了。

30、不值得定律

     最直观的表达为：不值得做的事情，就不值得做好。这个定律反映出人们的一种心理，一个人如果从事的是一份自认为不值得的事情，往往会持冷嘲热讽、敷衍了事的态度。不仅成功率小，即使成功，也不会觉得有多大的成就感。

       值得做的工作是：符合我们的价值观，适合我们的个性与气质，并能让我们看到期望。如果你的工作不具备这三个因素，你就要考虑换一个更合适的工作，并努力做好它。

　　因此，对个人来说，应在多种可供选择的奋斗目标及价值观中挑选一种，然后为之奋斗。选择你所爱的，爱你所选择的，才可能激发我们的斗志，也可以心安理得。而对一个企业或组织来说，则要很好地分析员工的性格特性，合理分配工作，如让成就欲较强的职工单独或牵头完成具有一定风险和难度的工作，并在其完成时，给予及时的肯定和赞扬；让依附欲较强的职工，更多地参加到某个团体中共同工作；让权力欲较强的职工，担任一个与之能力相适应的主管。同时要加强员工对企业目标的认同感，让员工感觉到自己所做的工作是值得的，这样才能激发职工的热情。”

6 && arg.substring(0, 7) == 'bgcolor') color(arg.substring(8, arg.length)) f = eval('parent.' + self.name + 'Init') if (f) f() }

六十六、大声说出你的爱
　　
　　　　谁要是不会爱，谁就不能理解生活。
　　　　——高尔基
　　
　　　　有次我受邀前往外地，发表有关高效率管理的演讲。抵达当晚，主办单位的几个人请我吃饭，顺便聊聊明天来听演讲的是些什么听众。
　　　　艾德显然是这几个人的龙头老大，块头很大，声音十分低沉。他告诉我，他是家大型国际企业的经理，主要职责是到一些分公司，去处理公司内部较为棘手 的人事问题，终止一些高级主管的聘用。
　　　　"乔，"他说："我十分期待明天的演讲，因为这些人在聆听过你的高见后，就会知道我的管理方式是正确的。"他得意地对我笑道。
　　　　我微笑不语，因为我知道明天的情况绝对与他想象的大不相同。
　　　　第二天，艾德表情木然地听完全场演讲，然后一言不发地离开会场。
　　　　三年后，我重返旧地，向相同的听众发表另一篇有关管理的演讲，我在听众群中又发现了艾德。就在演讲即将开始前，他突然站起来，扯着喉咙问我：" 乔，我能先讲几句话吗？"
　　　　我打趣地说："当然，你身材如此魁梧，你爱讲几句就讲几句，我不敢拦你。"
　　　　艾德于是开口："在座的各位都认识我，其中有些人还知道我近来的改变，今天我想把亲身的体验与各位分享。乔，想必我这番话会让你感到欣慰。"
　　　　"三年前的一场演讲里，乔曾表示，若想培养坚韧的意志，首先就该学习向身旁最亲近的人说声我爱你。起初我对这点颇不以为然，心想这种肉麻兮兮的话 和意志坚韧能扯上什么关系？乔说坚韧与坚硬不同，坚韧如同皮革，坚硬则像花岗岩，而一个意志坚韧的人应该是思想开通，不屈不挠，行为自律，做事灵活，这些 话我赞同，但这与爱有什么关系呢？"
　　　　"那晚，我和太太两人坐在客厅的两端，脑中仍想着乔的话。霎时我发现自己竟鼓不起勇气向太太表示爱意，我好几次清了清喉咙，但话到了嘴边，只含糊 地发了些声音，其余的又吞了回去。我太太抬起了头，问我刚才嘟哝了些什么，我若无共事地回答说没事。突然间，我起身走向她，紧张地将她手上的报纸拿开，然 后说：‘艾丽斯，我爱你。'她好一阵子说不出活来，泪水涌上她的眼眶，这时她轻声地说：‘艾德，我也爱你，这是你25年来第一次开口说爱我。'"
　　　　"我们当时感触万千，深深体会到爱能化解一切纷争摩擦。突然间，我像是受到鼓舞般，立刻拨了电话给在纽约的大儿子，我们已经许久没有联络了。我一 听到他的声音便脱口而出：‘儿子，也许你以为我喝醉了，但我现在很清醒。我打电话来只是想告诉你我爱你。'"
　　　　"他在话筒那端沉默了片刻，然后语气平静地说：‘爸，我知道你爱我，真高兴能听到你亲口告诉我，我也要对你说我爱你。'"
　　　　我们开始闲话家常，聊得十分愉快。接着我又打电话给在旧金山的小儿子，告诉他同样的事，结果我们父子畅谈许久，那种温馨的感觉我从未有过。
　　　　"那晚我躺在床上沉思，终于领悟了乔所说的那番话有更深一层的意义：如果我能真正地了解以爱待人的含义而且身体力行，定能对我的管理方式产生正面 的影响。"
　　　　"我开始阅读相关题材的书籍，从中吸取到不少人的宝贵经验，使我更体会到这套哲学能运用到生活的各个层面，无论是家庭或是工作。"
　　　　"你们有些人知道，我彻底改变了与人共事的方式。我开始仔细倾听他人的想法；我学会多欣赏他人的长处，少计较他人的短处；我也体会到帮助别人建立 信心的那种快乐。然而最重要的是，我现在了解，尊敬他人的最佳方法，便是鼓励他们发挥自己的能力，来达到大家共同努力的目的。"
　　　　"乔，借着今天这个机会，我要说声谢谢你。顺便跟大家提一下，我现在是公司的副董事，领导能力颇受肯定。好了，各位，现在专心听他演讲吧！"
　　
　　　　——乔?贝顿
　　
　　
　　六十七、多一句赞美
　　
　　　　人们相互希望得越多，想要给予对方的越多......就必定越亲密。
　　
　　　　几天前，我和一位朋友在纽约搭计程车，下车时，朋友对司机说："谢谢，搭你的车十分舒适。"这司机听了愣了一愣，然后说："你是混黑道的吗？"
　　　　"不，司机先生，我不是在寻你开心，我很佩服你在交通混乱时还能沉住气。"
　　　　"是呀！"司机说完，便驾车离开了。
　　　　"你为什么会这么说？"我不解地问。
　　　　"我想让纽约多点人情味，"他答道，"唯有这样，这城市才有救。"
　　　　"靠你一个人的力量怎能办得到？"
　　　　"我只是起带头作用。我相信一句小小的赞美能让那位司机整日心情愉快，如果他今天载了20位乘客，他就会对这20位乘客态度和善，而这些乘客受了 司机的感染，也会对周遭的人和颜悦色。这样算来，我的好意可间接传达给1000多人，不错吧？"
　　　　"但你怎能希望计程车司机会照你的想法做吗？"
　　　　"我并没有希望他，"朋友回答："我知道这种作法是可遇不可求，所以我尽量多对人和气，多赞美他人，即使一天的成功率只有30％，但仍可连带影响 到3000人之多。"
　　　　"我承认这套理论很中听，但能有几分实际效果呢？""就算没效果我也毫无损失呀！开口称赞那司机花不了我几秒钟，他也不会少收几块小费。如果那人 无动于衷，那也无妨，明天我还可以去称赞另一个计程车司机呀！"
　　　　"我看你脑袋有点天真病了。"
　　　　"从这就可看出你越来越冷漠了。我曾调查过邮局的员工，他们最感沮丧的除了薪水微薄外，另外就是欠缺别人对他们工作的肯定。"
　　　　"但他们的服务真的很差劲呀！"
　　　　"那是因为他们觉得没人在意他们的服务质量。我们为何不多给他们一些鼓励呢？"
　　　　我们边走边聊，途经一个建筑工地，有5个工人正在一旁吃午餐。我朋友停下了脚步，"这栋大楼盖很真好，你们的工作一定很危险辛苦吧？"那群工人带 着狐疑的眼光望着我朋友。
　　　　"工程何时完工？"我朋友继续问道。
　　　　"6月。"一个工人低应了一声。
　　　　"这么出色的成绩，你们一定很引以为荣。"
　　　　离开工地后，我对他说："你这种人也可以列入濒临绝种动物了。"
　　　　"这些人也许会因我这一句话而更起劲地工作，这对所有的人何尝不是一件好事呢？"
　　　　"但光靠你一个人有什么用呢？你不过是一个小民罢了。"
　　　　"我常告诉自己千万不能泄气，让这个社会更有情原本就不是简单的事，我能影响一个就一个，能两个就两个......"
　　　　"刚才走过的女子姿色平庸，你还对她微笑？"我插嘴问道。
　　　　"是呀！我知道，"他答道，"如果她是个老师，我想今天上她课的人一定如沐春风。"
　　
　　　　——雅特?鲍奇华
　　
　　
　　六十八、最后的心愿
　　
　　　　无言的纯洁的天真，往往比说话更能打动人心。
　　　　——莎士比亚
　　
　　　　26岁的母亲凝视着她那罹患血友病而垂死的儿子。虽然她内心充满了悲伤，但同时她也下定决心，就像其它为人父母者，她希望儿子能长大成人，能实现 所有的梦想。如今这一切都不可能了，因为病魔会一直缠绕着他。即使如此，她仍希望儿子的梦想能够实现。
　　　　她握着儿子的手问道："巴柏西，你曾想过长大后要做什么吗？你对自己的一生，有过什么梦想吗？"
　　　　"妈咪，我一直希望长大后能成为消防队员。"
　　　　母亲强忍悲伤，微笑着说："我来想想看能不能让你的愿望成真。"当天稍晚，她到亚历桑纳州凤凰城当地的消防队，找到了消防队员鲍伯，他有一颗宽大 的心。这位母亲向他解释儿子临终的心愿，并请问是否能让他坐上消防车在街角转几圈。
　　　　鲍伯说："不只这样呢，我们还可以做得更好。如果你在星期三早上7点把你儿子带到这里来，我们会让他当一整天的荣誉消防队员。他可以到消防队来， 和我们一起吃饭，一起出勤。对了，如果你把他的尺寸给我，我们还可以帮他订做一套真正的消防制眼，附加一顶真的防火帽，不是玩具帽，上面还有凤凰城消防队 的徽章，印着我们穿的黄色防水衣和橡胶靴。这些东西都是在凤凰城里制造，所以可以很快拿到。"
　　　　3天后，消防队员鲍伯带着巴柏西，帮他穿上消防制服，护送他从医院的病床到消防车上。巴柏西必须端坐在车子后面，鲍伯引领他回到消防队，他仿佛置 身于天堂。
　　　　当天凤凰城有3起火警，巴柏西每次都得出勤务。他乘坐不同的消防车，还有救护车，甚至消防队长的座车。他还为当地的新闻节目拍录影带。
　　　　由于美梦成真以及加注在他身上所有的爱和关怀，令巴柏西深深感动，他比医生所预期的多活了3个月。
　　　　一天晚上，他所有的生命迹象开始急剧下降，护士长急忙打电话通知家属到医院。
　　　　然后她想起巴柏西曾担任过消防队员，因此她也打电话给消防队长，问他是否能派一位穿制服的消防队员到医院来，在巴柏西临终前陪伴他。队长回答 道："我们可以做得更好。5分钟之内就到。你能帮个忙吗？当你听见警笛响、看到警灯闪时，请通知医院，这不是真正的火警，这只是消防队来见他们好伙伴的最 后一面。请你打开他房间的窗户，谢谢。"
　　　　大约5分钟后，一部消防车到达医院，把云梯延伸到巴柏西三楼窗前，有14位消防队员、2位女消防队员爬上云梯进入巴柏西的房间。经过他母亲的同 意，他们拥抱他、握他的手，告诉他他们有多爱他。
　　　　巴柏西咽下最后一口气前，看着消防队长说："队长，我现在能算是真正的消防队员吗？"
　　　　"算！巴柏西。"队长说。
　　　　带着那些话，巴柏西微笑着闭上了眼睛3002

在网上看了一篇关于软件测试管理常见问题及其回答。一大片文档化的东西，没还真要点耐心看。虽然还是小兵一个，但感觉管理这东西还是要基于组织架构的。此文的很多内容有的是针对测试主管的，有的是针对测试经理的。不同的级别有不同的问题以及解决方案。

同化效应和先入为主的定位效应应该是我这种小兵在工作的时候特别要注意的。前一个就不用说了。这个是性格问题。有的同学缺乏对自己的观点的认同感跟坚持，一下子就被忽悠了。至于定位效应的避免需要测试人员对系统以及代码更加熟悉，根据已经产生过BUG的地方，去判断有可能出现的“附加BUG”。只是目前还感觉有些BUG出现的原因比较“灵异”。都不知道为什么会这样。有时候也是自己太懒，不会对BUG的根源刨根问底。

这篇文章贴过来了。PS:以后自己写文档一定要有层次感才好啊！！

软件测试管理常见问题及其回答

1、测试负责人要进行严格的测试进度跟踪吗？
很多时候，由于人力资源的不足，测试项目负责人都是在执行测试，这样就使整个项目缺乏控制，一些问题（例如：有些成员的缺陷质量不够合格；开发人员修改不及时，系统某些功能发生严重问题导致部分功能无法测试。）得不到解决，耽误了进度。所以测试负责任必须全程监控项目，尽可能多的掌握信息。通常，测试负责人需要完成下面这些内容的管理工作：
测试用例执行情况；
每个测试员提交的缺陷情况；
测试中是否发生突发问题。


2、 测试也有版本控制吗？
这里的版本主要是指测试对象的版本控制，也就是指对开发部提交的产品进行版本控制。在开发小组版本管理不规范的情况下，测试小组进行版本控制十分重要，要保证测试对象是可以控制的。建议开发和测试双方进行明确的约定，可以各自指定专门的测试版本负责人，制定提交原则，对提交情况进行详细的记录，这样基本避免了版本失控导致的测试失误或无效。


3、如何处理测试人员的流动问题？
人员流动不仅仅是测试部门，这是IT行业的普遍现象。从管理者角度，主管需要多多和团队内成员进行沟通，建立一个融洽的团队环境，及时掌握情况，可以早些进行相应的调整。但是只有企业建立好的用人制度，给员工提高广阔的发展空间和好的培训学习机会，才能从根本上解决这一问题。
加强项目管理，强化文档管理并保证文档的有效性，可以大大减少由于人员流失带来的损失。同时，测试部门要建立培训机制，使新到员工接受直接或者间接的培训，快速适应工作。


4、为什么开发人员经常抱怨测试工程师提交的缺陷质量太差？
我们经常听开发人员说：“这不是缺陷！”，“这个缺陷没有，因为我的系统上运行正常！”。测试工程师本身就是做质量工作的，提交的成果本身就应该质量高些，为什么还会有这种现象？
提交的缺陷引起争议是一种正常的现象，例如测试人员描述不清楚就会引起争议。减少甚至避免这种现象的方法是交叉测试，交叉测试是提高测试质量的一个有效手段，当然交叉测试会增加一定的测试成本投入。在测试任务完成后，测试工程师之间互相验证彼此提交的缺陷，就会避免了缺陷描述不清、因运行环境而产生的缺陷等一系列问题，从而大大降低了回归测试以及交流的成本，因而这种投入也是值得的，实际开发人员在单元测试阶段也会进行交叉测试，来提高开发质量。
另外，测试人员一定要按照规范描述测试中发现的缺陷，一个缺陷至少描述清楚概要描述、详细描述、重现步骤三方面的内容，缺陷管理参考第八章的内容。


5、“让那些新手来做测试，反正他们也不会什么”正确吗？
在实际项目开发中，我们常常看到有些单位忽视测试团队存在的意义，当要实施测试时，往往临时找几个程序员充当测试人员。也有些单位尽管认识到了组建测试团队的重要性，但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作，这常常导致测试效率低下，测试人员对测试工作索然无味。
根据笔者的经验，测试团队应首先聘请一名资深的测试领域专家，他应具有极为丰富的同类项目软件测试经验，对软件开发过程中常见的缺陷或错误了然于胸;此外，他还具有较好的亲和力和人格魅力。其次，项目测试团队还具有很多具备一技之长的成员，如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本等。
另外，测试团队还应聘请一些兼职成员，如验证测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。至于测试团队里里的测试新手，这部分人可以安排去从事交付验证或黑盒测试之类的


6、测试同化现象是什么？
同化现象是指随着时间的推移，开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一产品，同一组开发人员和同一组测试人员共同配合了很长时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。
招聘新的人员，不同的测试项目组轮换去测试不同的产品，就可以避免。同时建议产品可以发布测试版，更多的人对其进行测试，就可以发现更多的问题。


7、测试工程师如何避免定位效应？
社会心理学家曾作过一个试验：在召集会议时先让人们自由选择位子，之后到室外休息片刻再进入室内入座，如此五至六次，发现大多数人都选择他们第一次坐过的位子。这种现象称为定位效应，说明人们习惯上凡是自己认定的，人们大都不想轻易改变它。
定位效应在开发人员和测试人员身上都有体现。例如开发工程师针对某一自己写的功能，经常进行代码移植，这种复制的“功能”，由于上一次经过调试，在新的地方往往不会认真调试，这些代码往往会带来共享变量冲突等许多种类型的缺陷。
定位效应体现在测试人员身上就是测试过的功能不再进行认真测试：在回归测试时，之前由于进行过认真的测试，往往会认为某些功能是可靠，只要验证一些以前发现的缺陷是否修改完成就可以了。这种现象在反复多次回归时表现的更加突出，因为回归测试中很多功能都会进行多次反复测试。众所周知，开发人员在修改缺陷时往往会引入新的缺陷，测试人员的疏于防范就会把这些缺陷带到用户这里。
解决这种问题的方案一般有两个：
(1)完整的执行测试用例：这种方法投入较大，但是在开发产品时最好在最后一次回归测试时测试的执行一次全部的测试用例。
(2)交叉测试：测试人员交叉测试，就可以很大程度的避免定位效应。测试工程师在回归测试时互相交换任务，反复测试某一功能的机会大大减少，从而也就不会“主观的”人员某些功能没有缺陷。
通常上面的两个方法都是结合使用的，既要进行交叉测试，又要全面执行测试用例，测试覆盖面要尽可能的广泛。


8、测试人员忽然辞职怎么办？
目前IT行业人员流动较大已经成为一种不争的事实，员工的辞职大多数都会给组织带来一定的影响，而这种影响基本是不可能避免的。在测试领域，员工忽然辞职也会带来很大的负面影响，尤其测试队伍规模较小时。面对这种情况，我们所能做的，就是如何最大限度的降低这种影响。
根据作者的经验，主要有两种方法：第一种是在测试人员内部建立一个良好的学习环境，大家互相学习，这样某些特有技术不会被某一个人所掌握，而互相学习和提高自身，也是大多数成员愿意做的；第二种就是在组织中进行知识管理，把技术作为知识沉淀下来，这样新的员工在接手工作时容易上手，通过学习快速适应环境。
此外，日常还要注意工作规范化，例如形成尽可能多的文档，都可以降低员工离职带来的损失。


9、测试人员工作发生问题测试经理应该如何做？
测试人员工作发生问题是测试经理经常要面对的问题，作为测试部门的领导，首先要做的是指出测试人员所犯的错误，使其尽快改正错误。
唯一不能做的就是盯着下属的错误不放。总盯着下属的失误，是一个领导者的最大失误。英国行为学家波特说：当遭受许多批评时，下级往往只记住开头的一些，其余就不听了，因为他们忙于思索论据来反驳开头的批评。身为测试经理要根据测试人员的心理来进行指导，最大限度的调动每个人员的积极性来参加工作。


10、不深入到具体测试工作时，测试经理如何考核员工？
这种现象在测试规模较大的组织中很常见。测试经理应该尽可能的安排每周与每个成员在不被打扰的环境下进行谈话，这样可以尽早发现和解决很多问题。
最为一个测试经理，主要工作之一就是定期的评定组织做了些什么并且是怎样做的。同时还要为员工做一个报告——关于充分了解测试人员正在做什么和怎样做的报告，以此来给测试人员做做工作成绩考核。这份报告要了解到每个人的动态。
测试经理和每个员工重点是谈谈目前的工作，例如大家在工作中的问题或意见；是否需要帮助等。许多管理者经常抱怨没有时间在一周会见每一个员工来谈他们的工作。但是根据作者的经验，如果不能安排时间和员工进行每周的谈话，员工会来打扰测试经理的工作，因为员工很多问题还要要来找测试经理商议。
同时对待员工要用他们能接受的方式，而不是我们自己可以接受的方式。“己之不予，勿施于人”，这条黄金法则可能会对许多生活中的纯粹的社交因素有效，但是并不是总对工作有用。有效率的管理者知道应该逐渐了解每一个员工需要怎样的对待方式。
总之，只有尽可能多的和员工接触，才能更精确的进行考核。


11、测试经理如何面对加班问题？
大多数情况下，作者是不主张加班的。当员工每周工作超过40个小时的时候，他们开始在工作的时候关心自己的事。他们花钱，会给很久没有联系的人打电话，因为员工们一直都在工作。员工不能在太疲劳的状态下完成工作，这是因为他们在工作时不能关心自己，这种情况下通常效率很低。
测试管理工作的重要任务之一就是要创造一个环境，让员工在工作时间内完成工作，同时还要鼓励他们每周不要超过40小时，甚至可以基于他们在40个小时能够完成的工作量给他们酬劳。通常情况下这样做能够提升创造力，从而会逐渐提高效率。
测试工作本身的一个突出特点就是不断重复枯燥、冗长的测试，如果在疲劳状态下，很有可能精力不集中，略过一些重要的测试环节。而且有的时候测试需要编写测试驱动程序，这种情况更需要较好的状态来工作。


12、测试管理者如何面对自己的错误？
每个人都会犯错。我们可能会因为忘记开会而使客户发怒，承认自己犯错是一件尴尬的事情，尤其是管理人员认为对自己负责的项目小组承认犯错可能会失去尊严。如果我们不是经常犯错，承认错误的时候其实能够赢得尊敬。例如我们忘记一次会议，然后为此向同事或者客户道歉，其他的人会理解我们的。
不管做了什么，不要否认或故意忽略自己的失误。故意忽略不会让错误消失，这只会让错误成长为怪物。


13、为什么计划定期的培训?
测试工作和开发工作一样，不但要面对日新月异的新技术，还要学习相关系统的领域知识。只有在不断的学习中，才能做好工作，跟上行业的发展。如果测试管理者没有基于不断的变化而培训员工，就会给组织带来一定的损失。日常培训可以是关于特定项目或者是技术，通常采用下面几种方法：
（1）测试部门内自由交流方式的培训。这种培训的交流比较随意，可以在周五的例会上进行交流，也可以大家一起坐在茶馆里进行交流。方法可以采用“头脑风暴法”，让每个组员讨论一个特定的领域，这种交流方法特别对同时要做很多不同项目的小组比较有益处。当每个人做不同的项目，这会有助于每个人了解你小组所有的工程。
（2）跨部门的互相学习。测试工作需要很多领域以及技术知识，这些知识单靠自学是远远不够的。和其它部门的同事进行交流是一个相当好的办法，大家在工作中可以在技术等各个方面互相得到提高。
（3）外部培训。外部培训尽管投入较高，但也是值得的。这些专家一般在自己的领域非常精通，可以快速提高整个测试团队的水平。也可以通过测试小组介绍一些朋友来进行培训，这种方式可以降低成本。
培训是构造学习型组织的基本条件，也是提高员工水平的重要方法。经常的定期培训，可以增强组织凝聚力，使员工更加愿意长期留在组织中发展。做为测试负责人，定期的进行培训是十分必要的。


14、时间上不允许进行全部测试，测试负责人应该如何做？
这个问题也许十分可笑，可是现实中我们的测试经理们却不得不面对这个问题。这里的全部测试不是指对软件进行遍历测试，而是指测试负责人制定的测试计划包含的全部测试内容。
通常，不管是开发产品还是做具体的项目，都会发生耽误进度的情况。一旦整体进度不能向后延迟，项目相关人员习惯上的做法就是缩减测试时间。尤其在功能还没有开发完成的情况下，这种现象更为突出。
担负着质量重任的测试经理，如何来解决这个问题呢？比较好的做法是按照下面的步骤逐步来完成和改进工作：
（1）按照测试任务的轻重缓急，尽最大努力完成测试任务。在时间不足的情况下，我们应该对测试任务按照优先级来划分，重要紧急的任务先完成。这个时候的测试任务是一种辅助性工作，其目的就是尽最大努力来提高质量。因此，面对这种情况，测试负责人要做的就是带领测试小组充分利用所有资源来保证质量。
（2）在实际工作中和开发人员共同配合，逐步改进工作。只有整个团队的软件开发能力提高了，才能从根源上解决问题。因此，测试负责人要带领团队和开发小组共同寻找适合自己的开发模式，从而使项目规划的更加合理，进而按照预定计划来开展测试工作。
总之，在任何情况下，测试负责人都不应该抱怨。只有积极的面对问题，才能更好的解决问题。


15、公司不重视测试，测试负责人如何开展测试工作？
目前国内的软件公司不重视测试仍然是一种普遍现象。尽管很多公司在意识上已经开始重视测试，但是在具体工作中，往往由于追赶进度、节省资源等方面原因而忽略测试工作。在这种情况下，测试负责人仍要对软件质量负主要责任。在这种环境下，测试负责人应该如何开展工作呢？
首先，要主动去配合开发人员完成工作。尤其是不能抱怨环境，在任何情况下抱怨是不能解决问题的，只能加重矛盾的激化。在此基础上，逐渐显出测试工作的重要性，然后再逐步健全测试体系。
其次，用实际行动来证明测试工作的重要性。只有测试工作的业绩逐步表现出来，人们才会真正的注意到测试的重要性。因此，测试负责人从点滴开始做起，才能逐步做好测试工作。
要想做好软件，把开发的软件产品形成商品，测试工作必须和开发一样重视。否则，质量不好的产品，很快会被市场淘汰的。现代的软件规模越来越大，测试工作也会越来越重要，因此测试负责人只要坚持做好工作，可发挥作用的空间会越来越大。
最后要说的是，如果真的是在一个没有希望的团队里，测试负责人可以考虑辞职。辞职也是一个不错的选择，到新的环境去发挥自己的能力，要比长时间的怀着“郁闷”的心情去工作好的多。


16、测试管理者需要是技术专家吗？
测试管理者在测试项目中的主要任务是制定测试策略，管理测试计划的落实情况，并且还要为测试项目的进行创造良好的执行环境。同时还要调动员工的创造性，对员工的工作作出评估。这些工作不一定要求测试管理者达到专家的水平。
但是在实际工作中，由于测试人员的短缺，测试管理者常常做为测试员来执行具体的测试任务。尤其在规模较小的测试团队，测试管理者的日常工作通常以具体的测试执行工作为主，这个时候更需要测试管理者有较好的背景知识。
总体说来，技术方面的背景知识对测试管理者是十分有益的。例如：分配工作任务、做进度预算，以及一些具体的执行工作，都需要一定的背景知识。当然，做为一个测试管理者，没有必要精通所有的技术，那也是办不到的。测试管理者做到正确的帮助员工最好地完成工作，并且提供最好的完成工作的环境就可以了。

转自：http://www.51testing.com/?uid-5387-action-viewspace-itemid-20793

1、“不关我事”：身为管理者，只要是公司的事情，事无巨细，都有一份责任。即使是完全在职责之外，态度和蔼地给予一些指引，也能表现出自己的成熟大度和礼节。工作当中很多时候都是说者无心，听者有意，对下属说一句这样的话语很容易将自己的形象彻底颠覆，对同事说一句这样的话语会激发矛盾产生误解，对上司说一句这样的话语可能意味着你该调整岗位了。

2、“为什么你们……”：在责问别人时，想一想自己有没有什么过失，尽了多少力多少心。有时，宽容地对待别人的错误，会使人更加振作，更加进步。用一连串的“为什么”去发难于人，得到的也可能是一连串的“为什么”的答案。反过来问：为什么我没有配合好你们？你们有什么地方需要我？也许事情会解决得更快一些的。

3、“上面怎样骂我，我就怎样骂你们”：作为管理者，起的是一个上传下达的桥梁的作用，但绝不是一个简单的传递。对上，要忠诚尽责，完成任务；对下，要想方设法，给予激励帮助支持。敢于承受来自上面的压力，担负起责任，敢于缓和下级的紧张，创造和谐的工作环境，才是一个管理者最应该做的事情。

4、“我也没办法”：管理者的能力，从某种方面来说，是用解决问题的能力来衡量的。只会强调客观原因，不会积极的心态去调动一切可用的资源，显露出来的肯定是无可奈何和对上级以及下属的打击。要相信办法总是比困难多，相信集体的智慧是可以攻克一切堡垒的。

5、“我说不行就不行”：以自我为中心的话语，与事实没有合理性的解释，很难服人的。凡事不能以事实为依据，不能本着商讨的态度来解决，可能会使事态更进一步的恶化。其实即使是错的意见，听听也无妨，应该是本着有则改之，无则加勉的心态来对待自己和别人。片面的做出判断，有时就是一种武断，说不行就不行，一定要有科学的分析和依据，这样才能降低判断结果错误的风险，保证判断的正确性。

6、“你说怎样就怎样”：听起来象是气话，又象是不负责任的话。在产生一些争议时，当一些意见没有被采纳时，这样的话脱口而出，听者会认为，你的见解毫无是处，本来还有可接受的地方，会变得全盘否认，而且从此将可能不再向你征询看法和想法了。保持冷静的头脑和清晰的思维，说出所有的思想，提供参考，并不因没有被使用而太过激动，是一个管理者良好的品质和性格。

7、“我随时可以怎样”：强权气势的话语，让人听到了就有一种很不舒服的感觉，换句话来说，你以为你是谁？你想怎样就怎样，你到底有多大的能耐？以势压人，只会贬损个人的形象，在大家心中埋下抱怨的种子，这种抱怨，一旦暴发，其弹力之大，是无可想象的。所以保持平意近人，多些尊重他人，是自己尊严的体现。

8、“你真的很笨”：奚落、讽刺、挖苦员工的话语是在伤害员工自尊及感情，“哀莫大于心死”，表面上员工是在听你的，按你说的去做，但实际上员工只是在敷衍了事，因为他根本体会不到工作的乐趣，工作质量肯定不高。同时，因为奚落、讽刺、挖苦更多的是伤害员工的心灵，长期以往，员工的自尊被摧毁，自信被打击，智慧被扼杀，工作可能干得更不好，最后抱着“死猪不怕开水烫”的态度，对员工、对管理者、对企业的都是不利的。

9、“不行啦，我能力有限，谁行谁来做”：如果是真正认识到自己的能力有限，能够迎头赶上，自我充电，或许可说是一种有自知之明而且有上进心的表现，也算是一大幸事。但如果是用这句话来抵触工作，来嘲笑挖苦他人，来掩饰自己内心的慌张，全无挑战工作的意识，则可以说，说这句话的管理者无形中已散失了一个管理人最基本的素养，他已不配再做管理者了。

10、“都很好”、“蛮不错”：泛泛的表扬，既缺乏诚意又不能振奋整体、激励个体，因为人皆不喜欢廉价的、言不由衷的恭维，因此表扬的言语策略应该是及时、有代表性、有充实具体的内容，能够体现被表扬者风貌的语言。不实的表扬表现在用夸大的言辞去称赞不足为奇的小事，有用心炮制的嫌疑，该类表扬其危害在于只令被表扬者高兴，而令所有其他人反感。极力吹捧的行为，其结果往往导致民心的背离，因此人才管理中，及时且适度的赞美言辞是领导者必须掌握的一门学问。

从2008年12月开始，到2009年5月结束，半年的时间里我短暂的带领一个10人的测试团队，负责公司光网络网管系统产品的试生产测试。这是我第一次做软件测试管理，虽然测试的最终结果并不让人十分满意，我的工作大家也不是十分认可，但我还是认为我学到了许多东西，包括一些测试管理的经验及教训，总结如下：

一、不要给自己分配过多的测试任务，以便留有时间思考及调整

初为测试管理人员，我们常常在短时间之内无法把身份调整过来，总认为自己还是骨干测试人员，于是给自己分配置了很多的测试任务。殊不知，除了测试任务之外，我们还有更重要的测试管理任务，比如测试任务分配、跟踪和汇报，并且时不时有些额外任务加进来，而且都可能是紧急且重要的任务，这些都需要你亲自完成。此外，杂七杂八的事情也多，版本协调呀、故障处理协调呀、CCB会议呀等等，这些都会让你忙得脱不开身。

于是我们就常常加班，为了测试执行任务，也为了测试管理任务。我们总是很忙，但是忙的结果却不太好，不论是测试执行任务的结果，还是测试管理任务的结果。其实，原因不在其它，也正是因为给自己分配了过多的任务，我们没有调整好自己的工作重心，我们太忙了，而又忙得没有头绪。

二、需要努力地使自己挤出时间与测试人员做沟通，这很重要

我们常常会说因为自己很忙，抽不出时间，或者说因为自己不善沟通，反正大家都知道自己要做什么，所以不与测试人员沟通也没有什么问题。其实我们错了，尤其是在刚走上测试管理岗位的时候，与测试人员的沟通对我们来说很重要！

不沟通，你知道测试人员在想什么吗？不沟通，你知道测试人员在担心什么吗？不沟通，你知道有的测试人员对你有什么意见吗？不沟通，你知道测试人员最近碰到了什么问题吗？不沟通，你知道测试人员对最近的加班很不满吗？

不沟通，你不会知道的。我们常常说如果有事情，测试人员会来找我们沟通的，所以我们不用主动去找他们沟通，但你忘了，你的角色已经改变了，只有你主动找他们才行，他们是不会主动找上门来的，除非是他们想离职走人。此外，沟通千万记得不要用邮件的方式，最好是当面沟通，这样的效果最好。

三、积极转变观念，从全局把握测试过程，抓住测试重点

以前的我们只需要考虑一个系统模块，使用什么样的测试方法可以找出更多的问题就可以了，但现在不行。我们要考虑的是全局，考虑到哪个是测试重点，哪个任务需要在短期内完成，哪个模块要加强测试，哪位测试人员需要督促，下一步测试工作该怎么开展等等，可惜的是，我们有时常常拣了芝麻，忘了西瓜。

以前作为测试人员，我们是一个人，但现在，作为测试管理人员，我们是一个团队，不再是一个人，这个观念很重要。

四、主动让领导和测试人员知道你在忙什么，让他们认同你

很多时候，做事都是这样，明明你做了很多事情，但是你的领导不知道，你的手下也不清楚。到头来，你会落得两头埋怨，甚至他们会觉得你根本就没有做事，或者你做的事情都不是你应该做的，该做的事情你又没做。

主动让领导和测试人员知道你在忙什么很重要，不要单纯的以为不说他们也看得到。让他们知道你在忙什么，至少他们会知道你在很努力的做事情，你也没有闲着，你不是单纯的所谓管理人员，你也是干活的。否则，他们可能会说，这人之前还和我们一样呢，可现在倒真的成领导了。

五、做好测试计划和测试风险评估，及时做好对策

一个好的测试计划很重要，至少让我们知道该如何分段组织工作，如何做，但更重要的是，我们需要做好风险预防。也许我们常会因为测试工期太短，需要要求测试人员加班，可你知道吗？过几天是情人节，再过几天是元宵节，你还让要求加班吗？也许你会觉得元宵节算是什么节日？！可事实是，在许多人的心目中，它是一个很重要的节日。

你要了解你的测试人员，他们有不同的性格和想法，每个人都不同，所以对症下药是最最关键的，要多了解，多沟通。

六、有理有节的为测试人员和自己拒绝不合适的任务

作为一个测试管理人员，我们的任务除了下发任务、跟踪任务等等之外，另外一个很重要的任务就是为测试人员拒绝一些额外的、不合适的任务。测试人员本来就很忙，如果再增加任务，原来的事情还得做完，这样的话，无论对测试任务的质量，还是对测试人员本身，都是一个很大的伤害！

除此之外，我们还得考虑到自己的能力及时间，为自己拒绝一些任务，否则，很可能的结果是，吃力不讨好。

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

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

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

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

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）对于给出的技能点的培训任务的担当和完成情况。

  总结：

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

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

1、测试负责人要进行严格的测试进度跟踪吗？

很多时候，由于人力资源的不足，测试项目负责人都是在执行测试，这样就使整个项目缺乏控制，一些问题（例如：有些成员的缺陷质量不够合格；开发人员修改不及时，系统某些功能发生严重问题导致部分功能无法测试。）得不到解决，耽误了进度。所以测试负责任必须全程监控项目，尽可能多的掌握信息。通常，测试负责人需要完成下面这些内容的管理工作：

测试用例执行情况；

每个测试员提交的缺陷情况；

测试中是否发生突发问题。

2、 测试也有版本控制吗？

这里的版本主要是指测试对象的版本控制，也就是指对开发部提交的产品进行版本控制。在开发小组版本管理不规范的情况下，测试小组进行版本控制十分重要，要保证测试对象是可以控制的。建议开发和测试双方进行明确的约定，可以各自指定专门的测试版本负责人，制定提交原则，对提交情况进行详细的记录，这样基本避免了版本失控导致的测试失误或无效。

3、如何处理测试人员的流动问题？

人员流动不仅仅是测试部门，这是IT行业的普遍现象。从管理者角度，主管需要多多和团队内成员进行沟通，建立一个融洽的团队环境，及时掌握情况，可以早些进行相应的调整。但是只有企业建立好的用人制度，给员工提高广阔的发展空间和好的培训学习机会，才能从根本上解决这一问题。

加强项目管理，强化文档管理并保证文档的有效性，可以大大减少由于人员流失带来的损失。同时，测试部门要建立培训机制，使新到员工接受直接或者间接的培训，快速适应工作。

4、为什么开发人员经常抱怨测试工程师提交的缺陷质量太差？

我们经常听开发人员说：“这不是缺陷！”，“这个缺陷没有，因为我的系统上运行正常！”。测试工程师本身就是做质量工作的，提交的成果本身就应该质量高些，为什么还会有这种现象？

提交的缺陷引起争议是一种正常的现象，例如测试人员描述不清楚就会引起争议。减少甚至避免这种现象的方法是交叉测试，交叉测试是提高测试质量的一个有效手段，当然交叉测试会增加一定的测试成本投入。在测试任务完成后，测试工程师之间互相验证彼此提交的缺陷，就会避免了缺陷描述不清、因运行环境而产生的缺陷等一系列问题，从而大大降低了回归测试以及交流的成本，因而这种投入也是值得的，实际开发人员在单元测试阶段也会进行交叉测试，来提高开发质量。

另外，测试人员一定要按照规范描述测试中发现的缺陷，一个缺陷至少描述清楚概要描述、详细描述、重现步骤三方面的内容，缺陷管理参考第八章的内容。

5、“让那些新手来做测试，反正他们也不会什么”正确吗？

在实际项目开发中，我们常常看到有些单位忽视测试团队存在的意义，当要实施测试时，往往临时找几个程序员充当测试人员。也有些单位尽管认识到了组建测试团队的重要性，但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作，这常常导致测试效率低下，测试人员对测试工作索然无味。

根据笔者的经验，测试团队应首先聘请一名资深的测试领域专家，他应具有极为丰富的同类项目软件测试经验，对软件开发过程中常见的缺陷或错误了然于胸;此外，他还具有较好的亲和力和人格魅力。其次，项目测试团队还具有很多具备一技之长的成员，如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本等。

另外，测试团队还应聘请一些兼职成员，如验证测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。至于测试团队里里的测试新手，这部分人可以安排去从事交付验证或黑盒测试之类的

6、测试同化现象是什么？

同化现象是指随着时间的推移，开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一产品，同一组开发人员和同一组测试人员共同配合了很长时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。

招聘新的人员，不同的测试项目组轮换去测试不同的产品，就可以避免。同时建议产品可以发布测试版，更多的人对其进行测试，就可以发现更多的问题。

7、测试工程师如何避免定位效应？

社会心理学家曾作过一个试验：在召集会议时先让人们自由选择位子，之后到室外休息片刻再进入室内入座，如此五至六次，发现大多数人都选择他们第一次坐过的位子。这种现象称为定位效应，说明人们习惯上凡是自己认定的，人们大都不想轻易改变它。

定位效应在开发人员和测试人员身上都有体现。例如开发工程师针对某一自己写的功能，经常进行代码移植，这种复制的“功能”，由于上一次经过调试，在新的地方往往不会认真调试，这些代码往往会带来共享变量冲突等许多种类型的缺陷。

定位效应体现在测试人员身上就是测试过的功能不再进行认真测试：在回归测试时，之前由于进行过认真的测试，往往会认为某些功能是可靠，只要验证一些以前发现的缺陷是否修改完成就可以了。这种现象在反复多次回归时表现的更加突出，因为回归测试中很多功能都会进行多次反复测试。众所周知，开发人员在修改缺陷时往往会引入新的缺陷，测试人员的疏于防范就会把这些缺陷带到用户这里。

解决这种问题的方案一般有两个：

(1)完整的执行测试用例：这种方法投入较大，但是在开发产品时最好在最后一次回归测试时测试的执行一次全部的测试用例。

(2)交叉测试：测试人员交叉测试，就可以很大程度的避免定位效应。测试工程师在回归测试时互相交换任务，反复测试某一功能的机会大大减少，从而也就不会“主观的”人员某些功能没有缺陷。

通常上面的两个方法都是结合使用的，既要进行交叉测试，又要全面执行测试用例，测试覆盖面要尽可能的广泛。

8、测试人员忽然辞职怎么办？

目前IT行业人员流动较大已经成为一种不争的事实，员工的辞职大多数都会给组织带来一定的影响，而这种影响基本是不可能避免的。在测试领域，员工忽然辞职也会带来很大的负面影响，尤其测试队伍规模较小时。面对这种情况，我们所能做的，就是如何最大限度的降低这种影响。

根据作者的经验，主要有两种方法：第一种是在测试人员内部建立一个良好的学习环境，大家互相学习，这样某些特有技术不会被某一个人所掌握，而互相学习和提高自身，也是大多数成员愿意做的；第二种就是在组织中进行知识管理，把技术作为知识沉淀下来，这样新的员工在接手工作时容易上手，通过学习快速适应环境。

此外，日常还要注意工作规范化，例如形成尽可能多的文档，都可以降低员工离职带来的损失。

9、测试人员工作发生问题测试经理应该如何做？

测试人员工作发生问题是测试经理经常要面对的问题，作为测试部门的领导，首先要做的是指出测试人员所犯的错误，使其尽快改正错误。

唯一不能做的就是盯着下属的错误不放。总盯着下属的失误，是一个领导者的最大失误。英国行为学家波特说：当遭受许多批评时，下级往往只记住开头的一些，其余就不听了，因为他们忙于思索论据来反驳开头的批评。身为测试经理要根据测试人员的心理来进行指导，最大限度的调动每个人员的积极性来参加工作。

10、不深入到具体测试工作时，测试经理如何考核员工？

这种现象在测试规模较大的组织中很常见。测试经理应该尽可能的安排每周与每个成员在不被打扰的环境下进行谈话，这样可以尽早发现和解决很多问题。

最为一个测试经理，主要工作之一就是定期的评定组织做了些什么并且是怎样做的。同时还要为员工做一个报告——关于充分了解测试人员正在做什么和怎样做的报告，以此来给测试人员做做工作成绩考核。这份报告要了解到每个人的动态。

测试经理和每个员工重点是谈谈目前的工作，例如大家在工作中的问题或意见；是否需要帮助等。许多管理者经常抱怨没有时间在一周会见每一个员工来谈他们的工作。但是根据作者的经验，如果不能安排时间和员工进行每周的谈话，员工会来打扰测试经理的工作，因为员工很多问题还要要来找测试经理商议。

同时对待员工要用他们能接受的方式，而不是我们自己可以接受的方式。“己之不予，勿施于人”，这条黄金法则可能会对许多生活中的纯粹的社交因素有效，但是并不是总对工作有用。有效率的管理者知道应该逐渐了解每一个员工需要怎样的对待方式。

总之，只有尽可能多的和员工接触，才能更精确的进行考核。

11、测试经理如何面对加班问题？

大多数情况下，作者是不主张加班的。当员工每周工作超过40个小时的时候，他们开始在工作的时候关心自己的事。他们花钱，会给很久没有联系的人打电话，因为员工们一直都在工作。员工不能在太疲劳的状态下完成工作，这是因为他们在工作时不能关心自己，这种情况下通常效率很低。

测试管理工作的重要任务之一就是要创造一个环境，让员工在工作时间内完成工作，同时还要鼓励他们每周不要超过40小时，甚至可以基于他们在40个小时能够完成的工作量给他们酬劳。通常情况下这样做能够提升创造力，从而会逐渐提高效率。

测试工作本身的一个突出特点就是不断重复枯燥、冗长的测试，如果在疲劳状态下，很有可能精力不集中，略过一些重要的测试环节。而且有的时候测试需要编写测试驱动程序，这种情况更需要较好的状态来工作。

12、测试管理者如何面对自己的错误？

每个人都会犯错。我们可能会因为忘记开会而使客户发怒，承认自己犯错是一件尴尬的事情，尤其是管理人员认为对自己负责的项目小组承认犯错可能会失去尊严。如果我们不是经常犯错，承认错误的时候其实能够赢得尊敬。例如我们忘记一次会议，然后为此向同事或者客户道歉，其他的人会理解我们的。

不管做了什么，不要否认或故意忽略自己的失误。故意忽略不会让错误消失，这只会让错误成长为怪物。

13、为什么计划定期的培训?

测试工作和开发工作一样，不但要面对日新月异的新技术，还要学习相关系统的领域知识。只有在不断的学习中，才能做好工作，跟上行业的发展。如果测试管理者没有基于不断的变化而培训员工，就会给组织带来一定的损失。日常培训可以是关于特定项目或者是技术，通常采用下面几种方法：

（1）测试部门内自由交流方式的培训。这种培训的交流比较随意，可以在周五的例会上进行交流，也可以大家一起坐在茶馆里进行交流。方法可以采用“头脑风暴法”，让每个组员讨论一个特定的领域，这种交流方法特别对同时要做很多不同项目的小组比较有益处。当每个人做不同的项目，这会有助于每个人了解你小组所有的工程。

（2）跨部门的互相学习。测试工作需要很多领域以及技术知识，这些知识单靠自学是远远不够的。和其它部门的同事进行交流是一个相当好的办法，大家在工作中可以在技术等各个方面互相得到提高。

（3）外部培训。外部培训尽管投入较高，但也是值得的。这些专家一般在自己的领域非常精通，可以快速提高整个测试团队的水平。也可以通过测试小组介绍一些朋友来进行培训，这种方式可以降低成本。

培训是构造学习型组织的基本条件，也是提高员工水平的重要方法。经常的定期培训，可以增强组织凝聚力，使员工更加愿意长期留在组织中发展。做为测试负责人，定期的进行培训是十分必要的。

14、时间上不允许进行全部测试，测试负责人应该如何做？

这个问题也许十分可笑，可是现实中我们的测试经理们却不得不面对这个问题。这里的全部测试不是指对软件进行遍历测试，而是指测试负责人制定的测试计划包含的全部测试内容。

通常，不管是开发产品还是做具体的项目，都会发生耽误进度的情况。一旦整体进度不能向后延迟，项目相关人员习惯上的做法就是缩减测试时间。尤其在功能还没有开发完成的情况下，这种现象更为突出。

担负着质量重任的测试经理，如何来解决这个问题呢？比较好的做法是按照下面的步骤逐步来完成和改进工作：

（1）按照测试任务的轻重缓急，尽最大努力完成测试任务。在时间不足的情况下，我们应该对测试任务按照优先级来划分，重要紧急的任务先完成。这个时候的测试任务是一种辅助性工作，其目的就是尽最大努力来提高质量。因此，面对这种情况，测试负责人要做的就是带领测试小组充分利用所有资源来保证质量。

（2）在实际工作中和开发人员共同配合，逐步改进工作。只有整个团队的软件开发能力提高了，才能从根源上解决问题。因此，测试负责人要带领团队和开发小组共同寻找适合自己的开发模式，从而使项目规划的更加合理，进而按照预定计划来开展测试工作。

总之，在任何情况下，测试负责人都不应该抱怨。只有积极的面对问题，才能更好的解决问题。

15、公司不重视测试，测试负责人如何开展测试工作？

目前国内的软件公司不重视测试仍然是一种普遍现象。尽管很多公司在意识上已经开始重视测试，但是在具体工作中，往往由于追赶进度、节省资源等方面原因而忽略测试工作。在这种情况下，测试负责人仍要对软件质量负主要责任。在这种环境下，测试负责人应该如何开展工作呢？

首先，要主动去配合开发人员完成工作。尤其是不能抱怨环境，在任何情况下抱怨是不能解决问题的，只能加重矛盾的激化。在此基础上，逐渐显出测试工作的重要性，然后再逐步健全测试体系。

其次，用实际行动来证明测试工作的重要性。只有测试工作的业绩逐步表现出来，人们才会真正的注意到测试的重要性。因此，测试负责人从点滴开始做起，才能逐步做好测试工作。

要想做好软件，把开发的软件产品形成商品，测试工作必须和开发一样重视。否则，质量不好的产品，很快会被市场淘汰的。现代的软件规模越来越大，测试工作也会越来越重要，因此测试负责人只要坚持做好工作，可发挥作用的空间会越来越大。

最后要说的是，如果真的是在一个没有希望的团队里，测试负责人可以考虑辞职。辞职也是一个不错的选择，到新的环境去发挥自己的能力，要比长时间的怀着“郁闷”的心情去工作好的多。

16、测试管理者需要是技术专家吗？

测试管理者在测试项目中的主要任务是制定测试策略，管理测试计划的落实情况，并且还要为测试项目的进行创造良好的执行环境。同时还要调动员工的创造性，对员工的工作作出评估。这些工作不一定要求测试管理者达到专家的水平。

但是在实际工作中，由于测试人员的短缺，测试管理者常常做为测试员来执行具体的测试任务。尤其在规模较小的测试团队，测试管理者的日常工作通常以具体的测试执行工作为主，这个时候更需要测试管理者有较好的背景知识。

总体说来，技术方面的背景知识对测试管理者是十分有益的。例如：分配工作任务、做进度预算，以及一些具体的执行工作，都需要一定的背景知识。当然，做为一个测试管理者，没有必要精通所有的技术，那也是办不到的。测试管理者做到正确的帮助员工最好地完成工作，并且提供最好的完成工作的环境就可以了。

    刚接到这个题目的时候也有一些犯难，测试流程在不同的公司都会有微小的差异，而这些差异就有可能会决定测试流程是否是真正适用。在不同公司，不同的现状情况引入适合的测试流程，就好像如同在《寻秦记》中提到的剑圣，他的三个徒弟剑法的风格类型完全不一样同，这一点上，因材施教是非常重要的。其实在动笔撰写本文的时候之前，我一直觉的感受到很大压力很大，这其中最重要的原因莫过于怕误人子弟了。测试流程的制定不是一门科学，而有时看起来，它更像一门艺术，一个好的测试管理者其实在面对不同的公司，不同的研发阶段，会采用不同的测试流程,或是而同样的测试流程，为了真正达到执行的效果，执行的方法也可能不一样。

    实施测试流程一般都是有两个原因：一是软件质量出现的了问题，虽然在某种程度上已经得到解决，但仍需要通过测试，把预防措施的方法找到并固化下来；还有另一个原因则种是软件研发的规模壮大，要求做的在流程上更加清晰，可靠更好。我个人从我自己的角度出发最怕以下一某些情况是让人非常头疼的：一种情况是，是今天刚看了一本书，被告知说这样做是规范应该这样制定的，而明天就要引入进来，完全不考虑公司的实际情况；另一种情况是“苏联模式”，二是那种即某某大公司的测试流程如此制定是这样做的，我们也要采用相同的方法这样。其实流程没有最好的，只有适合自己的，规范的测试流程不一定会帮助研发成功，反而在某些情况下会弄不好羁绊到自己自己的工作。

• 现在大多数测试人会犯一个共同的错误，往往——把流程设计的得很完美，但没有可操作性很差，无法帮助对于软件公司真正的目的——研发，并没有起到应有的作用成功，久而久之测试的重要性就无从谈起，测试团队也渐渐在公司变成次要部门，成为打杂的得不到应有的重视。
• 在流程的设计过程中，最重要的问题在于是目当前项目的特点是什么，产品经常出什么样的哪些问题，需要做什么怎样的调整，现有测试团队能不能做这样的能否做作出调整，研发团队是不是会不会能接收接受?

首先谈谈项目特点，按照项目特点，大致可以一般来说分成两类：

• 一种是长期进行的项目，这种项目有基本的框架，有核心的技术，应用比较稳定，这种项目要注重测试用例的积累与复用，同时也适合做单元测试，自动化测试的积累；
• 另一种是变更频度更高，灵活，规模不大的项目，如果做自动化测试则会出现二次开发的时间大于手工测试的时间，而且项目结束后测试用例在长期中也没有任何复用，在自动化测试人员普遍成本比较高的情况下，所以反而更适做功能测试。
• 虽然这两者可能在长远的目标上并不一致，但是引入测试管理平台，从测试需求、测试设计、缺陷管理等方面入手则是测试团队必备的技能。一个好的测试流程必需要有好的系统平台的支撑，如果你把测试流程设计的得很完美，跟如同小学语文教科书一样，但执行这样的流程在起来现有的资源的情况下是未免不现实，倒并非说详细的流程是洪水猛兽，只是对于一家软件公司来说，资源的限制仍然是瓶颈所在的。，那流程也就没有意义，一般来说一个执行的得好的测试流程必然会有好的平台，就像我以前所在国内的几家很有声名的软件公司，其测试平台要不是么是采购的，就要么是自己开发的，但最主要是要适合自己一套适合自身特点的流程平台起了非常积极的作用。在这里也给大家建议一些好的测试平台，比如Mercury Interactive的Test Director，、IBM的TestManager,、Silk的一些缺陷管理平台，这些平台大多都能充分满足测试团队的要求其实都能满足大家的要求。当然，还有一些免费的开源工具也是可用的。但从长远的角度看，我还是更建议大家读者使用那些不仅仅只是满足缺陷管理的工具，而是要应该选择能集成测试需求、测试设计、测试用例、缺陷管理的工具，最好也能满足自动化的集成的，什么样的产品能满足就不多说了，免得有打广告之嫌，而商业软件，如MI或IBM的产品在这些方面都有较好的表现。
• 项目特点决定流程的长期目标，但对于不同产品类型的公司，可能出现的问题往往会不一样同。比如说在金蝶的EAS-BossBOSS、或是在金山做的游戏软件、亦或还是在阿里巴巴做电子商务，作为测试管理者，就要具体的问题都应该区别对待。

对于EAS-Boss这样大型的软件产品，团队的规模比较大，核心技术比较稳定。但对于这样的这样的产品有以下一些特点：

• 由于产品比较大，手工测试时重复的工作量特别大；
• 引擎与产品框架比较稳定；
• 编译与发布的流程比较固化；
• 由于团队的规模比较大，接口特别多，集成测试风险特别高；。

这样种产品的测试，主要是把大量的重复频度比较高的功能测试转化为自动化测试角本脚本，在开发过程中要注意，核心引擎与稳定的产品部分，尽可能使用测试框架形成单元测试集，同时由于编译与发布固化，适合做每日编译，自动化的执行单元测试集与自动化的测试角本。在做这种测试流程时，同时还要注意引入强大的分析统计工具，比如代码覆盖与评审工具，内存检查与性能函数分析工具，出错表统计模块，达到发布、测试执行与评估自动化、一体化。由于进行每日集成，接口的问题可以尽早的暴露出来，避免了后期集成的风险。

• 这一点每日集成对于大型项目非常重要。同时，由于测试的自动化，大部分的自动化测试角本在空闲的时间运行，测试组可以在进入手工测试时得到比较稳定的版本，及大极大的提升了团队开发与测试的执行效率，。但然而在这样的情况下，缺陷点是整个团队对研发，、测试体系的技术要求特别高，其本上不亚于有时甚至难过做一个大型的项目。这样的测试流程在，在中小团队比较难以实现比较困难，而关键就在于无法降低的成本比较高。下图就是一个稳定项目的测试流程图。

• 游戏软件产品的测试流程又有不同。当你去带领这个测试团队一个游戏团队时，可能游戏核心引擎应该是比较相对稳定的，而游戏内部的故事情节可能会不断的变化，。这时你可把一些更加稳定的程序做成比较稳定的自动化回归测试，同时加强对不断变化的游戏情节的功能测试，同时注意这些功能是不是否会影响到其它相关的模块。同时在因此，游戏测试的过程中还有一些比较有其特殊性，主要表现以下几点：
• 服务器的稳定性，网络流量，与安全是游戏最至关重要的，（往往有很多游戏不是不好玩，而是太不稳定）；
• 游戏由于有及时的即时更新，会经常在同时修改缺陷的时候，还在同一模块下增加新功能；
• 好的网络游戏开发，其的功能必然会是迎合玩家的需求(游戏性 分析)。

  对于游戏软件产品来说，这些需要特别注意重点控制的点关键，要求测试团队必需要加强以下几个方面，性能测试，代码的融合、相关性影响面的判断、版本的变更与控制，还有游戏性的分析与测试。性能测试主要加强以下几点，则需要注意在并发下服务器的稳定性监控、网络流量与游戏客户端在大场面下的表现。而版本控制在游戏软件的过程中，其意义更多——则会避免已经改了的问题重复出现，或是改了更新上去问题还是存在，如何高效的合并代码、合成游戏资源、图片与角本脚本还是一个比较难度很高的事情，尤其涉及到多个部门。而游戏性测试主要是避免那种些与游戏风格相背的情况，或是开发团队累死累活拼命完成得功能性任务做出的功能没有可延续性。

  • 性能测试与版本控制，在大多数软件的测试流程中都会涉及，但是在不同的软件产品/项目中都有其特点。一般属于通用软件测试流程的部分，但而游戏性测试则需要对游戏感觉很好有比较深刻的了解，并由真正懂懂得的玩家的人来担任。某些时候，他甚至可以不是一个很好的软件测试人员，但他一定是一个真正懂游戏的人，这里有一些扯远，但这里，本文稍后一节，将我会在后面会强调人的因素也决定了流程的实施。
  • 下图是游戏迭代开发模型图
  
  • 如果你去做电子商务，或是做门户，这些项目的适时性，高性能，复杂的功能会给你更高的技术要求，更高强的时间性效率挑战，对测试的设计、执行、与性能测试提出更高的要求。其实在大多数互联网公司经常会出现这样的情况：刚出去的功能又撤下来修改，或是性能达不到要求仍需要又要调优。许多一些人都会犯这样一个错，认为测试的时间不够，就只要测试执行，而忽略了其他几个环节就可以了，不做细致的分析与设计，为后续工作带来很大压力。其实，一个充分测试过的有质量保证的产品，可以减轻客服、市场、等各方面很多的压力。产品在用户和研发之间，反复，几次不如晚一些上提供给用户。从另外一方面看，这还需要测试主管能顶住某些压力。时间紧迫当然这不是理由，如何在流程上保证测试的需求分析，用例的设计与研发在开发时同步进行是最重要的，这时你要加强早期的测试介入，明确卡住需求确认这一部分。这样，在研发进入开发阶段时，测试团队也能进入测试设计。当研发开发完成时，你测试团队事实上已经其本基本上完成了大部分的测试设计，并准备进入测试执行。不要在开发提交后再去想如何测测试，抱怨之声也就不绝于耳了。这样才可能测试好一个时间比较紧的项目不管在用于测试的时间上，还是测试的质量上都无法满足要求。
  • ，同时测试设计的很好，不仅可以节约测试执行的时间，也可以在反复提交的过程中，由于用例执行的一致性，保证了测试在多次的执行中的质量。同时也有发布的标准，一是缺陷的情况，二是用例的执行与覆盖。同时由于研发给的测试时间比较紧，所以有两件事情就必需作做好，：一是明确产品提交测试时间，并在研发延迟时给自己争取时间；二是在质量达不到要求的情况下，时间及时的做出反应，不要到最后在研发不了解项目质量的情况下建议研发延迟项目。为了达到上面的要求你必需要一个很好的测试平台，把设计，测试用例管理，执行与用例的联动，缺陷管理与报表统计打通，尽可能的利用平台解决事务性工作，降低流程执行的成本。也就是说，既让测试人员可以集中精力去测试，同时又能够让研发管理人员随时获取正在进行测试的进度与质量。当这些工作做到透明化时以后，就算让研发延迟发布，研发部门也会接收接受。下图是这一阶段的大致流程
  
  • 在这里可以跟大家说一下，我就曾经在产品发布权限不在测试这里部门的情况下，成功的让研发决定推迟发布了大约一半以上的项目。大多数的测试部门主管，很难顶住来自项目/技术经理的压力是有理由的，因为他们根本不了解你做了哪些工作。有时候一些情况下，看似不可能的事情任务要想做成完成，关键要看在于事情的技巧。流程表示了只是一个大方向的东西，而且，你永远也无法将责任推卸给流程也许是对的，更多情况下，作为测试主管，需要但将做事的方法与风格可以影响到推广到测试流程的推广中。
  • 在测试互联网项目时，还有一个更重要的就是如何保证性能。
  • 也许大家会说不就是性能测试并不是单独存在的。其实不是完全正确，如果有充足的优秀高手人力资源做性能测试当然很好，但性能测试也不能完全保证所有的项目完全没有性能问题都完美无缺，因此，项目投入期间，同时性能测试是一个这个费时费力的工作，所以往往都是一般在资源不足的情况下开展的。作为测试主管，更应该，要学会判断那些相对更加重要的问题项目影响面会更广，需要集中做性能测试。这时你也许会问，那么会有人问其它相对不太重要的项目与问题怎么办？其实做过性能调优的人都知道，大部分的性能问题都是由于一两个弱智的SQL语句导致的，所以可以从流程上加强对SQL查询语句在I/O问题的跟踪与评审，从而避免大部分性能问题。
  • 上面分析了不同公司根据上文的分析，不同类型的产品在测试流程上的是有很大差异的。这时，也许大家你也许可以把握测试流程大的方向了，但真正是否适合现有的测试团队与研发团队，则仍需要精心的调整。当我遇到问题的时候，第一时间往往有时候不是去寻找流程不对的问题，而是通过现有资源与执行的方法可能需要着手来微调一下你的测试流程，直到发现问题的所在，并纪录下来，最后整合到原来设定的流程中。
  • 这样的情况大概常常发生：比如说在需求上的处理，可能会有很多的测试人员会经常指责需求人员撰写的文档非常粗糙不详细，无法进行测试。好像在我的记忆中，需求人员常常就是被骂的得灰头土脸，但是经过这些年在测试岗位上的工作，我才渐渐发现，其实有时候需求人员更需要鼓励鼓励是比职责更加有效的工作方式。这可能是一个放之四海皆准的工作态度。，指责只能加深对立。其实在验收需求时，由于当时大家也只是知道一个大概我们的需求人员也只能从大致上把握核了解，可能大多数情况下是：原则上没有问题就通过了。但然而，这种不负责任的态度却是给我们在做的测试工作带来相当多的麻烦。也只有在这样的时候，这些问题才能真正暴露出来，从而使测试设计时就会发现很多问题并没有写清楚。一般情况下，很多测试人员这时就多半会放弃手边的工作，并消极地认为认为无法做工作无法继续下去，等东西出来，并将问题最终归结到是需求给的不详细，而大加指责。
  • 从我对测试主管工作的记事以来，就在印象中保留了这样的一幕。记的刚进一家公司时，我团队中的人员就开始经常会有下属跟我说抱怨，公司的需求工程师让我们太失望了。需求如何如何不好，然而，多少有些经验的我，当时我是把几家国内我服务过的顶尖公司情况作了一个简单的对比，的需求跟公司的需求人员的需求做了比较这时才发现，发现，原来我们公司的需求人员还是做的得不错的，。让测试人员把心态调整过来是测试主管的另外一件事。试问，，如果是你做需求作为需求工程师，是否会比他们做的好吗得更好?？有了这样的基调，就可以让然后建议测试人员去总结不清楚的地方，给需求人员一个相对比较具体和明确的意见，这样顺利的了解了需求。
  • 其实有时候不是流程不对流程在这其中并没有太多值得指责的地方，而是相互的理解与支持,换位思考而对流程的执行态度，却是更加关键的。我们不得不学会如何换位思考，并更多地从他人的角度来看待这些问题。
  • 同样的问题还出现在还有需求变更上，很多测试人过不了这一关。总是他们指责研发人员，让研发那些本来就已经恼火的软件工程师更加火冒三丈。换位思考一番，其实不难了解，，其实需求变更对研发工程师来说是更大的麻烦。他们需要修改设计，代码，相较而测试只要需改测试用例，他们的工作确实更加麻烦。简单来说，就ok了，其实大家要分析什么样的需求变更最可怕，而不是眉毛胡子一把抓,其实测试对需求变更并不可怕，怕的是只有在提交时才发现，导致测试时间不够，才会真正让测试人员心慌。这时需要从研发流程上保证变更及时的通知到测试就可以了行。也许有人会说你也需要说：说的倒很容易，如果研发不按照你的要求做怎么办！其实这里你只要用我所采用的方法是用数据说话，在项目进行时统计发生过多少次这样的事情，让研发管理层知道，让项目组之间有一个比较。一方面，如果是一家公司重视质量的公司，必然会引起重视；另一方面，从质量管理部门角度本身出发，也应该推动公司重视质量。随着时间的增加，需求变更给测试人员的反馈一定会有下降的趋势。关键是测试不能抓住鸡毛就一直揪着不放宽容一些来看待身边的同事，要允许别人他们犯错，对于解决问题本身来说会大有裨益。只要趋势是好的就可以了。同时如果出现这样的情况并且极大影响到了测试进度，则要与研发部门沟通清楚，如果研发不认可的情况下还可以请上级进行评估一下。
  • 上面说的是不同态度在同样流程下的实现不同结果,下面主要讲一下关于自身资源是否胜任做流程上规定的事情，某些工作，也许并不一定是测试部门的优势，而另外一些，则需要根据测试团队的基本能力和资源进行评估。比如像性能测试、SQL的trace、自动化功能测试、单元测试集成、游戏性测试。其实这些流程上的关键点，可能大多数从功能测试上来一路走来的测试人员是无法做的到，这时要善于利用资源，不一定要测试做，可以从通过流程上保正有人来做积极调动其它部门的同事，或是找有能力的人来做，测试可以进行监控。其实这种技术含量高一点的测试，对人的因素要求更大高，可以借助研发团队一起来做会有更好的效果。记的第一次做Oracle数据库性能监控时，就是请的Oracle的DBA专家帮助设计了性能参数，成功的地进行了关于Oracle应用的性能测试。现在国内的测试人员普遍的技术水平不高，严重的限制了测试的发展，希望测试的同行能真正的提升测试技术水平，把这些高难度的测试做起来，而不是仅仅只是工具上玩玩。只有真正提升测试团队的技术含量，这样别人才会更信赖你，这也是我这么多年来的一点经验。如果你对开发很精通、同时又精通对测试颇有研究、善于诊断性能与架构上的问题、经常会帮助研发部门解决一些他们无法解决的事情、同时又还懂的如何做测试管理，并了解研发人员的心态，那就真得的找不出你还有不成功的理由了任何理由让人不对你刮目相看了。