很久没有上论坛了，细算应该有2年了。这2年期间测试部门发生了不小的变化。首先是测试同事接连的离职，公司新人陆续报到。测试招聘门槛很低哦，要求非应届生，会用电脑就可以。由于是做手机黑盒测试，没啥技术。新人大部分不是干IT的，非科班生，有做行政的，有做服装的，有做培训的.....,而且只要稍微努力点，就可以做的不错，1年下来，竟也让带项目。在这感叹测试门槛之低，去年来的新人更让我无语了，有几个连高中都没读，只是进培训班学习了小半年，现在的年纪也刚过18岁。不得不感叹自己已经老了。

   以前一个人的时候很自由，加班后回家也没有什么负担和责任，现在结婚了就不一样了，以后有小孩就更难了。LG的工作需要经常出差，以后家里的事情基本上是我打点。现在的工作比较忙，晚上经常加班到9-10点，周末也是经常要加班。有时候还会将工作情绪带到生活中，为此LG不止一次的埋怨过我。

   公司有个女同胞，刚休完产假回公司，领导曾让她担任测试负责人，但被她委婉的拒绝了。为了家庭她舍去了好的升迁机会。有个朋友刚怀孕2个月就流产了，主要原因还是工作太劳累，她是搞软件开发的，已经干了3年多了，平时压力太大，流产后她就辞职转行了，之前她是个事业心很强的女人，挣的比她LG还多，上次和她通话，竟然从她口里说出挣钱是男人的事情，真的有点让我不可思议。我也是一个比较有事业心的人，不知道以后是否也能做到家庭重于工作？也曾想过换个行业，找个轻松点的，能准点下班，周末不需要加班的工作，但我不知道除了IT行业我还能干什么？即使找到了这样的工作我是否会甘心？内心一直都在纠结，家庭和事业很难平衡。

    静下心来想，家庭肯定要重于事业，有小孩后家庭教育很重要。不希望因为自己的时间精力有限而让小孩走上不健康的道路。所以现在初步的想法是：提高工作效率，尽量不加班，除非迫不得以，周末也尽量少加，多增加和家人相处的时间，在家里最好不想工作的事情。

  

    自己一直都很比较自卑，平时也比较容易否定自己。记得第一次转测试的时候，自己啥都不会，和我一同进公司的同事提的bug比我多，本来心理就有点着急，一听领导表扬那个同事，我更是心急如焚。所以那段时间心情很压抑，一遍遍的在扪心自问，自己是否适合做测试，如果不适合的话自己还有退路么？有1次刚好和领导一起下班，在那短暂的几分钟内我鼓起勇气问领导，自己是否适合做测试。领导说我不适合，这个回答让我更有压力了。自己放弃了工作转测试了，现在也有几个月了。自己要不要坚持呢？挣扎了几天后我决定在测试的道路上一直走下去，我自己没有退路了。后来过了几个月我找了份新工作（之前的工作只是实习）。这是我第一份正式的测试工作。新工作压力很大，开始的一二个月我有点跟不上，我知道自己比别人笨，所以花的时间要比别人多，所谓笨鸟先飞。在工作中我很卖命，经常是项目中最后一个下班的，也是项目中最早上班的。2个月后领导跟我说我过试用期了，也得到了领导的表扬，之后我总是项目中提bug最多的一个。工作之余偶尔会想起之前领导说我不适合做测试，我想她看错了，一个人只要坚持，只要用心去观察，用心去学，再比别人多花点时间的话肯定能做好。

   这份工作干了2年后我辞职了，到了现在的公司。在新公司我的表现还可以，进公司3个月后领导主动给我涨工资了，虽然不多，我也挺开心的，至少自己的成绩被领导认可了。1年后公司的测试组长纷纷辞职，我被担任测试组长，开始带项目。由于沟通技巧、经验不足及项目时间紧张等多方面因素，自己的压力很大，有连续2个星期没睡好觉，有时候整晚都睡不着。人没休息好白天干活就没精神，一没精神人就容易很出错，一出错我就常常自责，一自责我又睡不好觉，如此恶性循环，那段时间LG也很郁闷。看着我一天天的消瘦下去，他心理也很难受，他建议我辞去这份职务，但我自己又不是特别舍得，这毕竟是自己职业规划的一大提升。这些都被领导看到眼里，不久前的一天领导找到我，很认真的跟我谈了谈现在我的状况和项目的状况，然后让一个同事代替了我的职位，也就是将我换下来了，领导说的很委婉，说我不适合做这个，但我知道意思。会后的几天里我一直都无法平静下来，因为被人换下来了面子上总觉得过不去，自尊心受到了沉重的打击，在项目组同事那总觉得抬不起头，当我向客户、向项目组内、向项目测试发出更换测试组长的邮件后，我的心情是特别的沉重，特别是当项目经理问我为啥要换的原因时，我说话的声音几乎有点哽咽。自己在沟通方面确实不太好，说话也太实在了，也不够灵活，这个也不是一天2天能提高的。所以后续自己在这方面得多学学，如何做好和其他部门的沟通协调、如何和客户之间沟通、遇到突发事件如何灵活应对等等问题是我后续学习的方向。

  领导否定我没关系，只要自己别否定自己，之前说我不适合做测试，我现在也做的挺好的，说我不适合做测试组长，我会证明给你看。相信自己，只要用心去体会、用心去学、多总结，我相信没有什么是不可能的。

