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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

项目组规定本周六、周日加班，开始新一轮的版本测试，时间为9：30-17：30。我来公司一年多以来，最多只是周六加班，周六、周日一起加班的情况还没碰到过，不过既然有规定，那我就得执行。我是项目新人，所以今天早上我很早就往公司赶，到了之后却发现办公室没几个人，更诧异的是，测试负责人说，版本今天出不来！

听说版本出不来的原因是有几个开发人员没有及时改完BUG，所以系统暂时不能集成，明天中午才能出版本。这个情况对项目进度来说是一个不好的消息，但对我来说是一个难得的喘息机会。我转进项目组的第一天就被要求开始测试，而这时我连系统、界面是什么都不清楚。过去的一周我是昏昏噩噩过来的，整天在执行一些不清不楚的用例，提交日报，都快崩溃了。现在我真的感觉很好，因为终于停下来了，我有时间查看需求、详细检查一下用例了。下周，我需要好好计划一下，不能这么无序了。

但愿，下周测试进行得好些！

刚到一个新的项目组，东西刚搬下去，我屁股都还没有坐热，就开会说要加班了，而且就从本周开始。现在项目处于集成测试阶段，为了尽早提交一个稳定的系统测试版本，所以测试人员得加班加点、保质保量。集成测试阶段总共有两周时间，划分为三个阶段，大约5天为一个阶段，强度可想而知，所以刚召开的那个会议也叫动员大会。

其实所谓的集成测试并非真正意义上的集成测试，其实质就是系统测试，只是为了满足系统测试准入条件而往前提了。和我前一个项目组做的集成测试差不多，只不过当时是都由开发人员自己做，而现在则是由开发和测试一块做罢了。哎，那么多外国好的概念、流程，比如集成测试、测试驱动开发，为什么到了中国就变味了呢？！

无所谓了，做IT的，尤其是做研发，不管哪个阶段，加班都是家常便饭。不管它是每周晚上都加班，还是周六、周日也加班，慢慢加吧，反正做测试的我们都习惯了！

在公司软件测试人员很少，甚至没有测试部门的时候，测试人员只是开发人员的一种补充，不需要对软件质量负全责，所以也就没有太多的担心，但是当有了独立的测试部门，软件测试人员越来越多的时候，情况就不一样了。这个时候，公司的大部分人都认为测试部门应该为软件的质量负全责，如果用户那边出了问题，那就是测试部门没有测试好。于是，测试人员就一直战战兢兢、如履薄冰地做着测试，生怕出现问题，所以就产生了很多的担心：

1、担心测不出BUG。

软件被认为是无论怎么样测试都会存在问题的，所以说，大家都认为只要去测试就一定会发现BUG，你也这样想。可是，当你对分配给你的模块进行了长时间的测试之后，你仍然没有找到一个BUG。于是，慢慢的，你开始怀疑自己的能力；慢慢的，你开始担心你的考核；慢慢的，你开始质问你自己，为什么找不到BUG？慢慢的，以后你再做测试时，刚开始你就担心自己找不到BUG。

其实不用这样担心，即使测不出BUG也不能说明你的工作做得不好，至少，你已经证明了软件在一定程度下是正常工作的，而软件测试不仅仅是找BUG。况且，很多时候你要测试的模块已经经过了其他同事多轮的测试，或者这个版本它没有任何变更。当然，也不是没有可能测试出BUG，那就是多考虑环境，多考虑方法，保持耐心，这样的话，一定可以找出BUG来的，要相信自己。

2、担心别人在自己已测试过的模块中测出BUG

在现实的测试中，常常使用交叉测试的方式，也就是让测试人员共同测试某一个模块，当一个测试人员测试完成后再让另一个继续测试。很多情况下，另一个测试人员都可能再发现一些该模块的BUG，而之前的测试人员没有发现。所以当我们把模块让另外一个人测试的时候，常会担心再发现BUG，因为我们觉得这是我们没有测试好的缘故。当他提交BUG的时候，我们常会拍着自己的头责备自己说，为什么我就没有测出来。有时甚至人家会这样说，“连这么简单的BUG你都没测出来！”，让人感觉很难受，很难堪。

