测试学习4

GUI测试的其他用法

页面对象自动生成

• 以web页面为单位来封装页面上的控件以及控件的部分操作，而测试用例基于页面对象完成的具体操作
• 典型模式就是：XXPage.YYComponent.ZZOperation
• 开发和维护页面对象的类(Page class)，比较消耗时间
• 可以使用页面对象自动生成技术，适用于需要维护大量页面对象的大中型GUI自动化测试项目

页面对象自动生成技术

• 基本思路，不需要手工维护Page Class，只需要提供Web的URL，就会自动帮你生成页面上所有控件的定位信息，并自动生成Page Class
• 需要注意的是，那些依赖数据的动态页面对象也会被包含在自动生成的Page Class里，而这种动态页面对象通常不应该包含在Page Class里，所以往往需要以手动方式删除
• 很多商用自动化工具，如UFT，已经支持页面对象自动生成功能了，还可以对Page Class进行版本管理
• 开源的自动化方案，页面对象自动生成功能一般需要自己开发，并且需要与你所用的自动化测试框架深度绑定

GUI测试数据自动生成

• 由机器自动生成测试用例的输入数据
• 仅仅局限于于两种情况：
  • 1，根据GUI输入数据类型，以及对应的自定义规则库自动生成测试输入数据
  • 如：GUI界面有一个’姓名’输入款不过，数据类型是string，基于类型可以自动生成Null,SQL注入，超长字符串，非英语字符等数据
  • 根据自定义规则生成测试数据的核心思想，与安全扫描软件AppScan基于攻击规则库自动生成和执行安全测试方式类似
  • 2，对于需要组合多个测试输入数据的场景，测试数据自动生成可以自动完成多个测试数据的笛卡尔积组合，然后再以人工方式剔除非法的数据组合
  • 并不一定是最高效的，对于输入参数比较多，且数据之间合法组合比较少或者难以明确的情况，自动化生成笛卡尔组合再提出非法组合，效率往往不如认为组合来的高
  • 常见用法:先手动选择部分输入数据进行笛卡尔积，删除不合法部分，在此基础上，人为添加更多业务上有意义的输入数据组合

无头浏览器

• Headless Browser，一种没有界面的浏览器
• 拥有完整的浏览器内核，包括js解析引擎、渲染引擎等
• 与普通最大的区别在于，执行过程中看不到运行界面，依然可以用GUI测试框架截图功能截取执行中的页面
• 主要应用场景，包括GUI自动化测试、页面监控以及网络爬虫三种
• 在GUI测试中，使用无头浏览器好处有四个方面
  • 测试执行速度更快
  • 减少对测试执行的干扰
  • 简化测试执行环境的搭建
  • 在单机上实现测试的并发执行
• 最大缺点：不能完全模拟用户真实行为，而且由于没有实际页面渲染，不太适合需要对页面布局进行验证的场景
• Headles Chrome配套的Puppeteer框架

提高GUI测试稳定性的关键技术

• GUI自动化测试稳定性，典型表现形式就是，同样的测试用例在同样的环境上，时而测试通过，时而测试失败，降低了GUI测试的可信性

造成GUI测试不稳定的因素

• 非预计的弹出对话框
• 页面控件属性的细微变化
• 被测系统的A/B测试
• 随机的页面延迟造成的控件识别失败
• 测试数据问题

解决方法

非预计的弹出对话框

• 一般包含两种场景
  • GUI自动化测试用例执行过程中，操作系统弹出的非预计对话框(如：系统更新请求)
  • 被测软件本身也有可能在非预期的时间弹出预期的对话框(如：随机的用户调查)
• 解决思路；
  • 手工测试时，直接点击关闭对话框即可
  • 对于GUI自动化测试来说，道理相同
  • 自动化脚本发现控件无法正常定位/正常操作时，自动化框架自动进入’异常场景恢复模式’
  • 在’异常场景恢复模式’下，GUI自动规划框架依次检查各种可能出现的对话框，一旦确定了对话框的类型，立即执行预定义操作，然后重试刚才失败步骤
  • 注意：这种方式只能处理已知可能出现的对话框，对于新类型的对话框，只能通过自动化方式尝试点击处理，每当发现一种潜在的对话框就把它详细信息更新到场景库

页面控件属性的细微变化

• 如果页面控件属性发生变化，哪怕是细微变化也会导致脚本定位失效
• 定位控件思路
  • 通过控件类型(Button)缩小范围
  • 通过属性值中关键字(Login)进一步缩小范围
  • 根据属性值变化前后相似性，最终定位到该控件
