总是希望能给手下一些机会来锻炼他们在项目中的leadership的能力，公司那边也来指示精神，要我们这些老鬼们抓大放小，放大胆子让手下的娃儿们把项目挑起来。所以那些都想当将军的士兵们个个摩拳擦掌的跃跃欲试。于是我们开始了每个人一周的代理leader的尝试，经过一个月的试运行，发现大家积极性都比往常高了，对项目的了解和关注都空前高涨，不过是运行中也发现了这样或者那样的不足，于是记录下来，总结如下。
　　以下为了方便描述我们简称他们为小A。
　　1. 信息乱，文档化意识不强
　　项目中一些重要信息往往只是在MSN，或者口头说一下，无法跟踪分析。
　　案例分析：记得小A初任代理leader一职的时候，意气风发，一会统计大家的机器配置，一会儿查看服务器的使用情况，问完了也就没消息了，事后在大伙建议下，建立文档专人负责更新。
　　2. 思路不清楚，随机性强
　　小A们的特点就是想到什么就说什么，没形成固定的标准。
　　案例分析：我们要测试一些老的测试用例，我们的小A一开始光分配工作了，对怎么填写没做要求，经过提醒，才制定出一个标准，但是在Fail情况下是使用红色加粗还是都是黑色犹豫了很久。直到最后我按捺不住了，要她给个痛快的时候，那扭扭捏捏的说了一个标准大家执行。作为leader需要的就是给大家一个标准，一个方向，很忌讳目标不明确的任务。
　　3. 出发点是好的，可惜可操作性不强
作为新人，思维总是跳跃，我们鼓励大家思考，去改进流程，促进项目更好的管理，可能有的想法现在不成熟，或者说现在的条件不够。
案例分析：我们的小A很喜欢开会，总结，喜欢大家一起讨论学习，这并不是坏事情，但是她的想法是在项目最忙碌的时候，而且很机械的固定每天必须要多少时间，来学习总结工作经验，当然在我们竭力反对和劝说下，小A放弃了这项计划。
　　4. 自信不够或者过于自信
　　这是两极端，多了少了都不好，自信来源自己的积累．别怕犯错，要善于总结．
　　案例分析：做完smoke test了，需要发个报告给开发，是否接受，小Ａ就很着急，找来sample，按理说很容易写的，不过以往都是pass，这次是fail，所以我们就告诉小Ａ把问题描述清楚，状态就设置成reject好了，小Ａ如临大敌，憋了多小时写了几个字，还非要我们review一下．
　　5. 依葫芦画瓢，形似神非
　　新人的学习能力很强，模仿性很强，只是有时候没去理解为什么，拿过来用就好了．
　　案例分析：某日临近中午的时候，忽然收到今天工作的安排，甚是差异，忙呼之以明真相，果然，平时因为我们带几个新人，习惯了分配任务下去，担心他们自己不会安排，没想到我们的小A，忙完自己的事情，忽然发现小本子上记得要发工作安排，特地整理并组织了一封很正式的邮件给我们．我观察到收信时间已经临近中午。
　　6. 下达任务的时候不清晰，容易误会
　　因为缺乏经验以及必要的思考，所以在分配一些应变任务的时候，task很模糊，容易造成误会，花费很多人力去做无用功。
　　案例分析：客户来了个更新的需求分析文档，我们的小A就马上放到共享目录下，告诉大家都去看下，语气很紧急，很重要的。我们等手下见状，不敢怠慢，草木皆兵，即刻打开文档，因为文档没更新记录，所以通读全片，发现就多了一个大家都知道的流程图，虚惊一场。大伙却白白花了很多时间。事后，小A还觉得自己很有理，其实我们拿到东西的时候都会自己先浏览一遍，看有多少价值，少的话，可以自己总结，然后share给大家，多的话，才会调整项目的schedule来进行处理。像这样劳民伤财的举动尽量避免。
　　7. 缺乏解决问题的能力
　　项目中总会遇到这样或者那样的问题，小A们最喜欢说的，老大，那个怎么做啊？
　　案例分析：有次小A在写个新功能的测试用例。花了半天时间琢磨，后来鼓气勇气告诉我们不太会写，看不懂需求（因为事先我们已经告诉他们自己要学着去独立解决问题，尽量自己先思考了）。原来是小A要写的测试用例是我们系统和另外系统的接口的测试，所以对于一些陌生的名词，自己就迷糊了。当然这样的东西在以前培训中都讲到过了，也有相应的文档可以参考的。
　　8. 缺乏判断，来什么做什么
　　可能是新人的原因，比较容易被客户牵着走，因为客户是上帝啊，所以客户想要的就是我们要给的。
　　案例分析：一早客户来要我们填个最新测试情况的文档，也没很着急的要，我们的代理leader小A就着急的招呼大家去填写，吩咐了最晚提交时间，还时不时的提醒大伙要记得按时填写，结果那天我们的测试进度都延误了，作为leader，需要去权衡利弊，知道什么是紧急，什么是不紧急的，而且有的事情可以一起做效率高。敢于和客户有条件的say no。当然也不是客户的什么要求都不需要接受。到时候别客户投诉了，别怪我哦。
　　9. 习惯自己做事情，不会分配工作
　　自从小Ａ作了代理leader,很明显的就是平时工作忙了，加班时间长了。具体一问，很多文档需要更新，记录。其实很多时候大家都在做这些事情，自己更新自己的就好了。比如我们每天的例会就是轮流主持，轮流记录，养成了习惯，leader的工作自然会减轻很多。
　　10. 缺少主见，墙头草
　　项目中总少了不几个资深的，几个刺头，在一些项目细节处理的时候，我们的代理leader习惯性的墙头草，那边嗓门大就倒在那边，当然两边都有道理，或者是一些标准的制定，可有可无的，那时候就需要leader最后定下来，减少一些无谓的讨论和争论，个人觉得有时候作为leader需要专制点，来处理一些问题，否则会发现一些会议是在磨时间，无法产生了conclusion的output。这可能就是民主的悲哀。
　　11. 对业务缺少深度了解，一知半解
　　真没见过几个新人会把自己的精力放在学习业务知识上的，即便有时候项目有时间，给他们去看去学习，发现收获很少，这个是一个普遍的现象，所以就不举例说明，这边只是分享一些我的个人经验，对于项目需要一定的专业知识作为基础，但是通常情况下，我们可能对我们要测试的行业一无所知，所以在日常工作中我们会有针对性安排这样的学习和培训，当然很多时候是自己利用空余时间学习，在学习完或者测试前，自己会去冥想，项目的流程是什么样子的，其中的业务逻辑是什么样子，除了正常的情况，异常的情况呢，当然适当的交流，讨论可以帮我们整理思路，巩固知识。
　　结束语：
　　作为leader，不是一时半会可以修炼成功的，不是经历了几个项目就可以沾沾自喜了，即便我们这些在项目里摸爬滚打近十年的老鬼们，也每天在学习，每天在成长，别眼高手低，测试的基础知识不可少，再加上自己的总结，不仅仅是自己的实践经验，更多是别人的，特别是一个好的leader能让手下迅速成长起来。不过良马常有，伯乐不常有，自己多学多看多想，别怕犯错，但别总犯一样的错，明天肯定是很精彩的 ^_^。

