敏捷的Web UI自动化测试框架_第1页
敏捷的Web UI自动化测试框架_第2页
敏捷的Web UI自动化测试框架_第3页
敏捷的Web UI自动化测试框架_第4页
敏捷的Web UI自动化测试框架_第5页
已阅读5页,还剩22页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、敏捷的Web UI自动化测试框架摘要案例简述敏捷的Web UI自动化测试框架案例背景敏捷需要自动化测试艰辛的自动化测试之路成功要素像用户一样“测试”软件最佳实践用户化的测试脚本灵活多样的断言机制根据脚本自动生成用户化的报告发展规划ROI分析案例启示案例简述敏捷的Web UI自动化测试框架案例简述Web开发时UI框架的广泛采用极大提高了开发效率和用户体验。然而UI框架自动生成的海量页面源码却让原本就举步维艰的UI自动化测试变得雪上加霜。为了有效解决常见自动化测试工具普遍存在的使用成本高、测试用例有效性低,以及对不同Web技术测试方案不统一等问题。我们需要提供一个测试框架,来跨越“技术”与“用户”

2、之间的鸿沟,简化脚本及断言条件的编写和维护工作、提高对UI框架和业务编码规范的支持程度,从而降低成本、提升效率。 案例目标降低Web UI自动化测试的难度和成本,使更项目能真正实现Web UI层面的自动化测试,从而让团队真正享受到自动化测试带来的收益:使及时全面的回归测试、稳定性测试、兼容性测试成为可能,为持续集成提供基础;便于重现(或校验)偶发性缺陷;将测试人员从日常大量的重复性工作中解放出来,可以把更多的精力投入到针对业务场景的测试设计、用户体验测试、性能测试、安全性测试等工作中。案例背景敏捷需要自动化测试需求测试设计开发交 付快速原型设计尽早确认功能快速响应需求自动化测试用例都能在当天的

3、版本上有效运行么?敏捷依赖自动化测试,但自动化测试本身够敏捷么?可扩展的架构复用已有组件每日站会、迭代演示会快速开发工具持续集成案例背景艰辛的自动化测试之路 学习成本高工具的操作使用、相关的脚本语言、测试过程的调试分析,是压在广大技术比较薄弱的测试人员身上的三座大山! 测试脚本维护困难业界的测试工具本质上还都是针对页面源码来编写(或生成)脚本的,与页面源码高度耦合、可读性差。页面的任何变化都极有可能导致测试脚本不可用,即使提供脚本录制工具,我们能做往往也是重新录制。 断言机制繁琐呆板测试脚本中的“断言”依赖手工插入。页面上蕴含大量的信息,潜在的断言对象如此之多、预期结果时常变化(甚至是动态的)

4、、UI样式或UI逻辑(比如,翻页图标灰显)也很可能出现错误。因此,“断言”可谓是测试人员的“噩梦”! 自定义扩展难度大测试是个系统的工程,自动化测试是中间的一个执行环节。与之关联的工作还有测试场景设计、测试结果分析、持续集成、版本控制、测试用例覆盖率统计、测试环境搭建,等等。自动化测试工具在扩展方面的局限性,破坏了测试管理的整体性和一致性。业界有很多优秀的自动化测试工具,它们都有各自的优点,但也普遍存在的一些问题,让我们举步维艰案例背景艰辛的自动化测试之路优秀UI框架/工具的采用大大降低了开发成本和难度测试脚本则要面对UI框架生成的海量源码用例回放的有效性大幅降低,自动化测试变得雪上加霜页面D

5、OM结构非常复杂所录制/编写脚本的复杂度变的更大、可读性变得更差;即使页面代码没有任何变化,UI框架的升级也会导致DOM结构的变化脚本无效的风险变得更大;控件ID是自动生成的,甚至可能随机变化导致根据ID定位控件的策略无效;成功要素像用户一样“测试”软件页面上的不稳定因素:页面布局、页面样式、UI框架及版本更新用户只关注体验,不用户只关注体验,不CareCare具体实现方案;具体实现方案;自动化测试人员为什么会纠结于此呢?自动化测试人员为什么会纠结于此呢?成功要素像用户一样“测试”软件用户操作时只关注页面上能“看”到的,而不用“查看页面源码”;用户会更关注整体业务的正确性、稳定性,而不仅仅是每

6、个孤立页面的功能正确性;用户对页面样式、浏览器兼容性要求越来越高;根据界面快速编写测试用例敏捷应对需求的变化;隔离对技术实现(UI框架、页面样式/布局)的依赖敏捷应对设计/开发的变化;支持跨浏览器稳定回放敏捷应对环境的变化;“用户使用软件”与“自动化测试软件”之间目前存在一些重要差异如果能像用户使用软件一样进行自动化测试,我们会变得更敏捷敏捷的核心是响应变化,因此开发和测试都需要快速响应需求的变化;而测试额外还需要快速响应开发的变化;实践 1用户化的测试脚本当你在上述界面上进行操作时,你心里是否会默念:“账号”输入*、“密码”输入*、“姓名”输入*、“性别”选择*、“生日”输入*、“国籍”选择

7、*,点击“保存”按钮。类似的,当我们日常使用各种系统时,心里还会默念:“展开/收拢”树(Tree)的某个节点、关闭某个Tab页、 数据表格(Grid)的下一页/上一页、 选中数据表格(Grid)的某一行如果测试脚本就像这个样子,大家觉得怎样?实践 1用户化的测试脚本基于界面上可以“看”到的内容定位对象,对象的操作按照用户习惯命名。操作定义对象类型脚本示意实践 1用户化的测试脚本对象类型操作定义脚本示意基于界面上可以“看”到的内容定位对象,对象的操作按照用户习惯命名。实践 1用户化的测试脚本对象类型操作定义脚本示意基于界面上可以“看”到的内容定位对象,对象的操作按照用户习惯命名。实践 1用户化的