提高说话技巧对每一个职场中人来说都是很重要的，一句话可能就关系到你的前程。往往每个人都有一个隐私区域，不愿意被打扰，不愿意被催促，不愿意和陌生的面孔交谈，不愿意被人指责，不愿意按照规定的时限做事，不愿意主动的去关心别人，不愿意去思考别人还有什么没有想到。在工作之后，你要极力改变这一现状。否则，你会很快因为压力而内分泌失调。特别在会议上，许多人会消极的听取领导的话语，消极的待命，很死的完成上级交给的事情，但从来不关心此事以外的任何事情，更不会想到多做一步，让接下来的别人的工作更加容易上手。而掌握说话技巧的人，敢于在适当的时候提出自己的看法和不理解，并在得到上级认可和指点之后把手头的工作尽快的完成，并随时接受别人的批评和调整。

我们不要把好像、大概之类不确定的话放在嘴边。尤其是和上级谈论工作的时候。因为似是而非的应答往往一样会暴露出你更多的弱点：1.你之前没有想到这个工作，或者一直在拖延。2.你没有责任心，认为这些并不重要。3.你应付上级。4.你不敢说真话。5.你喜欢逞能，答应一些做不到的事情。6.你不能独立工作。

当你的上级在以上选项中怀疑的时候，潜意识中你已经同时具备了以上所有的弱点了。

再者不要表现得消极，仅仅因为你所做的事情不是你的兴趣所在。很显然，在学生时代，当做到自己喜欢的时候，我们会很多精力去创造，但如果是枯燥的事务，我们便懒得理睬，最好能有办法应付过去。但在工作上大部分你所做的事情都是繁琐而看似机械的，如果仅仅为此而表现的闷闷不乐，那么你会郁闷更久。要知道你的上司已经为这个项目够烦恼了，你还想让他看到你的表情吗?学会喜欢自己的工作，并把注意力放在日常工作能学到些什么上去。如果现在你努力的抱怨工作，那么接下来你就是努力的寻找工作。尽量少用“有趣”，“好奇”之类的词语来描述自己想要的工作，而是“充实”， “有成就感”，“乐意”。

也不要推卸责任，推卸责任是害怕的条件反射。不要认为别人看不出这点。其实现在很多人面对工作也是这样，当上级责问的时候，很条件反射的就做出了推卸动作，然而这样的动作，接下来往往是无力的辩解，以及一些很粗糙的借口。这样会让上司感到你这个人很难沟通，并且很不真实。

最后分享一些职场中人提高说话技巧的秘诀。

1. 不要说尖酸刻薄的话，。

2. 转移话题要尽量不着痕迹。

3. 如果你要加入别人的交谈，先要弄清楚别人究竟在说什么。

4. 交谈之前尽量保持中立、客观。表明自己的倾向之前先要弄清楚对方真实的倾向。

5. 以谦卑的姿态面对身边的每一个人。

6. 多给别人鼓励和表扬，尽量避免批评、指责和抱怨。

7. 要学会倾听。不要说得太多，想办法让别人多说

8. 不要因为对方是亲朋好友而不注意礼节。

9. 尽可能谈论别人想要的，教他怎样去得到他想要的。

10. 一定要尊重对方的隐私，不管是朋友还是夫妻。

  最近自己的工作和管理搭上勾了，平时没注意说话技巧，给客户留下了不好的印象，被领导批了。看来真的学学，无意中看到这篇文章，觉得写的还是挺好的。如下：

以最婉约的方式传递坏消息句型：我们似乎碰到一些状况…

　　你刚刚才得知，一件非常重要的案子出了问题；如果立刻冲到上司的办公室里报告这个坏消息，就算不干你的事，也只会让上司质疑你处理危机的能力，弄不好还惹来一顿骂、把气出在你头上。

2)?1:TurnAD42.visit; TurnAD42.store(); function showTurnAD42(basenum){ if (basenum==1){ document.getElementById('TurnAD42').innerHTML = "";} else{ document.getElementById('TurnAD42').innerHTML = "";} } showTurnAD42(intTurnAD42); }catch(e){}

此时，你应该以不带情绪起伏的声调，从容不迫的说出本句型，千万别慌慌张张，也别使用「问题」或「麻烦］这一类的字眼；要让上司觉得事情并非无法解决，而「我们」听起来像是你将与上司站在同一阵线，并肩作战。

　　上司传唤时责无旁贷句型：我马上处理。

　　冷静、迅速的做出这样的回答，会今上司直觉的认为你是名有效率、听话的好部属；相反，犹豫不决的态度只会惹得责任本就繁重的上司不快。夜里睡不好的时候，还可能迁怒到你头上呢！

　　表现出团队精神句型：安琪的主意真不错!

　　安琪想出了一条连上司都赞赏的绝妙好计，你恨不得你的脑筋动得比人家快；与其拉长脸孔、暗自不爽，不如偷沾他的光。方法如下：趁著上司听得到的时刻说出本句型。在这个人人都想争著出头的社会里，一个不妒嫉同事的部属，会让上司觉得此人本性纯良、富有团队精神，因而另眼看待。

　　说服同事帮忙句型：这个报告没有你不行啦!

　　有件棘手的工作，你无法独力完成，非得找个人帮忙不可；于是你找上了那个对这方面工作最拿手的同事。怎麽开口才能让人家心甘情愿的助你一臂之力呢？送高帽、灌迷汤，并保证他日必定回报；而那位好心人为了不负自己在这方面的名声，通常会答应你的请求。不过，将来有功劳的时候别忘了记上人家一笔。

　　巧妙闪避你不知道的事句型：让我再认真的想一想，三点以前给您答覆好吗？

　　上司问了你某个与业务有关的问题，而你不知该如何做答，千万不可以说「不知道」。本句型不仅暂时为你解危。也让上司认为你在这件事情上头很用心，一时之间竟不知该如何启齿。不过，事後可得做足功课，按时交出你的答覆。

　　智退性骚扰句型：这种话好像不大适合在办公室讲喔!