当“好人”前提是做好本分
“三好精神”到底是否适用于职场?人力资源专家、北大纵横高级合伙人王山认为，前提是要先做好自己的本分。
职场生存其实比宫廷还难一些。企业为什么会请你?因为你对企业有用，你和企业之间的关系是市场关系的延续，说的白一些是一种“交换关系”，能否在企业生存是看你的使用价值。职场中处理好人与人关系自然重要，做三好学生也是无可厚非。但现代职场更多考虑的是“任职资格”和“胜任力模型”，即把合适的人放在合适的位置上，而你要把你该做的事情做好，才对得起企业付给的工资，否则无论你人有多好，你的老板(上司)还是不得不请你走人。


职场人士对刘三好精神的反感与当今职场主力80后的强烈的自我意识有关。无论是许三多式的只做不说，还是余责成的左右逢源到大智若愚的刘三好这些榜样，也许代表的是70后的心态。正所谓吃的苦中苦，方为人上人。但对80后们来说，“三好”们只是一些不会干事只会做人的庸人。
“三好”们在企业还是能够生存的，但前提是先做好自己的本分。“三好精神”只能作为锦上添花，而不能成为你上班的主要工作。好事要做，不要影响企业运作;好话要说，但一定要有立场，存好心也对，只要不好心办坏事。

职场是非多，你要做好人?也未必受落!
有“翻版《金枝欲孽》+韩剧《大长今》”之称的热播剧《宫心计》，讲述一个毫无背景的小宫女，磕磕碰碰地走到宫中“高层”之位。主角之一“刘三好”备受争议———她是在宫廷斗争中
“出污泥而不染”的大好人，宣扬“三好精神”：做好事、说好话、存好心，并受到同事上司的赞赏。
获取职场成功之道的途径并不多，榜样中唐骏也好李开复也好，离普通打工仔似乎也太远。所以人们把眼光投向了荧屏上的小人物，从前段时间的《士兵突击》的许三多，再到《潜伏》中的余则成，或者是正在热播《宫心计》中的刘三好，似乎都有着职场精英的影子。做好人可以升职加薪?这一点又在职场上引起热议。在现实中，刘三好这种过于正面的“三好精神”，令在职人士们大为反感，纷纷数落起“大好人”们的种种“罪行”。看来，好人唔易做，往往还会遭遇“里外不是人”的尴尬。

戏说“三好”
王老师：刘三好的成功在勾心斗角的宫廷之中太过“非典型”了!因为非典型，也能给没性格的“老好人”、“非成功人士”有点幻想的空间罢了。

Angle：刘三好能在险恶的后宫生存，除了心地好之外，运气好有贵人相助也很重要。她的“三好”应该换成运气好、人缘好、样貌好才对，不然做多少好事也无法博得“领导”的赏识。
豆豆妈：“三好”其实是个厉害角色。首先她熟悉宫中上下各种人物关系，然后既要上至天文、下至地理略懂一二，又要有一门专业手艺，最后，找个有发展前途的好上司，就不一定循规蹈矩。在关键时候，运用起几样学识，才有“出口救人”的效果。

“做好事”———鹤立鸡群犯众憎
做好事本无错，但每次都大大超过“好”的平均水平，让自己显得鹤立鸡群，反而会变成众矢之的。
Anny在看电视剧的时候，特别讨厌“三好”，因为“她”会让她忍不住想起公司里的一个新同事。Anny是做销售的，每组人每个月会有一定的销售任务，平时各组都有“默契”，步速不紧不慢，反正到月底结算时，都有不同量的超额就好。那位新同事做事积极，样样争先，一进公司就督促组员半个月就完成了当月的销售量，令上司一下子质疑他们原有小组的工作能力。而且，凡是公司有促销活动，无论是否安排他去帮忙，他都会自动自觉跑去做“义工”。Anny抱怨说：平时工作已经够忙的了，结果因为他的“积极”，其他同事也不能“甘于落后”地跟着去促销场帮忙，变相加重了工作量。

有网友在“戏说三好“时认为：“同样毫无背景的宫女出身，三好的姊妹金铃的处事方式反而更加普遍，但因为有三好这样的人存在，对比之下就成了丑角的。”“三好”以做好事博出位，确实容易得到上司的称赞，不过就失去同事之爱，为以后工作埋下阻碍的伏笔。

“说好话”———假好人真小人
“说好话，谁不会呢?最怕是口是心非。”标准办公室女郎沫沫，当了几年经理助理，见过口蜜腹剑的小人太多，现在已经不再相信有“说好话”的好人了。
沫沫的上司相当受公司器重，随之而来巴结的人自然就多。不过，去年公司要裁员的时候，上司差点被“说好话”的同事“淘汰”了。当时公司宣称要适当裁员，要求员工之间互相评分，采取“末位淘汰制”。恰好沫沫上司做的一个较为重要的投标项目没中标，大家就以此为由，只给他很低的分数。讽刺的是，给低分的不乏平时常对着上司说好话的“马屁精”!沫沫感叹道：“平时给你一两句赞美，又没有成本，有什么所谓?但关键时候能‘出口相救’的少之又少。”

另外，常对你“说好话”的人，谨防是小人!跟沫沫一样当助理的小崔，刚入职时不熟悉对处理各种繁琐事情，只好去请教同样做文职的一个资深阿姨。阿姨一边教一边赞小崔天资聪颖之类，让小崔听得飘飘然的，不知不觉地把阿姨当成同事好友，无话不说。边做边学了一阵子，小崔的工作始终未见起色，上司不满意的时候越来越多。有一次偶然发现，阿姨背地里找上司投诉他办事不力，而最终目的是把她的小外甥推荐入公司、顶小崔的职位。
“存好心”———未必有好下场

存好心，最怕是好心做坏事。好事做不成，还让自己遭遇“里外不是人“的尴尬。
刚刚大学毕业的小宇找工作还算顺利。为了尽快与同事搞好关系，对同事们的要求几乎没有拒绝过，有时还主动为同事分担工作，结果在小宇还未能单独做项目的一个月内，他就迅速变成办公室里最忙碌的人。买早餐、吃饭订座、发快递……琐碎工作让小宇自动升级成高级打杂，完全没有时间做他的正职———设计图样。上周日有同事因为要去相亲，想和小宇代班，小宇家里不巧有事就拒绝了她。之后，女同事明显冷落他，甚至背后议论他说：“领导的要求有求必应，同事的请求就摇头拒绝”。小宇觉得委屈：“我帮她是人情，不帮他是道理!”当习惯成自然的时候，你想改变角色定位、不再当老好人就难了。

