来ERP2项目组之前，我便在智能交通领域这片广阔的海洋中，苦苦挣扎了两年时间。期间，虽然呛了不少水，有过教训，但同时也积累了经验，学了不少东西。或许是曾经有过这样的项目经历，刚进项目组，便有幸成为负责稽查设备测试的小组长。初期的时候也就一光杆司令，只能被管理。后来，我们小组成员增加到三人，虽然人数不多，终究手底下也有兵了。那么测试管理又如何在测试团队中实施的呢？

　　首先是管理人。如何管呢？这个我要说只能是靠制度了，经过多年的沉淀，公司有一套相对完善的开发测试控制流程。具体点说，团队成员每天必须写日报。这种方式的缺点是，时间长了真的很烦，有种被监视的感觉。可是又没办法，谁让这是重点项目呢。优点是，由于每天都要汇报工作，所以几乎没有人偷懒。

　　除了日报，还得写周报。我做为测试的小组长，除了周一分配工作任务外，周末还要汇总团队成员的周总结，总结测试小组上周的工作进展和遗留问题，然后汇报给测试经理。

　　当然，周例会也是不可少的。团队的每个成员都要做汇报，重点总结上周的工作成果。对于遗留问题，大家有针对性地一起讨论，定一个解决方案。这种方式能起到好的督促作用，而且对管理的效果也起到了直接检验的作用。       

　　每个人都是一座宝矿，这话一点不假。尤其是对测试团队来说，成员来自不同的公司或部门，有不同领域的从业经验，每个人都有独到的地方，有自己的优点。为此，团队建立了内部培训机制，以便于团队成员之间优势互补。这种管理方式也算是对公司现有制度的一个补充。这种方式的最大优点是轻松自由，毕竟隔行如隔山嘛，即使有些术语听不懂也没关系，成员之间经过交流探讨，加深了了解，增进了友谊。      

　　另外一个补充，是后备领导培养机制。这个项目，由于工作关系，测试经理需要经常出差去国外，讨论关于需求和测试方法的问题。出差期间，测试团队怎么能群龙无首呢，这就需要一个临时领导，管理整个测试团队。虽然我没有被选中，有些沮丧，但同时也发现了自己能力的不足，那就向别人学习吧。后来证明这种机制是明智的，使得整个团队能够有序运转，团队成员的工作也没因为测试经理不在而受到影响，实现了无缝管理。   

　　加班，是每个做项目的人都会经历的过程。除此之外，提高单位时间内的工作效率也是测试团队成员追求的目标。之前提到的临时领导，也是因为他能合理安排时间，工作效率高，而深得测试经理的器重。有次还在会上表扬他，今日事，今日毕，是我们学习的好榜样。在他的影响和带动下，大家也都尽量在下班之前结束一天的工作。由此看来，树立典型是管理好时间一个行之有效的方法。

 　　还有一种方法也是实践中总结出来的，不做重复劳动。可真是说起来容易，做起来难。内部测试开始后，团队成员用邮件的方式整理BUG，并汇报给开发人员。后来公司QA要求测试团队使用CQ，团队成员可能也是考虑到邮件的方便快捷，仅把之前的BUG都提到CQ上去，但同时也保留了使用邮件汇报BUG的方式。这种不规范也不专业的BUG提交方式，立刻引来了项目副总监的注意。他转发了QA的邮件，要求使用CQ的方式提交BUG即可，没必要使用邮件方式汇报，这样也就避免了重复劳动。我们这才完全放弃了使用邮件汇报BUG。这件事印象深刻，幸亏问题纠正的早，如果按照之前的工作方式，我们又需要花不必要的时间。

 　　本文结合实际项目从人、时间和资源的角度浅谈了实际工作中的测试管理，希望能藉此抛砖引玉，与大家探讨交流测试中的管理学。　　

 

　　本文收录于《51测试天地》电子杂志第三十一期

　　

　　查看全文请点击下载：http://www.51testing.com/html/88/n-853288.html

 

 