　　如果有男同事的黄腔令你无法忍受，这句话保证让他们闭嘴。男人有时候确实喜欢开黄腔，但你很难判断他们是无心还是有意，这句话可以令无心的人明白，适可而止。如果他还没有闭嘴的意思，即构成了性骚扰，你可以向有关人士举发。

　　不著痕迹的减轻工作量句型：我了解这件事根重要；我们能不能先查一查手头上的工作，把最重要的排出个优先顺序？

　　不如当下就推辞。首先，强调你明白这件任务的重要性，然後请求上司的指示，为新任务与原有工作排出优先顺序不著痕迹的让上司知道你的工作量其实很重，若非你不可的话，有些事就得延后处理或转交他人。

　　恰如其分的讨好句型：我很想您对某件案子的看法……

　　许多时候，你与高层要人共处一室，而你不得不说点话以避免冷清尴尬的局面。不过，这也是一个让你能够赢得高层青睐的绝佳时机。但说些什么好呢？每天的例行公事，绝不适合在这个时候被搬出来讲，谈天气嘛，又根本不会让高层对你留下印象。此时，最恰当的莫过一个跟公司前景有关，而又发人深省的话题。问一个大老板关心又熟知的问题，但他滔滔不绝的诉说心得的时候，你不仅获益良多，也会让他对你的求知上进之心刮目相看。

　　承认疏失但不引起上司不满句型：是我一时失察，不过幸好……

　　放错在所难免，但是你陈述过失的方式，却能影响上司心目中对你的看法。勇于承认自己的疏失非常重要，因为推卸责任只会让你看起来就像个讨人厌、软弱无能、不堪重用的人，不过这不表示你就得因此对每个人道歉，诀窍在于别让所有的矛头都指到自己身上，坦承却淡化你的过失，转移众人的焦点。

　　面对批评要表现冷静句型：谢谢你告诉我，我会仔细考虑你的建议。

　　自己苦心的成果却遭人修正或批评时，的确是一件令人苦恼的事。不需要将不满的情绪写在脸上，但是却应该让批评你工作成果的人知道，你已接收到他传递的信息。不卑不亢的表现令你看起来更有自信、更值得人敬重，让人知道你并非一个刚愎自用、或是经不起挫折的人。

  由于测试组长有事，请假一个月，所以我有幸体会了一次测试组长的工作，感慨颇多，简单总结了，具体如下：

1、  任务比较多时，需要根据优先级来安排任务，哪个最着急先完成哪个，且最好是记录下来排个顺序。因为有些任务是电话、开会上口头说的，有些是零散的邮件说明的，如果时间一长估计就忘了。这个我也就遇到过，当时项目经理隔三差五的给发个邮件说要完成哪些任务，我基本上都是来了任务就分配下去，未弄明白优先级，导致后来忙的团团转，一会儿要这个报告，一会儿要那个报告，结果呢要不是没完成，要不是就完成的质量不行。

2、  任务的细节最好搞清楚。比如要专项测试时问清楚测试版本，测试时是否需要抓相应的log,对结果反馈有没有特殊要求，如果在测试期间有新版了是否需要更换新版本测试，之前旧版本测试过的是否需呀用新版本再次验证….

3、  对任务完成的进度、bug数等相关信息要很熟悉，并能随时说出来。这个我也做的不好，记得开周会的时候被项目经理问及系统测试完成的进度如何，在规定时间是否可以完成，现在bug是否多不多，集中在哪些模块….，我当时脑袋都蒙了，不知道需要了解这些信息。当时我就说任务差不多能够完成，发现的bug都已提交到bug库了，如果想了解的话可以上那里查看。项目经理听了没说什么，我觉得自己做的很差。开完会后我就赶紧挨个问组内成员是否可以在预期的时间内完成任务。有了这一次的教训，在下次的例会上我就先做了相关方面的工作，任务分配下去了，过一段时间邮件或电话询问进度，然后也时不时的上库中查看Bug。

4、  测试人力方面有困难要及时找测试经理。当时也是测试时又来了个很着急的任务，人力实在有限，这个任务又不能延后，我都不知道怎么办，只是跟项目经理说人力有限，要完成的话很难。项目经理还比较好，知道我是临时的，所以她直接找到测试经理说明任务，一番沟通后又支援了一人，这样任务就能完成了。不知道为啥我自己就没想到找测试经理，当时的想法就是自己加班来完成，但那段时间我都连续家加了好几次班了。

5、  了解组内成员的能力。当时测试时人力有限，有3个人被临时支援测试。分任务前我先电话了解这个人之前测试的模块，也通过他们的领导了解到这几个人的测试水平，然后再分任务时可以有的放矢，将重要的模块分给能力强的，对于走case慢但发现Bug能力强的可以将任务少分点，让有时间做自由测试，以发现更多的bug.这方面我还是做的可以的。

6、  适时鼓励、赞美组内成员。前段时间是比较关键的时候，任务多、重，过几个星期就要出货了，所以周末难免要加班，平时晚上也要加班，同事都有怨气了，这几个人都是临时支援的，普遍有种只是完成任务，给我的感觉就是没有那种很尽力的感觉。我也能理解，所以当人发现比较好的bug时我都会发邮件赞美一番，或者是他们的工作习惯很不错时也会适时的赞美一下，组内有个新人很久都没发现bug，在这期间突然发现了几个bug，而且个别Bug也不错，为此我也特别发邮件鼓励了一番，没想到后来发现bug的数量有所增加。我不知道是否和我的鼓励有关，但进步了总该是好事。如果能细心认真的观察组内的成员，相信多多少少有一些闪光点是值得我去学习的。

 

目前的体会就这些了，毕竟经历的时间有限，相信如果在这个职位上工作的时间更长的话会有更多的体会，希望大家拍砖，谢谢。