因为好心而没有了主见的人，更有可能成为裁员的首要目标。在公司里出了名的“老好人”阿辉，工作中他与大家共进退，有困难与大家一起扛;别人说好，他就说好;别人说坏，他就不作声，默默隐匿在大家之中，久而久之他成了老板视而不见的隐形人。公司不景气，老板有意裁员，却首先想到了他。有星级酒店的人力资源人士表示：职场中的“老好人”，事实上最终将成为一个碌碌无为的人，他们在职场中总是因为分担了别人的工作而使自己职责范围内的工作一团糟，而且大部分人从来不敢表现出自己的想法，表达出自己的态度，相信这样的人在职场上是永远都不会有突破，永远都不会成功。

在我测试工作的前5年，一直以为测试的目标和价值就是在黑盒测试活动中找bug，以找到bug越多越自豪。但当我随着商业意识的不断积累，跳出测试的视角，站在公司的角度看测试时，会发现测试的目标是商业成功，而不仅是找bug。商业成功的关键是什么？简单点说就是可以长期地稳定获得大量的客户并获得足够的利润。而要想长期稳定的得到客户的喜爱，就必须提供让用户满意的质量，这是测试找bug的初衷。可是商业成功要解决的“大量的客户”，“足够的利润”，如何由测试来保障呢？“大量的用户”的获得有时关键就是看谁的产品先推向市场，先占领市场。因此一个词“TTM——Time to Market”就是非常重要的，测试应该支撑项目在满足质量目标的条件下能及时地推向市场，而不是拖延产品的发布进度。“足够的利润”就要确保成本越低越好。减少研发人力：减少开发人力和测试人力；减少研发时间：减少开发修改bug的时间和减少测试活动时间；就能帮助产品减少成本，提高产品的利润。

项目成功的铁三角：质量，成本，进度。每一个关键因素都需要测试人员来做出贡献和支撑。如果仅仅只找bug，可能只支撑了质量，甚至有时也并未真正保障了客户想要的质量。那么测试如何支撑项目成功的成本和进度呢？这时需要的就不仅仅是自动化测试，虽然自动化测试能起到一定的效果。但更需要具有商业意识的测试领导者，站在公司的角度思考选择做正确的测试决策。

下面就以一个案例来证明测试如何更大地发挥其应有的商业价值：

如果一个项目有10个功能：3个功能支撑性能，3个功能支撑可靠性，2个功能支撑可用性，2个功能支撑基本功能。（客户最关心：可靠性，不太在意性能和可用性）

测试如何支撑项目获得更短的研发周期和更低的研发成本：

反面案例：

一个测试思考简单化的测试经理，可能要求10个测试人员进行10个功能的全面测试。1个测试人员的生产力为：1个功能需要10天测试完成，1天发现1个bug。10个测试人员用了10天时间完成了测试，并在每个功能发现了10个bug，一共100个bug。

1个开发人员的生产力为：1天修复1个bug。100个bug需要10个开发人员修改10天。

总结：重点功能50个bug，开发人力：100人天。测试人力：100人天，项目用时：20天。

正面案例：

一个真正了解客户需求，理解公司商业利益的测试经理做了如下决策：用10个测试人员，2个人一组重点测试可靠性的3个功能和2个基本功能，用时5天，每个功能发现10个bug，重点功能共发现50个bug。其余5个非重点功能的测试工作量可以减少一半，用时2.5天，每个功能发现5个bug，非重点功能共发现25个bug。开发人员10人，修改75个bug，用时7.5天。

总结：重点功能50个bug，开发人力：75人天，测试人力：75人天，项目用时：15天。

从以上数据可以看到，只需要测试经理或测试架构师多用一点时间来思考，以公司最终目标：“在保障满足客户需求质量的前提下成本更低，进度更快”为自己的工作目标。避免大而全的唯bug论，就可以发现在重点功能质量标准不下降的前提下，可以实现开发和测试都节省了25%的研发成本和25%的研发进度。

测试如何支撑项目获得更高质量的同时有更短的研发周期和更低的研发成本：

测试经理做了如下决策：用10个测试人员，2个人一组重点测试可靠性的3个功能和2个基本功能，每个功能发现15个bug，重点功能共发现75个bug，用时7.5天。其余5个功能的测试工作量可以减少为1/4，用时1.25天，每个功能发现2.5个bug，非重点功能共发现12.5个bug。开发人员10人，修改87.5个bug，用时8.75天。

总结：重点功能75个bug，开发人力：87.5人天，测试人力：87.5人天，项目用时：17.5天。

  从以上数据可以发现在同样的测试人力和开发人力情况下，最应该保障的重点功能发现了更多的bug，为原方案的150％，必须重点关注的地方的相对质量得到了提升，而研发成本下降为87.5%,研发进度减少了2.5％。

本文通过一个简单的案例故事，说明了测试的价值不仅是找bug，只要我们测试工作追求科学的思考，而不盲目的干活，那么我们测试执行活动也能在提高关键质量目标的同时，帮助公司降低研发成本，减少研发时间，全面真正支撑公司商业成功所必须的：更快的进度，更低的成本，更高的质量。

希望我们广大测试人员能从平时的测试工具研究使用和测试脚本开发过程中多抬头思考，选择正确的事来做，做到事半功倍。要相信测试人员能创造更大的商业价值，而不仅仅是bug。

注：本文转自http://www.51testing.com/?uid-293557-action-viewspace-itemid-172908 

宫廷争斗中学职场攻心术

影视标本：《宫心计》

启示录：待人处世绝对是一门深厚的艺术。平凡如你我的办公室小小职员，至少可以从中学会“揣摩上意”的方式，减少行差踏错。

时下剧集暗藏“办公室政治”的颇多，间谍戏《潜伏》蕴藏了职场“厚黑学”、商战戏《绝代商骄》暗藏了“办公室生存法则”。时下正在热播的TVB台庆剧《宫心计》更直接地讲述了后宫的权术斗争，引发荧屏下观众对职场艺术的热议：老板如何摆平下属职员的纷争，下属如何借招“上位”。

A.如果你是老板……

■适当留面

剧情：金铃设计的“竹报平安”的发钗式样被部门中地位更高的掌珍程颖芳骗去据为己有，金铃为此在部门领导阮司珍面前吵闹。但阮司珍明知是程颖芳抢功依然批评了金铃。

点评：金字塔形式的人力资源需要你确保中层领导的权威。他们没有威信就意味着你需要接受处理中层原本可以处理的事情，大大降低你的工作效率。

■扑朔迷离

剧情：金铃向太后告密是惠妃给皇帝吃了金丹导致皇帝中毒，尚宫局得以解除危机，金铃以为蔡尚宫要感激自己救了尚宫局，岂料，蔡尚 宫斥责她知情不早报且予以惩罚。同样，三好救了郑皇后导致太后不满，以为太后要百般刁难，岂知却得到了太后的称赞。 点评：如果次次都被下属猜中你的心思，那么下属取代你的时间相信不远了。

■暗度陈仓

剧情：三好与金铃夜会被同屋撞见，告发到不许两房私下来往的钟司制那里。钟司制被带去现场抓三好。走到门口，大叫“有蛇”并让带路的女史去查看，给金铃离开的机会，果然进去只有三好一人。