8、测试脚本点击“业务角色列表”上的“新增”按钮输入“名称”和“描述信息”后点击“保存”选中“业务角色列表”中“TOP100 Test”对应的行右侧切换到“应用菜单授权”Tab页展开“管理控制台”和“组织机构”树节点选中“用户管理”树节点点击“应用菜单授权”上的“保存”按钮结合“角色创建及授权”功能,看一下其对应的用户化测试脚本实例:实践 2灵活多样的断言机制断言对象页面信息量大,需要断言的对象多;需要在脚本中补充大量断言语句;预期结果预期结果很可能发生变化;预期结果的值与脚本逻辑耦合度大;断言机制未设定为断言条件的字段,如果发生错误,无法感知;UI样式及部分UI逻辑无法设为断言条件;实践 2灵活

9、多样的断言机制 页面控件值断言 业务逻辑断言 自定义断言 页面级UI断言 后台数据库断言 页面级数据断言实践 2灵活多样的断言机制 页面控件值断言 业务逻辑断言 自定义断言 页面级UI断言 后台数据库断言 页面级数据断言在测试过程中,可以在任何位置增加断言事件,来判断页面指定控件是否存在、控件显示值是否为预期结果等。实践 2灵活多样的断言机制 页面控件值断言 业务逻辑断言 自定义断言 页面级UI断言 后台数据库断言 页面级数据断言测试脚本按照业务流程组织并运行,如果某个步骤执行错误,则当前步骤或后续步骤会出现断言错误。无需编写任何断言语句以及预期结果值,但测试设计要考虑业务逻辑顺序;不需要可对

10、比的正确版本,通常适用于项目刚开发或样式做整体调整等情况;断言错误的位置不精准,可能延后;操作过程有截图备份,可以有效辅助定位准确的出错原因;鉴于回归测试的时候,通常大部分用例应该是可以通过的, 所以此类断言的投入产出比非常占优势!测试用例在“增加”出错时可能的断言结果增加记录A查询A修改查询结果删除记录A实践 2灵活多样的断言机制 页面控件值断言 业务逻辑断言 自定义断言 页面级UI断言 后台数据库断言 页面级数据断言无需编写任何断言语句以及预期结果值;用于可提供预期正确版本的项目,在可持续构建或项目后期比较适用;能判断出样式、页面逻辑上的“非数据”类错误;对比绝对精准,导致可能存在误判,因

11、此需要人工对差异图片进行排查;鉴于回归测试的时候,通常大部分用例应该是可以通过的, 所以此类断言的投入产出比非常占优势!通过对比前(之前测试通过)后(后续持续发布)版本在相同测试路径和入参情况下的页面截图是否严格相同来断言结果。实践 2灵活多样的断言机制 页面控件值断言 业务逻辑断言 自定义断言 页面级UI断言 后台数据库断言 页面级数据断言支持在用例执行过程中嵌入SQL语句,以便从数据库中取实际结果,用于断言。实践 2灵活多样的断言机制 页面控件值断言 业务逻辑断言 自定义断言 页面级UI断言 后台数据库断言 页面级数据断言通过提取页面JS数据对象(或JSON)、获取格式化后的页面文本内容,

12、来自动对比判断结果是否正确(无需编写断言语句)。原始页面页面文本内容实践 2灵活多样的断言机制 页面控件值断言 业务逻辑断言 自定义断言 页面级UI断言 后台数据库断言 页面级数据断言在测试过程中如果一些断言结果并不在前台显示,就需要自定义后台断言(操作移动设备、网络设备等),并插入到测试执行过程中。实践 3根据脚本自动生成用户化的报告传统的测试脚本用户化测试脚本实践 3根据脚本自动生成用户化的报告有效减少文档格式测试用例的维护成本,并保证用例和软件功能的及时同步。实践 3根据脚本自动生成用户化的报告传统的自动化测试报告(如上图)可读性很差,不能直观的体现整个测试过程。用户化的测试报告(如右图

13、),可以非常直观的充分还原整个测试过程。极大提升测试结果的分析效率,降低分析难度。发展规划与模型驱动开发工具结合,在模型生成实际页面的同时,生成用户化的测试脚本,并进行参数化。在基于产品线开发模式的项目中,支持在装配软件特性的同时,装配测试用例。与云计算资源管理工具打包,形成完整的企业私有测试云解决方案。案例ROI分析投入工作量备注测试框架研发成本6人月一次性投入,具体视功能范围而定测试脚本语法实现5人天一次性投入,可复用于相同UI框架开发所有项目测试脚本语法学习成本0.5人天掌握基本用法,不含在用例设计方面的经验积累 覆盖基本流程的测试脚本开发工作量相对功能开发而言,几乎可以忽略不计; 脚本维护、运行及结果分析总工作量降低至原来的1/10左右,回落到可控范围; 降低自动化测试专业技能要求,团队任何成员都可以完成; 界面可自动化测试的时机提前,不必等到功能稳定之后,有力保障项目过程中每日构建工作的开展; 断言成本降低,准确率提升,有助于发现样式瑕疵、用户体验差、内存泄露等容易被忽略的缺陷; 其它附加回报提高自动化测试实施成功几率、降低文档格式测

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论