在整个测试过程中，人是最重要的因素之一。不管是多好的过程，还是多好的方法，最终都需要由人来执行和完成。好的过程就像是一条高速公路，而人就是在这条高速公路上的车，好车配合好路才能够保证行驶的速度和安全。

　　测试经理在日常工作中的一个重要任务就是保持对测试团队成员的激励。一谈到激励，可能很多人下意识就会想到金钱，例如：给员工奖金，或者加工资。实际上，物质奖励只是激励方式的一种，但这并不是唯一的和最有效的方式。每个员工都有自己的梦想和目标，希望能够获得更多自主的空间，希望自己的才能得到施展，希望得到认可，希望自己的工作富有激情，因此，测试经理除了提供物质上的激励以外，更应该为员工提供一个施展他们才能的舞台，激发员工内在的自我激励和自我实现。而且每个员工的需求不一样，激励的方式也各不相同。例如：公开表扬对有的员工有明显的激励作用，但对于性格内向的员工，效果可能会大大打折；提供弹性的工作时间也是对员工的一种激励。下面介绍一些常见的激励方式。

　　1）满足员工的需求

　　作为团队核心的测试经理，必须针对部门内员工的不同特点“投其所好”，寻求能够激励他们的动力。每个人内心需要被激励的动机各不相同，因此，奖励杰出工作表现的方法也应因人而异。不同的人在不同时期的需求也是不一样的。员工主要的需求包括：

　　● 得到尊重和认可。

　　● 获得自我表现的机会。

　　● 在积极的团队氛围中工作。

　　● 获得一定的做决定的权力。

　　● 公平的竞争环境。

　　● 广阔的成长空间等。

　　要满足员工的需求，首先需要理解员工。这就要求测试经理在日常的工作和生活中能够多倾听、多观察，还应该注意员工的一些肢体语言或者异常的情绪波动等。测试经理可以通过以下途径获得员工的具体需求：积极倾听员工的呼声、换位思考、观察员工的情绪波动并做出积极的回应等。当员工的需求获得满足时，他们的工作效率会有很大的提高，员工的内在激励会起到重要的作用，团队会处于一个积极向上的氛围，员工的聪明才智和创造性才能够得到最大的发挥。

　　马斯洛需求层次理论（Maslow's hierarchy of needs），亦称“基本需求层次理论”，由美国心理学家亚伯拉罕·马斯洛提出。马斯洛是当代最伟大的心理学家之一，由于他的著作使人本心理学的观点更加丰富和清晰，所以被人们称为“人本心理学之父”。他的需求层次理论对团队激励有着很大的帮助。表1列出了根据马斯洛的需求层次理论得到的团队激励的实例。

表1  马斯诺的需求层次理论在团队激励中的实例

马斯诺需求层次	工作中的对应关系
自我实现的需要	参与挑战性的项目、创造性获得鼓励和支持、获得创新的机会
尊重的需要	获得尊重和认可、能够被委以重任
情感和归属的需要	友好的团队氛围、良好的客户关系
安全上的需要	工作的安全性、良好的工作环境
生理上的需要	基本的薪酬、工作空间、饮食

　　2）有效授权

　　测试经理在安排工作的时候，应该考虑让团队成员承担更多的责任并拥有更多的权利。授权并不一定是升职。测试经理在向其测试团队成员分配工作时，也要授予他们相应的权力，否则就不算授权。测试经理应该在合适的场合让所有的相关人员知道被授权者的权责，同时需要确保授权之后应该尽量减少干涉，要给被授权员工做相应决策的权力。

　　有效授权是一种很好的激励员工的方法。权力的下放同时也意味着责任的下放。员工在获得一定的决策权力的同时，也应该明白要全力以赴把事情做好，要对任务的结果负责。通过有效授权，员工的积极性和创造性能够被最大限度地调动起来，同时员工的责任感和主人翁精神会得到加强，对组织的认同感会不断提高。员工通过承担更多的责任，也获得提高自身各项技能的机会，从而获得更广阔的发展空间。但是在授权的过程中，测试经理也要注意确保授权的范围和员工的实际能力相匹配，尽量避免一开始就赋予给团队成员过多的授权和责任。在实际的授权过程中，测试经理可以以渐进的方式授予测试团队成员的权力，同时在必要的时候需要为员工提供相应的培训。

☆示例：有效授权

　　测试经理通常需要协调整个测试过程中的所有活动，包括测试计划和控制、测试分析和设计、测试实现和执行、评估测试出口准则和报告以及测试结束活动等。但是作为测试经理，并不需要对所有的测试活动亲力亲为，而是应该将测试活动进行划分，将测试过程中的一些活动下放到测试团队成员中去。在项目中可以采用“一事经理”的方式。所谓的“一事经理”，就是对某个独立的任务或活动具有决策权力的人。测试经理可以将测试活动中的测试环境管理、测试用例配置管理以及测试度量等任务的权力授予相应的测试人员，由其负责处理相关事宜，定期向测试经理汇报。

　　以测试度量为例，某个测试团队成员成为该任务的“一事经理”后，全权负责测试度量相关事宜，包括测试度量系统的设计、测试度量数据收集和测试度量数据分析等，而测试经理作为测试度量活动的一名成员而不是管理者参与到测试度量活动中。测试经理最终使用测试度量活动的分析结果作为其他活动的输入，例如：作为测试出口准则评估的输入。测试人员在“一事经理”这个方式下也得到了锻炼，自己的技能得到了增强，同时获得了整个团队的尊重和认可；测试经理也因此减少了日常的工作量，可以将更多的精力投入到其他测试管理活动中去。

　　3）有效沟通