点评：领导也是人，也有偏爱的人才，但是不能因为欣赏他而被其他员工指责你不公平。因此，当你欣赏的人才犯错之后，不能一味偏袒。既要保住你欣赏的人才，同时又要让其他人觉得你处事公平。

■假手他人

剧情：服侍太后多年的徐妈妈违反宫规在后宫放高利贷,还企图嫁祸给尚宫局，事情被揭发后，太后将徐交由尚宫局处理。

点评：所谓“关系户”自然与你有某种特别的关系，他们犯了错或者不能胜任工作时应该怎么处理？你亲自收拾，或被非议，说你不讲人情，假借他人之手是最好的选择。

■留条后路

剧情：胡司设因害阮不成而自杀，职位悬空，蔡尚宫欲将阮调往司设房为两房之首，并暗示阮有机会当尚宫，其实蔡是要腾空司珍之位，让三好上位，希望三好感恩图报，向郑太后求情，令自己离宫安享晚年。

总结：谁都知道要为自己留条后路，但是怎么铺设后路？一要看准人，不能捧“阿斗”。二要摆平其他关系，不要临走还去得罪人。

■保持“内讧”

剧情：蔡尚宫明知钟司制与阮司珍水火不容，坚持将阮提拔与钟平起平坐。

点评：身为领导，不能让下属太团结，否则被动的只会是自己。领导看部下争斗，就好像猫看老鼠打架。他拿捏得住你，你们要怎么折腾就折腾去。

■信任有度

剧情：谭司膳恼恨蔡尚宫原本答应自己退休时让她接任的承诺食言，向阮司珍和钟司制道出了当年阮出红疹不能出宫与情郎变路人以及钟被栽赃嫁祸均为蔡尚宫所安排，令蔡尚宫如意算盘破局。

总结：做领导不能对下属太过信任。尽管可以常对部下说“我很放心你”，但事实必须正好相反。你必须让部下相信你，但不能轻易相信部下。如果太信任下属，让下属知道太多你的秘密，你终有栽在他手里的一天。

B.如果你是下属……

■扮猪吃老虎

剧情：光王天资聪颖，被太后当成心腹大患，处处设计陷害，幸得阮司珍出谋划策，让光王假扮从树上跌落脑部受伤智力停留在10岁孩童的程度，光王才得以被送往道观养病，安然长大。到马元贽杀掉皇帝捧光王上位之后他才暴露自己的才智。

点评：锋芒毕露并非好事，偶尔装装傻，放放烟幕弹，可以麻痹对手。重要的是眼光要长远，锋芒要用在关键时刻。

■留一手，钓鱼

剧情：服侍太后的徐妈妈在宫中放高利贷，败露后企图嫁祸钟司制。蔡尚宫为保下属与其理论。奉王贵妃之命用刑的徐妈妈假装自己是无旨办事，引诱蔡尚宫将事情闹到太后面前，才说出自己奉谁之旨，令蔡尚宫自乱阵脚，被打入天牢。

点评：这个属于“钓鱼”的办公室版。秘而不宣的底牌就像钩子上的鱼饵，鱼被钩住你就掌握了主动权。

■别太功利

剧情：何采女没钱打点尚宫局，司珍、司制都不愿意费心为她做行头讨好皇上。但三好觉得她可怜，偷偷为她做了一只“影舞荧光”，何采女得到皇上宠幸，三好的技法也得到了太后赏识。

点评：做事情不要太功利。有些烂活大家都觉得无利可图不愿干。只要你扎实肯干，也许就在没有预料的情况下得到丰厚的收获。

■找准后台

剧情：阮司珍在光王母子完全没有前途的时候还是帮助他们出谋划策。刘三好在光王还在扮傻保命时就已经与光王在后宫的斗争中结下了深厚的情谊。

点评：领导很重要，靠山更重要。有好的靠山，直接领导就不能轻易动你，甚至必须拉拢你。

■保持中立

剧情：在充满暗涌险滩的尚宫局，刘三好保持着中立，不明确站队，但与各司老板都保持良好关系。加上自身有实力，不管哪个派系掌权，她都是被团结的对象。

点评：保持中立的前提是你自己要有实力。没有实力的人只能明确态度站好位置等待别人来扶持你。

■不要讨好上司的仇人

剧情：三好将赏赐的糕点送给自己上司的死对头吃，恰被上司看到。

点评：世上没有不透风的墙，讨好上司的“仇人”就得预先想好如何应对责问。同样忌讳的还有搭救老板的“眼中钉”。

也许你象爱因斯坦一样聪明，创意也绝对独特，为什么在别人眼中依旧是无足轻重？先不要因此抑郁，生活往往是可以改变的，试着按以下的要点做，你会成为上司眼中不可缺少的重磅人才。

1、早到。别以为没人注意到你的出勤情况，上司可全都是睁大眼睛在瞧着呢？如果能提早一点到公司，就显得你很重视这份工作。

2、不要过于固执。工作时时在扩展，不要老是以“这不是我份内的工作”为由来逃避责任。当前额外的工作指派到你头上时，不妨视之为考验。

3、苦中求乐。不管你接受的工作多么艰巨，鞠躬尽瘁也要做好，千万别表现出你做不来或不知从何入手的样子。

4、立刻动手。接到工作要立刻动手，迅速准确及时完成，反应敏捷给人的印象是金钱买不到的。

5、谨言。职务上的机密必须守口如瓶。

6、亦步亦趋跟主管。上司的时间比你的时间宝贵，不管他临时指派了什么工作给你，都比你手头上的工作来得重要。

7、荣耀归于上司。即让上司在人前人后永远光鲜。

8、保持冷静。面对任何状况都能处之泰然的人，一开始就取得了优势。老板、客户不仅钦佩那些面对危机声色不变的人，更欣赏能妥善解决问题的人。

9、别存在太多的希望。千万别期盼所有的事情都会照你的计划而行。相反，你得时时为可能产生的错误做准备。

10、决断力要够。遇事犹豫不决或过度依赖他人意见的人，是一辈子注定要被打入冷宫的。

11、善于资讯。要想成为一个成功的人，光是从影音媒体取得资讯是不够的，多看报章杂志才是最直接的知识来源。

小区切换
在无线通信系统中，当移动台从一个小区（指基站或者基站的覆盖范围）移动到另一个小区时，为了保持移动用户的不中断通信需要进行的信道切换。

如何成功并快捷地完成小区切换，是无线通信系统中蜂窝小区系统设计的重要方面之一。

英文全称：Channel Switch

小区切换-概述

在GSM这样的蜂窝小区系统中，充分采用了频率复用的概念，使一个区域是由多个小区来共同完成覆盖的。这样就出现了一个小区自动切换的概念，一个简单的例子，当一个移动用户正在通话的时候，从某小区的覆盖范围移动到另一个小区的覆盖范围时，为使通话不被中断需要自动切换信道。这个过程应在用户察觉不到的情况下进行，也不需要用户介入。

判定移动台是否需要小区切换有三种准则：

1.依靠接收信号载波电平判定。当信号载波电平低于门限电平（例如－100dBm），则进行切换。

2.依接收信号载干比判定。当载干比低于给定值时，则进行切换。

