本文最先刊载于《51测试天地》第三十一期电子杂志，此处节选。

有这样一件事情一直记忆犹新，刚入行时，通过LoadRunner实现了性能测试，过程之艰辛非三言两语能概述。

　　来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，枯燥乏味是因为没有在重复的工作中深入思考，没有提炼出新的东西。那么为什么不转行呢？我觉得，测试中有开发，开发中也有测试，测试和开发本来就是互相融合不能分开的，因此，测试领域里一样可以大有作为，为什么要转行呢？朋友无言。

功能自动化测试工具——Selenium

一、Selenium简介

Selenium是一款开源的功能自动化测试工具，它有三个方面的用途。1：可以用它来做浏览器的兼容性测试。例如：可以在浏览器的地址栏中输入网址202.205.%%.%%/selenium/index.html，然后运行Selenium Testrunner，如果Web应用程序可以依照测试脚本自动无误的执行完成，说明web应用程序和此浏览器的兼容性良好；2：可以用它来做Web应用程序的功能自动化测试。例如：某Web应用程序优化了其中的功能模块，我们可以用先前编写好的测试脚本测试整体的功能是否正常，这样做节省了大量手工测试的时间，提高了工作效率；3：可以用它来给客户做演示。手工给客户做演示时，操作可能会出现各种意想不到的失误或错误，而用Selenium就不会出现任何的问题了，降低了演示的风险；可以用Selenium同时演示多个Web应用程序，而且可以控制程序运行的快慢。

二、Selenium组成

Selenium有三个组件组成：Selenium IDE；Selenium Core ；Selenium Remote Control。

Selenium IDE是一个用来开发测试脚本的集成开发环境，它可以看作是Firefox的一个插件，只能在Firefox里安装，运行。用Selenium IDE录制好脚本后，可以直接在Selenium IDE里修改脚本，从而使得脚本可以顺利回放。开发出的测试脚本可以保存为HTML、Ruby scrīpts等格式的文件。

Selenium Core是用来测试web应用程序的工具，它可以在Windows、Linux、Macintosh等操作系统平台上的IE、Mozilla、Firefox浏览器中直接运行。它可以简单理解为运行测试套件的工具。测试套件是测试用例组成的。在Selenium中，测试用例可以理解为由Selenium IDE开发出的测试脚本。

Selenium Remote Control可以用来替代Selenium Core 和 Selenium IDE，只不过功能更强大，允许用户使用自己喜欢的编程语言开发测试脚本，而不仅仅局限于Selenium Core所要求使用的HTML语言。上述编程语言包括Java、.NET、Perl、Python以及Ruby等。Selenium Remote Control的内核是Selenium Server。Selenium Server可以理解为为Web应用程序客户端配置的一个介于浏览器和Web站点之间的HTTP代理，它允许支持Selenium的浏览器运行任意Web站点的Javascrīpt应用程序。Selenium Server 使用AJAX协议直接和浏览器建立通信。总之，Selenium Remote Control可以适用于复杂的基于AJAX协议开发出的Web应用程序。

关于Selenium的三个组件的详述，请参考官方网站：http://www.openqa.org/selenium/

三、Selenium的部署

Selenium需要和Web应用程序部署在同一台服务器上才可以执行功能自动化测试。以Selenium Core 举例，事实上，是将Selenium Core 和Web应用程序放在同一台服务器上的同一个目录下。

四、Testrunner简介

Testrunner包含在Selenium core中，是测试员和Selenium交互的用户界面，可以通过它来调用测试脚本，运行测试用例。针对Testrunner的特点，需要开发出测试用例和指向测试用例的测试套件。测试用例可以用Selenium开发，生成的脚本保存为HTML文档。测试套件实质上是用HTML语言写的一个多行一列的表，也要保存为HTML文档。上述表中的每一行表示一个测试用例，指向相应的测试脚本。在浏览器中调出Testrunner后 ，就可以直接运行测试用例执行功能自动化测试了。