　　沟通无时无地不在，测试经理每天要和各种不同角色的人以各种不同的方式进行沟通。有效地沟通能够节约测试经理的时间和工作量，同时也能帮助团队成员更好地完成任务。另外，有效地沟通还有助于构建一个开放的测试团队，最大限度地发挥团队的积极性。倾听是有效沟通的一个重要方面，尤其是对待团队成员的抱怨，测试经理更应该认真倾听，如果能做到认真倾听，大部分的抱怨都可以得到解决。很多时候，员工可能并没有期望问题得到解决，他们更看重的是测试经理或管理者的态度，通过认真的倾听，员工的问题即使没有得到解决，员工的不满意度也会得到很大的降低。此外，在沟通的过程中，测试经理要避免过于封闭而听不进员工的建议，或者只是进行有选择地倾听，例如：只听好的内容，对提及的问题视而不见，同时，测试经理必须对员工的意见及时进行反馈。

　　沟通的方式有很多，例如：面对面交流、Email、电话、文档评审等。测试经理应该根据实际需要选择合适的交流方式，例如：简短的信息传递，可以通过电话的方式很快解决；对于复杂方案的讨论，需要安排专门的会议；有些事情可以先通过Email的方式传递基础信息，给员工一个准备的时间，然后通过面谈的方式做最后的沟通。以下的建议将有利于改进沟通的效果：

　　● 多听少说。

　　● 使用简单、容易理解的语句。

　　● 注意使用合适的肢体语言。

　　● 不明白的要及时提出问题。

　　● 要经常沟通以及沟通要保持热情。

　　☆示例：有效沟通

　　测试经理和测试团队成员之间如果能够建立有效的沟通渠道，团队成员和测试经理之间能够有效地交换意见，将有助于测试团队成员的激励。但是在实际的测试过程中，测试团队成员很少主动找测试经理反馈意见。尤其是以技术为主的测试团队中，测试团队成员相对比较“内向”，交流不够主动。这种情况下，测试经理可以定制一个团队沟通交流计划，团队成员每个月都有一次和测试经理单独面谈的机会。测试经理会轮流和每个测试团队成员进行面对面地交流，给员工一个反馈意见的机会。这些面谈都是在一对一的情况下进行的，团队成员不会有太多的顾虑；同时面谈的时间都是提前计划好的，如果有需要反馈的问题或建议，员工在沟通之前可以做好充分的准备。测试经理在这种方式下要把面谈的气氛调节为一种非正式的交流，可以交谈任何内容，从工作到生活。

　　4）提供学习和培训的机会

　　现代社会，科学技术迅猛发展，信息和知识急剧增加，知识更新周期缩短，创新频率加快，各种技术方法层出不穷。如果员工不积极学习，就很难跟上时代发展的步伐，甚至会被社会淘汰。因此，每个员工自身都有危机感和紧迫感，从而自身都有学习和培训方面的需求和需要。这种情况下，为员工提供良好的学习和培训的机会，显然能够激励员工创造更大的价值。通过提供学习和培训的机会，不仅员工自身的能力得到增强，对组织的认同感提高，整个团队的能力也会得到提升，从而能够更加有效地完成相关任务，并承担更大的责任。

学习和培训的方式有很多，可以在团队内部组织交流和学习、相互进行培训，也可以聘请外部专家进行培训；可以通过E-learning的方式，也可以通过课堂教学的方式。要开展学习和培训，必须将员工的兴趣和工作需要结合起来。在开展培训之前，首先收集员工的培训需求，然后结合项目或者团队的目标，从而在个人目标和团队目标之间实现共赢。学习或培训后，需要及时收集员工的反馈，不断改进培训的效率和有效性。

　　☆示例：提供学习和培训的机会

　　“岗位轮换”是一种很好的学习方式。当测试团队成员在自己的岗位上工作了一段时间以后，相关技能已经熟练掌握，这个时候都希望能够有机会再增加一些其他方面的技能。这种情况下，可以在测试团队内部进行岗位轮换，给每个员工一个学习新知识的机会。在iBAS R1.0项目中，随着测试执行的不断进行，被测试对象中发现的问题越来越少，测试人员已经开始“审美疲劳”，觉得很难再发现新的问题。这个时候，在测试团队中进行岗位轮换，原来执行IGMP系统测试的人员开始测试DHCP功能，其他人也相应地进行轮换。通过这种方式，测试人员可以掌握原来不具备的知识，增加了对整个被测试系统的了解；同时由于相互轮换，起到了一个评审的作用，测试人员对新分配任务的功能可从自己的角度重新思考，可以对原来的测试用例进行修改或补充，这样也有利于发现更多的缺陷，提高被测试对象的质量。

　　5）尊重和认可

　　每个人都希望得到别人或团队的尊重和认可。尊重和认可能够使员工对自己更加自信、对工作更加热爱，能够鼓励员工提高工作效率。给员工的认可也要及时而有效，当员工工作表现很出色时，测试经理应该立即给予称赞，让员工感受到自己受到上司的赞赏和认可。测试经理可以通过各种不同的方式认可员工的工作表现，例如：口头赞赏、书面赞美、对员工一对一的赞赏、公开的表扬等，从而不断鼓舞员工士气。对于测试人员而言，当测试人员的建议被开发人员或项目团队采用、测试人员能够在项目早期介入项目开发活动、为测试团队分配足够的资源等，这些都是对测试人员的尊重和认可，可以激励测试人员更好地工作。

　　☆示例：尊重和认可