3.依移动台到基站的距离判定。当距离大于给定值时，则进行切换。

实际上，在通话过程中测量接收信号载/干比有一定的困难；而用距离判定时，则距精度有时很难保证。所以，一般常用的时第一种。

小区切换-分类

小区切换从技术上可分硬切换和软切换：

硬切换：新的连接建立前，先中断旧的连接。例如GSM系统。

软切换：指既维持旧的连接，又同时建立新的连接。例如CDMA系统。

小区切换从小区的性质上可分：

同一交换中心基站之间的越区切换

同一BSC之间的切换

不同BSC之间的切换

不同交换中心之间基站的越区切换

微小区与宏小区之间的切换

同基站内不同扇区的切换

不同运营商之间的切换
小区切换-控制

 

过程控制主要有三种：

① 移动台控制的越区切换

移动台连续监测当前基站和几个越区时的候选基站的信号强度和质量，当满足某种越区切换准则后，移动台选择具有可用业务信道的最佳候选基站，并发送越区切换请求。
DECT等小系统常采用，在大系统中容易引起切换冲突。

② 网络控制的越区切换

基站监测来自移动台的信号强度和质量，当信号低于某个门限后，网络开始安排向另一个基站的越区切换。
缺点：若MS失去联系，将造成信号中断。
第一代模拟系统采用此方法
切换时间长，可达10S。

③ 移动台辅助的越区切换

网络要求移动台测量其周围基站的信号并把结果报告给旧基站，网络根据测试结果决定何时进行越区切换以及切换到哪一个基站。
第二代系统GSM，CDMA都采用此方法。
特点：时间快，切换过程1s~2s ，信号中断<1s。

微小区高速移动切换的问题

在微小区，高速移动用户仅有很少时间就需切换，对系统压力太大，一种宏小区与微小区相结合的伞状小区结构，切换时采用宏小区信道可解决上述问题。

觉得这个比喻比较新颖，觉得蛮有意思的，故转自过来。

最近部门中有同事在问这个问题，我想应该还是有满多人对这三个角色的定位还不是很清楚，因此就这三个角色谈谈我个人的认识。

网络上关于这三种角色的定义已经够多，在此就不复赘言。我举个例子。

假设产品投放市场的过程等同与学生考试及格的过程，那么在这个过程中：

开发人员是做考卷的学生。

测试人员是改考卷的老师。

QA人员是辅导员。

产品是开发人员做出来的，产品是否可以在市场使用，考试是否及格，决定性的因素还是在开发。

开发人员提交了结果，学生做完了试卷，是否及格？需要测试人员进行测试的分析与判断。

辅导员对具体课程没有专业知识，但是他会要求开发人员要先复习，然后做模拟题，最后才参加考试。他不管你在复习时看的是《天龙八部》还是《线性代数》，他只要监督你复习了，这就够了。因为他知道，不复习直接考试，基本上就是不及格的命。复习了，总比不复习好。

OK，例子说完了，回到三个角色。

开发是实现过程。测试与QA是质量保证过程。

测试与开发一样，是一个单纯的技术活，我称之为结果控制。QA不涉及具体的技术，我称之为过程控制。

扯句题外话，通过组织架构、业务流程甚至IT工具的改革来提升产品质量甚至企业核心竞争力，是大多数企业发展的认识。IBM把PC卖给联想后，就靠这个来赚钱，赚的还不少。

我是做测试的，下面说说就上面这个例子说说测试的发展方向。

测试既然是改考卷的，那么什么能力最重要？

当然是出考卷的水平了。

测试需求分析、测试用例设计，是每个测试人员在工作中都必须不断提升的能力。

转自；http://www.51testing.com/?uid-22490-action-viewspace-itemid-129603

这2个概念我一直都搞不清楚，看到这篇文章觉得不错，所以转载过来，最后的那句话算是真谛。
一、测试计划：

　　对测试全过程的组织、资源、原则等进行规定和约束，并制订测试全过程各个阶段的任务以及时间进度安排，提出对各项任务的评估、风险分析和需求管理。

　　二、测试方案：

　　描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。

　　三、测试计划是组织管理层面的文件，从组织管理的角度对一次测试活动进行规划。

　　四、测试方案是技术层面的文档，从技术的角度度一次测试活动进行规划。

　　五、测试计划要明确的内容：

　　1、明确测试组织的组织形式

　　1>测试组织和其他部门关系，责任划分。

　　2>测试组织内的机构和责任安排。

　　2、明确测试的测试对象（明确测试项，用于后面划分任务,估计工作量等）

　　3、完成测试的需求跟踪

　　4、明确测试中需要遵守的原则

　　1> 测试通过/失败标准

　　2> 测试挂起和回复的必要条件

　　5、明确测试工作任务分配是测试计划的核心

　　1、进行测试任务划分

　　2、进行测试工作量估计

　　3、人员资源和物资源分配

　　4、明确任务的时间和进度安排

　　5、风险的估计和规避措施

　　6、明确测试结束后应交付的测试工作产品

　　六、测试方案的具体内容：

　　1、明确策略

　　2、细化测试特性（形成测试子项）

　　3、测试用例的规划

　　4、测试环境的规划

　　5、自动化测试框架的设计

　　6、测试工具的设计和选择

　　七、测试方案需要在测试计划的指导下进行，测试计划提出“做啥”，而测试方案明确“咋做”。

在软件消亡之前，如果没有测试的结束点，那么软件测试就永无休止，永远不可能结束。软件测试的结束点，要依据自己公司具体情况来制定，不能一概而论！个人认为测试结束点由以下几个条件决定：

1．基于“测试阶段”的原则：

每个软件的测试一般都要经过单元测试、集成测试、系统测试这 几个阶段，我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后，再进行后面一个阶段的测试。举个例子来说：单 元测试，我们要求测试结束点必须满足“核心代码100％经过Code Review”、“功能覆盖率达到100％”、“代码行覆盖率不低于80％”、“不存在A、B类缺陷”、“所有发现缺陷至少60％都纳入缺陷追踪系统且各 级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准，当然也是如此。

2．基于“测试用例”的原则：

测试设计人员设计测试用例，并请项目组成员参与评审，测试用例一旦评审通过，后面测试时，就可以作为测试结束的一个参考标准。比如说在测试过程中，如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在功能测试用例通过率达到100%，非功能性测试用例达到95%以上，允许正常结束测试。但是使用该原则作为测试结束点时，把握好测试用例的质量，非常关键。

3．基于“缺陷收敛趋势”的原则：

软件测试的生命周期中随着测试时间的推移，测试发现的缺陷图线，首先成逐渐上升趋势，然后测试到一定阶段，缺陷又成下降趋势，直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向，来定测试是否可以结束，这也是一个判定标准。

4．基于“缺陷修复率”的原则：

软 件缺陷在测试生命周期中我们分成几个严重等级，它们分别是：严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点 时，严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误；次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺 陷，后面版本解决；对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题，可以暂时不用修改。

5．基于“验收测试”的原则：