交叉测试的本意是让不同的人从不同的角度、不同的方法来测试软件，从而找出软件更多的BUG。人和人都是不同的，想事和做事方法都可能不同，有的时候我们都会觉得对方有些不可理喻，但反过来说，对彼此来说也是一个有益的补充。有时候我们可以从别人提交的BUG中得到某种启迪，使自己想问题想得更全面，找出更多的问题。所以，再测试出问题没什么的，很正常，你只需要拍一下他的肩膀，笑着说一声，“谢谢呀，我怎么没想到呢！”，那就可以了。

3、担心BUG不能重现

不能重现的BUG是不能提交变更管理库的，也就意味着我们测试人员的劳动没有成果，所以很多人都在发现BUG之后担心不能重现，尤其当开发人员一直要求重现的时候。这种情况常有，因为有些BUG必须在一定环境中、特定的操作下才会出现。遇到这种事情不要慌，回忆自己操作的每一步骤，分析可能的问题所在，甚至有时可以借助键盘记录器这样的软件来帮忙。如果不行就寻求开发人员的帮助，或者先放一放，之后再好好想想，很有可能它就重新出现了。

4、担心软件在用户侧出现BUG

软件发布了，软件测试员的心也变得更加脆弱，更加担心用户侧出现问题。测试人员总是这样，对事务要求完美。其实呢，软件是不可能没有BUG的，只是没有测试出来罢了。软件测试的任务是尽可能找出软件的BUG，然后修复，并不能保证软件没有BUG。软件测试人员不需要为质量负全责，也不可能负全责。

5、担心自己写的用例、报告无法通过评审

很多人，在刚开始写用例的时候，有时并不是因为难写，而是担心自己写不好，老大批评，没法通过评审。这也是很正常的，尤其是刚开始写的时候，不过写多了就好了。不要担心自己描述有些不清楚，不要担心自己考虑问题不够全面、不要担心自己写得是否符合要求，因为评审是来帮助你的，大家集思广益来帮忙把事情做好。很多时候，你会发现，自己写的还不错！

6、担心BUG是否真的被修复了

我们常常担心开发人员是否真的把BUG给修复好了。因为有时候，从表象来看，确实感觉BUG好像没有了，但实际上呢，未必如此。为了减少这种担心，首先我们应该给BUG找到必现的手段，这样验证起来就方便多了；其次我们应该全面细致地分析BUG，找出它出现的真正原因；最后就是详细的测试，而不是随便一测就算验证通过了。

7、担心做测试没有前途

这种担心也常有，尤其是大多数都做黑盒测试的我们，感觉工资、待遇都没法跟其它人比，感觉没有前途。说实在的，不要担心，软件测试是一个做得越久越吃香的行业，所以我们就慢慢做吧，学得更多，积累更多的经验，慢慢的，你就知道做软件测试是有前途的。

进入软件测试行业快三年了，尽管我还只是公司普通的一个测试人员，也算尝到了做软件测试工作的些许滋味。这些滋味虽然凑不上百味，只有少少的几味，但因为是亲自品尝，以致感触颇深，常想一吐为快。当然，这只是我一家之言，如能博得几分同感，那将是我的幸事，在此先谢过。以下我将与诸位分享我做测试的滋味人生，测试的滋味：

1、 烦闷的滋味

大家都知道，做软件测试的目的是尽可能多的找出软件的缺陷。对于没有接触过软件测试的人来说，他们会觉得这很容易，点几下鼠标就出来了，可实际上不是这样子的。测试人员要测试的软件往往经过了前一阶段人员多轮的测试，最不济也由开发人员自己测试过一遍了，想从这样的软件里找到缺陷，常常是“鸡蛋里挑骨头”，谈何容易？！可我们还必须找出问题来，于是我们设计众多的测试用例，包括功能、性能、安全等等方面的用例，一轮又一轮地执行它们来测试软件，用通俗的话来说就是“把软件往死里整”，可实际上我们没把软件整死，却被软件给整死了。每天我们的工作就是执行那众多的测试用例，好像总也执行不完；每天我们的工作就是找软件的缺陷，好像总也找不到，只是不停地在测试、测试。。。。。。一个星期下来，我们看着那众多未执行的测试用例，再看看变更管理库自已提交的故障单，感觉这个星期都白干了，哎，郁闷呀！

