揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！,揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！,揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！,揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！,揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！,揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！,敏捷的,Web UI,自动化测试框架,摘要,案例简述,敏捷的,Web UI,自动化测试框架,案例背景,敏捷需要自动化测试,艰辛的自动化测试之路,成功要素,像用户一样“测试”软件,最佳实践,用户化的测试脚本,灵活多样的断言机制,根据脚本自动生成用户化的报告,发展规划,ROI,分析,案例启示,案例简述,敏捷的,Web UI,自动化测试框架,案例简述,Web,开发时,UI,框架的广泛采用极大提高了开发效率和用户体验然而,UI,框架自动生成的海量页面源码却让原本就举步维艰的,UI,自,动化测试变得雪上加霜。
为了有效解决常见自动化测试工具普遍存在的使用成本高、测试,用例有效性低，以及对不同,Web,技术测试方案不统一等问题我们需要提供一个测试框架，来跨越“技术”与“用户”之间的,鸿沟，简化脚本及断言条件的编写和维护工作、提高对,UI,框架和,业务编码规范的支持程度，从而降低成本、提升效率案例目标,降低,Web UI,自动化测试的难度和成本，使更项目能真正实现,Web UI,层面的自动化测试，从而让团队真正享受到自动化测试,带来的收益：,使及时全面的回归测试、稳定性测试、兼容性测试成为可能，为持续集成提供基础；,便于重现（或校验）偶发性缺陷；,将测试人员从日常大量的重复性工作中解放出来，可以把更多的精力投入到针对业务场景的,测试设计、用户体验测试、性能测试、安全性测试等工作中案例背景,敏捷需要自动化测试,需求,测试,设计,开发,交,付,快速原型设计,尽早确认功能,快速响应需求,自动化测试用例都能在当天的版本上有效运行么？,敏捷依赖自动化测试，但自动化测试本身够敏捷么？,可扩展的架构,复用已有组件,每日站会、迭代演示会,快速开发工具,持续集成,案例背景,艰辛的自动化测试之路,学习成本高,工具的,操作使用,、相关的,脚本语言,、测试过程的,调试分析,，是压在广大技术比较薄弱的测试人员身上的三座大山！,测试,脚本维护,困难,业界的测试工具本质,上,还都是,针对页面源码,来编写（或生成,）脚本,的,，,与页面源码高度耦合,、,可读性差,。
页面的任何变化都极有可能,导致测试脚本不可用,，即使提供脚本录制工具，我们能做往往也是重新录制断言,机制繁琐呆板,测试脚本中的“断言”依赖,手工插入,页面上蕴含大量的信息，潜在的,断言对象如此之多,、,预期结果时常变化,（甚至是动态的）、,UI,样式或,UI,逻辑,（比如，翻页图标灰显）也很可能出现错误因此，“断言”可谓是测试,人员的,“噩梦”,！,自定义扩展难度大,测试是个系统的工程，自动化测试是,中间的,一个执行环节与之关联的工作还有,测试场景设计,、,测试结果分析,、,持续集成,、,版本控制,、,测试用例覆盖率统计,、,测试环境搭建,，等等自动化测试工具在扩展方面的局限性，破坏了测试管理的整体性和一致性业界有很多优秀的自动化测试工具，它们都有各自的优点，但也普遍存在的一些问题，让我们举步维艰,案例背景,艰辛的自动化测试之路,优秀,UI,框架,/,工具的采用大大降低了开发成本和难度,测试,脚本则要面对,UI,框架生成,的海量源码,用例回放的有效性大幅降低，,自动化,测试变得雪上加霜,页面,DOM,结构非常,复杂,所,录制,/,编写脚本的复杂度,变的更大,、,可读性变得更差,；,即使页面代码没有任何变化，,UI,框架的升级也会导致,DOM,结构的,变化,脚本,无效的风险变得更,大,；,控件,ID,是自动生成的，甚至可能随机,变化,导致,根据,ID,定位控件的策略,无效,；,成功要素,像用户一样“测试”软件,页面上的不稳定因素：,页面布局、页面样式、,UI,框架及版本更新,用户只关注体验，不,Care,具体实现方案；,自动化测试人员为什么会纠结于此呢？,成功要素,像用户一样“测试”软件,用户操作时只,关注页面上能“看”到的,，,而不用“查看页面源码”；,用户会更,关注整体业务的,正确性、稳定性,，而不仅仅是每个孤立页面的功能正确性；,用户对,页面样式,、,浏览器兼容性,要求越来越高；,根据界面快速编写测试用例,敏捷应对需求的变化；,隔离对技术实现（,UI,框架、页面样式,/,布局）的依赖,敏捷应对设计,/,开发的变化；,支持跨浏览器稳定回放,敏捷应对环境的变化,；,“用户使用软件”与“自动化测试软件”之间目前存在一些重要差异,如果能,像用户使用软件一样进行自动化测试,，我们会变得更敏捷,敏捷的核心是响应变化，,因此,开发和测试都需要快速响应需求的变化,；,而,测试额外还需要快速响应开发的变化,；,实践,1,用户化的测试脚本,当你在上述界面上进行操作时，你心里是否会默念：,“账号”输入*、“密码”输入*、“姓名”输入*、“性别”选择*、“生日”输入*、,“国籍”选择*，点击“保存”按钮。
类似的，当我们日常使用各种系统时，心里还会默念：,“展开,/,收拢”树（,Tree,）的某个节点、关闭某个,Tab,页、,数据表格（,Grid,）的下一页,/,上一页、,选中数据表格（,Grid,）的某一行,如果测试脚本就像这个样子，大家觉得怎样？,实践,1,用户化的测试脚本,基于界面上,可以“看”到,的内容定位对象，对象的操作按照,用户习惯,命名操作定义,对象类型,脚本示意,实践,1,用户化的测试脚本,对象类型,操作定义,脚本示意,基于界面上,可以“看”到,的内容定位对象，对象的操作按照,用户习惯,命名实践,1,用户化的测试脚本,对象类型,操作定义,脚本示意,基于界面上,可以“看”到,的内容定位对象，对象的操作按照,用户习惯,命名实践,1,用户化的测试脚本,点击“业务角色列表”上的“新增”按钮,输入“名称”和“描述信息”后点击“保存”,选中“业务角色列表”中“,TOP100 Test,”对应的行,右侧切换到“应用菜单授权”,Tab,页,展开“管理控制台”和“组织机构”树节点,选中“用户管理”树节点,点击“应用菜单授权”上的“保存”按钮,结合“角色创建及授权”功能，看一下其对应的用户化测试脚本实例：,实践,2,灵活多样的断言机制,断言对象,页面信息量大，需要断言的对象多；,需要在脚本中补充大量断言语句；,预期结果,预期结果很可能发生变化；,预期结果的值与脚本逻辑耦合度大；,断言机制,未设定为断言条件的字段，如果发生错误，无法感知；,UI,样式及部分,UI,逻辑无法设为断言条件；,多,变,呆,实践,2,灵活多样的断言机制,页面控件值断言,业务逻辑,断言,自定义断言,页面级,UI,断言,后台数据库断言,页面级数据断言,实践,2,灵活多样的断言机制,页面控件值断言,业务逻辑,断言,自定义断言,页面级,UI,断言,后台数据库断言,页面级数据断言,在测试过程中，可以在任何位置增加断言事件，来判断页面指定控件是否存在、控件显示值是否为预期结果等。
实践,2,灵活多样的断言机制,页面控件值断言,业务逻辑,断言,自定义断言,页面级,UI,断言,后台数据库断言,页面级数据断言,测试脚本按照业务流程组织并运行，如果某个步骤执行错误，则当前步骤或后续步骤会出现断言错误无需编写任何断言语句以及预期结果值，但测试设计要考虑业务逻辑顺序；,不需要可对比的正确版本，通常适用于项目刚开发或样式做整体调整等情况；,断言错误的位置不精准，可能延后；,操作过程有截图备份，可以有效辅助定位准确的出错原因；,鉴于回归测试的时候，通常大部分用例应该是可以通过的，,所以此类断言的投入产出比非常占优势！,测试用例,在“增加”出错时可能的断言结果,增加记录,A,查询,A,修改查询结果,删除记录,A,实践,2,灵活多样的断言机制,页面控件值断言,业务逻辑,断言,自定义断言,页面级,UI,断言,后台数据库断言,页面级数据断言,无需编写任何断言语句以及预期结果值；,用于可提供预期正确版本的项目，在可持续构建或项目后期比较适用；,能判断出样式、页面逻辑上的“非数据”类错误；,对比绝对精准，导致可能存在误判，因此需要人工对差异图片进行排查；,鉴于回归测试的时候，通常大部分用例应该是可以通过的，,所以此类断言的投入产出比非常占优势！,通过对比前（之前测试通过）后（后续持续发布）版本在相同测试路径和入参情况下的页面截图是否严格相同来断言结果。
实践,2,灵活多样的断言机制,页面控件值断言,业务逻辑,断言,自定义断言,页面级,UI,断言,后台数据库断言,页面级数据断言,支持在用例执行过程中嵌入,SQL,语句，以便从数据库中取实际结果，用于断言实践,2,灵活多样的断言机制,页面控件值断言,业务逻辑,断言,自定义断言,页面级,UI,断言,后台数据库断言,页面级数据断言,通过提取页面,JS,数据对象（或,JSON,）、获取格式化后的页面文本内容，来自动对比判断结果是否正确（无需编写断言语句）原始页面,页面文本内容,实践,2,灵活多样的断言机制,页面控件值断言,业务逻辑,断言,自定义断言,页面级,UI,断言,后台数据库断言,页面级数据断言,在测试过程中如果一些断言结果并不在前台显示，就需要自定义后台断言（操作移动设备、网络设备等），并插入到测试执行过程中实践,3,根据脚本自动生成用户化的报告,传统的测试脚本,用户化测试脚本,实践,3,根据脚本自动生成用户化的报告,有效减少文档格式测试用例的维护成本，并保证用例和软件功能的及时同步实践,3,根据脚本自动生成用户化的报告,传统的自动化测试报告（如上图）可读性很差，不能直观的体现整个测试过程。
用户化的测试报告（如右图），可以非常直观的充分还原整个测试过程极大提升测试结果的分析效率，降低分析难度发展规划,与模型驱动开发工具结合，在模型生成实际页面的同时，生成用户化的测试脚本，并进行参数化在基于产品线开发模式的项目中，,支持在装配软件特性的同时，装配测试用例与云计算资源管理工具打包，形成完整的,企业私有测试云解决方案案例,ROI,分析,投入,工作量,备注,测试框架研发成本,6,人月,一次性投入，具体视功能范围而定,测试脚本语法实现,5,人天,一次性投入，可复用于相同,UI,框架开发所有项目,测试脚本语法学习成本,0.5,人天,掌握基本用法，不含在用例设计方面的经验积累,覆盖基本流程的测试脚本开发工作量相对功能开发而言，几乎可以忽略不计；,脚本维护、运行及结果分析总工作量降低至原来的,1/10,左右，回落到可控范围；,降低自动化测试专业技能要求，团队任何成员都可以完成；,界面可自动化测试的时机提前，不必等到功能稳定之后，有力保障项目过程中每日构建工作的开展；,断言成本降低，准确率提升，有助于发现样式瑕疵、用户体验差、内存泄露等容易被忽略的缺陷；,其它附加回报,提高自动化测试实施成功几率、降低文档格式测试用例维护成本、扩大用例复用范围赢得其他团队支持,回报,案例启示,技术的发展是为了让人类生活变得越来越轻松。
Web,技术发展至今已经可以让开发人员很容易的实现交互性强、展现效果绚的界面，用户也从中得到非常好的使用体验众所周知，“优秀的测试人员一定要有用户视角”为什么用户感觉很易用的软件，实施自动化测试时却不能像开发时那么便捷？,主要原因是“自动化测试”并没有“用户视角”本方案的核心思想就是“像用户使用软件一样的进行自动化测试”。