• 采取’组合属性’定位控件会更精准，成功率会更高，在此基础上加入’模糊匹配’技术，可以进一步提高控件识别率
• '模糊匹配’是指，通过特定的相似度算法，控件属性发生细微变化时，这个控件依旧可以被精准定位
• 商用GUI自动化测试工具(如UTF)，已经实现了模糊匹配，通常情况下只需要启动’模糊匹配’选项即可，开启后测试报告中会显示该信息，因为GUI自动化工具不能保证每次模糊匹配都一定正确
• 开源的GUI自动化测试框架，目前还没有现成的框架支持模糊匹配，通常需要二次开发，实现的思路是：实现自己的对象识别控制层，就是在原本对象识别的基础上额外封装一层，在额外封装的层中加上模糊匹配的实现逻辑
• 通常不建议把模糊匹配逻辑以硬编码的方式写在代码里，而是引入规则引擎，将具体的规则通过配置文件方式与代码逻辑解耦

被测系统的A/B测试

• A/B测试，是互联网产品中常用的一种测试方法，为web或app界面/流程提供两个不同的把版本，然后用户随机访问其中一个版本，收集两个版本的用户体验数据和业务数据，最后分析评估出最好的版本用于正式发布
• A/B测试通常会发布到实际生产环境，所以会造成生产环境中GUI自动化测试的不稳定
• 这种问题的解决思路是，在测试脚本内部对不同的被测版本做分支处理，脚本能够区分A/B两个不同版本，并做出相应处理

随机的页面延迟造成控件识别失败

• 随机页面延迟，是GUI测试防不胜防的，既然是随机的，只能减少造成的影响
• 办法是加入重试(retry)机制，重试机制是指，当某一步GUI操作失败时，框架会自动发起重试，可以是步骤级别的，也可以是页面级别的，甚至是业务流程级别的
• 对于开源的GUI测试框架，重试机制往往不是自带的功能，需要自己二次开发实现
• 对于那些会修改一次性使用数据的场景，不要盲目启用页面级别和业务流程级别的重试

测试数据问题

• 测试数据问题，也是造成GUI自动化测试不稳定的一个重要原因
• 如：测试所依赖的数据被其他用例修改了或者发生错误后进行了重试操作，都会导致数据状态在第一次执行中被修改

GUI自动化测试报告

• 是GUI自动化测试重要组成部分,测试用例执行失败时，可以通过分析报告，看出到底是哪一步出错了，错误发生时被测系统在哪个页面上，并且前序步骤又是哪些页面等

早期的基于视频的GUI测试报告

• 早期自动化测试框架会对测试执行整个过程进行屏幕录像并生成视频
• 可以提供清晰的GUI测试执行上下文，缺点是
  • 通常体积较大，管理和实时传输非常不利
  • 分析测试报告时，往往需要结合测试用例以及服务端日志信息
• 商业GUI自动化软件，如UTF已经自带了截图以及高亮显示操作元素功能

开源GUI测试框架的测试报告实现思路

• 如果使用selenium webdriver就需要自己实现截图以及高亮显示操作元素功能
• 主要思路是，利用sceenshot函数在一些特定的时机完成页面截图功能
• 具体代码实现，通常有两种方式
  • 扩展selenium原本操作函数
  • 在相关的Hook操作中调用screenshot函数

1，扩展selenium原本操作函数实现截图以及高亮显示操作元素的功能

• 自己实现一个click函数
• 当自己实现的click函数被调用时：
  • 首先，用js代码高亮显示被操作的元素，实现方式就是利用js在对象边框上渲染一个5-8像素的边缘
  • 然后，调用screenshot函数完成点击前的截图
  • 最后，调用selenium原声click函数完成真正的点击操作
• 以后凡是需要调用click函数时，都直接调用自己封装的click函数，直接得到高亮被操作对象的界面截图

2，在相关的Hook操作中调用screenshot函数实现截图以及高亮显示操作元素的功能

• Hook就是钩子函数
  • 当要执行某个函数时，系统会在执行函数前先隐形执行一个空实现函数，那么当你需要做一些扩展或者拦截时，就可以在这个空实现的函数中加入自定义操作，这个空实现函数就是Hook函数
• 可以在Hook函数中添加截图、元素高亮、以及额外的任意操作，这样的测试报告具有更好的可读性

全球化GUI测试报告的创新设计

• 所谓全球化测试是指，同一个业务全球各个国家都有自己的网站，那么这些站点的测试除了关注基本功能和不同国家的特有功能外，还要去验证界面布局以及翻译在上下文环境中是否合适
• 最好的解决方法是：利用GUI自动化测试工具生成完整的测试执行过程截图
• 这样LQA就不需要手工执行测试用例，直接分析测试报告中业务操作中GUI界面截图就可以，然后发现界面布局问题或者不恰当的翻译问题
• 并不是最优的方案，LQA实际中还会有三个问题：
  • 需要经常在多个国家测试报告之间来回切换去比较页面布局
  • 需要频繁切换到主站的报告，比较翻译内容与上下文匹配度
  • 发现缺陷后，还是需要从测试报告中赋值截图，并用图下个标注有问题的点，然后才能打开去缺陷管理系统递交缺陷报告
