敏捷的WebUI自动化测试框架-51Testin课件.ppt
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《敏捷的WebUI自动化测试框架-51Testin课件.ppt》由用户(三亚风情)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 敏捷 WebUI 自动化 测试 框架 51 Testin 课件
- 资源描述:
-
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用户化的
展开阅读全文