本节书摘来自异步社区《精通自动化测试框架设计》一书中的第1章,第1.4节听说又有一个新框架了,作者陈冬严 , 邵杰明 , 王东刚 , 蒋涛,更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.4 听说又有一个新框架了
在2009年年初,也就是基于上一个UI自动化框架的BCO自动化项目刚刚实施完毕,开始进入生产运行时,又有一个重要的特性版本开始开发。这次整条产品线采用了新的前端框架,引入了大量提高性能和易用性的设计。简而言之,就是之前的绝大部分UI自动化测试用例都失效了。于是又有一个新的自动化框架从上而下推行下来。这次它的名字叫Solvent,是基于Selenium+JUnit的,在Eclipse中通过编写代码进行用例开发。
当时,这套框架已经基本完成了一期的开发工作,正在寻找团队进行试用,而BCO按照老规矩,就被管理层选中了。
从团队成员的工作经历来讲,这是一次比较大的工作方式的变动。很多人毕业以后基本没正式写过Java代码,而Selenium的使用还需要更多有关HTML的知识。不过再难也难不倒这个聪明好学的团队。通过头脑风暴,大家很快辨识出了以下几个需要学习的方向。
Java基础知识。
HTML及XPath定位。
Selenium API。
接下来,每周都组织1~2次团队分享,轮到介绍技术的同事就自己选择的学习点进行大约半个小时的介绍,然后大家讨论。
最后一个“大作业”是由一位同事搭建了一个简单的网页,罗列了常见的一些HTML控件,然后所有人用Selenium IDE进行录制,并转换成Java代码,通过Eclipse调试,完成代码的编写。当然基础好点的人,就直接在Eclipse中开始写代码了。
1.4.1 初见Solvent
过完农历新年,终于有一天团队组织了一次正式的培训,介绍如何使用这个框架进行自动化测试。培训取得了很大的成功,大家都对这个新框架显示出了浓厚的兴趣。培训也达到了它所宣称的目的,介绍清楚了如何利用这套框架进行自动化用例的编写。它很好地对页面对象和动作进行了封装,隔离了针对Selenium的操作,减轻了自动化用例编写人员的工作量。
不过,还是有同事在培训完成后表达了对培训的不满,他们认为内容过于简单,过多着重于如何应用的层面,对于框架如何构建,页面如何封装等问题没有过多涉及。
An君对此的看法是,国内的测试团队已经不仅仅满足于简单的用例自动化实施,而是希望能更进一步深入核心,完成更多、更有挑战性的课题。显然,北美的管理层可能没意识到,或者没有意愿做这件事。另一方面,坦诚地说,国内的测试团队在技术上也没有做好充足的储备,或者更准确地说整个QA组织还没有做好技术上的储备,这也是当时很多测试团队的现状。
如果敏捷是这个快速变化的时代的要求,那么来自20世纪的独立的QA组织如何获取自动化这个钥匙,打开走向敏捷的这扇大门?这已经是必须解答的问题了。当时的现实情况是,这把钥匙掌握在开发团队手上。
1.4.2 学习XPath和HTML
对于HTML、DOM、XPath等基本概念是什么还不是很了解的读者,推荐大家去学习W3C学校的在线课程[2]。这个网站比较系统和详细地介绍了各种HTML中的概念以及常见的控件。其次,通过自己的动手实践,尝试编写简单的HTML页面和学习如何对元素进行定位,掌握基本的定位方法和技巧。
1.4.3 XPath定位工具
在学习使用XPath或者CSS进行元素定位时,拥有一个合适的工具是很重要的。读者可以参考使用Firefox下的调试工具Firebug,这款由Joe Hewitt开发的插件[3]可以非常方便地在页面的HTML源码中进行元素查找和定位。
Firebug以Firefox的插件方式工作。在完成插件的安装之后,在Firefox工具栏(如图1.5所示)中就会出现Firebug的图标(一只虫子)。在单击了虫子右侧的下拉箭头之后,Firebug的相关菜单就会展示出来。默认情况下,单击虫子图标就会激活Firebug,之后在浏览器的底部就会出现如图1.6所示的Firebug UI。
![16b22326b8c29ce106ed3f178b1e6e1e204d5e9f](https://i-blog.csdnimg.cn/blog_migrate/9e7c7cbd9e3d0753bcaf6b847a8e01f4.png)
![6b02336a9a58042f7589c1b3033945e922ee09b8](https://i-blog.csdnimg.cn/blog_migrate/64b795aa6e22575d2486040a228f2474.png)
这其中最常用的功能,是Firebug UI左上角倒数第二个带框箭头图标,也就是“inspect”。在单击该图标后,再选择页面中的任何元素,就可以在下面的信息区动态展示该元素所对应的HTML。在图1.6所示中,通过选中“Login Name”下方的输入框,在信息区中就显示出了id="login"的input元素的详细信息。通过这种方式,可以非常方便地了解元素的相关定位信息和层级关系,这是后续的Web UI自动化测试的一个基础性工作,很多时候这也是一个难点工作。
俗话说,一个好汉三个帮。除了Firebug之外,在进行元素定位和查找时,还有一个搭配使用的工具,即Firefinder。这是一款Firebug的插件。在安装之后,就会在图1.7所示的Firebug UI的最右侧出现一个“Firefinder”页面。
![26cb289aafbac06a713a518c75dadb3aeafd2bf0](https://i-blog.csdnimg.cn/blog_migrate/05ae7d5d728716166c2433db59a94a6e.png)
这款插件用来在Firebug环境中搜素匹配的CSS或者根据XPath表达式来搜索对应元素。在图1.7的示例中,通过输入XPath "//[@='login']"来查找该页面中所有带有属性值为'login'的元素,并且将匹配结果显示在下部的页面中。这样就更加方便进行元素的定位了。特别是通过这个方法来验证元素定位串的正确性,而不再需要在Web UI自动化测试框架中通过编写用例进行验证,可以大幅提高工作效率。当然,读者需要注意的是,Firefinder目前暂时不能通过frame进行元素匹配。如果元素是嵌在frame或者iframe中,就无法通过Firefinder插件来判断输入的元素属性是否正确,会一直提示找不到元素。
1.4.4 自信与挑战
在进行了基础概念的学习以后,需要使用一个合适的项目对象进行练习。很多人喜欢用自己常用的网站,如搜索网站、购物网站或者邮箱等。这些都是很好的案例学习的实践对象。需要提醒读者注意的是,一开始不要过多地挑战这些属于行业标杆型的产品或者系统。这样做的一个直接结果是容易使自己陷入挑战技术难点的岔路中。经常有朋友在技术交流的群中询问如何获得某网站的搜索结果,或者得到某网站的搜索框的某些关键字的问题,甚至还有询问某火车购票网站的识别码的破解问题。交流之后,An君发现问这些问题的人对什么是DOM还不是很清楚。
An君希望提醒读者的是,在学习的初期,能解决这些问题固然会带来很大的成就感,但更多时候会因为没有解决问题而带来挫败感。从心理学的角度来说,保持自身的自信和对新事物的兴趣,是成功学习新事物的一大保障。如何不断地小有成绩,逐步推进,维护好自己的信心和兴趣,是所有新学者需要面对的问题。
1.4.5 找到适合自身的实践对象
首选的实践对象是读者目前正在进行测试的产品或者系统。如果你是带着领导安排的任务来学习Selenium或者自动化框架的,那么早先的这些学习成果可以直接在以后的工作中进行复用,也可以在后期框架完善过程中,不断回过头来看看自己的早期代码,体会到自己是如何进步的。
更为重要的是可以找到免费的教练(这个产品或者系统的开发人员)来帮助解答一些自己遇到的难点问题,甚至因为你的练习而发现一些软件兼容性或者可测试性方面的问题。此外,还可以在学习定位控件和XPath的同时,了解产品的前端框架以及一些以后在开展自动化框架建设过程中的技术难点。当然,同样建议先把它们扔到Backlog List(任务清单)里,等以后再说,记得保护好自己的学习兴趣。
如果因为某些原因不能使用自己的产品/系统,那么可以考虑自己搭建一个比较简单、但是控件类型较为丰富的网页,并把它部署到Apache或者其他Web 服务器上,供自己学习使用。
当然,当你学习完这些,自信满满地准备大展拳脚的时候,有一点需要注意,以上这些只是在模拟器上学习了一下如何飞行,正式属于你自己的飞机还没造出来呢。
1.4.6 框架的归属问题
如果你是团队里唯一的自动化测试人员、测试架构师兼用例设计师,或者作为架构师(或用户),你的用户(或架构师)和你向同一个经理汇报,那么非常感谢你购买了这本书,并且读到了这里,不过你可以完全略过讨论归属问题的这一小节,除非你有兴趣了解其他人的曲折经历。
An认为,自动化测试框架的未来属于一个独立的、小型的,同时服务于开发和测试团队的工程团队。在到达这个目标之前,作为P公司最为成功的一个自动化框架,Solvent已经被整个组织所接受。但框架的归属权并不在其使用者手中。它的核心底层归属于一个自动化工作组,而这个工作组的绝大部分成员来自于一个提供公共前端框架的开发团队。
An一直以为,抛开其他的因素,这的确是一个非常好的主意。尤其在自动化推进的早期,这样的解决方案保障了框架的开发质量,并为测试团队后续与开发团队共用API/单元测试自动化框架植入了许多的可能性。
1.4.7 Automation 100
现在来介绍下Solvent这个框架是如何进行推进并取得成功的。首先,BCO团队顺利完成在新的特性发布(还记得那个耗时2年、耗资上亿的版本发布吗,就是它)上将全新产生的用例实现了自动化测试,并赶在最终发布版本构建以前的若干个Sprint(迭代)投入了生产,保障了最后一轮回归测试的开展,增强了组织对这个框架的信心。
而后,一个名叫Automation 100的计划横空出世。计划的核心内容是每个集成SCRUM团队(一般由3~6个SCRUM团队组成)在每个Sprint中投入100个人天天进行自动化测试实施,以提高各个解决方案/子系统的自动化测试用例的覆盖率。
经过前前后后很多人历时5年的努力,在整个测试组织的人手不断减少的情况下,自动化测试用例的总数成功突破了10000大关,并且在后续所有的发布版本上进行了每个版本的全回归测试。
它还实现了对多种浏览器的支持,完成了Selenium向Webdriver的迁移,使用者也顺利拓展到开发、本地化等团队。涵盖的测试类型则从功能测试扩展到了兼容性测试、本地化测试和可靠性测试等。