很 多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。如果通过用户的测试验 收，就可以立即终止测试部门的测试；如果客户验收测试时，发现了部分缺陷，就可以针对性的修改缺陷后，验证通过后递交客户，相应测试也可以结束。

6．基于“覆盖率”的原则：

对 于测试“覆盖率”的原则，个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求，包括行业隐性需求、功能需求和性能需求等等，只要测试用例执行 的覆盖率达到100%，基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率 应达到100%”都可以作为结束确定点。如果你不放心，非得要看看测试用例的执行效果，检查是否有用例被漏执行的情况，可以对常用的功能进行“抽样测试 ”和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试，每个阶段都不能忽略。

7．基于“项目计划”的原则：

大多 数情况下，每个项目从开始就要编写开发和测试的Schedule，相应的在测试计划中也会对应每个里程碑，对测试进度和测试结束点做一个限制，一般来说都 要和项目组成员（开发，管理，测试，市场，销售人员）达成共识，团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了，测试时间就相应缩短。大多 数情况下是所有规定的测试内容和回归测试都已经运行完成，就可以作为一个结束点。很多不规范的软件公司，都是把项目计划作为一个测试结束点，但是如果把它 作为一个结束点，测试风险较大，软件质量很难得到保证。

8．基于“缺陷度量”的原则：

这个原则也许大家用的不是很多，了 解比较少。我们可以对已经发现的缺陷，运用常用的缺陷分析技术和缺陷分析工具，用图表统计出来，方便查阅，分时间段对缺陷进行度量。我记得以前zhuzx 在这个论坛上提出过缺陷分析技术这个问题，我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然，最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说：一万行代码最多允许存在多少个什 么严重等级的错误，这样比较好量化，比较好实施，成为测试缺陷度量的主流。

9．基于“质量成本”的原则：

一个软件往往要 从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位,就要看是什么软件了。比如说是：人命关天的航天航空软件, 那还是质量重要些,就算多花点钱、推迟一下进度，也要测试能保证较高质量以后才能终止测试，发布版本。如果是一般的常用软件，由于利益和市场的原因，哪怕 有bug，也必须得先推出产品，没办法呀。一般来说，最主要的参考依据是：“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时 候，可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”，同时保证公司利益最大化。如果找到bug的成本比，用户发现bug 的成本还高，也可以终止测试。

10．基于“测试行业经验”的原则：

很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。因此通过测试者的经验，对确认测试执行和结束点也会起到关键性的作用。

本文转自：http://www.51testing.com/?uid-258885-action-viewspace-itemid-142798

问题描述：测试过程中一些bug会被研发认为是无效bug，但从用户角度出发，测试认为该bug需要更改，此时测试如何更有效的说服研发去修改bug？

精彩回答：

　　1. 扭转研发领导的思想，提高研发人员的响应速度：

　　a). 让研发团队的领导重视缺陷：

　　很多研发团队的领导都是销售出生，懂技术的很少，他们和搞技术的想法明显不一样。我在的第一家公司，发布版本时很多时候，都是没有测试结束，功能开发的差不多就把产品卖掉了，后面再对版本不断升级，结果这个公司没多久大概3年不到就散伙了。后面一家公司的领导是做质量管理出 生的，明显对测试的质量要求就不一样，每次要求都特严，对以前测试结束标准都做了进一步的修改。如果领导对缺陷都视而不见，你说研发人员还愿意花大量的力 气去修改Bug吗？所以说，团队的领导的想法或意识，对缺陷是否修改起到非常重要的作用。我记得以前测试高手zhuzx也在每周一问中提到过，大家也可以 借鉴一下。

　　b). 采用常用的缺陷管理工具（QC9.0），提高缺陷的透明度：

　　我们公司使用缺陷管理工具（QC9.0）,测试经理任管理员，给公司高层领导、项目经理、开发经理都分配了权限，自己可以登录系统查询相关信 息。在测试后期，特别是要发布版本前后，领导们一有空，也随时上去浏览一把，无意识给开发人员施加了较大的压力。如果这个时候还有很多Open的缺陷，开 发人员自然不敢怠慢。

　　c). 把开发人员的修改缺陷的响应速度，记入绩效考核内容：

　　由于公司总监特别关注产品质量，我们公司对缺陷修改这一点做得比较好，每次都是递交缺陷以后，开发人员响应特别快。如果有疑问，就马上和测试人 员一对一交流，尽快修复或解决该缺陷。我们公司的口号是：“宁愿花出100倍的代价，也不让发现的缺陷留给客户”。还有一点就是开发人员绩效考核的时候， 我们测试人员要给开发人员打分，很重要的一点就是：开发人员对测试缺陷的响应速度，如果这一项很低的话，老大要找你谈话的，问具体原因是什么？呵呵。所 以，我们公司很少有测试人员追着开发修改缺陷的情况，把修改缺陷的响应速度纳入个人绩效考核，我个人觉的是一种比较好的方式，值得借鉴或推广。

　　2. 组建一个合理的研发团队，规范测试规范：

　　a). 关键是建立一个完善的研发机制：

　　在大多数情况下，是不是软件缺陷或者需不需要修改，怎样修改不是测试人员和开发人员说了算的，应该是靠研发部门的相关制度或相关部门去约束。毕 竟在国内软件的软件企业缺少这样的部门，所以说把修改缺陷相关的重任推到了测试人员的头上，其实对测试人员实在是太不公平了。要解决这个问题，最关键就是 建立一个完善的研发机制，让QA等相关部门督促解决这类问题，比较好。

　　b). 分清团队成员的具体责任：

　　对于研发团队中的每个成员，必须责任明确，否则像督促缺陷修改这样的事情本来不是测试人员的责任，现在都推到测试人员头上了。很郁闷！！

　　c). 完善测试规范，明确Bug管理制度：

　　大部分的公司，都没有单独的部门来单独管理督促缺陷是否修改，都默认为是测试部门的事情。个人觉的最好是赋予项目组中相关人员一定的资质，让他 们去处理这些琐事。经常碰到这样的情况，很多争议的缺陷都一直放到后面一个版本，一段时间下来，几个版本争议的缺陷就多于100个，弄得后面版本也不好发 布。我们的做法是，发布前几天，对每个争议的缺陷用邮件先发给项目组成员先看，后面在召开缺陷评审会议，如果通过，毫无疑问修改，否则关闭或保留到下一个 版本。

本文出自51Testing软件测试网，感谢会员sun_0910在每周一问（08-10-27）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

　　3. 从源头上杜绝无效缺陷的递交：

　　a). 测试前细化测试需求,避免递交歧义缺陷：

　　很多研发不愿意修改的缺陷，大部分都是由于需求不明确或者理解歧义引起的。所以，最好的做法是在测试以前，开个项目会议，细化一下测试需求，让 研发去确认或项目组成员集体Review，达成一致观点。尽量减少理解上的歧义，力争尽早消除无效或争议的软件缺陷，避免递交的缺陷成争议的缺陷。测试人 员无法说服研发，让研发去修复缺陷，长期这样，测试部的威信就大大降低了。

　　b). 把握不准的缺陷，递交以前最好讨论一下：