2、兴奋的滋味

当然测试工作也不只是枯燥，只让人品尝烦闷的滋味，有时它也会让你兴奋的，这便是当你发现故障的时候。测试了那么久，执行了那么多的用例，想了那么多的方法来折腾软件，终于发现故障了，哈哈，太高兴了！赶紧把开发人员找来，用邮件或者电话的方式，当然电话告诉他们最好了，不过，这个时候我们别得意忘形，尽量用最平和的语气，心里高兴就行了，因为有时开发人员并不乐意看到这样的表情或者听到这样的语气。

3、失望的滋味

当发现了故障，诚然有我们高兴的时候，但也有让我们失望的时候。比如你发现的故障在两个小时前就被别人提过了；比如开发人员经过调试以后发现这不是一个故障，功能表现很正常；再比如是你操作步骤有误，看错了现象。。。。。。这种情况很多，也比较容易让我们本已经很疲惫的心再次被浇了一盆冷水，冰凉冰凉。

其实这也很正常，连微软的测试同行们都在拼命抢BUG，所以没事的，努力测、仔细测、快速测，很快就可以提许多的故障了。

4、惊喜的滋味

有道是“踏破铁鞋无觅处，得来全不费功夫”，测试过程中也常有得到大礼的时候—比如空中忽然掉下个大BUG，而且是M1级别的！很多时候，我们测试的死去活来都没有找到一个问题，嘿，突然系统里就多了一个core文件，一查，原来是系统模块异常退出了。呵呵，真幸运呀，提个CQ先！

当然，不是每天都掉BUG的，不劳而获的思想我们不能有，我们只能把它当作上天送给勤劳的测试人员的一个小礼物，仅此而已。

5、恼怒的滋味

发现了故障，也已经确认这是一个故障，但开发人员却死活不认为是故障，回个邮件跟你说，需求里没有说，没有定义。需求没定义就不是问题了？其实这只是一个很简单的问题，开发人员处理起来很简单，改几行代码就可以了，但可能因为考核或者工作量的原因，开发人员不愿意改。这种事情有时很让人恼火的，尤其是私下里沟通未果的时候。我们常常会碰到这种问题，大家基本上都是对事不对人，实在不行，就转交给上司来判断，再不行就由项目CCB或者产品CCB来决断，不要觉得不改问题也无所谓，因为我们的职责是发现一个故障，解决一个故障，这样才能给最终用户一个好的软件。

6、无奈的滋味

大家也常常碰到自己提交的故障最后被CCB拒绝的情况，不知道大家感受如何，反正我有时觉得挺无奈的。当然，拒绝故障可能是因为CCB认为投入比产出大，或者是因为不影响使用，但对于故障提交人来说，总是感觉有些不爽。我常常会在提交一个故障之后的几天里多次查询该故障的状态，看一看是不是被拒绝了。如果看到状态为“被指派”，则感觉良好；如果看到“被拒绝”，则有种没有被人承认的感觉。虽然CCB也会在拒绝故障之前跟你沟通，但很多时候尽管你力争，还是被拒了，让你感觉有些不好。

7、感动的滋味

前些天因为给其它项目组提交了一个故障，人家不承认，准备拒绝，跟我沟通。其实也不是说沟通，因为都准备拒了，我把邮件转发给了我的老大，看看他的意见。许久没有看到他的回复，于是我就回复邮件给那个项目组的人，拒就拒吧，于是就被拒了。没想到5分钟后老大从四楼跑到六楼跟我说他刚开始没看到邮件，说我为什么不顶回去？哎，感动中。做软件测试，有一个支持自己的人不容易呀，因为很多时候，测试人员都与开发人员不太对等，话语权都掌握在他们手中。

8、无助的滋味

2006年我临时作为技术支持人员到用户现场做技术支持，期间因为贫血的缘故，眼花、头痛，在操作设备的时候差点就倒了下来，但还是坚持着完成了任务。那个时候就一个人，很无助，谁也帮不了你，只能靠自己，现在想来挺难受的。其实哪一份工作都是这样的，碰到问题就努力解决，也不是什么大不了的事情。

9、难过的滋味

