淘测试第2期

测试百态台前和幕后■文/天彤我在之前的一些文章里，曾经提到关于测试人员的职业发展，不过说的都是具体的测试技术，今天我会针对测试在软件行业中的地位，以及大家对测试这个职业的看法，进行完整深入的分析，希望能给各位测试同仁一点启发。测试工程师几乎每天都在对自己说：测试和开发同样重要！并且经常对别人说这句话，有时也能从别人嘴里听到这句话。时间长了，我们便对这句话深信不疑，逐渐形成了心理暗示。可是有时我们能感觉到，你越是反复强调一个观点，就说明这个观点越是可能有问题。比如有人家里生了儿子，贺喜的人常说“恭喜恭喜”，如果生了女儿，就会说“一样一样”。嘴上说一样，可是好像又不太一样。让我们先离开软件行业，看看别的行业。以时装设计业为例，每次时装发布会，最后出来亮相的都是时装设计师，却从来没有看到裁缝走上T台，与观众见面。你可以说，如果不是裁缝一丝不苟的按照服装设计图，制作出完美的时装，设计师的理念就无法展示给观众。但是，即使是世界最好的裁缝，也无法与设计师同场登台。他们是幕后的英雄。在摇滚乐圈子里，流传一个非常有名的笑话：“鼓手在离开乐队前说的最后一句话是什么？”。答案是：“我写了几首歌，我们一起来排练一下吧！”。摇滚乐队的核心人物，往往是主唱歌手或者吉他手，鼓手则是默默无闻的。虽然鼓手的重要性对乐队来说不言而喻，但他们的名字却很难被大家记住。鼓手的工作是给乐队提供稳定的节奏，一般不会参与歌曲的创作，一旦当他想涉足创作，便会遭到乐队无情的解雇。当然这只是一个笑话，对鼓手进行调侃，不过却暗示着，鼓手如果想从幕后走到台前，需要付出巨大的代价。刘少奇主席曾经紧紧握着时传祥的手说：“革命工作只有分工不同，没有高低贵贱之分”。这是一种政治上的辞令，在现实生活里，我们却不得不接受这个骨感的事实，那就是，革命工作即使没有贵贱之分，但是其受到社会的重视程度，也有着巨大的差别。这种重视程度，就是我们通常说的：“重要性”。我们发现各行各业都有这么一个规律：在一个组织里，最受大家重视的工作往往都集中在“做什么？”和“怎么做？”上面，从事此类工作的人站在“台前”，其他人则藏于“幕后”。测试百态现在我们再回到软件行业。严格来说，写代码也属于“幕后”工作，其原理可参考刚才说的裁缝。不过在大部分软件企业，开发团队都会兼任需求分析、系统设计的工作，而这些工作都属于重要的“台前”工作。相比之下，测试的工作目标就非常单纯：“利用最少的资源，尽量多的发现软件的问题、Bug”。这确实是不折不扣的“幕后”工作。虽然不愿意，但是我们不得不承认这个事实：对于软件企业来说，开发比测试更加“重要”。请大家听到这个观点先别太沮丧，因为在社会舞台上，站在台前的职业毕竟是少数，大多数职业都是幕后功臣。测试工作虽然不像开发那样更容易引起大家的关注，但是测试也为软件工程做出了重要贡献，赢得了软件行业的重视和尊重。作为软件测试的从业人员，早一点看清并且接受这个事实，有助于为自己的职业生涯确定更明确的目标。一旦选择了软件测试这个职业，就意味着需要做好思想准备，接受测试工作的寂寞，习惯在幕后聆听观众的掌声，忍受被观众遗忘的痛苦。也许有时你能走到台前，但是在大多数时候，舞台很小，没办法站那么多人。如果你无法接受这些，那么，请慎重考虑你的职业选择。“如果我还是选择做测试，但是我也想能走到台前，可以么？”这个问题想来很多人都会问到。我觉得答案是非常肯定的：“完全可以！”这里我想再重复强调一下软件测试的核心价值和终极目标，因为这一直是指导我工作的重要方针，那就是：“用最少的资源，发现最多的软件Bug，最终准确的评估软件的质量是不是合格”。如果我们想走到台前，有A、B两个方案可以选择：A用这种方式虽然能走到台前，但测试不能代替主角，而只能是配角。如果你觉得主角演的不好，可以用合适的方式告诉主角，而不能越俎代庖演起主角的戏份来。就像那位想写歌的鼓手一样，一旦他越过了那条线，便很难在这个团队立足了。、测试工程师通过学习增强自己的综合能力，然后参与“需求分析”、“系统设计”这些台前的工作，注意是“参与”不是“负责”。参与的形式，也要符合刚刚说的测试的“核心价值”，具体来说，就是找出需求和设计中的严重问题，提请项目组尽早修正，问题也必须要提在要害上。我们要努力达到这种效果，测试组提出问题后，项目组纷纷感叹：“多亏测试发现了”、“这个问题提的很犀利”等等。如果提的问题仅仅是文档格式是否规范，那还是不要参与算了。测试百态如果你确实非常想当主角，那就必须放弃现在，重新开始。在实际工作中确实有一些测试工程师改行做产品经理，做程序员，我觉得这很正常，因为他们不甘于做一名寂寞的测试人员，想要在更大的舞台上唱主角。不过，如果测试团队中绝大多数人都要唱主角，那就不太妙了。或者，我们把一些乐于做幕后工作的测试人员逼上台前，也是非常不妥的。B说到这里我想起一个很有意思的事情，我曾经参与一个部门主管会议，会议上一位开发的主管跟上级抱怨，说开发团队不如销售团队更有成就感。我听了以后顿悟，原来，台前和幕后都是相对的，在研发部门中，开发是台前，测试是幕后，可是到了公司层面，销售是台前，研发是幕后。每个人，可以说都同时位于两个舞台上，在小舞台上唱主角，在大舞台上唱配角，当你慢慢变成了大舞台上的主角，你又发现，还有一个更大的舞台。心有多大，舞台就有多大！、虽然在软件工程中，测试属于幕后，但我们仍然可以做到，在测试团队内部，走到台前，影响测试团队的工作方式和思想意识。这并不仅仅是测试管理者的事情，如果你提的意见很靠谱，拿出的方案很科学，能为大家解决实际问题，那么慢慢的，就会走到测试团队的“台前”。最后，我祝愿所有的测试同仁，早日找到属于自己的舞台，并且在舞台上找到属于自己的位置。测试百态作者简介：太禅，目前在淘宝自动化测试组负责页面自动化框架的开发。4年自动化测试及测试工具开发经验，之前在微软从事自动化测试的工作。熟悉各种自动化测试手段，擅长软件架构设计，对UI自动化解决方案富有经验。基于页面模型的自动化测试——Automan页面自动化框架介绍关键词：Automan，页面模型，自动化测试，jQuery为什么要做Automan我们原来的框架是基于描述型编程的思想，就是在脚本里定义如何找控件及如何操作。我们原先一直在寻求如何方便地让用户进行调用，比较常见的如：button(:id=“sth”)，lclick(“确定”)，tdoclick(保存)，ie.button(:text,保存).click_no_wait。还有不常见的：click_button_by_id()，click_button_by_name()，click_frame_object()，click_object()，click_ole_object()，div_button()。这些封装确实能让脚本轻便很多，但新的问题上来了：当一个新人想写脚本的时候，他怎么知道应该用哪个方法呢？有固定文本或ID的还好说，遇到不固定的就得折腾很久。这无形中增加了自动化测试的成本。如何降低自动化测试的门槛，让更多的项目自动化起来，就成了我们自动化组要面对的首要问题。Automan也正是在这种背景下诞生的全新的自动化框架。什么是Automan页面自动化框架Automan以页面共享和分工合作为出发点，将元素查找和页面操作分开来，减少定位元素的重复劳动，提高自动化测试的工作效率。同时，通过控件类型的封装将不同类型的操作整合起来，做到元素操作的尽量统一，将写脚本的难度转移到创建页面模型上。由于页面模型相对脚本是一个一次性投入的工作，它的成本高一点相比整个自动化测试过程来说其实还是降低了的。同时，我们提供Web方式的页面模型管理平台，让创建、维护页面模型更直观。进一步降低自动化的难度。测试百态Automan的特点a.元素查找功能丰富：1.一套强大的页面元素查找方式，是支撑基于页面模型的架构的基础。我们引入jQuery的页面查找方式：Selector，来定位控件。jQuery()，有语法简练易懂，学习快速，文档丰富的特点。Selector也是开发和UED们熟知的元素定位方式。同时我们根据实际情况，将iframe下的元素查找化繁为简。对于不跨域的iframe，用户可以直接查找到它们，相当于iframe对用户而言是透明的。2.原来tcommon里我们也有对象库的概念，那除了jQuery的查找方式，我们还有什么改进呢？改进主要分两点：SubModel和Collection。•SubModel是将原来平铺的对象库，用树型的方式展现出来，让对象(element)的存储更有层次感，从而让对象查找更方便。可以将SubModel理解成页面上的子模块，子模块下面可以嵌套其它子模块或者对象(element)。•Collection可能支持把一组类似的页面元素封装到一个element数组中，在脚本中调用。举一个例子，我们可以把今日关注热门里的链接建成一个link对象的数组，这样用一个方法（page.hot_links）就能拿到这五个热门的数组。接下来就可以对获得的对象做想做的事了。比如：page.hot_links[“女包”].click，page.hot_links[0].text==”连衣裙”，page.hot_links.count==5。脚本的灵活性和自由度得到了酣畅淋漓的发挥，再也不用怕校验或操作难以实现了。•SubModel和Collection相结合，更是整个建模思想的升华。一组对象（element）封装成SubModel，同时又有很多看起来一样的SubModel组合在一起。我们常用的搜索宝贝就是一个例子=豆浆机：测试百态这里一条宝贝记录下面有宝贝链接、宝贝价格等属性，而宝贝记录本身又是一个数组。当我们拿到这样一个宝贝记录的数组时，又能做什么神奇的事呢，请看：page.auction_records[“九阳JYDZ-510W”].price.text==”238.00”，page.auction_records[1].lnk_auction_link.click。可以毫不夸张地说，如果没有SubModel和collection，页面模型库便不是完整的，基于页面模型的测试就是一句空话。b.Web化的页面模型管理平台，让用户可以将页面模型方便地搭建起来，完美支持包括SubModel和Collection的丰富页面组织方式。所有的页面都是放在服务器端的，等脚本需要运行的时候，Automan内建的页面加载机制会从服务器上增量更新有变动的页面，并动态加载它们。本地要加载的页面文件源代码对用户来说是透明的，用户不用关心在代码层面页面模型是如何组织的，只要直接拿来用就好了。我们还支持脱机工作，在当脚本需要在子网里运行、无法连接到Automan服务器时，也能加载本地创建好的页面模型文件。c.控件操作简单统一：统一操作方式，是降低脚本编写难度的有效途径。有人可能会问，那些click_no_wait，send_key操作都到哪里去了呢？答案是，这些都让创建页面模型的人去关心去了。click_no_wait是通过另起ruby进程的方式来点击会引起弹出框的控件，send_key是为了解决支付宝安全控件密码无法set的问题。这些非常规的方法在Automan的框架里面仍然存在，我们通过添加元素类型对操作的重载，将这些方法封装在新的特殊类型里。目前有的特殊类型包括：AlipayPassword，ANoWaitElement，AInnerTextSetElement。这样封装的好处在于，脚本编写人员不用关心控件的操作是应该用send_key呢还是用set，只要用最基本的set方法就好了。只要创建页面时选一下类型，以后就能很方便的用了。测试百态d.强大的调试工具：AutomanconsoleAutomanconsole提供了一个脚本调试和帮助控件定位的平台。支持自动加载页面模型，逐行调试脚本。提供元素的高亮