　　“每周之星”是一种表扬员工的方式，通过这种方式可以使员工感受到被组织的认可，从而获得满足感和成就感。测试经理每周发掘团队中表现出色的员工进行表扬，是尊重和认可的重要表现形式。员工的出色表现可以是各种各样的，例如：需求评审过程中发现了很多问题、测试设计过程中有效地引入了测试自动化、为客户制定了良好的解决方案等。测试团队每周肯定都会有一些特别的事情发生，因此，总归可以发掘成为“每周之星”的员工。即使是测试团队处于项目的前期学习阶段，也有很多员工的行为是值得表扬的，例如：对及时总结或者分享学习成果的员工进行表扬。“每周之星”这样的形式不仅对员工的工作进行了认可和表扬，而且能够激励其他员工不断地努力。

　　6）物质奖励

　　上面介绍的几种激励方式更多地偏重于精神上的鼓励。实际上，除了精神激励外，物质奖励也是必不可少的，它也是日常工作中经常使用的一种方式。薪水不仅能保证员工生存，同时能者多得的薪酬机制也能有效地起到激励效果。物质奖励的多少依赖于员工能为公司带来的价值，例如：对于为公司创造出高利润、开发出赢利新项目的核心人才，通过加薪激励是必不可少的。在使用物质奖励方式的时候，一个重要的考虑因素是公平。如果某个员工的贡献突出，那么可以对这个员工进行单独的奖励。假如突出的是团队共同努力的结果，那么需要对整个团队进行奖励。同时物质奖励要有充足的理由，确保只有表现优秀的员工或者团队才能够获得物质奖励。

　　☆示例：物质奖励

　　物质奖励的方式既可以是单次奖金的形式，也可以是加薪的方式。在平时的激励过程中，测试经理应该综合应用这两种形式。每个季度可以对个人或团队进行一次评比，对表现突出的优秀个人或者优秀团队进行单次的奖金激励。每年对团队成员进行综合考核，根据团队成员的年度表现，对不同贡献的员工进行不同程度的物质奖励，可以是年度的加薪，也可以是年度加薪和单次的年终奖相结合的方式。

　　上面介绍了几种常见的激励方式，其实，激励的方式还有很多，例如：建立良好的团队氛围、鼓励大家注意身体健康、重视工作和生活的平衡等。在日常管理过程中，测试经理应该灵活应用各种激励方式。

　　激励测试人员的方式有很多，同时也有很多方式会打击测试人员的积极性，造成消极的影响，例如：测试人员在一个几乎看不到结束期限的项目上工作；测试人员致力于保证产品的质量，并且投入了额外的时间和精力，但是由于一些外部因素影响，输出的产品仍旧没有满足计划中设定的目标；尽管测试人员尽了最大的努力，但还是没有及时完成测试任务；如果测试人员的贡献没有被理解和衡量，不管最终结果是否成功，对测试人员而言都很可能造成消极的影响。

本文转自：http://www.51testing.com/html/02/n-226402-3.html

   提取测试需求是软件测试活动中的基础工作，是测试活动展开的前提条件。

        在项目实施前在做整个系统的测试方案中工作量评估时，如果是基于系统功能点的方法，则已经对系统中的功能点、性能点等进行分析统计，可以直接在该分析结果的基础上进行细化和完善。

    外包项目测试活动中确定用户需求范围是最重要也最困难的工作之一。往往在项目实施前无法准确界定测试范围，原因很多，主要有以下几个方面：

1、系统用户需求不详细，从而无法确定测试范围；

2、用户需求中简单的描述，可能包括很多研发工作，也需要测试，容易别忽略；

3、行业经验不足，对其中的业务不熟悉，造成对业务功能不能确定；

    在测试过程中，带来测试范围变化的原因，主要包括：

1、在研发过程中客户较大的改变原来的需求，扩展原来的需求；

2、研发公司改变客户的需求，带来测试范围的变化；

    综合以上的原因，主要来自于三个方面：

1、客户的需求前期描述不清，后期的增加、修改变化；

2、研发公司对需求的变更；

3、我们自己团队行业业务、项目经验的不足；

  对于第1点，可以约定测试用户需求的基线版本，对于研发过程中需求变更超过一定范围，重新评估增加的工作量。

  对于第2点，可以同第1点一样，同客户在前期约定好。

  对于第3点，则是需要一个过程，业务和项目经验积累需要一个过程。

        要确定测试需求，相当于确定了测试范围，则能比较准确的确定工作量。如何分析测试需求呢？

        首先、分析用户提供的所有文档，在业务分析师的帮助下，根据业务分解系统功能，由粗到细，逐渐细化需求，这其中需要客户、研发团队的协助，把不清晰、不明确、不具有可测试性的需求转化明确的、具有可测性的需求。根据测试需求对应的集成测试、系统功能测试和性能测试活动不同，其测试需求也不同，例如，对于产品集成测试，则测试需求细化到测试集成的每个模块接口、子系统接口即可。对于功能测试则时一个具体的功能实现，该功能可能时一个典型业务中的一个操作，也可能是整个典型业务。如果是一个典型业务的一个操作功能，则最好把整个典型业务的测试需求串接在一起，形成一个典型业务的测试需求链（具有相关的测试需求形成的一个序列）。

        其次、把测试需求尽量使用测试管理工具进行管理，便于测试需求的统计、变更，以及与测试用例形成关联。

        测试需求在客户评审通过后，要形成基线，以后用户需求变更后，要进行测试需求的变更，且保持测试需求与用户需求的版本一致



    这篇文章觉得写的不错，所以转载一下。对于需求最近也深有体会啊。公司刚接收了一个新项目，客户的需求也比较简单，只说要有什么功能，一句话就没了。因为这个功能虽然是A模块的，但它牵涉到调用B模块，在A和B模块的交接处客户未做说明。于是开发想当然的做了，功能是做好了，也满足了需求，但对于用户来说是很不方便的，我们测试人员为此就提了bug.可以说这个测试还是很不错的，能够站在用户的角度考虑。

  ----------------------------------------------------------------------

需求一般分为显式需求和隐式需求两种