• 报告的横向是一个国家的业务测试顺序截图
• 纵向是同一界面在不同国家的形式
• 整个报告可以用键盘上下左右依次移动
• 在技术上实现测试报告和缺陷管理系统交互：利用缺陷管理系统对外暴露的API接口
• http://www.testclass.net/jenkins

如何在大项目中设计GUI自动化测试策略

• 主要分为测试策略如何设计和测试用例脚本如何组织

大型全球化电商网站前端模块划分

• 由于大型全球化电商网站业务及其庞大，所以前端架构也要按照笔筒的业务模块来划分，如用户管理模块、商户订单管理模块、商户商品管理模块等
• 前端模块会使用项目自己封装的组件库，如自定义的列表组件、登陆组件、信用卡组件等，通常将自定义组件放置在’公共组件库’中，为前端模块提供依赖
• 所以，从代码库(Repository)角度看，各个前端模块都有自己独立的代码库，还有一个公共组件的代码库

大型全球化电商网站的GUI自动化测试策略设计

• GUI测试通常只覆盖最核心且直接影响主营业务的E2E场景
• 不一定是系统全部完成后才真正展开的，也应该分阶段、分层次指定测试策略

1，从前端组件级别来保证质量，需要对自定义开发的组件进行完整全面的测试

• 公共组件库会被很多上层的前端模块依赖，它的质量直接影响到上层模块的质量
• 最常用的方案是：基于jest开展单元测试，并考量js代码覆盖率指标
• jest是facebook发布的，基于lasmine开源的js单元测试框架
• 完成单元测试后，往往还会基于被测控件构建专用的测试页面，在页面层面再次验证控件相关的功能和状态
  • 先构建一个空页面，并加入被测控件，由此可以构建出一个包含被测控件的测试页面，这个页面往往被称为Dummy Page
  • 从黑盒角度出发，在测试页面上通过手工和自动化方式操作被测控件，并验证功能正确性
• 对于自动化部分，需要基于GUI自动化测试框架开发对应的测试用例，这些用例也会采用和GUI E2E一样的测试框架，也是从黑盒角度来对被测控件做功能验证

2，每一个前端模块构建的页面对象库，开发封装自己的业务流程脚本，可以组装成每个前端模块的测试用例

• 以用户管理为例，测试用例组装过程如下：
  • 首先，把用户管理模块中涉及到的所有页面(如登陆，注册等)，按照页面对象要求写成Page类
  • 然后，利用这些Page类封装业务流程脚本，如用户登陆流程，用户注册流程等
  • 最后，在GUI测试用例脚本中，调用封装好的业务流程脚本构成该模块的GUI测试用例
• 自动化测试用例的原则：
• 优先选取业务关键路径以及Happy path作为自动化测试的范围，在资源充足的情况下，希望当前阶段的自动化率达到70%-80%
• 在这个层面主要是针对模块级别的要求，E2E测试是针对系统级别测试
• 两者的共同点是都属于GUI自动化测试范畴

3，组合各个前端模块，站在终端用户视角，以黑盒方式进行端到端测试

• 主要分为两部分
  • 一部分是，通过探索式测试的方法手工执行测试，目标是尽可能多发现新问题
  • 另一部分是，通过GUI自动化测试执行基本业务功能的回归测试，保证网站核心业务相关的所有功能正确性
• 这部分端到端GUI测试用例绝对数量不多，但是对于保证最终网站的质量有着关键的作用

这部分端到端的GUI自动化测试用例由谁负责开发

• 由于每个前端模块都会有一个Scrum团队,但是端到端的GUI自动化测试不属于任何一个团队
• 这种情况下最好的做法就是：成立一个专门的测试团队，负责该级别的GUI测试(E2E)
• E2E团队应该尽可能地利用各个模块已有地页面对象和业务流程脚本，组装端到端地GUI测试

大型全球化电商网站的GUI自动化脚本管理

• 将各个模块的页面对象和业务流程脚本放在各自的代码库中，并引入页面对象和业务流程脚本的版本管理机制，通常采用页面对象和业务流程脚本的版本号和开发版本号保持一致的方案
• 在端到端的GUI自动化测试脚本中，引入各个模块正确的页面对象和业务流程脚本的版本号，测试用例代码就可以直接调用模块的页面对象和业务流程脚本