人最难受的是不被人理解，做软件测试也是一样。软件测试有时被定义成了软件的破坏活动，在有些开发人员的心里，测试人员是找碴的，是有些病态的一群人。软件测试只有投入，从现象来看，没有产出，测试人员的价值无法完全体现出来，所以也被认为这样也算正常。记得以前有位开发经理冲我喊道“这样的问题为什么没有测试出来？你们测试人员是干什么的？”，当时感觉很委屈的，如今想想，也算不了什么，只能说他的质量认识只到了那一层次，我也不想反问“这个软件你们是怎么开发出来的？”。

上个月，我被评为了质量标兵，二等奖，感觉挺好的，不只是因为奖金，更因为我的工作被人理解了，看重了。

10、抓狂的滋味

不知道你是否还记得你的第一个测试用例是怎样写成的？不知道你是否还记得你出的第一份测试报告？我还记得，那种滋味怎么说呢，对我来说，就是抓狂。我很奇怪，为什么执行别人的用例时总说别人写得烂，可自己要去写时，却不知道怎么描述、怎么措辞；为什么有测试报告的模板，甚至有一部分可以直接从TM直接导出，可写起测试报告来为什么还那么难？

其实写多了这些文档就不会这样抓狂了。不要怕麻烦，多写写，对开阔你思考问题的视野、锻炼找BUG的能力都是很有好处的。

11、担心的滋味

这种滋味，或者说这种心情，其实是一直陪伴着我们的，尤其是当软件已经发布后。软件测试是一个有风险的工作，因为它不可能把软件测试彻底，最终用户有太多各种不同的环境，所以尽管软件版本已经发布了，仍然会在用户那边出现许多故障。做测试的我们，总认为经过我们测试的软件应该没有问题，如果在用户那边出现任何一个问题都是因为自己的错误导致的，于是开始担心，担心用户那边会出现问题。当听到用户那边出现故障时，作为测试人员的我们一般都会感觉很难受、很内疚。其实没什么的，我们只需要尽我们的能力去做好测试就可以了，因为好的软件是设计出来的，不是测试出来的。

12、。。。。。。

还有许多的滋味，没法一一表述，如果你想知道，就来做软件测试吧，它会给你切身的体会。

   经过半年多的系统测试和转产测试，我们的网管软件终于在昨天通过了设计定型评审，要发布了。这个版本，包括4个大版本和3个小版本，经过我们测试人员日夜不停的迭代测试，终于要发布了，真不容易呀！想到这里，我不由地把心中的一块巨石放了下来，长吁了一口气，是啊，终于完了，总算可以休息一下了。

    昨天的评审，评委包括质量、市场、用服和工程部门的一些相关人员，主持人还是质量部那位兄弟，不过感觉参加会议的人员似乎比以前少。会议的过程相比上一次而言有些精简，直接去掉了测试经理宣讲测试报告的环节，直接到预审意见答复及评审，然后就是给出评审结论，评审结束。整个评审会议只持续40分钟就结束了，很快，我想，应该是老大们都很忙吧。这次的预审意见重点关注的还是那些严重的遗留故障，提的问题很有针对性，不过语气都不尖锐，项目经理一一给了相对合理的答复意见，就很快被接受了，通过。这一次，说实在的，我感觉有些走形式，心里有些失望，虽然我同样希望评审通过，但质量部那位兄弟上次尖锐的问题就见不到了，哎。

    一切为了考核，虽然我们的版本质量也不错，也算正常吧。如果评审不通过，不出版本，项目组人员的绩效从何而来？开发人员、测试人员的工作怎么体现？。。。。。。这些都是要考虑的问题。不管如何，在这漫长的测试过程中，我尽到了我测试的责任，这就可以了，其它的就不要管了。

    当然，评审通过了，版本发布了，同时也意味着新的测试任务即将到来，我所想要的休息看来是不可能了。果不其然，就在评审会议完结之后，科长告诉说我们将被调去一个新的项目组，算是提前介入测试，下个星期就要参与进去。我听说那是一个新的项目，比较忙，项目人员需要常常加班。算了，到哪都是工作，努力做事就是了，休息，永远都是将来时。

    正所谓，生命不息，测试不止！测试，我们一直在路上。