　写测试用例简单,写好测试用例难,写得让客户满意就更难了。这句话在ERP2项目中得到了完美无瑕的验证。如果说这个项目有哪些事情给我留下刻骨铭心的记忆的话，那么编写测试用例便是其中之一了。同事们苦笑，这堪称史上最让人纠结的测试用例。为什么纠结呢？如果用三个字概括，就是长、多、严。
　　长。用了半年时间写测试用例，你可能会觉得惊讶吧，可能会说这是什么鬼项目，居然用了那么久，放在我们公司早做完两三个项目了。连我自己也觉得不可思议，细细想来却又在情理之中。这其中，不光是因为项目确实庞大，还有我们自身的原因，和客户的原因。
　　就我们自身而言：写用例的风格没有及时统一，写出的用例千人千面；对字面上的测试需求没有理解透彻，这也是和老外沟通渠道不畅造成的；前期系统设计一直没有定稿，其间，又修修改改，使得测试用例也跟着在变动。有件事情记得比较清楚，由于前期系统设计的不确定性，测试用例编写也受到严重干扰，到底是写还是不写，如果写的话，连设计都没确定，又怎么能得到确定的期望结果呢?可是，如果不写的话，又影响测试用例编写的进度。两难之际，老大拍板，写！就是让我们依照原有的设计，或者按我们自己的设想编写测试用例。虽然这样做给之后测试用例的修改增加了负担，但也是个没有办法的办法，测试用例的提交是有时间节点的，为了能准时提交测试用例给老外审查，心急火燎下不得不这样做，很无奈。
　　就客户而言：没有及时提出合理的测试模板，没能及时限定测试用例的包含的项目；客户对测试用例的要求过于简单或概括化，前期没能给出一个测试用例怎样写，及写到什么程度的Checklist。这使得工作开展较为被动，我们也在绞尽脑汁揣摩老外的心思，究竟怎样写才能满足人家的要求。字面上的要求是这样的，从单元，到集成，再到系统，均用英语写测试用例，不仅要做到各个阶段的测试用例覆盖面全，还必须做到测试描述易于理解，可操作性强。不容许出现模棱两可，似是而非的描述。
　　话虽如此，实际做起来难了。比如，测试用例覆盖面全这条，需要考虑系统在各种交通场景下的情况。要知道，各种交通场景指的是新加坡不是中国。当时就傻了眼，新加坡咱也没去过啊，国内和国外又是两套不同的交通规则，所以，一开始用例写的也是惨不忍睹。后来，去了后才发现，在新加坡，摩托车也是可以在高速路上驰骋的，在小轿车和大型车之间来回穿梭，就像鱼群一样，很有特色。再比如，描述易于理解这条，实际上客户的意思不仅是要字面上描述清楚，而且要能“看”得到，也就是图文并茂的意思。或者说这算是客户隐性的需求，诸如此类的要求，也是后来在和客户经过几次交锋之后，我们才弄清楚的。
　　多。 有两层意思，编写的测试用例多；修改的次数多。
　　测试用例多。多到连我们自己都在怀疑，这么多测试用例，将来在新加坡测试场在限定时间内能执行完吗？！实际上，测试用例编写也经历了从无到有，从少到多，从多到精的阶段。尤其是最后一个阶段，在删除了重复，不可执行的测试用例，以及合并了一些测试用例后，测试用例的数量仍然很可观，但已经是经过压缩，千锤百炼后的结果了。
　　修改的次数多。每次修改的原因也都是五花八门，有种想吐的感觉。有时因为测试步骤不详细，重写；有时因为测试场景不丰富，重写；有时因为没有图例说明，重写；有时因为测试步骤冗长，重写；有时因为拼写，标点符号错误，重写；有时因为测试用例写重了，重写！一次又一次的修改，以至于大家见面语都变成了，今天你用例改好了吗？晚上下班，抬头仰望星空，真想对上帝大声说，Please take me away。
　　为了避免反复修改产生的视觉疲劳感，也为了更好的发现测试用例的错误，每次提交测试用例前都要在组内开展交叉检查活动。就是组内成员互相检查对方写的用例。这个方法很有成效，也确实帮助我们发现了自己发现不了的问题，也相对减少了用例修改的次数。
　　严。说的是新加坡政府公务人员工作态度严谨，细致。每次我们怀揣着忐忑不安的心情提交给客户审核后，就是焦急而漫长的等待，等待客户的反馈。这种感觉更像是一个交考卷的学生的感觉。客户几乎每次都能不厌其烦地找出他们认为不合适的地方，即使连一个标点符号也不放过，至于拼写和语法错误更是他们无法忍受的，像是在拿着放大镜仔仔细细鉴赏着一件工艺品。最后，客户反馈的Checklist，是一份长长的修改清单。
　　经历十多次的修改，换来的是逐渐变短的错误清单，直至客户最后说，恭喜你们，测试用例审核通过！那时，我们才终于有种解脱的感觉和淡淡的喜悦。我们努力过，付出过，虽然很艰辛，但是很值得。
　　纵观整个测试用例阶段，小水滴感觉英语真的很重要，如果英语不好的话，就会在阅读客户邮件或手头的需求时理解的不透彻，在编写测试用例时就会犯拼写、语法、句法错误；其次团队协作精神也很重要，要时时对对负责其他子系统的成员在编写测试用例时提供有效支持；最后，是有效沟通，尤其是与海外客户要能保持良好的沟通，才能得到客户真实的需求。
　　声明　:　本文只代表个人观点，不代表公司观点。

　2007年4月入行，掐指算来，在测试行业里混迹将近7年之久。回首过去，虽未经历大风大浪，但也历尽坎坷，遍尝酸甜苦辣，测试于我来说犹同爱人，想说爱你真的不容易。俗话说婚姻有七年之痒，那么扪心自问，我是否也有逃离这个行业的想法？至少现在没有，我仍然热爱着这个行业，这个带给我满足感，带给我希望的行业。

　　有朋友问我，为什么不转行做开发，而屈身在这个不受重视的行业里，挣钱不多，而且又枯燥又乏味？我笑答，也许人各有志吧，不受重视是因为测试不够专业不够深入，挣钱不多是因为不是这个行业的No.1，枯燥乏味是因为没有在重复的工作中深入思考，没有提炼出新的东西。那么为什么不转行呢？我觉得，测试中有开发，开发中也有测试，测试和开发本来就是互相融合不能分开的，因此，测试领域里一样可以大有作为，为什么要转行呢？朋友无言。