走我自己有特色的测试之路
-
职场前辈的九个发自肺腑的忠告（转贴）
2008-12-15 10:56:25
职场前辈的九个发自肺腑的忠告（转贴）
当年，在大学毕业聚餐的时候，一位在我们班进修的过来人说，你们到了单位后，一定要夹着尾巴做人，不然最后吃苦头的都是你们自己……。那时很多人听了都不舒服，不以为然，现在，经过了多年职场生涯，想想那时我们大多数人是不懂事的，从大学到工作单位，绝对有很多需要我们改变和学习的。
忠告一：勤快总没有错
作为一个职场新人，勤快点总没有错，最忌讳的是眼高手低又懒。一般新人到职场，都不会立刻适应环境，那勤快些的比较多能得到老员工的指导，也更多地会得到一些机会。
记得一次部门来了三个新人，其中一个名校的，一个二流学校的，一个四流学校的。那个名校的透着一股聪明劲，夸夸奇谈，开始比较吸引我的注意力，偶就有意给他锻炼一下，结果一段时间下来发现小孩不踏实，口才很好，但一碰到烦琐的事就往后躲，最大的毛病是懒，能写五十个字决不写五十一个。他并不是能力问题，文笔也还可以，而且几个新人都打过开水，只有他一次也没见打过。
几次后就把这个小孩PASS掉了。
再谈那个二流学校的，看起来笨笨的，后来发现该小孩很勤奋，很快适应了环境，最后这个小孩也是在我们那里发展得最好。
忠告二：大企业锻炼，小企业发展
经常有新人问我们，我是到一个大企业去呢，还是到一个发展中的小企业去呢？我的看法是：如你是个新人，则建议你先到一个大单位去，在那里可以学到很多规范和规矩，但由于大单位一般已形成了固定的组织结构，新人想往上发展可能会比较难（一般而言），最后可能就变成了一颗螺丝钉。当在大企业积累了一定做人和做事的经验后，再到一个发展势头良好的小单位，你就会比较容易获得快速向上发展的机会。
我的经历是反过来的，因此走了一些弯路。先在一个小企业，该小企业发展极快，因此在这里很快就挑了大梁，但小企业做事没有什么规矩，业务发展快，但企业总体规划业务流程人事管理都是乱糟糟的。后来企业重组进了一家大公司，原单位的人就很不能适应，这一方面是因为大公司业务管理人事更复杂，另一方面，我们没有受过规范的训练，自然与大公司的运作流程不适应，在处理人事方面，也没有相应的经验。不过，我是个喜欢观察总结的人，现在已经适应了，但一些同事至今还在怨天尤人。
举个例子来说，在原来的小企业时，由于单位发展快，制度和流程建设滞后，很多项目都没有建立文档或只有很简单的文档，我那时还负责着一个部门，但也不懂这些，给领导的方案、报告都是很简单的，有时就在一张纸上写几句话就交上去了，领导也不严格要求，就直接在上面批示，这样做的后果是不严密，事后管理非常麻烦。到了新的大公司后，接触了大公司的管理才知道，原来项目应该这样管理的！
等你在小企业发展积累到了一定时候，如果可能，就又应该考虑可以转向大公司发展，这次不是学规矩和规范了，而是谋图在更大的舞台上见世面和发展。这时你已不是刚入职场时的青涩了，在做人和做事上也积累了不少东西，而实力与早先也大不可同日而语，如果确有实力，你将在大舞台上获得更大的空间。
忠告三：要积累人缘资本，但不要钻营
新人到了单位，要慢慢地跟本部门的同事以及其他部门的同事建立起良好的关系，这一点对新人能否在单位立足、顺利发展都是很重要的。有的新人来了以后，只跟卡座周围的人说话，或者只跟老乡、师兄师姐交往，都是不好的，还有的新人满世界乱窜干扰别人，也易引起别人反感。
更多的新人不知如何打开与老员工交往的第一步，其实作为新人，虚心、礼貌、微笑、少说多做总没有错。如果不是在人际关系特别险恶的地方（不排除有恶领导领导下的恶部门），一般来说，老员工虽然在新人刚进的时候，会有欺生的现象（人性弱点啊），时间长了大多还是乐意帮助新人的。当然新人自己不能做出讨人嫌的举动，比如：乱插嘴、乱奉承、占便宜等等。
一个比较明显的职场忌讳是：过于表现。记得有一个到单位来实习的MM很活泼，当时很想到单位来工作，对每个人尤其是领导很主动。有一天，有个员工要出国，在大家为此人饯行的饭局上也叫了MM同去，大家正说着惜别的话，MM一下站起来不顾当时气氛，梆梆梆地敬领导酒，又说了很多热情洋溢的话，与气氛特别不协调。后来部门开会时也喊此MM旁听，但MM又站起来主动发了二次言（按说她不是部门正式员工只听着便了），这样，在大家的感觉里就有些不太好，后来MM居然又跑到领导办公室教领导减肥，终于该MM没有如期望的那样留下来。
还有一个新人，很活络，刚进来就搞清了部门里的人事关系，很快找机会跟一把手沟通，我一开始觉得他挺机灵，因为是我分管他，就给他一些比较有挑战性的事情做做，也跟一把手推荐过他。后来发现该新人太活络了，不太懂事，眼睛只盯着一把手，除了一把手吩咐其他的事包括我考验他的都是能拖则拖。后来，该新人发现公司里还有更好的去处，直接越级跑到总裁助理那里要求调走，搞的公司上上下下都知道有这么个人，结果公司领导没有让他去那个要害部门，而他在本部门也过不下去了，只好走人。
忠告四：对不了解的事情，请务必三缄其口
相邻的部门发生了这样一件事，原先上级答应给该部门的奖金搁置了。于是各种猜测纷起，有一天我听见有个不新不老的新人（说他不新不老是因为该人年纪不小了，但是刚进单位）对大家说，公司领导得了红眼病，看他们工资高了所以不给他们发奖金了。后来该人又在多种场合散布这样的言语，说得一本正经的。让人觉得此人怎么这么幼稚，奖金发不下来，可能有多种原因，对于不了解公司上层运作的底层工作人员，在无法知道真实情况的情况下，最好不要胡猜乱说，以免给自己造成被动。后来情况下来了，是他们部门资金出了差错，奖金还是发下来了。任何行业或单位都有自己的游戏规则，有一些内幕是我们永远也无法知道的，我们能做的就是闭嘴和看。
还有一件事，我所在的部门曾经来了个新人，这个部门在单位里不是核心部门，经营状况也不好，当然奖金什么的都不理想，新人来后就打听收入等等情况，老员工自然有牢骚，说这里是最差的部门，这样新人心里就留下了阴影，并与与之同时期进来的其他部门的新人传播。
我的理解是，新人刚到一个地方，对周边的了解多是停在表面上的，老员工有牢骚可发，新人就不可以，因为老员工对部门有贡献，而且老员工在部门很多年，是家里人，说些过激的话没什么，一旦到了外面他们还是很团结一致对外的，新人刚来，什么都没做，就不应该说三到四。后来，该新人在偶部门待过了很长一段尴尬的日子才慢慢与大家相处好起来。
在某些年代悠久的老单位里，人和人之间的关系错综复杂，有的是多年的老同事同学，甚至亲家关系，他们之间既有利益冲突关系，又有长期的感情依恋，真真假假，新人初到最好不好贸然介入矛盾当中。有时你听见一个老员工在对另一个骂骂咧咧，其实他们私下可能是非常好的私交关系，新人贸然伸张正义，轻者可能被当做人来疯，重者就是张狂了。
有这么一个例子，某个部门一个MM失踪已久突然回来，部门要对其处分，部门开大要大家表态，结果MM哭得梨花带雨，说是因什么什么原因没有与单位联系的（其实是带着单位的产品到南方干私活去了）。部门里分成了两派意见：一派主张处罚，一派主张算了。当时，有位新人心地单纯，动了恻隐之心，竟然说MM也没给单位带来损失，那是她个人隐私不应该处罚。于是新人留给领导这样一个印象：一点是非观念都没有，老成世故。
忠告五：睁眼识人，寻找帮助
在职场中，有利益就会有冲突，但也是有非常值得交往之人，只是能否遇到遇到这样的人能否慧眼认出并有缘份得到他（她）的指点。职场中有的人在业务方面有独到的方法，有的在为人处事方面有特别的眼光，有人判断力很强，有人善于化解矛盾和冲突……，如果这样的人愿意在你困惑的时候帮助你，那对你来说实在是幸运的事。
我在一个职场转换的关键时刻（曾经非常困惑，患得患失，不知何去何从）有人对我说，任何选择都不会十全十美，如果你无法判断未来那就遵从你内心最原始的感觉——你喜欢就去做！还有，在我纠缠一段人事的苦闷期，有人告诉我说，无欲则刚，只管做事；在我埋首局部事务的时候，有人告诉偶说，到外面看看……
这些都给了我莫大帮助，在职场中，眼界的打开一方面要靠自己观察和领悟，另一方面也要靠高人指点。这个高人可能不是什么方面的专家，只是在某一特定时刻特定主题下对我们有所帮助。
职场高人的最高境界是所谓人品处事专业能力样样都超强的人，这样的人遇到又与你有缘，可遇不可求，不过人品好、在某方面确有过人之处的人，在你漫长的职业生涯中一定可以遇到，如果遇上了，一定不要忘记寻求他们的帮助。
谈到识人，想起一件事。单位来了个新人，分在A部门，部门某领导对其很是亲近，新人受宠若惊，某领导常对新人说，某某部门不好，某某人历史上如何，新人深信不疑，平时总跟在某领导后面，既然领导说某部门不好，那某部门一定有问题，领导说某人如何，那某人一定是的。以这种观点，新人决定自己对周围部门同事的态度，渐渐地新人感觉到几乎在所有其他的部门，无论他做什么都受到抵制，部门内外的年轻人都不和他一起。新人认为大家是嫉妒，只要领导对自己好就行，有一次部门工作出了差错，新人事先跟该领导提醒过，事后又跟该领导汇报了，由于领导未重视导致损失严重。公司追究责任，领导对新人说，你放心我会把责任担下来，你下次工作注意。新人虽委屈，但觉得不都是自己的错，想领导对自己好得给领导面子。然而无意亲耳听见该领导对公司领导说：XX（新人）虽是名牌大学出来的，能力很差，责任心也差，这次事情我本来千叮咛万嘱咐他还是不放在心上，搞出这么大的事，一点挽回的能力也没有……。新人几乎不能相信自己的耳朵，再后来新人在A部门待不下去换了部门，新人才知道，过去一年，自己的视野太窄了，公司里个部门及各人事都不是他最初所听到的那样。
忠告六：该说就说，该沟通的一定不要闷在心里
上面说了，对不了解背景的事不要乱发言；但有的话你必须要学会说出来，比如你的工作的进展、你的想法、你受到的委屈等等……
其一、一个人有没有能力，要做出来也要说出来（还要写出来），光做不沟通是不行的，边做边沟通可以让上级知道你的工作进展情况，也可以让其他人配合你（所谓团队合作），否则领导怎么知道你行不行呢？尤其是遇到故障，一定要及时汇报，不要等积累成了大问题你无法控制的时候才跟上级汇报，弄到不能收拾，不要因为怕别人笑话或领导看轻或以为自己能侥幸躲过，就隐情不报，要知道，没有新人是万能的，领导/同事都知道不会苛责你。
其二、工作过程中说和写是对自己工作的总结，通过这一过程，会理顺自己的思维，会有灵感闪现，锻炼自己的逻辑思辨能力。如果是做的比较重要的工作，一定要写下来，业务方面/协作方面/工作的方式方法方面等等，没有总结就没有提高，没有提高你在职场中永远只能是做个螺丝钉。
其三、如果你在工作中遇到了阻力或委屈（除非你已找到了解决问题的良策）也要说出来，你可以对事不对人，注意说话的方式，寻求帮助，不能让事情就停在那里。
这里有个例子，部门有A/B两个年轻人，A比B先进来是B的组长，一次我交给B一个项目，跟A也打过招呼，等了好久也没见B拿出来，每次问B都说快了，最后我忍无可忍交给了C，C是很快就完成了，后来知道B出了方案压在A手里了，B毫无办法，就只好等着。如果B当时告诉我实际情况，我就帮助他改变这种状况了，我屡次问到B的时候，B都不吭声，跟A好像还不错的样子，就唯独把工作耽误了，那我觉得B的能力还是有问题的。
其四、每次项目或工作会议都是新人展示的好机会，新人（尤其手头有活的）应充分准备，领导要看看谁在进步，谁是有心人，谁可以托付给下一个重要任务，因此新人千万不要等被点名了才乱说一气。部门曾经进了八个MM，那些会议上说得有条有理的都是事先充分准备的，这样的人往往较易受到注意。
关于招聘种种
前段时间帮助朋友搞了一次招聘，有些感想。
朋友所在金融机构在本地是个不错的单位，打算招两名毕业生，因为时间仓促，就找我帮忙，我先托了熟人，熟人介绍了一个说是专业课不错，我就把电话告诉学生要他直接去那单位面试。那天是周五，我朋友等了好久结果学生没来，后来来个电话说有事能否周六来，朋友说周六不上班，下周吧。面后，朋友觉得不太理想，我就找到母校老师，结果好几个学生有兴趣来。然后，朋友又是等了一天多。朋友说这些孩子来不来怎么也不打个电话呢，如果有课也应该打电话约一下呀！
几年前，部门要招本科生，我直接找了某学校某系的辅导员，辅导员给介绍了十来个学生，其中有的打招呼说某某不错，那招呼过的自然多留意一点。有一个据说是动手还可以的，满不在乎地说你们单位一年收入几何？有没有某某数字？低于某某数我是不去的，我们去后宿舍是几人一间啊？多于四人我是不去的。觉得该同学是被什么东西误导了，按说20的人了，人情世故多少也要懂点了。
忠告七：不要太斤斤计较
某部门有两个MM ，业务能力都很强，MM A性格泼辣，工作大胆，MM B细腻认真，部门准备在两个中提拔一个，领导比来比去，难以取舍。有一天，MM B写了一张假条，上面写着：请假一天，由于某某天，加班1小时，某某天替班0.5小时……，合计实际请假3.5小时。
领导慷慨给了一天假，但是提拔的结果也出来了：MMB 出局。
知道为什么吗？MM B太计较了，居然精确到分钟，使人感觉不能担负重任。
职场识人续
有人问，职场中如何与人友好相处不发生冲突？我以为重要的是在保持原则性的前提下增长识别不同类型人的知识，学习与各种各样人打交道的本领，冲突有时是不可避免的，有时冲突并非坏事，你得做好准备，把你的第一场冲突变成一件有益于自己成长的事。
话说林子大了，什么鸟都有。下面举几个例子来说说。
鸟A：喜欢打听别人私事，听到了后便四处张扬，喜欢攀比，嫉妒心强。这样的人，一般的来说在单位里没什么人缘和地位，业务能力不强，整天是今天谁买了件新衣服，明天谁跟老公吵嘴了，谁又出了风头……这是其身体里某种激素导致不能自控（有人说是一种精神病，呵呵），个别极端的还会做出翻看你的个人物品，偷看你的电脑资料的行为，喜欢口头上逞强。对于这类人，一般没有太大的破坏性，不须太介意，客客气气地就行了，但因其包打听和多嘴多舌的毛病，不要与之多言，要提防的她把你的资料传遍全公司。这样的人，有时你觉得可能并不太坏，就是有些讨厌。
但其中有一种人要特别引起警惕，就是那与高层有私人关系、嫉妒心特强的，虽然在单位没什么人缘，但偶尔有心无心对领导说的议论你的话，可能对你会造成巨大的杀伤力。
鸟B：喜欢吹牛，把小事吹成大事，把没有吹成有。
有这么一个例子：有一个新人来单位实习，很想留下来，但苦于没什么门路。这时老某出现了，老某吹嘘自己跟领导不同寻常的关系，于是新人就请老某吃饭，请老某帮忙，老某吃了新人几次饭说已经跟领导通过气了，领导正考虑中。新人很感激，于是又给老某送礼，老某故作深沉地说领导快开会讨论了……，其实天晓得，老某自己在单位就是一个无足轻重的人物，不要说给领导递话，就是平时跟领导见面的机会也很少，最后新人当然也没留下来。
识别这类人很简单，只要看看周围人对其的态度就可以了。如果有一天，你遇到这样的人，对你说：XXX啊，今天你得到表扬提升奖励是因为此前我对领导表扬了你，你先不要感激涕零，先看看此人有没有这个能力，真心帮你并有能力帮你的人，是不会一这种夸张方式说话的。
此类人中要特别提防的是那种谎话联篇，就是捅破了也不脸红的人，光吹吹牛，占你点便宜也就罢了，如果大事小事都说谎、黑白颠倒、无中生有，那就一定要远远离开这种人……这是人品恶劣的问题了。
鸟C：为人刻薄，对任何人任何事，不管是否于己有关都要评述几句，跟你不熟时白眼看你，跟你熟了以后，平时对你热情，一旦你有短处被他看见了必遭挖苦，如你有好事了必遭讽刺（也许不当你面说）。
这类人，往往是职场中长期的不得志者，长期抑郁弄成这个样子。这类人又分两种情况：一种没权没势的就是一张嘴、一张脸讨嫌，尤其喜欢欺生，但他的攻击没有什么目标性，今天对你明天对他。要注意的是其中生来心理阴暗或后天心理阴暗的那类，尤其是那种手有一些权力或资源的，那是职场中的真正害虫，因为心理上的问题，把什么都往负面去考虑，同时他对人对事的态度也是极其负面，前者仅仅是有时让你情绪不好，后者则可能不留神毁了你的职场生涯。要是不幸你与之为邻，那你就要注意了，这种人就是见不得别人好，哪怕损人不利己，也要给人制造困难甚至陷阱，如果此人平时还笑口常开的，那更要小心。
识别此类人，也有办法。
如果一个人对你表面还过得去，但他对周围多数人（可能是所有人）都言语刻薄，甚至一点小事都喜欢给人使绊子，什么事都喜欢从反面去猜度和理解，那你就要小心了，最起码此人心地不善，至于他属于该类人的第几级别，那要看他做事有没有底限，是属于什么事都干得出来的，还是有所不能的。
作为新人遇到职场大奸并与之纠缠上的机会还是不多的，通常我们碰上的是那些心理个性有缺陷的，我们要做的是：静静地观察，把他们识别出来，不要让他们纠缠上我们，也不要怕他们，暗暗想好应付这些人的办法，然后把他们甩到后面去。特别留意其中那些出格的个体，平时应对他们时，既不软弱也不张扬，保护好个人隐私，不要让他们伤害到我们。
当你的实力涨了，他们就越发难以伤害到你了。
鸟D：心胸狭窄、眼光短浅。
此类职场人与上述A、B、C有交集部分，在职场中此类人还挺多的。平常处着没事，一旦你有了什么好事，马上就让你不舒服，给你制造流言蜚语，甚至陷阱。这类人中危险的不是那些跟你表面上过不去的，而是那不动声色甚至笑容可掬的，怕就怕他实在过不了你这坎儿，非得出出气发泄一下，至于发泄后果的严重性，有人是没有考虑，有人是刻意为之。所以，要充分估计人性的弱点，得意不要忘形，失意也不要潦倒。
还是一句话：不要怕，做好准备，不断增长自己的综合实力（用一句老掉牙的话），你才能在职场角逐中胜出。
忠告八：扩大视野，扩大接触面
新人来到工作岗位，当务之急是尽快熟悉本部门本岗位业务，赶快上手（有条件多学多问多练，没条件也要创造条件尽快上手）。同时，也要熟悉本部门其他岗位，公司其他部门的流程和业务，这对你迅速成长是非常重要的。如是是技术岗位的，一定要熟悉业务岗位，销售岗位都在做些什么；如你是销售能手，千万不要以为后台的都在没事干。你需要在整个公司的层面上了解你的工作，你还要了解整个公司的流程和你所在岗位的定位关系，在这个过程中，你不断熟悉公司业务，渐渐积累人脉关系，了解其他业务岗位做事规则和方式，学习他人做事的长处，扩大你的眼界，而非局限于一个狭小的区域当中。
有这么一个例子，有个技术部门的A，不久前出了个大家都没想到的错误。原来一年了，该同志从来未出过本部门的门，除了交待给他的那点点事情，对公司的主营业务不甚了了，对相应业务细节也从不关心，于是笑话自是难免。在单位里，如果你自己不主动去学，谁会教你这些呢？
扩大视野的另外一个意思是，不要被小环境的家长里短局限住了。有时，你会碰到周围一些婆婆妈妈、鸡鸡狗狗的事，这些事总是无可避免，你可以听着，不可深介其中。要是攻击到你了，你也不要纠缠其中，把目光放得远一点，记住，保持自己独立思考的能力，千万不要沉溺于这样的小圈子。要是你的脑子里装满了鸡鸡狗狗，那你的心胸必不会开阔，你的眼光必定狭隘，你行必烦恼、做必蹩脚。
作为一个新人，结交人品优秀的人，也是扩大视野的一个方面。这些人犹如红木家具，散发着智慧、厚重的光彩，必定会让你收益菲浅。
如果你能够遇上一个亦师亦友的上级，那是你的幸运，但请记住，即使这样，你也不要以为你可以和上司称兄道弟。上司就是上司，你可以尊敬某位领导，但不要依附于某个领导，更不要与领导有感情上的牵扯，否则你就不能保持你的独立和客观。记住你不可能一直待在某领导的保护伞下，试想一旦该人离开，你如何生存？在你漫长的职业生涯中，可能会遇上那种红木家具似的优秀人物，也可能遇上什么都不能什么都不是的乱七八糟的人物，而更多的是那些有缺点，又有优点的前辈，你要做的，是表达出你的诚恳，善意和合作，大大方方，不要太敏感，不要执拗。
忠告九：为你的第一场冲突做好准备
一般地来说，在与同事相处中，如与人有了矛盾，我们应尽量采取和缓的方式解决问题（如请中间人调停等），避免与人发生正面激烈冲突，给对方和自己留有余地，得理也要饶人（如都是为了工作那又何必呢），避免造成矛盾激化，弄出个仇人。但是，如果对方实在是欺人太甚，让你饱受屈辱，身心都受到压抑，反反复复问题得不到解决，那么你就要准备迎接你的第一场职场冲突，冲突总会到来，一味的压抑自己不是良法，如果压抑到身心受到影响那更不值得，也许冲突一场，问题的症结反而解开，你的处境也出现改观。
有这么一个例子：有个新来的MM，经常受到某人的压制，由于某人是跟随领导多年的老人，在领导那里有一定的受信度。起先MM一直让着某人，后来某人有些忘形，时常扯谎来诋毁MM.
有一次开项目会议，领导叫某人通知MM，某人没有通知，于是MM迟到了。领导问原因，某人说通知了，领导于是批评MM，MM决定不再忍让。该MM思维敏捷问了几个问题，某人你是叫别人通知的吗，是打我的手机的还是固定电话的。某人说打你手机你占线。MM说既然占线那就是没有通知到我，那你为何不再打一遍？你是在家打的吗？某人说路上打的，MM说路上打的那是用手机打的了，那手机上去电显示这个时间应该有我的电话号码，请给某总看看吧。某人慌乱，说我记不请了，好像我叫XX通知的不知他通知了没有。MM接着说，不管是你亲自通知还是叫别人通知，那么如果电话打通，不管我接不接电话，我的手机上会有来电痕迹，如果没打通电话，那应该继续打电话直到通知上我为止，否则就不能称为通知到我了；无论哪种情况，你的手机和通知人手机或电话都会有去电痕迹，你能不能给某总看看？
MM语气不急不慢，眼神清澈，一时鸦雀无声。
出处：世界经理人社区 -
测试成长之路（转）
2008-12-15 10:41:15
对于刚进入软件测试工作岗位的新人，如何快速、健康的在职业道路上成长，我谈几点看法，欢迎大家讨论。
（1）兴趣是最好的老师
对于软件测试工作，通常是比较枯燥的，如果没有兴趣很难做到持久。
我最近参与了一个软件测试项目，在测试团队中，有三位是在校学生，他们以兼职的身份到公司上班，他们都是软件相关专业的本科生和研究生，基础都不错。但是，只有其中一位表现最突出，因为他很珍惜这份社会实践的工作机会，做事认真，找出了很多高优先级的Bug。
另两位同学，在参加项目不到1个月后就以各种理由退出了。在我与他们的交流中，其中一位说测试工作太枯燥了，没有挑战性，他更希望做软件开发的工作。这位同学由于不喜欢做软件测试，实际上他对软件测试技术缺乏基本的了解。所以他在7天的测试工作中，只找到了3个Bug（正常情况下，其他测试人员每天能找到5个缺陷）。因此，从绩效评比中他的成效最低。
另一位同学虽然愿意做软件测试，但是他觉得现在的黑盒测试太简单，学习不到测试技术的高级技巧，他更愿意学习白盒测试，能够自己测试软件源代码。而现在的项目没有这部分的内容，所以尽管他工作成绩也不错，但是积极性不高。
因此，建议同学们在寻找工作中，首先需要了解，你是否愿意做软件测试，愿意做白盒测试还是功能的黑盒测试，不要盲目的参与到工作中，否则对于用人单位，对于个人的成长都是浪费。
（2）测试人员要学会思考
测试是个技术工作，需要学会主动思考。如果你遇到一个好的测试主管（组长），他会主动的解决你的测试实际技术难点，这是你的幸运。但是测试问题错综复杂，测试主管工作很忙，他没有时间解决你遇到的任何技术问题，需要你自己分析问题的性质，尝试各种解决方法，搜索网络上的文章，最好如果仍然解决不了才向主管求助。
我们反对遇到问题表现得很茫然失措，不要问一些很“弱智”的问题，否则主管认为你解决问题的能力不做，学习能力欠缺，这样对于今后的发展不利。
测试人员如何思考？根据问题的现象思考。问题是属于测试专业知识不足引起的，还是测试用例等测试文档模糊、错误引起的，是个别现象还是测试项目的其他内容都存在的普遍现象。测试要从模拟用户使用的角度展看，因此要用最终用的角度，分析问题的严重程度。
在询问最终的解决方法前，确保你根据自己的经验尝试了各种解决方法，并且尽量把你发现的问题和猜测，告诉测试主管，证明你已经主动思考了，但是没有找到好的解决方法，或者不能确定是否方法可行。
（3）选择适合的测试学习材料
软件测试的技术博大精深，对于初学者该从何入手呢？可以从以下几个方面学习：
第一是公司提供的培训材料。测试新员工到公司后一般都要经过短暂的培训，这是学习的最好的第一手材料。针对性特别强，都是公司今后用到的测试知识的总结，针对性和实用性都很强。如果有不懂得问题，可以随时提出来，因为你是测试新人，不懂要问，任何人都不会对你的能力表示怀疑。
第二是借助测试项目的测试文档学习，包括测试计划、测试用例，测试缺陷数据库，可以先看看以前发现了哪些bug，这些bug是怎么发现的，有什么规律和特征，学习别人怎么写测试缺陷报告。
第三是阅读测试书籍和测试网站和论坛。这些内容很多，建议利用工作之后的时间，根据自己的知识有选择的选择测试书籍，先从基础知识阅读。正式出版的书的内容质量都比较高，而测试网站和论坛的文章良莠不齐，有些只是只言片语，很多还存在错误。因此，需要有一定的鉴别能力，否则会误导，浪费时间。
（4）巩固测试知识基础
练武术需要先练“蹲马步”，否则直接学习刀枪棍棒等十八般武器，只能学到几招皮毛，甚至伤及自己，武林高手都是基础很牢固的，内功很深厚的。
做软件测试也是这个道理。很多出入测试行业的新人，希望走捷径，往往听信各种测试培训机构的宣传，认为参加几天的能力提高班，就可以步入测试高手的殿堂，这是错误的，也是要吃大亏的。
另一个错误就是还没有学会测试的基本概念，就盲目地学习各种大型商业自动化测试软件，结果花了很多时间和金钱，只是学会了工具的具体操作。到了实际测试项目中，无法有效利用工具解决实际测试问题。
实际上，作为测试新手，大部分都是从手工功能测试开始起步的，大型自动化测试只有成为测试高手，才有机会使用。另外测试工具的操作是很简单的技术问题，关键是如何发挥测试工具的作用，这需要测试策略。
所以，初学者要老老实实的学习测试基础知识，学习各种测试术语、测试概念、测试分类、测试的流程、测试项目的执行过程等。如果这些都不懂，今后的职业发展会成为限制。
学习是痛苦的过程，但是学习是增强技能的必然之路。学习测试知识没有捷径，需要日积月累，需要勤奋，需要思考，需要总结，从一点一滴学起。
（5）不断学习行业知识
测试人员除了学习和掌握测试技术外，还需要不断学习行业知识，这是区别普通测试技术人员和测试行业专家的最好方法。
学习什么行业知识呢？根据你测试的软件的应用领域决定。例如，你正在测试的是电信行业的应用软件，那么你需要学习电信行业知识，包括术语、业务和行业技术。怎么学习呢？可以与客户交流，与开发人员交流，看专业书和文章。
学习行业知识是个不断进步的过程，每个行业都有很系统的知识架构，首先学习工作中最需要的理论和技术。然后有机会和兴趣的时候，不断细化和深入。
高级的测试人员需要精通测试技术，掌握行业知识，可以提供行业软件的测试和质量保证方案。对于初学者，要认识到经过不断努力，可以成为测试行业专家。千里之行，始于足下，目前最重要的是从测试入门知识开始。 -
建议测试新人可以看得测试书籍(转)
2008-12-14 22:39:50
建议测试新人可以看得测试书籍
新人要看的测试书籍！
虽然FP已经列了很多的测试书籍了，但是还是看到会有人问看什么书，我在这里把我自己看的书贴出来（包括已经买了，没有看完和没有来得及看的）。
测试书籍：
《软件测试（原书第2版）》
建议先看这本，这本书是软件测试界的经典书籍，里面的很多理论都写的不错，而且翻译的不错。
【原书名】 Software Testing (2nd Edition) [原书信息]
【原出版社】 Sams
【作者】 （美）Ron Patton[同作者作品] [作译者介绍]
【译者】 张小松[同译者作品] 王钰 曹跃 等
【丛书名】 计算机科学丛书
【出版社】 机械工业出版社
http://www.china-pub.com/computers/common/info.asp?id=29706
《软件测试的艺术（原书第2版）》
这本书技术性强，建议大家现看《软件测试》再来看这本书
【原书名】 The Art of Software Testing, Second Edition [原书信息]
【原出版社】 John Wiley & Sons
【作者】 （美）Glenford J.Myers 等[同作者作品] [作译者介绍]
【译者】 王峰[同译者作品] 陈杰
【丛书名】 软件工程技术丛书
出版社】 机械工业出版社
http://www.china-pub.com/computers/common/info.asp?id=27827
《面向对象的软件测试》
这本书挺难得，如果没有面向对象编程基础就不要看了，看不懂的
【原书名】 A Practical Guide to Testing Object Oriented Software [原书信息]
【原出版社】 Addison Wesley
【作者】 John D.McGregor David A.sykes 著[同作者作品]
【译者】 杨文宏[同译者作品] 李新辉 杨洁 译等
【丛书名】 软件工程技术丛书
【出版社】 机械工业出版社
http://www.china-pub.com/computers/common/info.asp?id=7078
《软件测试自动化》
【原书名】 Just Enough Software Test Automation [原书信息]
【原出版社】 Prentice Hall PTR
【作者】 （美）Daniel J.Mosley,Bruce A.Posey[同作者作品]
【译者】 邓波[同译者作品] 黄丽娟 曹青春
【丛书名】 软件工程技术丛书/测试系列
【出版社】 机械工业出版社
http://www.china-pub.com/computers/common/info.asp?id=14358
《软件评测师教程》这本书涉及面很广，不过过于理论了，有些地方写的不好不是很看地懂（可能个人水品有限吧，这个考试最近开始火了，不错好像很难考）！
【作者】 全国计算机技术与软件专业技术资格（水平）考试办公室组 柳纯录 黄子河 等[同作者作品]
【丛书名】 全国计算机技术与软件专业技术资格（水平）考试指定用书
【出版社】 清华大学出版社
http://www.china-pub.com/computers/common/info.asp?id=23803
以下的书是有关思想方面的书籍，或者说思考书籍，都是由Gerald M.Weinberg（温伯格）写的，这个人的书籍强调思考，强调本质，大家有了时间可以看看。
《质量·软件·管理：系统思维（第1卷）》
系统的讲述了什么是质量，质量的本质，不过本书本人还没有看完
作者：（美）温伯格 著，邓俊辉 译
出版社：清华大学出版社
系列：软件与系统思想家温伯格精粹译丛
http://www.dangdang.com/product/8867/8867166.shtml
《你的灯亮着吗》
这本书讲了如何思考，不错的
【原书名】 Are Your Lights On? How to Figure Out What the Problem Really Is [原书信息]
【原出版社】 Dorset House
【作者】 （美）Donald C.Gause;Gerald M.Weinberg
【译者】 章柏幸[同译者作品] 刘敏
【丛书名】 软件与系统思想家温伯格精粹译丛
【出版社】 清华大学出版社
http://www.china-pub.com/computers/common/info.asp?id=9919
以下的书籍都没有看过，不过都买好了：
质量·软件·管理（第Ⅱ卷）：一阶测量
【原书名】 Quality Software Management: First-Order Measurement [原书信息]
【原出版社】 Dorset House Publishing Co.,Inc.
【作者】 （美）Gerald M. Weinberg[同作者作品]
【译者】 李先华[同译者作品] 邢彦 张红艺
【丛书名】 软件与系统思想家温伯格精粹译丛
【出版社】 清华大学出版社
http://www.china-pub.com/computers/common/info.asp?id=27538
《质量·软件·管理--协调行动（第Ⅲ卷）》
【原书名】 Quality Software Management: First-Order Measurement [原书信息]
【原出版社】 Dorset House Publishing Co.,Inc.
【作者】 （美）Gerald M. Weinberg[同作者作品]
【译者】 李先华[同译者作品] 邢彦 张红艺
【丛书名】 软件与系统思想家温伯格精粹译丛
【出版社】 清华大学出版社
http://www.china-pub.com/computers/common/info.asp?id=26184
《软件自动化测试：引入、管理与实施》
【原书名】 Automated Software Testing Introduction，Management，and Performance
【原出版社】 Pearson Education
【作者】 （美）Elfriede Dustin Jeff Rashka John Paul[同作者作品]
【译者】 于秀山[同译者作品] 胡兢玉 等
【丛书名】 国外IT精品丛书
【出版社】 电子工业出版社
http://www.china-pub.com/computers/common/info.asp?id=8531
《软件子系统测试》
【原书名】 The Craft of Software Testing:Subsystem Testing,Including Object-Based and Object-Oriented Testing [原书信息]
【原出版社】 Prentice Hall PTR
【作者】 （美）Brian Marick[同作者作品]
【译者】 韩柯[同译者作品]
【丛书名】 软件工程技术丛书/测试系列
【出版社】 机械工业出版社
http://www.china-pub.com/computers/common/info.asp?id=14355
《软件测试：经验与教训》
【原书名】 Lessons Learned in Software Testing [原书信息]
【原出版社】 John Wiley & sons,Inc.
【作者】 （美）Cem Kaner,James Bach,Bret Pettichord[同作者作品] [作译者介绍]
【译者】 韩柯[同译者作品]
【丛书名】 软件工程技术丛书/测试系列
【出版社】 机械工业出版社
http://www.china-pub.com/computers/common/info.asp?id=14718 -
软件测试人员职业发展助手－来自51testing人才招聘网
2008-12-13 21:26:29
51Testing结合多年软件测试领域的个人与企业培训经验，将软件测试人员职业技能划分为若干等级，等级描述现总结如下，所有描述均出自软件测试角度，仅供参考：
外语水平
了解——掌握该语言语法，可以进行简单工作文档的阅读、书写，能进行基本口语交流
一般——熟悉该语言下的计算机工作环境，能够熟练阅读并编写该语种工作文档，能进行日常口语交流
熟练——母语或类似母语程度，熟练使用该语种计算机环境，并完全具备行业内听、说、读、写等表达能力
精通——在该语种工作环境下具有丰富的经验，能在正式商务文件起草与商务谈判中熟练驾驭该语种的表达
功能自动化测试工具使用经验
了解——仅具有个人学习经验，掌握工具的基本功能和操作方法
一般——了解自动化测试过程管理，并能对工具进行数据驱动式自动化脚本开发
熟练——熟悉自动化测试过程的实施与管理，能够结合工具自身特性，将自动化测试应用于企业级自动化测试过程里
精通——具有企业级自动化测试过程的实施与管理经验，能够结合工具特性和企业现状，为企业定制企业级或项目级测试框架，或自主开发测试工具等
性能测试/监控工具使用经验
了解——具有个人学习经验，掌握工具基本功能，能够进行初级的脚本录制、开发与设置
一般——了解某些网络应用程序性能计数器，能够独立设计性能测试方案（场景），并结合工具完成简单网络程序的性能测试工作
熟练——具有企业性能测试工作经验，熟悉特定网络应用程序每个逻辑层的系统性能指标，能够利用工具对特定架构（平台）的网络应用程序进行性能测试和性能分析
精通——在特定领域，能够独立承担大型或复杂结构网络应用程序性能测试的总体设计，对于该领域软件架构具有敏锐的性能瓶颈分析与定位能力，并对系统进行性能优化
白盒测试/代码分析工具使用经验
了解——仅具有个人学习经验，掌握工具的基本功能和操作方法
一般——深入掌握该工具的使用，能将工具应用于实际的软件开发或单元测试工作中
熟练——具有基于工具的二次开发能力，或具有单元测试过程实施与管理的经验，可以根据工具的特性，将其灵活应用于企业级软件开发的某些过程里
测试管理工具使用经验
了解——仅具有个人学习经验，了解工具的基本功能及使用
熟练——掌握工具的安装、配置与维护，具有企业应用经验，掌握工具使用中的操作细节
精通——掌握工具的技术实现细节，具有根据企业现状进行自定义或二次开发的能力
软件缺陷管理工具使用经验
了解——仅具有个人学习经验，了解工具的基本功能及使用
熟练——掌握工具的安装、配置与维护，具有企业应用经验，掌握工具使用中的操作细节
精通——掌握工具的技术实现细节，具有根据企业现状进行自定义或二次开发的能力
软件开发经验
了解——具有个人学习经验或实习经验
熟悉——具有特定语言的企业级软件开发经验
熟练——具有企业级软件架构设计或系统底层设计经验
数据库应用经验
了解——掌握数据库原理，会使用sql语句
熟悉——具有企业级数据库安装、配置、管理、维护经验
熟练——具有企业级基于数据库的特定开发经验
精通——深入掌握特定数据库的性能参数，具有数据库的性能优化能力
软件配置管理/版本控制工具使用经验
了解——仅具有个人学习经验，了解工具的基本功能及使用
熟练——掌握工具的安装、配置与维护，具有企业应用经验，掌握工具使用中的操作细节
精通——掌握工具的技术实现细节，具有根据企业现状进行自定义或二次开发的能力
说明：本资料仅供测试从业者在职业技能提升过程中作为参考，各种技能的列表，请见http://bbs.51testing.com/viewthr ... &extra=page%3D1 希望给大家带来实惠，给您一点点指导，仅此而已！
-
工作整一年了，特写下此文记录自己的成长过程和感悟（转）
2008-12-13 21:25:21
工作整一年了，特写下此文记录自己的成长过程和感悟。
1，测试路。
这一年一直在一家公司里做测试，虽说在公司里接触的不多，而在网络上接触了很多的东西。常逛论坛也认识了一些测试同行。
坛子上的迷茫的人依旧不少，回头看这一年的时间，想来想去，嗯，还在坚持。在一个正当的行业上，只要坚持，我觉得就不会有迷茫的想法了。纵然不知道你会努力成功到什么样子，可是也不会觉得没有重心。有人在谈论测试前途的问题时，总是一头雾水，其实对每个行业的人来说，可能有大多数的人处于这个状态。而能改变这个状态的，只有自己心态的改变。我记得有一个朋友给我发过一个短信：人们总结成功应具备三种素质：1，有肚量去容忍那些不能改变的事；2，有勇气去改变那些可以改变的事；3，有智慧去区分上述两类事。我觉得说的挺有道理，其实人遇到迷茫的事情，应该做的事，就是思考和判断。
谨希望各位同仁做到思考和判断。
2，工作相关。
不管个性是什么样的，在工作中一定要跟同事融洽相处。这一点真的很重要。特别是和开发的关系。我在公司里和开发的关系是最好的，因为我很尊重开发。大家一块工作，合作好一些，工作进度也会快一点。针对测试和开发对立的状况，我觉得尤为不妥。做测试是在针对开发的程序来做的测试。而一定要搞清楚的是，不是对人测试的。即对事不对人。但是呢，人都是有性情的，所以要明白开发的一些性情。千万不要对着干。这样一来可能导致的是测试的工作越来越难做。和开发要有互助的感觉。
对文档，我的想法在这一年里有所改变的。文档还是写的详细一些为好。刚开始进公司的时候。文档是很散乱的，看别人的文档总是晕乎乎。搞不明白。可是也没人问去，只有慢慢琢磨。后来我把文档整理了一下，在我的眼里看来：我的文档很容易理解了。但是，后来新来了两个新人，看我的文档也是一头雾水。所以写文档要尽力的写详细些。当然事无巨细也是做不到的，看具体的情况了。
沟通。这一点很重要。
做测试一定要学会沟通，做事要细致。
3，感恩。
我不知道其他人在公司里是什么样的感觉。不知道是不是满腹的抱怨。
我对第一家公司没有任何的抱怨的，我很感激第一家公司给我的机会。让我在测试这个行业深入了一些。有机会做自己喜欢做的事还是很开心的。
我想有些人对感恩嗤之以鼻。建议这样的人，好好的想一想。机会是很多人都可以提供的。这不错，可是也不是谁都愿意给你提供的。并且在生活中遇到的人，都应该好好的取之长。善于学习才能进步的更快。
不要只会抱怨，要学着感恩，学习中成长。
4，努力提高自己。
自学是持续的过程。千万不要放弃的就是自学。建议业余时间少打会游戏。多看点资料。以前我写过一些关于学习的话。现在对自学这一点感触更深。如果只等着别人拿食物来喂，那种状态是很慢的、可怜的状态。有些人工作三五年还是一个样子。这就绝对怪不得环境了，只能怪自己。别人花了一个月的时间的努力，比你一年的努力都多，那就显然相别人形见自己绌了。并且学习的心态要主动。被动的和主动的心态，即便在看同一份文档，收获也肯定是不同的。我不知道其他人有没有这种感觉。我自己是有的。
学习要靠自己。
谨以这几点总结自己一年的历程。 -
对测试职业的看法(转)
2008-12-13 21:17:28
工作有一段时间了，再谈谈对测试职业的看法
写的不对，你也看看，别影响食欲就行；你要是觉得还过得去，就顶顶哈
先说迷茫：这就是一个词，描述了现在很多做测试的人的心态，关于这个不想多说，和人的思想有关，我
有个朋友，做事情很简单，就是如果他认定了这件事，错的也做下去，你可以说是偏执，其实不见得是，
如果在没做之前就仔细的想清楚了，也就不能说是偏执了，何况对职业来说没有什么选择错的，只要你坚
定的做下去，古人有云：行行出状元。只怕你不想做状元，只想学会写两个字。拥有这种想法，偶的认为
是，要么你找个认为有希望的职业，要么你就迷茫的过吧，反正不是我的生活。
再说工资，这个问题不能不说，工作嘛，当然考虑到工资，不然吃什么，刚毕业的，拿个2K左右，已经算
是可以了，可是也有些人拿1K多，心里总是不爽的，觉得自己低了别人一头，技术上也觉得自己低了一半
，这种想法是没有必要的，技术和工资不成比例也有可能，再说刚毕业，学知识是第一的，不然以后你一
定是会低一头的，看到有帖子上说工资的，有的人拿的少了，就又晕又汗的，要是你敢拿出技术来要钱，
相信你也不会有什么可不服气的。面试，人家一定会问一些技术问题，你会的比人家要的还高，一个月多
给你1K、2K的其实对公司来说不算什么，只要你能做事。当然有的人认为和机会有关，机会是什么，人创
造的，人家敢做，敢拼，就机会多了。天天缩在被子里喊工资少，没人会理你。
有一天和一个网友聊天，说，他什么都挺好，就是工资少，我说为什么呀；他说，我的技术关都过了，可
是人家都说我要的工资太高，又没有什么经验。我说你有经验吗？要不我考考你。问了几个问题（针对他
说的自己较强的一方面），大部分没回答上来，我说要是我是公司的人员也不给你那么多工资。
我想说的是，既然做技术，那就拿出技术来问人要工资（这里不排除走后门和掉馅饼的可能性）。我现在
拿的工资我就很满意，我知道自己的份量。
接着说做事，既然是工作就要做事，别的不说，首先要认真，可以不懂，但不能不承认不懂，谁都不是万
能的，能全会？不懂就问，上面安排下来一些事，给你一周时间，你可以说，我可能需要多一点时间，因
为有些我还不太懂，但别一口答应，信心十足，最后两周没做完，还弄了个烂摊子，没人收得了。和一个
朋友聊天：说有一个人，在单位里做事，上面给了一个FTP方面的事情（具体就不用描述了），给了时间
限，最后到时间了，去拿结果。那人说，不会弄。不会弄你早干吗呢，怎么不问？没办法就又给了时间，
最后还是不会。这就是技术问题了。
还有做错事要敢承认，是我的工作有问题，我就承认，错就错了，都是人，没有不犯错的人，上面会体谅
的，不敢承认自己的错误，那是素质问题。做事不能没有这点素质。
条理，这里说的是做事，不能乱七八糟的一团，搞到最后自己都不知道哪有问题。本来我们就是做测试的
，结果软件的问题没找到，自己的问题一大堆，那怎么办？还要专门整个部门来解决测试工作人员的问题
？那炒了可能更简单一点。
这里我想说的是，工作要认真负责。别以为是老生常谈，看看自己做好了没有再来体会‘认真负责’几个
字。
接着说下学习，论坛上看到一些帖子，问了些问题，描述得不清楚，问得又是搜索一下或者看看手册就能
明白的问题，后面可能没人愿意回，最后一直喊，怎么没高手？怎么没高手？自己不主动就别叫天喊地的
，没用。还有的帖子后面说，谁知道这个问题，我的MSN是＊＊＊@hotmai.com，QQ：＊＊＊＊＊＊＊＊，
。不知道这样的人等什么，等上门服务的？手册留着当传家宝吗？
这里说的是学习要主动，不然没人愿意一步步告诉你，又没收你钱。
当然谁都有不会的问题不是吗？把问题的出现，描述清楚，手册找找，论坛翻翻，实在找不着，也描述多
一些，打几个字累不死人。别让后面跟了十个帖，全是在猜你要干什么的。
测试职业，做的就是它，当然要说它，有很多人对测试还是没信心，前面我说了，测试没有什么迷茫的，
只是一个职业，现在测试发展的已经不错了，51论坛的浏览量可以做个证明（这里不是广告哈，因为你都
到这里看帖了），和一些做过一两年测试的人聊天，说前几年的时候测试资料网上都找不见，看现在，一
搜一堆，这就是见证。所以这个职业的前景是很好的。软件的错是不会完全消失的。所以测试就得继续下
去。做好它，这就是选择了这个职业的人最应该坚定的事情。所以不会存在二义性。
最后祝愿，所有做测试的人，技术越来越好，都能昂着头跟招聘的公司谈工资。 -
一个优秀的软件测试人员所要具备的素质（转）
2008-12-13 16:38:25
作为测试工程师，在日常工作中接触最多的当然是团队中的开发工程师，如何和开发工程师进行有效的交流是测试工程师面对的 重要问题。一般来说，在一个团队中，总是有开发人员喜欢和不喜欢的测试工程师，这两者之间的工作效率和效果都有很大的差异。当然，不能武断地说测试人员不 喜欢的测试工程师就一定是效率低下的测试工程师，或者说是不合格的测试工程师，但一般来说，那些容易得到开发人员认可的工程师在测试时总能够更好地发现缺陷和敦促开发人员解决缺陷。
测试工程师和开发工程师承担的是开发工作的两个不同方面，说得极端一点，一个是创建，一个是破坏，虽然两者的 最终目的都是一样的，但在达成目标的方式上却有很大的差异。因此，在为同一个目标奋斗的过程中，发生冲突也是难免的，但通过下面的一些建议，换个视角看看开发人员的生活和工作，可能很多的冲突就能化解于无形了。
Cem Kaner在《Testing Computer Software》书中有一段话: “The best tester is not the one who finds the most bugs or who embarrasses the most developers. The best tester is the one who gets the most bugs fixed.” （最好的测试人员不是发现最多BUG或是使得最多开发人员不自在的人，而是能够[说服开发人员]修正最多BUG的人），建议大家好好理解这句话。
至于我个人，是从开发工程师转为测试工程师的，对于开发工程师的处境和想法也曾有过切身的体会，或许是这个原因，让我在和开发工程师交流的过程中还算是比较 顺利，和他们相处得也还不错。在我的测试经历中，也接触过相当多的开发工程师，这里我把和开发人员交流的经验归结为“五要四不要”：
1、要耐心和细心
细心是测试工程师的一个基本素质，测试工程师是对质量负责的人，涉及到质量问题，就不能含糊，因此一定要细心，细心对待每一个可能的BUG、细心对待每一段 被你检查的代码，细心对待每一个你撰写的BUG报告，细心对待你发出的每一封邮件。细心是一种态度，你的态度迟早会感染和你合作的开发人员，而这往往是合作愉快的基础。
至于说到耐心，在我的工作经历中，不厌其烦地向开发人员解释一个BUG，让他认识到BUG的重要性是经常的事情，其实想想也很正常，对任何人来说，被人指出自己的缺点和不足都不是让人舒服的事情，因此，一点不耐烦的情绪就可能引起对方很大的反感，给自己的工作带来不必要的麻烦。
2、要懂得尊重对方
开发是一件需要全面和综合考虑的工作，开发工作中，由于各种原因导致程序中出现问题是很正常的现象，作为测试工程师，发现了这些问题并不值得你夸耀，也不能 说明你比开发工程师聪明。一个好的测试工程师一定是懂得尊重开发工程师的人，尊重对方的技术水平，尊重对方的代码。我接触过的开发人员都是挺和善的，一般来说，对他们最大的尊重就是承认他的专业水平，承认他的代码。对他们来说，代码就像是自己的孩子一样：）因此，记得在合适的时候表达你对他的尊重，赞扬一下他代码的精妙之处。
3、要能设身处地为对方着想
开发工程师一般都处在较大的工作压力下，他的上司直接考核他们的指标很大程度上是已完成的代码，所以在工作任务紧张的时候，对于测试工程师报上来的BUG会 拖延解决甚至是推脱，给测试工程师的感觉就是很不合作。那么在这个时候，就需要设身处地的为对方着想了，每个人都会为自己的工作在内心排定优先级，如果他 认为解决你发现的BUG不是重要的事情，那么最大的可能就是你并没有向他解释清楚这个BUG的严重程度。
发现BUG是我们的责任，敦促BUG得到解决是我们更重要的责任，因此，我们可以心平气和地和开发人员坐下来讨论一下BUG的严重程度，和他一起排定BUG的优先级别并确定解决的时间。
4、要有原则
不要忘记，测试工程师需要对产品的质量负责，在这一点上一定要有原则。测试工程师可以和开发工程师建立良好的个人关系，但在具体的事情上，一定要按照公司的 相关流程来处理。当然，在坚持原则的同时，可以采用一些委婉的表达方式，可以在允许的情况下尽量体谅开发工程师，但请记住，一个有原则的测试工程师才能真 正帮助开发工程师，才能赢得开发工程师的尊重。
5、要主动承担
如果开发工程师要求你承担部分不属于你的责任，比如，定位你发现的BUG到代码一级，或者是帮助他编写部分文档和代码（不要不相信，真的有这样的事情），那 么你会怎么做呢？在我的测试经历中，这些事情都遇到过，我的原则是在可能的情况下尽量多承担。其实都是工作上的事情，有能力的话，多做一点也无妨。当然， 肯定有人不同意我的意见，在这里我也不想争辩，个人意见而已，仅供参考：）
在我的测试经历中，我会根据自己的进度和时间安排尽可能地提供更多的关于BUG的参考意见，甚至是定位到代码一级，这种方式不是正规的方式，但对于提高自己被信任的程度是非常有益的。但在主动承担时，一定要明确是在自己确有余力的情况下才能去承担，否则，婉拒是最好的对策。
【四不要】
1、不要嘲笑
不要嘲笑你所发现的BUG，即使是非常愚蠢的错误也绝对不要嘲笑，说不定那个错误是因为开发工程师联系加班24小时犯下的，对别人的工作始终应该尊重。如果 你觉得有必要提醒他不再犯一些经常犯的错误，可以采用这样的方式：编写一份测试过程中发现的开发人员常犯错误的文档（记住，千万不要写上谁犯了这些错 误），用轻松的口气调侃一下，发送给开发人员。这种方法我采用过，开发人员都能很快接受。
2、不要在背后评论开发工程师
永远不要在背后评论开发工程师的技术能力，这个绝对是非常忌讳的事情，一时的口舌之快或许会使你永远不再能同他良好地合作，要知道，开发工程师最在意地就是别人对他的技术能力的评价。其实这个不仅仅是作为测试工程师的准则，也应该是做人的准则。
3、不要动辄用上层来压制对方
在出现和对方的意见分歧的时候，应该采用什么方式说服对方呢？直接向上层求助当然是一个办法，但这种办法带来的负面左右也是很明显的，首先是作为上层的处理 结果可能不一定符合你的愿望（在很多公司，开发工程师的地位高于测试工程师的地位，这种地位的不平等导致上层在处理分歧时会有一定的偏向性）；其次是动辄 拿出上层来压制对方只能给他人留下无用的印象。所以在出现分歧时，尽量尝试通过沟通解决吧，实在不行，再动用最后的手段。
4、和开发人员的沟通不要只有BUG
除了在BUG记录单上，在其他的地方也让和你合作的开发工程师接触到你吧：），午餐或是集体活动的时候多和对方聊聊天，一方面可以增进彼此的感情，混个脸 熟，打交道的时候也方便；另一方面，从他那里了解业务的知识和他负责模块的方方面面，对自己也是提升。我个人就很喜欢和开发工程师沟通，开发工程师其实一 般都是比较健谈的，尤其是对自己程序的精妙之处，多了解一些，多接触一些，对自己总是有益的。
写了这么多，其实关键的就是两点：多从别人的角度去想想，所谓“换位思考”，多尊重对方就一定能得到对方的尊重与配合；其次是加强和开发工程师的沟通，让他清楚地认识到你的工作对他的价值，你发现的每一个BUG的重要性。
我一直认为，一个好的测试工程师一定是在公司里被所有人尊重的快乐分子，而不应该是一个“铁面判官”：）当然，作为我个人来说，绝对不敢说自己做的已经很好了，不过，我经常都记得提醒自己：尊重对方。 -
关于测试工程师的角色定位 （转）
2008-12-13 16:34:54
关于测试工程师的角色定位 http://blog.csdn.net/jackei/archive/2004/12/29/232946.aspx
如果把一个项目组比喻为一家餐馆，那么管账的是老板，也就是项目经理，他决定做什么，有多少人多少资源来做多大，有多大的风险，当然他这个决定不是他一个人拿主意，因为需要所有人对计划的认可，但是最后他对项目成败负的责任是很大的。其次系统架构设计就是主厨，他设计具体做法，程序员就是其他的厨师，配置管理员, 系统集成人员, 数据库管理员等角色是厨房里面的服务人员。而SQA 和测试工程师更像是第三方的检查人员，只不过检查的具体内容不一样。SQA检查的是制作流程是否正确，材料是否使用正确，卫生是否做好了，他检查所有人的工作，包括项目经理，看看老板有没有做账。他虽然没有决定权，但是他有建议权，他向项目经理的上级负责。测试工程师出场了，他们更像是试菜的，看看炒出来的京酱肉丝有没有放酱油，有没有按照客人的意思多放点葱丝。如果菜不对，他们只需要告诉老板（或者是二老板，比如开发小组的团队代表）就可以了，老板决定重新炒还是端出去。需求人员和销售人员才是直接面向客户的服务人员。他们不断的将客户的需求告诉其他所有人。
所有的人都要对这盘菜负责。 -
我在软件公司成长的三年【转贴】
2008-12-13 16:32:48
我在软件公司成长的三年
谨以此文与所有在琐碎、繁杂、平凡中日复一日地做着重复工作的人们共勉。
writen by Swallow Xia，转载请注明出处。
1前言
写完2004年的工作总结以后，再翻了翻2002年和2003年的工作总结，真是“一年更比一年长”。看着总结，回顾着这将近三年来在SK工作的点点滴滴，感悟：原来，这就是成长的历程。于是，决定将三年的总结一起整理出来，对我在SK工作的三年作一个回顾，和大家一起分享，感谢一路上伴我走来的所有同事的关心、支持和帮助。
2 2002年个人工作总结
回顾2002年，难免感慨。
在管理部从事前台文员半年多以来，工作主要可以归纳总结如下：
2.1 例行工作
认真做好来电的接听、访客的接待工作，做好订饭、订水工作；
做好文具的购买计划和消耗总结工作；
做好每月的考勤工作；
做好长途电话的管理工作；
将公司内的图书、杂志编号、分类整理，形成电子文档，使图书、杂志的管理规范化；
协助做好招聘工作；
做好办公室内务管理工作。这其间，因为排气扇导致电源跳闸多次与装修公司、物业管理处协调；注意植物的保养、更换及办公室内的清洁、保洁；注意复印机、打印机、热熔装订机等办公设备的保养。
2.2 临时安排的工作
组织每个月的团队活动。先后组织到暨南大学打球、天河公司游泳、天河公司烧烤、员村文化宫打球、从化温泉度假，都取得了较好的效果，加强了同事之间的交流，活跃了公司气氛。另外，9月底曾策划员工欢送大会，欢送吴涛等离职员工。
办好公司的内刊。从七月到十二月，一共办了五期内刊。经调查，普遍认为水平尚可。但因为大多数人工作较忙或其他原因无法投稿，造成每一期内刊的都存在稿源不足的问题。未能想方设法调动员工的写稿积极性，除了自身原因之外，也与管理层等其他因素有关。
公司网站的建设。由于没有制作网页的经验，所以存在很多技术问题不知如何实现。在不断学习的过程中，修改了主页，实现了公司产品等部分链接。因为公司形象需要重新策划，此项工作暂时告一段落。
2.3 协助其他部门工作
销售部成立后，曾参与销售部的销售例会，整理会议记录及销售部一些常用资料、表格；
协助开发部制作国资、灯饰ERP等项目的部分图片；
协助市场部进行国资宣传资料的排版、整理；
另外还参与了公有物业产品化的测试及《授权管理》等几次幻灯片的制作。
总的来看，2002年的工作是尽职的，但也有不少的遗憾。考勤的管理一开始并不规范；长途电话也因为疏于管理存在一些不良现象；没有投入全心的精力去办内刊；网站的建设太过于缓慢而且效果不够好；工作的确不够饱和，时有不知该干什么的感觉；个人能力的提升不够……在管理部的遗憾，可惜因为岗位的调换已无机会弥补。
调到开发部，这是上级对我工作的肯定，对我个人而言是新的开始，也是新的挑战。除了要努力扮演好开发部“文档管理员”这一角色以外，希望我能在开发部掌握更多的技术知识，不断提升自我。
2003年，我希望做得更好！2003年个人工作总结
犹记得我的2002年工作总结是以“2003年，我希望做得更好！”为结尾的，时间如此匆匆，2003年的个人工作总结转眼间提到了案前。
2003年，怀着这种希望做得更好的心态，我不断学习、不断追求、不断进取。
3.1 前台文员→文档管理员→配置管理员
年初，刚开始得知要调来开发部的时候，我是喜忧兼半。喜的是我去年的工作得到了公司的肯定，给了我一个更好地发挥自己和学习的机会；喜悦过后，更多的却是迷茫，不知道将会面临什么，能不能胜任新的岗位是个未知数。那个时候，开发部的软件过程也刚刚开始建立，还没有配置管理员这一说法，只说是把我调职过去做文档管理员，负责管理开发部的技术文档，协助部门一些内务。
最初的学习过程是比较苦涩的，不懂软件工程；不懂VSS；不懂ROSE；不懂UML建模；更是从来没有听过配置管理……对于工作有关的一切都是问号，开会的时候更是经常当愣头鸟。工作中，学习成了首要的主题，不学习，就不可能做好工作。将近三个月的时间里，从VSS到配置管理；从ROSE建模到UML语言；从面向对象的了解到对软件过程认识……在不断地学习过程中，对工作，有了一个基本的概念。5月的时候，我的工作表现得到了领导的肯定，受到了表彰。
虽然如此，但我并不满足于只是做文档管理员，只做简单的文档管理工作，我希望学习更多的配置管理和软件工程方面的知识，将项目中简单的版本管理融入配置管理的思想。最早的时候，公司的开发文档资料处于一片混乱之中，每个开发人员的电脑里都存有一份自己开发的工作版本，找不到哪一份是最新的。收集整理了国资一期、二期、产品化项目、南海国资升级项目、公有物业等一堆残留资料以后，也对东进ERP、财务异常警示系统项目中进行了初步的版本控制。再接着，到了企业转制与处置项目、三水项目的时候，开始制订了配置管理计划，项目的配置管理能够按照计划较为有序地进行，开发资料也能够定期进行备份，确保公司宝贵资源不会丢失。
SAM一期项目是公司最大的一个项目，也是涉及人数最多的一个项目。能否按照以前的方法进行配置管理，是否能够考虑用其他更好的配置管理工具？这个项目该怎么管理，我思索良久。经过对另一个免费的版本管理工具CVS的一番摸索之后，对两个工具的优缺点进行了比较，最终还是选择了VSS作为项目的配置管理工具，但在目录结构、权限分配和流程方面作了不少的调整。就这样，在工作中不断学习，不断地改进，使我，使开发部的大家都对配置管理工作有了较为完整的认识。
现在，无论是三水项目、SAM一期项目，还是接下来要做的天津项目、新疆项目、肇庆项目……无论是谁，都会深深地意识到配置管理在项目中的重要性，主动地希望用工具来进行版本管理。而公司各个系统的资料也在我的“仓库”里完好地存放着，作好了备份。回想起一年前在还没有配置管理员这一角色前开发资料混乱的管理，仿佛已是半个世纪前的事情！
3.2 项目组成员→“自由人”→质量与进度监督小组成员
调入开发部伊始，我被纳入财务异常警示系统项目组，并且说明，我所扮演的角色比较特殊，凡属开发项目我都需要参与其中。于是，我先后加入了财务异常警示系统项目组、东进ERP项目组、南海国有资产管理系统项目组。那段时间，让我感觉开会、作会议记录成了工作中不可缺少的一部分。开发部大大小小的会议要参加，作会议记录；项目组内部的会议要参加，了解进度；各个项目组的评审会议要参加，要准备好评审的制品，作会议记录……
接着，我的岗位结构作了调整，我成了一个不属于任何项目组自由人，反而要对各个项目的制品、进度进行管理。工作的内容没有多大的改变，在结构上却开始发生了变化。
成为“自由人”的时间并不久，开发部很快地成立了质量与进度监督小组。我成为了其中的一员，从此，我又变成了一个“有组织”的人了。我们的小组成员不断增加，队伍不断壮大，成员由一开始的两个人发展到了现在的四个人。工作范畴包括对各个项目组制品质量监督、进度监督、测试、配置管理、里程碑评审……成立了小组以后，开始想到了制订规范和制度。这段时间，我更加积极地学习软件质量管理和CMM体系的知识。经过学习，再加上对工作的不断总结，我先后在开发部制订、颁发了开发资料管理办法、服务器数据库管理规定、个人工作管理表格填写说明、测试流程；草拟了配置管理规范、里程碑评审规范、需求管理规范，规范了软件过程的各种文档的模板。
3.3 写用户手册生手→“专家”
第一次写用户手册是在财务异常警示系统的时候。财务异常警示系统是公司第一个完全按照软件过程规范并且运用J2EE进行开发的项目，对于公司来说，是在技术上、开发制度上的一个里程碑的飞跃。我有幸地加入了项目组，除了负责配置管理工作以外，还负责系统用户手册的编写。
万事开头难，从来没有写过用户手册的我，接到任务的时候忐忑了好久，不知道要怎么写。财务异常警示系统面向的用户是具有丰富财务知识的财务总监，涉及了大量的财务知识，面对取数运算元、标准运算元、异常、方法……这一大堆陌生的术语，不仅要学会怎么使用它，还要写成文档，教会别人怎么使用。我只好尽量多学多问，问巫锦新，问林戈，抓住机会让他们教我怎么使用，怎么表述。终于，第一份用户手册出炉了，图文并茂，自我感觉比公司以前系统的用户手册好多了。因为如此，这份用户手册经过多次COPY，作为指导，被接下来一个又一个的项目在写用户手册时所引用。也就是在那个时候，我学会了怎样看ROSE模型了解用例，怎样通过需求规格说明书了解系统功能，怎样在什么也不懂的情况下问人……
自始之后，写用户手册和帮助的工作似乎变成了我的专利。东进ERP系统、企业转制与资产处置系统、三水公有资产管理中心系统、SAM事项审批系统、SAM行政事业版，每一个开发项目的用户手册或帮助似乎都和我脱不了关系，虽然这期间也有派其他部门、其他人员参与协助。而我，不知什么时候起，竟然成了写用户手册的“专家”。要负责指导、教会别人怎么应该怎么写，甚至挑剔着别人写的内容过于简单不够充分，不能说明系统的功能；排版不符合规范；截图随便，没有反映真实内容……
3.4 2003年获奖次数最多的SK员工
2003年，对我而言，在公司可以算是光荣的一年。
5月，因为调职开发部以后工作表现突出，我获得了公司的表彰和奖金；
6月，我获得了财务异常警示系统项目奖；
7月，在半年总结中，经过全体员工投票，我获得了进步奖；
8月，我获得了企业处置与资产转制系统的项目奖；
11月，对于工作的情况向唐总提了一些个人的看法，意外获得了合理化建议奖。
虽然奖金微薄，但我深知这其中饱含公司对我工作的种种肯定，而这些小小的荣耀也在一步一步地激励着我前进！
3.5 不足和遗憾
总觉得还有太多太多的工作需要完善，有太多太多的东西需要学习。
在配置管理方面现在只是进行了比较简单的版本控制，初步实行了需求管理，虽然写了这方面的规范，但还没有颁布执行，配置的审核、产品的发布管理……还有很多的东西需要规范，需要完善。
质量与进度小组需要规范的制度很多，目前还没有一个质量体系指导工作；测试方面没有制度；项目的进度监督需要有制度……方方面面的规范，都来不及在2003年做好。
个人的技术能力提高不大，不懂系统分析、不懂设计、不懂开发，在工作中时常感到力不从心。另外，到目前为止，只能熟练地运用VSS进行版本管理，对于其他版本管理工具如CVS、ClearCase的掌握不够，还没办法根据不同项目的情况自如地使用不同的版本管理工具进行管理。学习编程知识，能够看懂源代码，看懂分析设计模型，掌握更多的配置管理工具……这些都是我2004年工作所向往的。
写用户手册是一个工作量大、时间甚长的工作，除了做好本身的配置管理、质量与进度监督的专职工作以外，其他的时间几乎都花在了 “兼职”写用户手册上。现在，SAM行政事业版用户手册的编写正在紧张地进行着。这一次，我在总结以往经验的基础上，对其风格作了不少修改，比以前更加清晰、明朗、详细。我希望写成一个模板，一个值得不断借鉴、引用的模板，这样以后的系统都不必再烦恼用户手册该怎么写，每个人只要看到这个模板，照着里面的内容、格式直接引用就可以了。能够在公司培养成更多写用户手册的专家，我也可以功成身退，分配一点时间去学习新的东西！
3.6 完结
写着，写着，总结，再总结……不断地回想着2003年，可以总结的东西竟然如此之多。无论如何，我想我是进步很多的。计划着2004年我该怎样秉承SK“诚信、和睦、实干”的文化，百尺竿头、更进一步提升自己；盘问着今年的努力够不够，年度的加工资会不会有我的份？憧憬着，努力着……
革命尚未成功，同志仍须努力！迎向2004之时，我对自己如是说。2004年个人工作总结
从踏入12月以后，就开始思付要写2004年的年度工作总结。一直没有动手，除了忙碌可以作为理由以外，更重要的是，不知道该怎么把这一年做过的许多零乱而繁杂的工作总结成文。
有人把工作总结当成一种形式，作为应付上级领导的苦差，我却发自内心地想写总结，通过总结，可以清楚、明晰地知道自己一年来做过什么，欠缺什么。好的，需要继续发扬的；不好的，需要加以改进的，都会在总结中一一罗列，鞭策自己。
2004年，我都做了哪些工作？还得从头回顾，娓娓道来。
作为质控部一员，我的工作却囊括了质控、研发、营销三大部门，随着公司的机构调整、人员变化不断调整和变化。按照部门分类，可以把我2004年的工作总结如下：
4.1 质控部门工作
质控部门的主要职责是负责监督和控制研发中心内产品和项目开发的工作进度与质量，包括质量保证、软件测试、过程监督、配置管理、技术评审。我在质控部门的工作也围绕着这几项来开展。
4.1.1 配置管理工作
配置管理工作是我的主要职责，在这一年内，我负责了研发中心所开展的十二个项目（包括三水项目、SAM行政事业版、天津项目、南海项目、SAM经营版、新疆项目、资产运营管理系统项目、江西国资委产权管理系统项目、河北省国资委业绩考核项目、技术准备项目、茂名项目、技术支持性项目，下文所提的十二个项目均指上述十二个项目，不再重要提及）的配置管理工作。
（1）根据项目的规模、性质、简繁，视情况针对各个项目开展常规的配置管理工作。包括：
制定配置管理相关制度和流程（有相关文档，但未遵照执行）
配置管理计划的制定（当项目规模较大时）
配置库的建立（按照项目编号，每个项目建立一个配置库）
对项目内各成员的用户帐号和权限的分配
定期检查配置库的使用情况，督促开发人员定期提交、更新相关的代码、文档，有需要时设置Label，记录重要基线
定期对配置库进行备份，设置对配置库进行日自动备份，每半年进行一次资料刻录。
（2）对研发中心内所有成员的配置管理培训，使受训人员了解公司配置管理流程及VSS使用情况，从而更好地开展项目过程中的配置管理工作。
包括：
4月份针对软件产品与项目的配置管理过程、配置管理工具VSS的使用等方面的知识，对研发中心全体成员进行了一次总体培训。
对4月份后研发中心新招聘的员工分别进行公司配置管理过程及配置管理工具VSS的使用培训。
注：个人编写、准备的培训材料包括：配置管理基本知识（见附件一：配置管理培训.ppt）和VSS使用说明（见附件二：VSS使用说明.doc）。
4.1.2 制度编写及流程改进工作
为了更好地提高工作效率，规范部门工作、个人工作，方便部门与部门之间的交互，这一年，在工作过程中结合领导要求、个人想法、同事意见，经过思考，在工作过程中制定、颁发了一些制度、整理了一些文档，对质控和研发工作的改进提供了一些帮助。包括：
（1）年初，研发中心设立产品、项目、质控三个部门伊始，各个部门之间独立开展工作，信息比较闭塞，而各个部门之间工作关联性大，需要不断沟通和交互。为了减少沟通成本，使部门与部门之间的信息交互、沟通能够更方便、更快捷，提议建立了项目部、产品部、质控部各个部门的部门配置库，将各个部门的制度及规范、会议、培训、计划与总结、个人周报等各种信息统一集中管理，大大方便了公司高层领导了解各个部门的工作开展情况；部门与部门之间相互了解彼此工作开展情况；部门成员之间了解彼此的工作开展情况。（见附件三：部门配置库管理办法.doc）
注：后面由于公司机构设置，将产品部、项目部合并为研发中心，也将配置库进行了合并。
（2）为了规范SAM行政事业版及后续产品序列号管理，编写了SAM行政事业版系统系列号管理办法（见附件四：SAM行政事业版系统系列号管理办法.doc）。
注：因产品的销售没有如计划般覆盖全国，该办法没有产生作用，如果尘封硬盘。
（3）为了规范公司内部产品的发布，将公司内部所有已经定版的产品、项目安装到SS服务器统一发布，并将各个系统的访问地址整理成文（见附件五：公司系统访问地址.doc）供公司内部开发人员、技术支持人员、市场人员访问系统，了解各个系统功能。
注：因为后期SS服务器中毒瘫痪，部分系统不再采用BS浏览器访问模式，采用需要到各台机安装才能使用的CS模式，没有再将此项工作持续进行下去。目前上面公布公司的网址因为SS服务器中毒后瘫痪未恢复无法再访问，系统的发布需要另觅它处。
（4）为了方便公司新老员工对公司所有项目情况有一个整体的了解，对公司历年来开展的项目信息进行了整理（见附件六：公司历年项目信息列表.doc）。
（5）由于前期质控部在了解各项目进度进展时需要分别与每个项目的具体负责人交互，当涉及的项目、人员较多时比较费时，且无法及时了解每个项目的进度情况，建议由项目负责人每周填写项目进度周报（见附件七：项目进度周报.doc），再统一将每个项目的进度信息汇总到“项目进度综合报告”（见附件八：项目进度综合报告.xls），以方便公司领导、质控人员及时了解各个项目的进度，开展后续的测试等工作。
注：后期部门合并，人员减少，质控部门纳入研发中心一起开会后，可以通过会议了解各个项目每周所开展的工作汇总项目进度信息，取消了项目进度周报。
（6）针对开发人员在开发过程中使用VSS出现不及时提交、更新代码、使用VSS时出现的普遍错误，编写了配置库管理规范（见附件九：配置库管理规范.doc）和使用VSS常见错误（见附件十：使用VSS常见错误.doc）。
（7）针对开发人员在项目开发过程中，对个人代码没有较好地把关，出现较多常见的低级性错误，对测试的依赖较强，造成测试人员工作量大且繁琐。部门内决定对项目测试过程中出现的Bug定期进行统计，并将统计结果公布到公告栏中（见附件十一：项目缺陷统计表.xls）。
（8）针对各个项目发布版本混乱，经手人过多且没有对项目过程中重要的版本进行label记录，造成有些重要版本无法追溯的情况，制定了项目重要版本记录表（见附件十二：项目重要版本记录表.xls），对十二个项目可以追溯的重要版本进行了整理，记录在表中，并在研发中心部门内推广、执行。
（9）以质控部的角度对研发中心2004年所开展的所有项目，从质量、进度、成本等各个方面进行总结、分析，为公司后续要开展的项目提供经验、指导，方便公司领导、研发中心所有成员回顾、了解2004年的项目质量情况（见附件十三：2004年项目质量总结.doc）。
4.1.3 软件过程监督工作
软件过程监督工作包括：
对项目的软件过程执行情况进行监控，定期向上级反馈各个项目的软件过程执行情况。
对项目开展的计划进度与实际进度进行跟踪，每周定期更新项目进度综合报告（见附件八：项目进度综合报告.xls）记录各个项目每周的进展。
4.1.4 软件测试工作
由于质控部人手少，负责测试的只有一人，测试任务繁重，在测试工作紧张的情况下有时也协助测试人员做一些简单的测试工作，包括：
协助进行SAM经营版的简单测试工作（主要针对财务异常警示子系统和决策支持子系统）
对北京机关事务管理局演示版本的测试
对资本管理系统的测试（拿到新疆去的第一版）
协助进行三水产品化项目的测试
协助产权关系管理系统客户端的测试
测试工作主要针对上述各个系统的功能、界面提出完善性建议及分担部分Bug的查找工作。
4.1.5 评审工作
评审工作也是质控部门的工作之一，在质控部门参与的评审工作包括：
前期协助组织了SAM经营版项目各个阶段的评审工作，包括会前发布相关评审通知、评审制品；会中进行评审意见记录；会后对评审结果进行跟踪。
中期由于公司部门机构调整、管理人员变化，取消了公司层面的评审，直接由项目内部进行评审，未参与其中工作。
后期参加了茂名项目的评审会议。
注：目前评审工作开展得比较薄弱，主要因为旧的软件过程制度不满足目前各个项目的需要，新的软件过程没有明确颁布，故没有明确应该以何种形式开展评审工作。这类工作参与得不多。4.2 研发中心工作
4.2.1 文档编写工作
除了负责质控部门的工作以外，本人还担任了研发中心大部分项目的文档编写工作，一年中，写过的文档不下千页，实在是一项很考验耐心的工作。总结起来，2004年写过的文档包括：
SAM行政事业版用户手册（包括Word文档版和CoreDraw印刷版）
SAM经营版用户手册、安装手册
资本管理系统用户手册（拿到新疆用的版本）
三水项目（用户手册、安装手册）
江西国资委产权管理系统的软件功能列表、系统功能流程图、用户手册、产品白皮书
河北省国资委业绩考核管理系统的产品白皮书、用户手册、安装手册、演示PPT
茂名项目用户手册（正在进行中）
4.2.2 软件使用培训工作
因为负责研发中心内各个项目用户手册编写工作的缘故，对各个系统的功能、操作流程、注意事项均比较熟悉，可谓除了负责测试的小曾以外最熟悉公司所有系统的人。所以也担负了部分对公司内部成员使用系统的培训工作。包括：
在公司级内组织开展对技术支持人员、营销人员使用SAM行政事业版的培训
在公司级内组织开展对技术支持人员、营销人员使用SAM经营版的培训
根据需要对公司内各部门的人员单独培训单个系统的使用
4.2.3 演示数据准备工作
为了使公司系统在给客户演示的时候能够达到较好的效果，帮助商务攻单，先后配合进行了两次较为大型的演示数据准备工作，包括：
江西国资委产权管理系统一千多家企业数据的整理、导入数据库，形成产权关系树；
重庆客户业绩考核系统几百个Excel表的演示数据准备。
另外，平常还不定时的视情况配合商务人员准备其它系统的演示数据。
4.3 营销中心工作
8月份，负责营销中心文职工作的小曹离职以后，我开始接替她先前的部分工作。包括：
4.3.1 奥汀软件的管理工作
奥汀软件的管理工作量不多，无非就是拥有管理员的权限，每次营销人员负责的区域、客户发生调整、变化的时候；有新员工入职的时候；有老员工离职的时候给相关人员重新分配权限，帮助新员工学会安装、使用该软件。就是这么一件看似简单的工作，有时却令我扼腕。在使用奥汀软件的过程中，最痛苦的事情莫过于公司调整营销人员负责的客户，需要对各地客户进行经手人变更的时候。奥汀软件的经手人变更功能没有批量选择、批量修改功能，每次只能一个客户一个客户地选中——点击右键——经手人变更——选择变更后的经手人和变更原因，有时一调整就是几百个客户，连续不断地上千次鼠标点击，点到手酸。
由此，我深深体会到，在编程的过程中，考虑到用户操作的方便性是多么的重要，就是这样一个简单的批量选择、批量修改功能，开发人员在编码的时候花不了几个小时，但由于没有考虑到用户这方面的需求，导致成百上千个客户增加几十倍的工作量！这一点，会不会给开发人员一点启示呢？
曾经找负责奥汀软件客服的人员抱怨过这个问题，他给我的回复是，在我们的新产品中已经增加了这个功能。换言之，要用，付钱吧。多么令人讨厌的事情，我们总不能为了那个批量功能特意再掏钱买个新版本吧？
前段时间由于DS服务器硬盘突然无端端损坏，造成存放所有客户资料、联系记录的奥汀数据库丢失。而因为我先前不了解服务器的安装等原理，也没有人跟我交接数据库的备份工作，只找到了以前的管理员7月份的备份版本，造成7月份以后登记的全部客户资料和联系记录丢失，造成销售人员大大的不便，这其中的损失，没有估量。自此之后，我意识到备份工作的重要性，现在无论是营销方面存放客户资料的奥汀数据库还是研发方面用的项目配置库，都会作好几手的备份，保证万一有意外，也不致造成数据丢失。可见，简单的工作，如果没有人做，有时也能带来不可意料的后果。
4.3.2 建立配置库整理资料
一直以来，营销中心的各种资料都是放在公司的OS服务器或个人电脑上，这当中包括部门内的各种规章制度；各个产品的资料，包括宣传单页、产品白皮书；各地客户的资料，包括针对某个客户做的方案、演示用的PPT、相关客户的反馈意见表；各个产品的培训资料、公司领域知识的相关资料，零乱而分散地放在各个不同部门的目录，各个不同负责人的文件夹中。文件的命名有的以日期为后缀，有的以Vx.y版为后缀，有的以new或old为后缀，要找一份文件，真不知道哪里下手，找出来的，还不知道是不是最新的。
目睹此情，我把整个OS服务器翻了一遍，把分布在各个角落的文档一一翻阅，有用的，拿出来，按照部门规范、部门会议、产品资料、客户资料、系统安装、培训资料、行业知识七大分类对各种资料进行整理，用VSS建立了一个配置库，像所有项目的文档、代码那样，纳入版本控制，把文档都集中管理起来。
可惜宣传做得不够，营销人员也没有体会到这样做的好处，现在我整理出来的营销中心配置库，除了有新员工进来，我可以比较自豪地叫他通过这个配置库，系统而完整地找到很多公司以往客户、产品、行业知识的相关资料以外，平常营销人员写的方案、PPT等资料还是习惯各自放到自己电脑上，共享给别人的时候发邮件，用一个个的日期或者new、old的标记标示着版本的新旧，不习惯用配置库保存、管理自己的资料。一个人若想一下子找到另一个人负责的东西，比较难……
4.3.3 会议记录
在公司内，我还有另外一份兼职工作，就是整理会议记录。无论是营销部门、研发部门还是质控部门的会议，经常都会充当会议记录的角色。经常会在开完会，整理完会议记录发送到相关人员的邮箱后听到有同事对我说：“会议纪要整理得不错”之类的话语，有了这些鼓励，使我在参加每一次会议时用心聆听，不怠动笔。
4.3.4 协助其他人员的文档工作
小xia，帮我把这份标书排一下版吧，你排版比较熟；小xia，能不能替我整理一下各个系统的功能模块，你对各个系统的功能了解比较多…… 每当听到有人要我帮忙协助这样那样工作的时候，如果不是手头有事安排不过来，只要力所能及，我一般都来者不拒。这些工作不再一一细数，只记得某同事对我说，我要向唐总提议，年底设立“最佳协助奖”，设立了，就投你一票时，我会心一笑，其实，那都是举手之劳。4.4 个人收获与体会
不知不觉中，一年的工作总结竟然写了有五页之多。看着一行行打出来的字，才知道我做的工作比我想象中还要多、还要琐碎、还要杂；不知不觉中，我也发现，在这貌似没有长进的一年中，其实也有不少的收获。
4.4.1 关于改进工作
这一年，我最大的收获就是，在工作过程中能够不断地发现问题，用心思考怎样采用更好的工作方法解决问题。于是，这便有了上面的“见附件一”到“见附件十三”。这些看起来很平常的文档，有的却是我困扰良久、茅塞顿开忽然想出来的办法。我想我不会忘记，当我建议项目部建立部门配置库，用VSS对部门事务进行管理，得到杨经理认可，再得到唐总好评时那种藏在内心的自豪感；也不会忘记，当我听到罗经理在研发会议上说：“小xia在工作的过程中总是能够提出很多自己的想法，给我们带来意外惊喜”时的成就感。虽然很多东西在推行、实施的时候，效果并不如自己意想中的好；有的甚至只开了个头就再也开展不下去；有的根本没有人知道、关心我在做什么……毕竟我对工作曾经那样用心良苦地思考过，我想，这会是我得益一辈子的东西。
4.4.2 关于身兼数职
不看内容、光看目录就知道，我做的工作横跨质控、研发、营销各个部门，各种类型都有，实在是杂、杂、杂。虽然如此，我还是很不情愿地用“打杂”两个字来形容我的工作。张瑞敏不是说了么：“把每一件简单的事做好就是不简单，把每一件平凡的事做好就是不平凡”。汪中求也有言：“对于敬业者来说，凡事无小事，简单不等于容易。大量的工作，都是一些琐碎的、繁杂的、细小的事务的重复。”我深有体会，能够把这些平凡而又简单的事情都做好，绝非易事，更会在参与这各种所谓的杂事的时候得到或多或少的收获。未来的日子，让我继续努力，达到把“简单的招式练到极致就是绝招”。
4.4.3 关于写文档
当我看到打印出来的行政事业版的400多页的用户手册有枕头那么高的时候，我惊叹：这些，都是我写的吗，都是我一个字一个字从键盘里敲出来的吗；
当我看到写出来的产权管理系统用户手册印刷成册、精美包装的时候，我自豪：成就感徒然而生，我的文字竟然通过这种方式变成铅字了；
当我看到售前人员、实施人员、营销人员看着我写的用户手册、安装手册学习系统的操作、使用、安装的时候，我高兴：我写的东西能够给别人提供帮助。
尽管如此，现在动笔写一个庞大系统的用户手册之前，想到日复一日对着键盘敲字；对着系统界面截图；对着没有成熟稳定操作起来bug连连的功能；对着甚至没有任何文档参考的系统冥思苦想怎样表述它的功能时，再想到写完以后还要根据客户的需求发生变更，修改相应的系统功能再修改相关用户手册功能操作时，还是会禁不住汗颜。半是恐惧之中，可喜地发现，在写用户手册等文档的过程中，也能得到不少提高呢。
经过这样一个接一个项目文档编写的千锤百炼，我的写作能力大大提高。现在，无论叫我写什么文档，不管是用户手册、安装手册、会议记录还是产品白皮书，不管是用Word、Excel、Powerpoint还是要用上Visio、Project、Photoshop，虽然谈不上信手掂来，但是以前那种“纵有千言万语不知如何下笔”的心情却不会再有。某次当我苦恼着跟罗经理说不知道某文档要怎么写的时候，他开玩笑地对我说：“还有什么文档你不会写的吗？”，禁不住一乐，对写文档的恐惧也开始淡化。
因为对每个项目都有写用户手册的任务在身，所以不单会从宏观角度跟踪项目的进度，了解项目情况，而且会从细节着手，小到了解每一个功能、每一个按钮的作用，有意见可以及时反馈，帮助改进软件功能、优化界面。也因为这样，我比公司大多数人都了解各个系统的功能、操作，了解公司的产品。这些，何尝不是一种收获呢？
4.4.4 关于坚持
以前，如果别人说我：“做事只有三分钟热情，心血来潮过后就无声无息”的时候，我会无言以对，没有理据反驳。因为，在我过去二十几年的人生中，除了每天例行的吃饭睡觉，实在是没有什么东西称得上坚持过的。记得曾经兴致勃勃地想过早上要起床背单词，周末要坚持运动，每周要坚持练听力……最后都因为这样那样的理由和借口而搁浅，没有一样事情能坚持哪怕一个月。
现在，虽然我还是有很多事情想过要做之后不能坚持，但却有一两件事情让我可以骄傲地说：我也是一个可以坚持的人。
生活中，我坚持每天自己做饭、带饭到公司来吃，这中间的理由有很多，不过最终发现，热爱做饭、并且爱吃自己做的饭是最大的理由：）；坚持写网络日记，虽谈不上日日更新，却会隔三差五地去记录自己平凡生活的一点一滴，一年多下来也收获良多。
工作中，我坚持写个人工作管理表格，做到对工作日计划、周计划，日总结、周总结，不管上级领导有没有要求，主动自发地坚持；每周坚持在项目进度综合报告中记录这一周哪些项目做了哪些事情，进度如何，虽然也没人要求甚至没人关心那份文档。
因为这两样坚持，使我在一年结束的时候，可以把自己做过的工作回顾得这么清楚，把总结写得如此详细；可以有根有据地写出一份长达上万字的04年项目质量总结报告；可以有这么多的感触和收获……想起那句听过无数遍的“贵在坚持”。
4.5 结语
职场中很流行一句话：衡量一个人工作的好坏，不在于这个人做了多少工作；而在于你的工作有没有为公司创造价值。我没有站在销售一线冲锋陷阵签过单；也不曾轰轰烈烈地能够在短期内开发出一个软件来占领市场的能力，甚至不会写代码，不能直接解决客户的需求；更没有通霄达旦地加班加点，超乎常人地付出自己的劳动。我所做的，都是自己职责所在、力所能及的工作，这些工作，能为公司创造多少价值？不曾衡量过。
有位前辈在给我提意见的时候这样建议道：“以后信心要强，希望你能有发展，每天提高自己，有计划的学习。建议加强：文档管理、日常事务处理能力、人际关系（表达），书写能力。培养职业女性的气质，比如：穿着，站的肢势，说话的方式，果断大方的说话风格，从细节入手。不要像小女孩，一两句打击的话就让你心里不高兴，要懂得自己控制自己的情绪……”，这些话，我一直铭记在心，在此谢谢为我如此中恳地提过意见的他。我知道，自己还有很多很多需要学习的地方，也一直在努力，希望可以“每天前进一步”。
2005年了，前方的路要怎么走？我追求什么，希望得到什么？我轻轻地问自己的心，带着一连串的疑问，思索，再思索……
4.6 附录说明
附件一：配置管理培训.ppt
附件二：VSS使用说明.doc
附件三：部门配置库管理办法.doc
附件四：SAM行政事业版系统系列号管理办法.doc
附件五：公司系统访问地址.doc
附件六：公司历年项目信息列表.doc
附件七：项目进度周报.doc
附件八：项目进度综合报告.xls
附件九：配置库管理规范.doc
附件十：使用VSS常见错误.doc
附件十一：项目缺陷统计表.xls
附件十二：项目重要版本记录表.xls
附件十三：2004年项目质量总结.doc -
测试需要三心（转）
2008-12-13 16:23:14
作者有四年的培训测试新人的 经验，测试 ‘三心’ 是俺的 培训 教材 ，主要培训新人的 品格，也是后期测试 工作 最需要的。中国人 讲究 以道御术，‘三心’如果具备 基本上测试60-80% 都可以胜任，其余的都是一些技能，也都好掌握。
1.诚心：
这个最重要，完全是 人品哈。我们讲究看到什么 就说什么，问题在奇怪 也不要坚持 你 看到的 ，有就有 没有 就没有。
2.细心：
这个一般大家都知道的，测试很需要细心 。但是你有多细心是要训练的
3.耐心
一时的细心大家都可以做到，但是长年累月的 细心 那就是耐心了 -
做测试需要学习哪些知识？（转）
2008-12-13 16:19:35
测试是一门非常注重实践的学科，如果对嵌入式系统测试有兴趣，建议进入一家做嵌入式产品的公司进行测试工作，否则是很难入门的。
成为优秀的测试人员，需要掌握的东西很多，下面是我认为需要努力的方向，我自己也在努力
:
1、计算机专业知识，至少应该具备计算机本科各学科理论知识，这个就不多说了；
2、被测对象专业领域知识，例如如果你是测路由器的，那么你应该具备通信专业基础知识，以及和路由器相关的通信专业领域知识，如OSPF、RIP等，如果你是测银行金融业务的，你应该对银行各业务流程熟悉，如果是嵌入式系统产品，那么还得学习VxWorks等操作系统，8260等CPU，呵呵，是不是有点头大了
3、测试专业知识，包括测试技术、测试方法、测试原理、质量原理、测试管理、测试工具、缺陷分析、测试度量等等。。。
4、沟通方面的技巧
测试的发展永无止境，只要努力，我想5年的时间突破上面的内容应该是足够的 -
工作感想－－关于测试（转）
2008-12-13 16:15:53
测试经验总结（2005-2）
1.测试人员和用户的联系与区别
黑盒测试人员和用户，都是站在实际应用层进行操作，因此他们对应用层的可用性、实用性非常关注。用户不懂的是软件的使用，而相对用户来说，测试人员对软件比较了解，但不熟悉业务本身。
八个字归纳：用户是用，测试是测。
用户不懂使用就需要技术支持人员去培训，而测试人员在测试初期经过开发人员和项目负责人的简单培训后，就应该通过所学的理论知识和相关的业务知识独立去了解、深入到软件的功能点中。
应该做到：由测试人员培训技术支持人员，由技术支持人员实施时给用户培训。
2.带着问题去测试
阿猪工作守则第一条：带着问题去测试
测试中会遇到很多问题，没关系，没有脑子里面的一个个问号，是不能很好的发现问题的。往往发现一些藏的很深的bug都是在测试人员一步步解决这些问号的过程中，切忌遇到问题就问，不仅因为增加不必要的与开发人员、负责人等的交流时间可能延误项目进度，而且自己对问题的印象也不会很深刻，毕竟在相对较短的测试时间内，听不如记，记不如自己去发现规律。
3.测试期间提问题和交流的时机
什么时候应该提问题？
我们都知道，作为测试人员，并不是测试期间什么时候遇到问题就要马上问，那什么时候是提问的时间？
培训
培训时，一般在讲解内容的间歇允许打断，由培训人员解答测试人员的疑惑。培训的过程其实就是一个传输新知识并答疑的时间，这个期间的提问是欢迎的，也可以增加参与性和调动积极性。所以希望大部分的问题能在这个阶段提出来。受时间、环境等条件制约，有时培训的人讲的也不一定细致和全面，这时就需要自己多想，想想这个功能是干什么的，为什么这么做，对应的业务是什么。
阿猪工作守则第二条：培训时脑子灵活转动，多想多问
以前大家可能有过参加辩论会的经历，就算没有其实和人聊天也是一个交互的过程。参加辩论会要求快速思考，然后放慢语速说出自己的观点，因为不能说错。我们在参加培训时前者相同，后者相反。脑子嘴巴都要快，说错了也没有关系，自己的想法被纠正的过程中也是加深印象和理解的过程。
计划评审
提出对于软件不理解、安排的任务不明白的地方。
测试期间
这个时期最主要的问题应该集中在影响测试流程和进度的问题，而不是说明书或其它文档上已有的内容，或者与自己负责模块无关的内容。开发人员和其他测试人员都有自己的进度安排，因此，
影响测试流程和进度的问题,马上问！
不影响流程的问题，记下来统一问！
不必要的问题（说明书或其它文档上已有的内容、讲过三遍以上的问题、今晚去哪里吃饭的问题），不问！
好处：避免不必要的时间支出，不打乱自己的测试思路，一气呵成，并且使项目成本得到控制
坏处（？）：脑子里、笔记本上留下一堆待解决的问号吧，浪费脑细胞和公司的笔和纸张等资源
阿猪工作守则第三条：先做事，后学习
在有限的时间内先完成该做的事，有空闲的时间再去补充自己的知识。
要很好的把握上述内容，也要求提高培训期间培训人员培训内容的完善性，要求前期培训人员强调出软件的重点、难点和注意事项。这个期间适合于上面提到的“带着问题去测试”的方法。
但有一点需要注意：不要为了一个地方的卡壳在那耗上一天半天的，这就不值得了。
测试中期评审测试问题
答疑解惑的时间。
测试报告评审
对一些结论有疑惑和不解的地方，提！
4.记笔记
一个老生常谈的话题。
阿猪工作守则第四条：好记性不如烂笔头
测试培训的时候对于一些重点应该记下来，即使当时听懂了；没听明白的更应该记下来，到测试软件的时候去验证自己的疑问。如果培训时特别强调的地方，测试时再去问，这就不好了。
养成一个良好的习惯，会使以后的工作更加顺利。
5.在公司和学校的学习的区别
学校是专门学习的地方，公司就是工作的地方，因此，它们的性质决定了其学习内容和方法的不同。
学校 公司 备注
内容上 主要是系统的理论知识 主要是和项目相关的业务知识 如果在测试中感到自己部分理论知识欠缺时，就应该回家多补充了
时间上 大块时间的连续学习 相对邻散 在公司一般不会拿出大块时间来学习和讲解
形式上 老师授课＋自学 培训＋交流＋测试过程中自学
个人觉得，一个高效的测试流程应该如下：
a.花几个小时至多半天时间快速阅读浏览软件说明书、设计文档；
这个阶段要让脑子里面形成对软件的整体印象感，能够让自己把握全局，因此，测试负责人安排时间看文档时，决不能忽视它的重要性，否则就会出现后续阶段磕磕碰碰的情况。注重速读，把握软件说明，忽略具体的数据库设计、功能点设计、计算、规则和辅助工具（相关软件）说明文档，囫囵吞枣的方法在这里就显得很有效。
如果项目时间紧或没有文档，这个步骤所做的事可以在下面完成。
b.利用培训时间消化吸收的知识
c.软件上手
几个小时至多半天时间，熟悉软件框架和基本功能，不要求所有功能都会操作，自己负责的模块可以多侧重一些。
d.细测
主要症对计划中安排给自己做的模块，这时就要相对放慢节奏，每一步操作、每个对话框（操作界面）都要深究，别放过任何情况。这时会遇到一些错误或不理解的地方，明显的如报错就提到开发过程论坛，不明显的就先记下来，等这个功能点测完再回头去看，你会发现：
50％的问题可以自己分析出来和解决，有的问题不是问题，只是开始还没有完全理解。
阿猪工作守则第五条：软件不是一次能测透的
Rome is not built in one day.
工期、人力、环境资料等，都制约着测试的深度和广度，因为不要期望一次能完全把握某个软件。
综合测试的优势在于，我们负责公司产品的把关，而项目由产品延伸而来；测试产品会不断出新的版本，一次没有理解，可以在下一次中弥补，温故而知新。
一口吃不成一个胖子，看我这么瘦又这么能吃就知道了^^
要结合自己的实际情况决定本次测试的深度，不要看着别人进度快了就打乱自己的节奏，只要安排合理，应该按照计划来。特别忌讳认为自己这块没问题了就马上去看看别人负责的功能，期望全能。这样一般来说除了ljl这种全能性人物外都会造成最后自己的问题留了一堆，别人的也没搞懂。
新人特别注意，踏踏实实的搞懂每个自己负责的模块，打阵地站，这种方法很有效。
评价自己是否可以转入下个模块的几个因素：自我提问与别人提问、测试进度
如果大多数相关人员（主要是测试负责人、其他部分相关测试人员特别是开发组集成测试人员和技术支持人员）对于自己负责模块的问题都能解答，搞定！NEXT-->转入下个模块。
否则，还是再回头想想思路和遗漏的地方。当然，要综合考虑测试进度。请组长对自己提几个软件的问题，他会很乐意的。
e.小结
一个阶段就进行一次小结，这个小结可以是书面的，比如测试问题记录、测试用例补充、测试模块设计等，但大多是自己分析，为了方便接下来模块的测试.
f.性能测试
性能测试不仅是测试性能，同时也加深自己对软件应用的理解，因为性能测试往往和实际应用或用户需求结合的很紧密，避免造成软件功能都会用，但不知用来干麻的尴尬情况。
g.安装盘测试
安装盘程序测试，简单过一下软件功能有无错误。
安装盘程序文件、库文件、组件等的完整性、正确性，这个非常重要，要不返工就浪费时间了。这个阶段要积极与开发负责人和GJ沟通，确保最后的胜利。
h.测试总结
测试接近尾声，总结自己对软件的掌握情况，得出测试结论、归纳测试方法、提出修改建议，为软件以后版本的修改提供依据，也为以后再测类似软件提供捷径。
5.小结
用户用软件，测试测软件
培训时多想多问
好记性不如烂笔头
带着问题去测试，在测试中解决问题
先做事，后学习，争取双赢
软件不是一次能测透的
在软件行业中，敬业精神尤为关键。默默无闻的测试员工作是比较枯燥和辛苦的，是否具有忍耐力、快速学习能力、沟通能力以及团体合作精神，是敬业素质的重点。
一点感想，敬请指正补充。 -
送给初学者－－软件测试之中文网络资源总汇（转）
2008-12-13 16:06:13
51Testing软件测试网 www.51testing.com
CSDN——软件测试频道 testing.csdn.net
希赛网——软件测试频道 testing.csai.cn
中国软件测试联盟 www.iceshi.com
一起测试网 www.17testing.com
北大测试 www.btesting.com
中国软件测试基地 www.cntesting.com
中国软件评测中心 www.cstc.org.cn
中国软件质量网 www.rjzl.gov.cn
更新说明：
1.去除了不可用的链接和更新较慢的网站
2.添加了几个网站的链接
下列网站中，部分已经不可访问，但作为V1.0的内容仍保留了下来
软件测试之中文网络资源总汇（顺序是我随意排的，不分先后）
中国软件测试社区 http://www.sztest.net/forum/
海松宝的小屋 http://www1.testage.net/haisongbao/
Alan工作室 http://alanzhou.nease.net/index.htm
软件工程专家网 http://www.51cmm.com/
51testing软件测试网（慧谷-博为峰软件测试工作室） www.51testing.com
中国软件测试在线 http://www.softtest.cn/
杨柳清风论坛 http://www.kaiyuanlaw.com/dvbbs/
天极网的软件测试板块
http://www.yesky.com/SoftChannel/72342393369657344/index.shtml
测试工程师 http://opentest.51.net/index.htm
自由龙（好像是珠海的） http://www.freedragon.net/ -
从程序员到测试工程师（转贴）
2008-12-13 15:59:26
前言：软件测试一门非常崭新的学科，目前研究的内容还很不深入，仍然处于婴儿阶段。软件测试需要什么样的专业基础还没有定论，而且目前还没有一种很好的标准来衡量测试人员。但无可置疑，软件测试越来越受到软件公司的重视，软件测试工程师的作用也逐渐被人们所认可。这一点已经在像微软这样的国外大型软件企业中所证实，在微软，一个开发人员相对应着一至两个测试人员。现在，就让我们走近软件测试工程师，关注他们的成长之路。
从程序员到软件测试工程师
特别策划/本刊编辑部 撰文/闫辉
国内软件公司对软件测试的态度令人担忧。软件测试工程师不足，开发测试人员比例不合理。据调查，最好的企业中测试人员和开发人员的比例是1:8，有的是1:20，甚至没有专职的测试工程师。
曾经参与微软Windows95、Exchange Server4.0和4.5、Internet Explorer 4.0和5.0、SQL Server 2000开发与测试工作陈宏刚博士尽管已经升任微软亚洲研究院商务及高校关系高级经理，但仍然对国内软件测试水平的落后深有感触。
国内很多企业还处在探索阶段，小企业的运作方式造成其主要精力是要尽快完成初始资本积累。有些企业也了解软件测试的重要性，很努力、很认真的在学，但因为很多原因而学不到精髓，不知道如何去做。于是只能局限于书本上学来的简单的黑箱、白箱测试而已。很多人知道有压力测试和性能测试，但针对产品具体如何去做就不清楚了。
陈宏刚表示，重视测试首先需要有开放性的软件文化，而在很多公司中，测试工程师只是绝对服从的听命角色，没有开发他们的积极性和创造性。一些管理人员对软件开发的流程管理经验不足，仍然用传统企业的方法进行管理，再加上对软件质量的控制理解不对，认为编完程序经过简单的程序员自己测试就可以使用了，而没有认识到软件测试是控制质量最好的方法。
不过，国内还是有一些大型公司和专业公司已经在软件测试方面走上正规。1994年开始接包IBM软件测试项目，1999年软件测试成为公司主体软件外包业务之一的和腾软件就是其中之一。因为客户就是IBM这样的大型软件公司，腾软件高级副总裁刘忠表示，它们在软件测试管理上，经同国外的公司相差不大，同时也研究和应用了多种软件测试技术。
软件测试工程师
一提到软件测试工程师，很多人就会想到那些反复使用软件，试图在频繁操作中寻找到错误发生的低层次人员或者软件用户。其实这是一种错误的概念，软件测试早已超越了用户使用来发现Bug的基本测试阶段。
陈宏刚介绍说，微软的软件测试工程师分为三种：测试执行者（Basic Software Tester）、测试工具软件开发工程师（Software Development Engineer in Test）和高级软件测试工程师（Ad_hoc Tester）
测试执行者负责理解产品的功能要求，然后根据测试规范和测试案例对其进行测试，检查软件有没有错误，决定软件是否具有稳定性，属于最低级的执行角色。
测试工具软件开发工程师负责写测试工具代码，并利用测试工具对软件进行测试；或者开发测试工具为软件测试工程师服务。产品开发后的性能测试、提交测试等过程，都有可能要用到开发的测试工具。对技术要求最强的是这些人，因为它们要具备写程序的技术。“因为不同产品的特性不一样，对测试工具要求也是不同的，就像Windows的测试工具不能用于Office，office的也不能用于SQLserver，微软很多测试工程师就是负责专门为某个产品写测试程序的。”
而Ad_hoc Testet属于比较有经验，自己会找方向并做的很好的测试工程师，这要求具有很强的创造性。刚进入微软时，老板也是只给陈宏刚一个操作流程，每天就按照这个规程去做，几天下来，一个Bug都没有发现。陈宏刚也很沮丧，觉得这样挺对不起公司，后来自己问自己：为什么非要这样做！于是换了其他的方法试试，令他吃惊的是，一下就找到很多严重的Bug，当时也不敢声张。有一天，他找到10多个非常严重的Bug，开发经理一下就惊呆了，怒冲冲的跑到陈宏刚面前问：“你是不是改变了测试方式和测试步骤？”陈宏刚有些吓住，说道：“可能改变了一点。”对方说：“我非常生气，但我不是生你的气，而是因为以前测试人员水平太差，或者以前的测试方面有问题，软件中有些Bug存在了半年甚至一年，但直到现在才发现，现在修补这些错误要困难很多！”后来陈宏刚得到了老板的赞许，可以按照自己的想法去做测试。对此，陈宏刚感受颇深：“一方面我体会到了微软非常鼓励创造的文化，同时也感到只遵守教条不是好的测试人员，就和用户一样了。做软件测试工程师同样需要开拓和创造性。”
在开发管理上，测试不应该归属于项目管理，也不应该归属开发人员。这三个部门应该是并驾齐驱，相互协作，测试工程师最终决定产品是否能够发布。
软件测试工程师的素质
因为软件测试仍然处在发展阶段，还没有上升到理论层次。对人员的评测，包括微软在内，都还没有一个统一标准，因此评定软件测试工程师只能根据工作实践进行自然淘汰。
软件测试对逻辑思维、学习能力、反应要求很高，是否有严密的思维和逆向思维也非常重要。陈宏刚介绍说，在五六个人的测试小组时，一半以上的Bug都是他找到的。他认为这同自己数学专业的背景关系密切，数学中有逻辑思维的培训，要善于找出来各方面的因素。比如要证明一个定理，各个方面都考虑到，一个条件不满足就无法证明；但如果证明其不成立，最常用的就是找到一个反例，只要有一点证明不成立就可以了，软件测试也是找这一点。
做测试还要考虑到所有出错的可能性，还要做一些不是按常规做的、非常奇怪的事。除了漏洞检测，测试还应该考虑性能问题，也就是要保证软件运行得很好，没有内存泄漏，不会出现运行越来越慢的情况；在不同的使用环境下，考虑软件的兼容性同样重要。软件测试同产品的规模也有很大的关系，因为软件的bug往往出在大型软件的连接处。
做软件测试工程师需要对软件抱有怀疑态度。这是因为开发人员喜欢想当然，总是找一些有利于自己程序执行的数据，有些开发人员甚至认为不利于程序执行的数据是对代码的玷污和亵渎。而软件测试却要策略性的准备各种数据，从每个细节上设计不同的应用场景，不去想当然的假定任何一个数据是可行的。
在职业素质和交际方面方面，并不是测试工程师爱挑别人毛病才好，反而这个工作要求很强的沟通能力。经常的和开发人员进行沟通，说话办事要很得当，不能指责别人，否则会事倍功半。性格随和才能和开发人员顺畅的沟通，对人和对事是完全不同的两个问题。
如何培养优秀的软件测试工程师
朗川软件测试工程师张建阳从北大力学系毕业之后，曾开发流体力学分析软件，软件缺少测试而产生的问题给她留下了很深的印象。后来去大唐电信做UIM（统一消息管理系统），她发现尽管公司为了鼓励员工找bug采取了很多奖励方法，但还是很少人愿意去做系统测试。而张建阳却从那时查阅翻译了很多国内外的资料，对软件测试产生了浓厚的兴趣。
像张建阳这样在工作中自己定位在软件测试领域的开发人员并不多见，因为程序员更愿意去做开发而不是测试，从大环境上，测试人员收入水平低也是原因之一。而在微软，测试人员和开发人员的工资水平是相同的。
如何改变这种现状呢？有人说可以可以派人去先进的国外软件企业学习，但这种方式因为牵涉到商业秘密，可操作性不大。陈宏刚博士认为更好的方法是引进人才，把在国外大型软件公司工作过、有经验的人才引进来，甚至要高薪聘请。他表示，这不仅仅是一个人的问题，关键是能够把整个软件测试的水准提高一个层次。
引进人才只是开始，更重要的是培养一批软件测试人才。软件开发的教育培训都是比较正规的，各个学校也都设有专业，但软件测试还没有正规的专业毕业生，而且没有评判的标准。陈宏刚博士给很多软件学院建议，开设四方面的软件测试专业基础课：软件测试基础、软件测试开发、高级软件测试案例和行业软件特色测试方法。国内现在已经有了一些软件测试基础的教材，但其他的教材还没有。高级软件测试案例主要是大型软件测试案例，大型软件出现的问题具有很强的代表性。而行业特色软件测试的课程可以开阔学生的视野。陈博士介绍说，在国外，也是极少的高等院校开设测试专业，但可以借鉴民间的培训机构课程。在有一批专业的测试人才出现之后，人们会认识到他们的重要性。
如果你已经开始从事软件测试工作，千万不要认为软件测试没有什么发展的潜力和前途。刘忠从1995年接下IBM的OS2汉化版本的测试开始到现在，他一直工作在软件测试领域，并升到了公司高级副总裁的位置。和腾软件也培养了一批测试工程师，它们从对测试职业将信将疑到明确自己的测试方面的职业目标。刘忠介绍说：“很多人开始做测试执行工作时会说很麻烦、很枯燥，只是一味的埋怨，而不是主动的去学习，他没有看到软件测试背后所隐藏的知识。因为学习可以做这些工作，不学习也可以做这些工作，但质量是不同的。有些人自学和请教了很多测试技术和管理方面的知识，公司自然就会在下个项目中去培养他。”
因此对于一个新手，要在各方面培养自己的能力。首先是要理解各种测试流程，并在理解的基础上转化为自己的知识，以后遇到相似的问题能自己去解决。在测试技能上，要知道测试有那些手段，比如压力测试有哪些方法，哪些工具可以辅助做测试。从专业技能上，面向不同的技术方向，像操作系统、网络、通信等都要从专业上深入了解。这三方面要同步去成长。
软件测试工程师未来的发展
从事软件测试有没有前途，未来的职业发展方向怎样呢？
陈宏刚博士表示，软件测试工程师在微软的发展有几种途径：一种走技术路线，成长为高级软件测试工程师，这时他能够独立测试很多软件，再向上可以成为软件测试架构设计师。第二种就是向管理方向发展，从测试工程师到组长（Lead），再到项目经理（Manager），到更高的职位。第三种可以换职业，做项目管理，做开发人员都可以，很多测试工具软件开发工程师在写测试软件的过程中，因为开发方面积累了经验，同时对软件产品本身产生了自己的看法，很容易转去做产品编程。
陈宏刚博士现在还带着一个测试小组，两个清华软件学院的学生，一个南开的专门做软件测试的博士生，一个北邮的学生，他们负责总部一个产品的测试。陈博士表示，在自己简单的讲讲思路，共同探讨之后，他们一星期就找出了70多个Bug，也感觉学了很多知识，并表示以后专注于软件测试专业，因为他们感觉软件测试真的是一门很深的学科，有很多可以研究的课题。其实微软的测试人员很多也都是硕士、博士，他们同样在做创造性的工作，保证着程序质量，推动着软件的进步。
软件测试是正在快速发展，充满挑战的领域。尽管现在单机版桌面软件的测试已经成熟了很多，但对于网络时代的到临，包括微软在内的公司对基于网络的测试也没有一套完整的体系，也是处于探索中，网络中被攻击的可能性太大，这就是为什么黑客在网络上能兴风作浪的原因。网络测试是一个新环境，而且是很大的挑战。
软件测试未来的发展空间很大，软件测试工程师的职业之路同样充满希望。
李维谈软件测试
记者：台湾的软件测试工程师的地位如何？
李维：就我知道的几个案例来说, 地位很低。许多公司不是没有专职的测试机制，就是老板认为不重要。许多老板还认为直接让客户测试即可，实在不可思议。
记者：测试工程师的人员比例也很小吗？
李维：是的, 大概6－8位工程师配一个测试人员，不过有的是以产品线来分的。
记者：台湾有专业的测试培训教育吗？
李维：据我所知, 沒有。
记者：依您的看法，软件公司如何才能重视软件测试呢？
李维：台湾国际级的软件公司如友立、趋势才重视测试。如果是短视的软件公司，由于许多老板不是资讯出身，所以不了解软件工程的重要。要重视软件测试，负责研发的头头必须有明确的认识。许多软件人员知道使用OO或者SD的方式设计软件，却不知对于测试也同样的需要事先设计并规划测试计划，这实在好玩。
记者：borland公司测试人员情况如何？
李维：Borland有不同的测试人員, 针对不同的产品。专职的测试人员大约有50－60人，测试人员占研发人数的30－40%。Borland的测试人员都会规划测试计划，同时有系统和回归测试。 -
新手做测试需留心（转）
2008-12-13 15:56:09
当你刚被聘用到一个测试小组时，作为新手，可能你应该按别人指定的测试计划执行测试。这并不是说你没有能力制定这样的计划，而是别人制定的测试计划可能比你的好（这是一个公认的事实）。按别人的计划执行，并记下那些可以用不同方式完成的部分和优秀之处。用不了多久，你就有自己作主的权利了，最开始要从你负责组件的测试计划作起。充分利用你的笔记和经验，这有助于你在第一次就能够写出一个高效、专业的测试计划。
当你在执行其他人的计划时，你可以考虑另外可尝试的测试用例。有一些可能不适用，但对于软件其他部分仍是好的测试用例，只是不是你负责的而已。不要低估自己作为测试人员的能力，要相信自己也能发现好的测试用例。
制定测试计划时应该考虑可用的资源和需要组织涉及参与的活动。不管是低级别的计划还是高级别的计划，都需要详细地规定工作的责任人、各人的工作任务，以及任务完成的时间。没有经过彻底交流过的计划是不可能有效的。最无效的计划就是那些没人知道其存在的计划。 -
测试工程师之“十二最……”（转帖）
2008-12-13 15:45:54
01.测试工程师最开心的事:发现了一个很严重的bug,特别是那种隐藏很深,逻辑性的错误.第一次发现这种问题的时候,听到上司和开发人员的表扬时,高兴的就想扭pp.不过现在慢慢矜持些了,呵呵.
02.测试工程师最提心吊胆的事:版本release出去后,客户发现了很多或很严重的bug.经过紧张的系统测试之后,好不容易可以轻松一下了,却又陷入了每天担心正在做验收或使用的客户一封邮件或一个电话说产品有问题.碰到好些的老板还会比较乐观的看这样的问题,最惨的就是有些人一顿臭骂,之前的辛苦,加班全部都给抹杀了.
03.测试工程师最憎恨听到的话:"为什么这个bug没有在测试的发现呢?"这句话经常是客户发现bug后,老板对测试人员的质问.当然这里排除那种很明显的错误.其实谁都知道bug是不可能全部发现的,这句话其实也是客户对大头,大头对小兵一级一级问下来的.除了希望测试人员警惕之外,还有更多的是一种"踢猫"的行为.对于这句话,第一次听到这句话的反映是"我们怎么可能发现所有的bug呢",后来变成"制造bug的人不是我们,是开发",到现在的"让我查查我的日志,问问开发这个bug的原因,为什么我们会没有找到,下次我们会怎样"的回复.
04.测试工程师最郁闷的事:"刚才那个版本打包打错了,你们要重测".新版本来了,马上投入紧张的测试,希望能够多找些bug.没想到辛苦了可能大半天,开发人员说打包打错了,你重测吧.这种情况虽然可以通过规范流程之类的办法控制发生的机率,但人总会犯错,多少而已.碰到这样,你除了提醒开发部门下次注意,你除了重测没有太多办法.
05.测试工程师最不想面对的事:在测试晚期或最新的版本里发现了以前一直存在的问题,特别是当问题很严重时决定到底报不报bug.报吗,开发人员肯定会问以前有没有这个问题,不报吗,客户发现更惨.毕竟客户或老板的责备比开发部门或主管的责备轻许多,最后还是会报到bug库里的.
06.测试工程师最不想做的事:申请版本推迟发布.由于在版本发现了太多的问题,觉得产品不能达到发布的标准,建议公司推迟发布产品.这时虽然大家都知道产品有问题,尽管你自己也不希望这样,但谁都觉得你是一个制造麻烦的人,毕竟市场的压力很大呀.
07.测试工程师最丢人的事:辛苦的发现了一个bug,居然是该配的参数没有配等一些自己的失误造成的.有些该注意的地方居然测试时忘了,找出的问题给开发人员一顿臭扁,无比丢人啦.
08.测试工程师最怕的事:一天,甚至几天都没有发现一个bug!经过一段时间的bug高峰期后,有段时间会发现bug数量的减少,最可怕的就是一天都没有发现一个bug.有时会难过的吃饭都没心情.搞得开发朋友说了一句最让人吐血的话:"要不要我在代码里放几个bug给你呀,hoho"
09.测试工程师最伤心的事:每年的调薪,发bonus或发股票时,测试工程师总比开发工程师少.一同事在调薪的第二天就申请转开发,说测试太没前途了.
10.测试工程师最有力的保护方法:把你认为是bug的问题都提交到一个正式的,可以追踪的地方(一般来说是bug库).有时总会碰到一些很小的或是很难判断的问题,犹豫一定是否要报,特别是一些UI的问题.有时问开发人员,他们可能会轻描淡写的回复你导致你没有report它.但多年的经验一定要报,了解bug流程走向的人都知道,后面还有人verify,还有开发经理判断,如果不是bug,自然他们会回复,会写明原因.说白了,出了问题也不是你的事情.当然一开始经验不足时会收到一些白眼球,但慢慢经验多了,对系统熟悉了,自然这种情况会少些.人也可以从一些问题中发现自己的弱点.但如果不报,那天客户提出来,你除了懊悔还要面对指责,严重的炒鱿鱼.
11.测试工程师最任重道远的事:测试驱动开发.碰到这种开发模式的项目,既是测试扬眉吐气的机会,也是可能会陷你于深渊的恶潭.你就必须打起十二分的精神.等于你在引导开发,有什么问题一定要提出来,否则你就等着被盲目的牵着鼻子走了.
12.测试工程师最期待的事:测试能够越来越受重视,测试工程师的考核越来越合理 -
给初学软测的新人几点建议（转贴）
2008-12-13 15:38:35
看到越来越多的新人加入到测试的行业当中是一件欣慰的事，这也说明测试作为一个新兴行业正在不断发展，相较于软件行业中的其它职业――例如软件开发，测试行业还显得比较稚嫩和混乱，人员水平也是良莠不齐，我想就个人经验谈几点看法。
1.从何入手？
刚开始接触测试，头脑里面还没有什么概念，心里也没底，不知道测试到底是做什么，怎么做。对于这样的朋友我建议可以先看看各种各样的文章和随笔，先把眼界拓宽，了解测试中有哪些相关概念，接触得越多越好，这样才不至于思维狭窄坐在井底就以为看到了整个世界。初期阶段我不建议匆匆忙忙去看一些测试书籍，因为书籍主要是理论性的抽象，对于实际工作指导作用不高，而且这时候还缺少基本的判断能力，很容易被一些过时或者滥竽充数的书籍所祸害。打好基础以后，再找些有针对性的书籍来深入学习效果会更好。
2.没有编程经验可以做测试吗？
很多人问过这个问题，那么有没有想过什么不学习编程呢？做测试编程经验并不是必须的，在开始测试的初期阶段。但是想要做好测试，专业化测试，那么编程技术你就必须当作一项基本技能来掌握。试问如果对软件的内部结构不清楚，又怎么可能会很好地知道产品如何工作呢？小时候我们对闹钟很好奇，可能就会打开它再把各个零件拆下来仔细研究，如果没有动手拆卸的勇气而只是抱着闹钟在那里呆呆地看着，就很难知道闹钟的工作原理。国外很多的测试人员都是在做了多年的开发之后转换过来的，国内由于一些特殊原因，测试工作常常交给一些新手去做，而且还有一种“重女轻男”的说法，一直没搞懂是为什么。
3.充分利用互联网
Internet是我们最好的老师，你所需要的一切都可以在这里找到。在测试领域没有笨蛋，只有懒汉，你没有别人做得好不是因为你天资不够，而是你不如别人努力。大家如果遇到了什么问题应该积极在网上寻找答案，国内的几个论坛如果不能帮你解决问题的话，一定要勇敢走出去，到国外的一些论坛和网站去找寻答案。基本上一些商业工具供应商都有一些专门的顾问和技术支持人员活跃在一些大型论坛和官方网站解答各种问题，对于所有的提问都是一视同仁耐心解答。
4.面试注意事项
找工作的时候除了充分表现自己以外，也要注意观察面试的公司。一般来说面试都会和你以后的直接领导有所接触，留意他的问题，因为好的问题有时比好的答案更重要。从提问的技巧可以看出你的领导有多少斤两，如果遇到一个无知的领导那么可要慎重考虑这份工作了。那么如何判断呢？如果他的问题基本都是泛泛而谈，那么很可能这人对测试理解不深，相反，一个资深的测试人员问题很有针对性，而且可能会根据你的答案提出新的问题，而不是像考试一样一二三条这样死板地问下来。总而言之，你在找工作的同时，企业也在招人才，所以面试时要保持平常心，如果希望了解多一些不妨主动提出一些问题，看看对方如何回应。