一、显式需求提取参照需求说明书：
1、逐个罗列出功能点，功能描述
2、考虑交叉功能点
3、画出业务流程图

二、对于隐式需求
1、针对行业知识，向客户（提需求的人）和项目组内熟悉产品的人请教。切记，“闻道有先后，术业有专攻”，在这方面很多人需要习惯并且擅长向他人学习，你就要问的他都烦。
2、针对用户实际需求，要问清楚他想解决的问题和以后的期望值，做到“未雨绸缪”，想客户之所想。期望值虽然暂时达不到，但一定会为你了解产品有非常大的帮助。
3、软件实际需求，在了解用户需求的基础上，向技术人员请教，了解当前产品所能达到的目标。

综上，把所有需求功能点罗列在一张表格里，找对应人员确认，查缺补漏

   昨天在聊天时偶然得知2个同学进百度北京研发中心了，很震惊。这2个人之前的公司也不出名，比较小，在过去的3年间跳过好几家公司，再加上我们也只是三流学校毕业的。进了百度以后再找工作就有敲门砖了，以后的路也是很光明的，那工资就更别说了。没想到毕业还不到五年大家的差距就出现了，想想心里就很郁闷，没想到晚上竟失眠了。

  其实说到自己，主要是走了些弯路，浪费了自己近1.5年的时间，从2009年才正式开始自己的测试工作，在过去的1.5年间自己也确实进步了不少。现在的工作相对之前的来说还是可以的，工资也翻了一番，所以说自己还是一直都在努力，只是大家不是在同一个起点上。只是跟他们一比就觉得自己很差，这也难怪，测试和开发能比么？

  心里郁闷归郁闷，生活和工作还是要继续，有差距不怕，怕就怕不迎头赶上。当然不能给自己太大压了，要不然身体会吃不消的，工作可以不要，但身体不能不要。顺其自然吧，生活中总有人比你强的，只要自己努力了，如果没达到预期的结果，我也没话说。

  偶然看到这篇文章《面对用户反馈的缺陷：我们能做些什么》http://www.51testing.com/html/75/n-221875.html，不禁让我想起了之前的公司。这家公司对测试还是蛮重视的，当然压力也是很大的。每个版本上发现的问题都需要对比上个版本，看是否为漏测的，所以每每发现了严重问题都比较害怕，所以每次的专项测试都希望尽量多测点，为的是少漏测，经常不要求加班的但我也会稍微晚点下班，为此那时候工作特负责，也特充实。这个还不算什么，特别是用户反馈来的bug，我们都要按模块进行归类，然后分析，看是否是测试漏测的，如果是的话需要写报告分析，为啥漏测，以后如何避免，然后再把它在用例中更新。

  现在换了新工作，压力没之前那么大了，对这些漏测的及用户反馈的Bug头都没对测试施压。想想这些我就觉得有点失落，在这样宽松的环境下测试的技术、水平如何提高？反正我不能这样，虽然头没要求，但我自己私下里还是得总结，反省，给自己点压力吧。

 

 

信产部CTA测试，英文全称：China Type Approval，即入网测试，只有通过了这一测试，才能获得信产部颁发的终端入网证。（相当一部分是在北京信息产业部电信研究所进行测试）

总体分为：室内测试和外场测试。

具体见：http://hi.baidu.com/dragoniye2008/blog/item/a4b7196cfcb5c7f6431694d3.html

  在新公司工作已经有3个月了，也快转正了，在此期间经历了几个同事的离职，有干了1年的也有干了好几年的。不禁会想自己的选择是否正确，再加上同经验的同事找的工作工资都比我高不少，但能力还不如我，这些因素造成了我浮躁的心理，所以在这段时间我没有很投入的去工作。我想或许转正时可以再跟领导谈谈工资的事情，但不知道该如何说出口。这阶段刚好有几个项目，一个项目是android的，而且需要提英文bug，自己一直在坚持学英语，加上有半年多的android手机测试经验，所以我特别想加入这个项目，但结果往往事与愿违，我被分到了其他项目组。为这事我又郁闷了一段时间，想想是否需要主动跟头说说，但又想自己刚转正不太好。总之有很多让我郁闷的事情、郁闷的地方，让我觉得在这个公司学不到什么东西。我总是在抱怨着抱怨那，但上周的一件事让我清醒了很多。

 之前我一直都在测A模块，对其他模块只是一个了解的程度，很少测。没想到在这个新项目组，另一个头分给我的模块却是我从未测过的，可以说是现在比较先进的模块吧，而且任务很急，加上那个case写的很专业，让我看不懂，或许因为我一点都不了解吧，再加上也没有一些环境搭配的说明书，之前只有几个同事测过，但大家都比较忙，很难有时间去教你。哎，这只能怪自己了，自己完全可以在不忙的时候，或者是自己晚上加个班啥的去了解，去问同事。总是说没地方可以学习的，这个就很好的啊。这个就是教训，在今后的工作中要不断学些，摆正心态，如果你想学的话在哪都可以的，也不要抱怨工资，如果你有能力的话还怕这个....

   公司交付软件时需要经过一系列的客户验收测试，在此次验收测试中客户发现了不少的问题。仔细看看其中的部分问题是不难的，步骤也不复杂，都是一些很普通的问题。我们总是说要站在客户的角度上去测试，但又有几个人能做到呢？其中客户发现的一个问题让我觉得自己真的是没站在客户角度的。

   问题大概是这样的：主界面上有一些快捷菜单，移动上下方向键可以在快捷菜单和时间widgets之间高亮，移动左右方向键可以在快捷菜单之间高亮，每高亮到一个菜单的话会有相应的动画或颜色显示。但现在这个动画或颜色不明显，有时候让人不知道当前高亮在哪个上面。这个问题其实在我测试中遇到好几次了，当时心理确实闪过一丝疑问，这个确实不明显，但我没有提单，为什么呢？公司其实在可用性方面做的还是很差的，没有相关的UI，或需求的话是不会改的。再加上之前的那个项目我提过几个和这类似的bug，都被reject，不是被开发reject而是被QA，她们认为现在是后期，只要不出现重启，某个模块不能用像这样的问题的话，才让提交。弄的我心里不舒服，有时候像这类问题我基本上也是睁一只眼闭一只眼。现在想想这种想法真的是不好的，像这次验收测试，客户提了不少这样的问题，导致重出版本，周末还得加班，还是苦了自己。如果不是被客户发现了而是直接投放到市场上，被最终用户投诉，那后果更严重。

   既然踏入了测试，就要把测试做好，也许有时候自己辛苦提交的bug被reject，让自己觉得很委屈，但有什么办法呢？自己提了总比被客户提要强。

   这几天在测试时发现一个小bug，大概现象是这样的：

  在进行操作时拔掉耳机后此操作被终止但未回到Idle界面，且这个操作功能正常，从这个现象来说也不是大问题，只是一个很小的问题，有时候对于这样的问题我都不会去提单的，但没想到这个操作对其他应用产生了影响， 某个应用启动不了。这可是个大问题啊。

  所以在测试时遇到小问题时不要轻易放过，可以再试试其他应用，或许会产生大问题，模块之间是相互影响的，谁知道会对哪个模块产生影响？

