敏捷的WebUI自动化测试框架课件.pptxVIP

敏捷的WebUI自动化测试框架

摘要?案例简述?敏捷的WebUI自动化测试框架?案例背景?敏捷需要自动化测试?艰辛的自动化测试之路?成功要素?像用户一样“测试”软件?最佳实践?用户化的测试脚本?灵活多样的断言机制?根据脚本自动生成用户化的报告?发展规划?ROI分析?案例启示

案例简述—敏捷的WebUI自动化测试框架Web开发时UI框架的广泛采用极大提高了开发效率和用户体验。然而UI框架自动生成的海量页面源码却让原本就举步维艰的UI自动化测试变得雪上加霜。为了有效解决常见自动化测试工具普遍存在的使用成本高、测试用例有效性低，以及对不同Web技术测试方案不统一等问题。我们需要提供一个测试框架，来跨越“技术”与“用户”之间的鸿沟，简化脚本及断言条件的编写和维护工作、提高对UI框架和业务编码规范的支持程度，从而降低成本、提升效率。案例简述案例目标降低WebUI自动化测试的难度和成本，使更项目能真正实现WebUI层面的自动化测试，从而让团队真正享受到自动化测试带来的收益：使及时全面的回归测试、稳定性测试、兼容性测试成为可能，为持续集成提供基础；便于重现（或校验）偶发性缺陷；将测试人员从日常大量的重复性工作中解放出来，可以把更多的精力投入到针对业务场景的测试设计、用户体验测试、性能测试、安全性测试等工作中。

案例背景—敏捷需要自动化测试?快速原型设计?尽早确认功能?快速响应需求?……?可扩展的架构?复用已有组件?……需求设计开发?自动化测试用例都能在当天的版本上有效运行么？?敏捷依赖自动化测试，但自动化测试本身够敏捷么？测试?每日站会、迭代演示会?快速开发工具?持续集成?……交付…

案例背景—艰辛的自动化测试之路业界有很多优秀的自动化测试工具，它们都有各自的优点，但也普遍存在的一些问题，让我们举步维艰……?学习成本高工具的操作使用、相关的脚本语言、测试过程的调试分析，是压在广大技术比较薄弱的测试人员身上的三座大山！?测试脚本维护困难业界的测试工具本质上还都是针对页面源码来编写（或生成）脚本的，与页面源码高度耦合、可读性差。页面的任何变化都极有可能导致测试脚本不可用，即使提供脚本录制工具，我们能做往往也是重新录制。?断言机制繁琐呆板测试脚本中的“断言”依赖手工插入。页面上蕴含大量的信息，潜在的断言对象如此之多、预期结果时常变化（甚至是动态的）、UI样式或UI逻辑（比如，翻页图标灰显）也很可能出现错误。因此，“断言”可谓是测试人员的“噩梦”！?自定义扩展难度大测试是个系统的工程，自动化测试是中间的一个执行环节。与之关联的工作还有测试场景设计、测试结果分析、持续集成、版本控制、测试用例覆盖率统计、测试环境搭建，等等。自动化测试工具在扩展方面的局限性，破坏了测试管理的整体性和一致性。

案例背景—艰辛的自动化测试之路优秀UI框架/工具的采用大大降低了开发成本和难度……测试脚本则要面对UI框架生成的海量源码……用例回放的有效性大幅降低，自动化测试变得雪上加霜……?页面DOM结构非常复杂——所录制/编写脚本的复杂度变的更大、可读性变得更差；?即使页面代码没有任何变化，UI框架的升级也会导致DOM结构的变化——脚本无效的风险变得更大；?控件ID是自动生成的，甚至可能随机变化——导致根据ID定位控件的策略无效；

成功要素—像用户一样“测试”软件页面上的不稳定因素：页面布局、页面样式、UI框架及版本更新……用户只关注体验，不Care具体实现方案；自动化测试人员为什么会纠结于此呢？

成功要素—像用户一样“测试”软件“用户使用软件”与“自动化测试软件”之间目前存在一些重要差异……?用户操作时只关注页面上能“看”到的，而不用“查看页面源码”；?用户会更关注整体业务的正确性、稳定性，而不仅仅是每个孤立页面的功能正确性；?用户对页面样式、浏览器兼容性要求越来越高；如果能像用户使用软件一样进行自动化测试，我们会变得更敏捷……?根据界面快速编写测试用例——敏捷应对需求的变化；?隔离对技术实现（UI框架、页面样式/布局）的依赖——敏捷应对设计/开发的变化；?支持跨浏览器稳定回放——敏捷应对环境的变化；敏捷的核心是响应变化，因此开发和测试都需要快速响应需求的变化；而测试额外还需要快速响应开发的变化；

实践1—用户化的测试脚本当你在上述界面上进行操作时，你心里是否会默念：“账号”输入***、“密码”输入***、“姓名”输入***、“性别”选择***、“生日”输入***、“国籍”选择***，点击“保存”按钮。类似的，当我们日常使用各种系统时，心里还会默念：“展开/收拢”树（Tree）的某个节点、关闭某个Tab页、数据表格（Grid）的下一页/上一页、选中数据表格（Grid）的某一行……如果测试脚本就像这个样子，大家觉得怎样？

实践1—用户化的