　　特别是在测试初期，由于测试介入项目时间较短，有时候测试人员对业务或需求了解不深，递交错Bug也是常有的事情。这个时候，往往测试认为自己 递交正确了，开发人员认为自己开发软件是对的，互不相让，如果处理不好，很容易弄僵关系，弄得大家都不是很愉快。要是项目中出现这样的Bug，是很难说服 研发去修改的，还有可能成为研发抓你的“小辫子”的有力证据，要是这样以后就更难做了。个人的一些做法：所有的测试缺陷相互审核后，才递交到缺陷系统上公 开，是最为保险的方法。

　　c). 清楚无歧义的描述Bug，减少随机测试，带来不可重现的Bug：

　　很多时候，测试人员把缺陷描述不清楚或者缺陷有歧义，开发人员看不懂，不明白具体的意思，加上开发人员任务重时间紧，很容易产生逆反心里，这就 让开发人员对测试人员有看法，以后递交的缺陷认可度就大大降低了。还有就是要减少随机测试，一定要保证递交的缺陷能够重复出现，最好要有截图、图片或者用 数码相机照下来，让开发人员认识到这个问题确实存在，并且更具说服力。

　　d). 做好版本配置管理工作，保证测试环境的准确性：

　　很多同事发现的缺陷，只有在测试环境下重现，而在开发环境下不能够重现。这样的缺陷开发人员往往是看不到的，他们很容易得出结论，说测试人员递 交无效的缺陷而被拒绝，大部分情况发现是版本弄错啦！！我们唯一能做的就是做好源代码的配置管理工作，保证测试环境版本的正确性和独立性，自己编译自己部 署测试环境。只有这样，才会减少无效缺陷的递交，避免“费劲周折”说服开发人员修改缺陷。

　　4. 正确分析测试中的软件缺陷：

　　a). 为递交的每个缺陷准备几条充足的理由：

　　一般情况下，我们提到一个Bug时，开发人员都会说出很多可以不修改缺陷的理由，尽量搪塞住我们的口，要求我们关掉缺陷或者置为无效或者延期到 下一个版本。如果你很牛，你可以为自己递交的每个缺陷准备很充足的理由去说服开发人员；如果你不是太强，那就可以求助部门同事，集中测试部门团队的力量， 想一些好的、站得住脚理由，详细介绍给研发人员听，只要我们递交的Bug，每个都具说服力的话，我想他们也会尽快修改的。这种方法还真是不错，大家不妨试 一试。

　　b). 详细分析缺陷给项目带来的各种可能影响或缺陷风险：

　　比如说，我们递交一个缺陷，如果研发的觉的这个缺陷可以修改或可以不修改时。我们一定要给研发分析修改这个缺陷的必要性，不修改，对客户带来哪 种可能影响或存在哪些风险。要在修改缺陷的代价与修复成本的关系上去衡量。相信，当我们对缺陷分析的很详细时，研发人员一定会修改Bug的。

　　5. 做一个聪明的测试工程师：

　　a). 注意和研发人员的沟通技巧：

　　如果测试人员没有做过开发工作，理解也许就比较片面。有的测试人员，对待问题没有耐心，性情比较急，也是常有的事。如果没有较好的沟通技巧，也 许就是几句话的功夫，就和同事争吵了起来，弄得大家都比较尴尬。个人建议：谈话时，要注意沟通技巧，要有换位思维的方式，做事情对事不对人，处理事情一定 要有一颗宽容的心。只有这样，才能够很好的说服研发去修改Bug。

　　b). 和研发人员搞好私人关系，做研发的听众：

　　比较明智的测试人员，一定要学会倾听研发人员的心生。很多时候，开发人员碰到工作困难的时候，很希望和人倾述，如果测试人员是他的听众，那么你 们的关系一定会不错。搞好了私人关系，工作中你递交的缺陷，他们就不会那么斤斤计较了，毕竟关系是基础，关系好了好说话呀，在中国就是如此。如果私人关系 好了，说服研发修改Bug就是很容易的事情。不过得提醒一句：不能因为关系好就把Open的缺陷给关了。

　　6. 抓住时机，不要错过千载难逢的好机会：

　　a). 求助公司上层领导：

　　很多时候，测试到后期，开发人员把缺陷也修改的差不多了，公司领导（比如说老总、总监、项目经理或开发经理）就会随时来测试部门，找测试经理或 负责人了解项目测试的具体情况。如果有一些问题都是争议问题，作为测试Leader的你不妨给领导聊聊，把更高层的人拉进来为测试部门说话，为测试部门撑 腰，但是凡事都有一个度，不能太过分，否则很伤同事的和气。

　　b). 要求客户代表援助：

　　很多GUI的缺陷或可改可不该的缺陷，可能作为客户使用不是很方便。我们可以和客户代表聊聊这样的缺陷，如果客户代表同意这样做，那没问题，可 以不修改；如果客户不同意，他自然会直接找项目经理或高层人员协调解决这个问题，这就不用我们测试人员操心了。因为客户就是上帝，这招不错吧！！！

   软件开发者和测试者对软件测试往往有着完全不同的立场。前者希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确的实现了用户的需求，确立人们对软件质量的信心；后者则是从用户的角度出发，希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑最终用户是否可以接受该产品。

因此，在软件测试过程中，测试者务必要注意以下几点：

1. 测试者不可以是开发者本人，也就是说开发者不应参与设计和执行测试。开发者的测试往往是用来证明软件的正确性的，违背了软件测试的目标。

2. 要始终相信bug一定存在。即使开发者跟你承诺提交的是一个完美的版本，不会有任何问题。因为，现实中的完美是不存在的，同样完美的软件也不存在。任何时候都不能因为开发者的话语而放松对bug的警惕。

3. 在时间和精力允许的情况下，任何时候不要停止测试。不要在发现了很多bug以后很有成就感，觉得不会再有其他bug出现了，就停止测试，这个时候更应该分析bug出现的规律，总结自己的测试结果，更进一步的去发现更深层次的bug。

4. 一定要细心核对所有项目，不要认为类似的情况可以忽略测试。比如：两个非常相似的网页，甚至底层的code可能是一个文件，就认为一个通过测试，另一个也不会有什么问题。因为，bug的出现有很多确定和不确定因素，只有真正确认过，才可以画押。

5. 始终从用户的角度考虑问题，不要有“我觉得这样挺好的”的思想，因为最终需要用户确认才算通过，用户的喜好、操作习惯、企业文化等等决定了最终的需求，我们必须按照需求来测试。

6. 测试者要有耐心，善于和开发者沟通。由于开发者和测试者对测试有着不同的态度，在很多问题上可能难以达成一致，尤其是测试者提出的某些缺陷要开发者来 fix，而开发者不认为这是缺陷的时候，对测试者的沟通交流技巧有较高的要求。首先，测试者要提供足够的证据证明缺陷的确存在，这些证据包括：重现步骤、 环境变量的配置、严重性和优先级的分析、log信息、屏幕截图、与需求对比不一致信息...另外，要理解开发者的心理，对他们的工作给与肯定，不要否认软件做的好的地方，跟开发者打心理战，注意沟通用词，要有耐心。