不论是刚接触测试的同学还是做测试已经有一段时间的同学，都会在一个问题上有类似的困惑：我们测试用例的粒度是粗点好，还是细点好。尤其是在时间紧张，人力有限，需要别人执行，后续需要维护的情况下，抉择更加艰难。本届黑灯舞会就这个问题展开了激烈的辩论。并获得了具有一定指导意义的结果。

　　正方观点认为：测试用例的粒度应该细点，主要体现测试细节

　　反方观点认为：测试用例的料度应该粗点，主要体现测试思想

　　论辩先由正方一辩马雯佳同学发言：“我方认为, 测试用例的粒度应该细点，主要体现测试细节。原因有（1）测试用例的编写就像是织网，而BUG就像是鱼，网织得越密，捕捉到的BUG就越多（2）测试思想的学习并不是一蹴而就的。对一个新人来说，这种学习是一个渐近的过程，具体到每个项目，更需要用更精细的用例来保证测试的覆盖率（3）设计详细的用例便于执行，便于新人理解，便于知识传承。”虽然做为一个新人，雯佳略显青涩，但言辞却很犀利。

　　然后是反方一辩达海发言：“我方认为, 测试用例的粒度应该粗点，主要体现测试思想。（1）粗并不等于简单。测试用例的粒度粗点，是建立在我们对需求完全理解，对设计完全掌握的基础上的粗粒度。这样我们可以避免繁琐的流程，提高测试执行的效率，把握重点需求。测试粗粒度可以避免陷入机械性的测试。（2）粗粒度的测试设计可以使我们把重点关注于设计，可以让测试往前走，在时间，资源有限的情况下，更高效地进行测试，保证产品质量。

　　随后进入激烈的自由辩论环节。双方你来我往，引起大家的阵阵喝彩。

　　正方：“测试用例过粗，当拿着过粗的用例都执行不下去时，如何让新人在执行中得到提升？”

　　反方：“如果都按照师父的提供的测试用例去测试，是否可以达到技能提升。”

　　反方：“思想就像大脑，测试用例是骨骼。在时间有限，资源有限时，必须要有所取舍，抓住主干测试，所以我们会追求白盒覆盖率而不是路径覆盖率。测试技能的提高是测试思想的不断丰富，测试手段的不断完善，而不是用例越写越细”

　　正方：“在测试领域有8：2原则，80%的bug源于经常修改的20%代码，tc的数量提升有利于减少这种bug遗漏。并且，越精细的用例越便于定位BUG”

　　反方：“就是因为我们的用例过细，导致在时间，资源紧张的情况下，导致覆盖律低，没有发现尽可能多的BUG,相反，如果我们在测试设计的时候，放得粗，可以把主要精力放在测试思想上，这样就可以提高测试覆盖率，发现更多的BUG。测试用例的设计要先搭一个整体的框架，然后再逐步完善”

　　正方：“逐步完善的过程是不是用例越来越细？”

　　在激烈的辩论中，时间到了。大家意犹未尽。

　　评委进行了精彩的点评：

　　辩论会是一种很好的形式，可以活跃大家思维。正方一辩马雯佳思路清晰，在立论阶段提出了很多很好的论据。可惜在后面的论辩过程中并没有展开。从管理者角度来看，还是希望测试用例的粒度细点好。

　　测试用例的粒度取决于项目质量的要求，时间的要求，用户的要求。如果时间充足，就可以把用例写细一些，时间紧张，就写粗些。有个词叫测试艺术家。就是要我们掌握质量与效率之间的平衡。

　　我们的用例不管是细还是粗，它都是为了达到最终目的“保证产品质量”。测试用例写粗点还是细点，可以用一个例子来说明。当我们刚学车的时候，什么时候打方向盘，什么时候踩离合，什么时候踩油门。都需要教练一步步教，要一步步来，这些都很明确的。当开车有一段时间后，什么情况下要做什么动作都会很自然，一气呵成。当我们的新人在进行测试的时候，需要很明确地知道怎么做，这时候用例就得细些。当成为一个很熟练的测试工程师的时候，设计用例时就不必纠结于这些细节了。每个阶段不同，做事方式就不同，只要满足结果就好。

本文转自：http://www.51testing.com/html/28/n-218628.html