此处填写密级标识QCon北京2014大会4月17—19日此处填写密级标识@InfoQinfoqchina此处填写密级标识特别感谢QCon上海合作伙伴顺势而为的Web自动化测试东软集团殷坤2013年11月1日技术发展对自动化测试的挑战提高用户界面测试的敏捷程度测试用例的高复用与自动装配云计算助力测试环境高效管理此处填写密级标识Web应用开发常用技术Web应用开发从架构设计、开发到部署目前都有非常成熟的技术架构设计编码实现应用部署开发过程RIA框架组件化云计算敏捷此处填写密级标识对自动化测试应该引发的思考技术的发展使开发效率逐步提高、交付周期逐渐缩短,而我们的自动化测试呢?测试用例稳定性•页面布局或样式发生调整后,测试用例还能运行么?•UI框架更换或升级版本后,测试用例还能运行么?•浏览器更换或升级版本后,测试用例还能运行么?测试用例复用度•测试脚本按照什么粒度划分既便于复用又便于组织?•测试数据如何管理才能实现与测试脚本的灵活搭配?•如何根据组件装配变化自动组织可执行的测试用例?测试环境管理效率•是否可以不安装相关工具,就能够快速运行测试用例?•如何快速搭建各种测试环境,并提高资源使用效率?•如何快速把环境恢复到历史状态,以便重现特定问题?技术发展对自动化测试的挑战提高用户界面测试的敏捷程度测试用例的高复用与自动装配云计算助力测试环境高效管理此处填写密级标识敏捷的瓶颈采用Scrum每日站会就够了吗?能快速响应用户需求就够了么?界面设计可以及时与用户确认就够了么?系统有可扩展的架构就够了么?有合适的快速开发工具就够了么?充分复用已有的技术/业务组件就够了么?每天坚持构建版本就够了么?采用自动化回归测试就够了么?自动化测试用例都能在当天的版本上运行么?敏捷需要自动化测试,但自动化测试本身够敏捷么?对于敏捷而言……需求测试设计开发交付…此处填写密级标识艰辛的自动化测试之路学习成本高工具的操作使用、相关的脚本语言、测试过程的调试分析,是压在广大技术比较薄弱的测试人员身上的三座大山!测试脚本维护困难业界的测试工具本质上还都是针对页面源码来编写(或生成)脚本的,与页面源码高度耦合、可读性差。页面的任何变化都极有可能导致测试脚本不可用,即使提供脚本录制工具,我们能做往往也是重新录制。断言机制繁琐呆板测试脚本中的“断言”依赖手工插入。页面上蕴含大量的信息,潜在的断言对象如此之多、预期结果时常变化(甚至是动态的)、UI样式或UI逻辑(比如,翻页图标灰显)也很可能出现错误。因此,“断言”可谓是测试人员的“噩梦”!自定义扩展难度大测试是个系统的工程,自动化测试是中间的一个执行环节。与之关联的工作还有测试场景设计、测试结果分析、持续集成、版本控制、测试用例覆盖率统计、测试环境搭建,等等。自动化测试工具在扩展方面的局限性,破坏了测试管理的整体性和一致性。业界有很多优秀的测试工具……分类商业开源功能测试QTP、RationalRobotSeleniumWebdriver、RobotFramework性能测试LoadRunner、RationalRobotJMeter它们都有各自的优点,但也普遍存在的一些问题,让我们举步维艰……此处填写密级标识艰辛的自动化测试之路优秀UI框架/工具的采用大大降低了开发成本和难度……测试脚本则要面对UI框架生成的海量源码……用例回放的有效性大幅降低,自动化测试变得雪上加霜……页面DOM结构非常复杂——所录制/编写脚本的复杂度变的更大、可读性变得更差;即使页面代码没有任何变化,UI框架的升级也会导致DOM结构的变化——脚本无效的风险变得更大;控件ID是自动生成的,甚至可能随机变化——导致根据ID定位控件的策略无效;为了在不同浏览器下“看着一样”,实际的DOM结构有时也可能不同——测试脚本的兼容性差;此处填写密级标识Web应用的稳定及不稳定因素稳定因素用户需求、软件特性不稳定因素页面布局、页面样式、用户数据、UI框架及版本此处填写密级标识像用户一样“测试”软件用户操作时只关注页面上能“看”到的,而不用“查看页面源码”;用户会更关注整体业务的正确性、稳定性,而不仅仅是每个孤立页面的功能正确性;用户对页面样式、浏览器兼容性要求越来越高;根据界面快速编写测试用例——敏捷应对需求的变化;隔离对技术实现(UI框架、页面样式/布局)的依赖——敏捷应对设计/开发的变化;支持跨浏览器稳定回放——敏捷应对环境的变化;“用户使用软件”与“自动化测试软件”之间目前存在一些重要差异……如果能像用户使用软件一样进行自动化测试,我们会变得更敏捷……敏捷的核心是响应变化,因此开发和测试都需要快速响应需求的变化;而测试额外还需要快速响应开发的变化;此处填写密级标识聆听自己内心的声音当你在上述界面上进行操作时,你心里是否会默念:“账号”输入***、“密码”输入***、“姓名”输入***、“性别”选择***、“生日”输入***、“国籍”选择***,点击“保存”按钮。类似的,当我们日常使用各种系统时,心里还会默念:“展开/收拢”树(Tree)的某个节点、关闭某个Tab页、数据表格(Grid)的下一页/上一页、选中数据表格(Grid)的某一行……如果测试脚本就像这个样子,大家觉得怎样?此处填写密级标识用户化的测试脚本基于界面上可以“看”到的内容定位对象,对象的操作按照用户习惯命名。对象类型脚本示意操作定义此处填写密级标识用户化的测试脚本基于界面上可以“看”到的内容定位对象,对象的操作按照用户习惯命名。对象类型操作定义脚本示意此处填写密级标识用户化的测试脚本基于界面上可以“看”到的内容定位对象,对象的操作按照用户习惯命名。操作定义对象类型脚本示意此处填写密级标识用户化的测试脚本—实例结合“角色创建及授权”功能,看一下其对应的用户化测试脚本实例:点击“业务角色列表”上的“新增”按钮eventid=[titleButton]业务角色列表,新增/输入“名称”和“描述信息”后点击“保存”eventid=[input]名称name=setValuevalue=QConTest/eventid=[input]描述信息name=setValuevalue=QConTestRole/eventid=[button]保存“/选中“业务角色列表”中“QCconTest”对应的行eventid=“[gridRow]业务角色列表,QCconTestname=check/右侧切换到“应用菜单授权”Tab页eventid=[tab]应用菜单授权/展开“管理控制台”和“组织机构”树节点eventid=[treeNode]管理控制台name=open/eventid=“[treeNode]组织机构name=open/选中“用户管理”树节点eventid=“[treeNode]用户管理name=check/点击“应用菜单授权”上的“保存”按钮eventid=[titleButton]应用菜单授权,保存/此处填写密级标识用户化的测试脚本—实现“树节点展开”就是对指定节点前面的第一个“展开”图标的“点击”操作。通过复杂XPath可以定位指定节点前面的“展开”图标:用户化的测试脚本中包含了XPath中所有可能变化的信息,其它信息都可以由UI框架封装的DOM结构决定。//td[contains(@class,'treecolumn')]//*[text()='RemodelProject']/img[contains(@class,'tree-expander')]接下来,就是解析XML,然后翻译成XPath了……以树节点展开为例,分析用户化测试脚本的实现原理……RIA框架的采用生成了海量的前端源码,导致WebUI自动化测试难度加剧;但也正是由于RIA框架的采用,让前端代码结构变得一致、规范,为测试脚本封装提供可能性。败也“萧何”,成也“萧何”此处填写密级标识敏捷中的UI自动化测试实施要点Automateduserinterfacetestingisplacedatthetopofthetestautomationpyramidbecausewewanttodoaslittleofitaspossible.WewantthisbecauseuserinterfacetestsoftenhavethefollowingnegativeAttributes:Brittle.Asmallchangeintheuserinterfacecanbreakmanytests…Expensivetowrite.Aquickcapture-and-playbackapproachtorecordinguserinterfacetestscanwork,buttestsrecordedthiswayareusuallythemostbrittle.Writingagooduserinterfacetestthatwillremainusefulandvalidtakestime.Timeconsuming.Testsrunthroughtheuserinterfaceoftentakealongtimetorun…Butdon’tweneedtodosomeuserinterfacetesting?Absolutely…wenolongerneedtorunallteststhroughtheuserinterface.Instead,werunthemajorityofteststhroughtheservicelayer…Todothisweneedamuchsmallersetofteststorunthroughtheuserinterfacelayer.此处填写密级标识敏捷中的UI自动化测试实施要点Automateduserinterfacetestingisplacedatthetopofthetestautomationpyramidbecausewewanttodoaslittleofitaspossible.WewantthisbecauseuserinterfacetestsoftenhavethefollowingnegativeAttributes:Brittle.Asmallchangeintheuserinterfacecanbreakmanytests…Expensivetowrite.Aquickcapture-and-playbackapproachtorecordinguserinterfacetestscanwork,buttestsrecordedthiswayareusuallythemostbrittle.Writingagooduserinterfacetestthatwillremainusefulandvalidtakestime.Timeconsuming.Testsrunthroughtheuserinterfaceoftentakealongtimetorun…Butdon’tweneedtodosomeuserinterfacetesting?Absolutely…wenolongerneedtorunallteststhroughtheuserinterface.Instead,werunthemajorityofteststhroughtheservicelayer…Todothisweneedamuchsmallersetofteststorunthroughtheuserinterfacelayer.如何改善UI自动化测试过程中的不利因素,提高稳定性、降低维护成本?从而使各层面的自动化测试能够密切配合、相辅相成。积极改善的想法UI自动化测试成本高、稳定性差,并且专家推荐尽量少做,那我们干脆就不做了吧。敏捷主要还是依赖单元测试,那就是开发人员的职责了。逻辑错误的想法基于业务测试框架开展自动化测试,提高UI自动化用例的稳