测试者一定要牢记：测试的目标是想以最少的时间和人力找出软件中潜在的各种错误和缺陷。

如果成功地实施了测试，就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符。此外，实施测试收集到的测试结果数据为可靠性分析提供了依据。

转自：http://www.51testing.com/?uid-236527-action-viewspace-itemid-132936#xspace-itemform

时间过的很快，想想第一份测试工作已经做了近半年，这个项目也快接近尾声。平时自己是1个比较懒的人，但还是需要总结一下的。

学到的东西：
1、测试和开发的关系。这个真的不好把握。太好了，不忍心给他们挑刺，因为他们都很忙，不想因为自己提的Bug让他们加班，总觉得于心不忍，但严重的bug还是要讲原则的。关系太差了，大家都是同事，抬头不见低头见，工作的心情很重要的。自己说不上和开发的关系很好，但至少是不坏。每次报bug时我都会先知会开发一声，和开发确认1下是不是问题。开发过来让我复现问题或是了解bug更多的信息时，我会很热情的招呼。路上遇到了也会很热情的打招呼。所以开发对我都蛮好的，有时候会主动告诉我哪有bug，我问他们有关开发的一些问题时，他们也会蛮热情的告诉我。这点是我最满意的。打算项目结束时，请他们吃饭，感谢他们对我工作的支持。

2、bug的写作。自己在这块做的不太好，有时候描述的不专业，太口语化了。记得刚写bug时，自己从没想过要把相关的文件附上。结果有1次，开发未复现，直接找到我帮忙复现。因为隔的时间有点长，自己把那个文件给删了，现在文件找不到，用其他文件又没有复现，弄的自己特别尴尬，开发觉得你是在糊弄人，但当时这个问题真的存在。后来吸取了教训，测试中遇到用到相关文件出问题的一定记得把文件附上，然后自己备份一下，省得到时候惹来那么多的麻烦。

3、责任意识。自己一直都认为是1个比较负责任的人，但在做测试中还真的不够。这个真的还需要加强。

工作中存在的不足：

1、责任意识不够，不要想着差不多就行了，该较真是还是必须较真的。

2、太容易相信开发的话了。开发有时候不想修改问题，经常会说一些很专业的话说某某平台限制，无法修改之类的话，自己一定要学会思考，不要被开发忽悠了，记得有1次自己真的被他们忽悠了。想想真的是那种被人卖了还替人数钱。

3、文档处理能力不够。自己真的太懒了，也许是平时没有养成好的习惯。在这个项目经常会有需求不明确的，或者是不知道需求的，所以经常会向开发确认，有时候是邮件有时候是电话形式，但一定要记录下来，方便以后查找。如果自己不整理，到时候需要时就不好了。

4、太情绪化了。本来心情不错，但有时候因为测试时环境不够，自己就容易发火，闹脾气。还有向开发确认问题，他们冲我发火，自己也偶尔会掉眼泪。

5、开会发言。在开会时自己很少发言，自己模块需要求助也不知会，测试中遇到问题也不吭声，总喜欢私下说。自己真的是那种在台上就垭口无言，在台下就叽叽呱呱的人。如果自己不表现那领导怎么去认识你？

6、时间的安排。自己在时间的安排上确实处理的不好。平时工作很忙，同时会有几个领导给你任务，每个任务都很重要，但不是每个都很急的，自己一定要分个优先级，否则哪个任务都完成不了。还有有时候任务按周分配的，只要在规定时间内完成就行，但自己一定要有1个合理的安排，每天做什么，不要都等到最后，万一最后一天又临时有任务，看你如何完成！

7、测试的思维。在测试中经常有偶然操作发现严重问题，但就是不知道哪步是最关键的，所以经常要采用排除法，自己有时候一着急就乱了，所以一定要先在纸上写明，然后有条理的去做，一个一个排除。如果胡乱去做的话，时间花费的要多，而且有可能做不出来，这时候就更急了。


暂且就写这些，希望自己在以后的工作中能尽量改正，努力提高自己的测试水平，把测试工作做好。

工作时间不要与同事喋喋不休，这样做只能造成两个影响，一是那个喋喋不休的人觉得你也很清闲，二是别的人觉得你俩都很清闲。

　　不要在老板不在的时间偷懒，因为你手头被打了折扣的工作绩效迟早会将你的所作所为暴露无遗。

　　不要将公司的财物带回家，哪怕是一只废弃的椅子或鼠标垫。

　　不做夸张的装扮，工作场合远离半尺厚的松糕鞋与有孔的牛仔裤，否则你的这种装扮让别人无法集中精神，也制造出与业务极不相称的气氛。

　　不要仅为赚取更多的钱，就为公司的竞争对手做兼职。更不要为了私利，就将公司的机密外泄，这是一种职场上的不忠，员工之大忌。

　　不要淹没在电子邮件中，除非你正在等一个很重要的东西，否则没有必要立即或时时刻刻阅读邮件。预留一段时间，一次性做出处理。

　　不要每日都是一张苦瓜脸，要试着从工作中找寻乐趣，从你的职业中找出令你感兴趣的工作方式并尝试多做一点。试着多一点热忱，可能你就只欠这么一点点。

　　不要推脱一些你认为冗长及不重要的工作，要知道，你所有的贡献与努力都是不会被永远忽略的。

　　不要忘记工作的满足感来自一贯的表现，因此要不断充实自己的专业知识，为公司整体利益做出直接贡献。

　　不要将个人的情绪发泄到公司的客户身上，哪怕是在电话里。在拿起电话前，先让自己冷静一下，然后用适当的问候语去接听办公桌上的电话。

　　不要一到下班时间就消失得无影无踪，如果你未能在下班前将问题解决好，那你必须让人知道。如果你不能继续留下来帮忙，那你应于抵家后打电话回公司看看事情是否已得到控制。就算是平常的日子，在离开公司之前，向你的主管打声招呼也是好的。

　　不要滥请病假，应考虑到自己缺席给他人带来的影响，如真的需要请假，请一定如实申报。

　　不要提交一份连你自己都不想收到的报告，更不要言之无物，因为你不只有填写报告的义务，同时也有提出改善意见的责任。

　　不要言而无信，否则会让所有与你工作上有关系的人都生活在惶恐之中。

　　不要只是一味等候或按照别人的吩咐做事，觉得自己没有负上责任，因此出了错也不用受到谴责。这样的心态只能让人觉得你目光短浅，并永不将你列为升迁之列。

　　不要在工作时间打私人电话，电话亭就在街边500米的地方，休息时间走出去，虽然要付出两枚硬币，但你的形象却不受损。

　　冒领功劳等于制造敌人，若你因一个不属于自己的成绩而受到称赞，那么你就坦白地讲出来。

　　不要在上司说些不好笑的笑话时开怀大笑，应明白上司需要一个有创意、有热忱的工作者远远胜过一个应声虫。

　　不要把办公室家庭化，这是不专业的表现，也是侵犯公司领地，更何况公司的客户没几个人愿意知道你的家庭是什么样