JB的阅读之旅-软件测试52讲（下）

17）精益求精：聊聊提高GUI测试稳定性的关键技术

问题：同样的测试用例在同样的环境上，时而测试通过，时而测试失败；

造成GUI测试不稳定的常见五种因素：

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

非预计的弹出对话框

新增异常场景恢复流程，一旦发现控件无法定位时，就走到该逻辑下，遍历满足的情况，执行相应的操作，缺点就是，不同对话框需要更新到该进程了，存在维护成本；

页面控件属性的细微变化

比如控件ID属性发生变化，也建议新增定位控件逻辑处理：

• 根据脚本里的属性找控件，如果没找到，尝试找控件的文本；
• 文本符合，获取该文本对应的控件属性；
• 判断脚本里的属性跟获取到的属性是否相似，相似则判定一致；

上面的方法只是一种思路，可以根据不同业务特性归总一定适用的方法来在出错时定位控件，提高识别率；

还可以使用xpath，但也一样存在属性被改的情况，只是相对控件元素，概率会少一点；

被测系统的A/B测试

在测试脚本内部对不同的被测版本做分支处理，脚本需要能够区分 A 和 B两个的不同版本，并做出相应的处理；

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

增加重试机制，当操作失败时，自动发起重试；

18）眼前一亮：带你玩转GUI自动化的测试报告

主要是说，好的测试报告，需要有截图及高亮显示操作元素功能；

如果使用selenium，需要扩展selenium原来的操作函数和hook函数实现；

19）真实的战场：如何在大型项目中设计GUI自动化测试策略

• 对那些自定义开发的组件进行完整全面的测试；
• 基于前端模块封装开发业务流程脚本；
• 站在终端的视角以黑盒的方式使用网站的端到端的测试；
• 对各个前端业务模块的页面对象库和业务流程脚本，实施版本化管理机制；

20）与时俱进：浅谈移动应用测试方法与思路

三类移动应用的特点

• web app，移动端的web浏览器，技术栈是传统的HTML、js、css等，优点是跨平台；
• native APP，移动端的原生应用，安卓是apk（Java），ios是ipa（objective-c），能提供比较好的用户体验跟性能，方便操作手机本地资源；
• hybrid APP，介于web APP和native APP两者之间的一种形态，在原生内嵌webview，通过webview来访问网页，优点是具备跨平台，维护更新，是主流的开发模式；

三类移动应用的测试方法

从业务功能测试的角度看，移动应用的测试用例设计和传统 PC 端的 GUI 自动化测试策略比较类似，只是测试框架不同，数据驱动、页面对象模型和业务流程封装依旧适用；

移动应用专项测试的思路和方法

交叉事件测试

也称场景测试，模拟各种交叉场景，手工测试为主；

兼容性测试

• 不同操作系统的兼容性，比如android和ios；
• 不同分辨率的兼容性；
• 不同机型的兼容性；
• 不同语言的兼容性；
• 不同网络的兼容性；
• 不同操作版本的兼容性；

因为需要大量真实社保，所以使用第三方的云测平台较多；

流量测试

• APP执行业务操作引起的流量；
• APP在后台运行时的消耗流量；
• APP安装后首次启动耗费的流量；
• APP安装包的size；
• APP内下载/升级需要的流量；

借助于Android 和 iOS 自带的工具进行流量统计，也可以利用 tcpdump、Wireshark 和 Fiddler 等网络分析工具；

对于 Android 系统，网络流量信息通常存储在 /proc/net/dev 目录下，也可以直接利用 ADB 工具获取实时的流量信息。另外，推荐一款 Android 的轻量级性能监控小工具 Emmagee，类似于 Windows 系统性能监视器，能够实时显示 App 运行过程中 CPU、内存和流量等信息；

对于 iOS 系统，可以使用 Xcode 自带的性能分析工具集中的 Network Activity，分析具体的流量使用情况； 
1
2
3

常见流量优化的方法：

• 压缩图片；
• 优化数据格式，比如使用json；
• 压缩加密；
• 减少api调用次数；
• 回传数据只需要必要数据；
• 缓存机制；

耗电量测试

耗电量一般从三个方面思考：

• APP运行但没有执行业务操作时的耗电量；
• APP运行且密集执行业务操作时的耗电量；
• APP后台运行的耗电量；

检验方法，偏硬件的是耗电仪，软件则如下：

• 安卓adb 命令adb shell dumpsys battery来获取应用的耗电量信息；
• 安卓，Google推出的history batterian工具；
• iOS 通过 Apple 的官方工具 Sysdiagnose来收集耗电量信息，然后，可以进一步通过 Instrument工具链中的 Energy Diagnostics 进行耗电量分析；

弱网络测试

日常生活中，弱网的场景比较多，如地铁、隧道、车库，伴随着就是丢包、延迟、断线的异常场景；

文中作者推荐Augmented Traffic Control，是Facebook的开源移动网络测试工具，详情请点击这里查阅；

而jb日常用的比较多的是fiddler来模拟弱网，感兴趣的点击这里查阅；

边界测试

意思就是找出程序的临界值场景，验证这些临界场景是否正常，常见的就是最大值最小值；

21）移动测试神器：带你玩转Appium

本文主要是介绍了Appium及安装使用，网上也有很多，请自行查阅；

Appium 的内部原理可以总结为：

Appium 属于 C/S 架构，Appium Client 通过多语言支持的第三方库向 Appium Server 发起请求，基于 Node.js 的 Appium Server 会接受 Appium Client 发来的请求，接着和 iOS 或者 Android 平台上的代理工具打交道，代理工具在运行过程中不断接收请求，并根据 WebDriver 协议解析出要执行的操作，最后调用 iOS 或者 Android 平台上的原生测试框架完成测试。 
1

22）从0到1：API测试怎么做？常用API测试工具简介

常用的api测试工具有cURL、postman，还有jmeter跟soapui也算；

cURL

cURL是一款命令行工具，需要安装，然后执行下面的命令发起api调用；

curl -i -H "Accept: application/json" -X GET "https://www.baidu.com" 
1

返回的内容如图：

常见的参数解析：

Session 的场景

curl -i -H "sessionid:XXXXXXXXXX" -X GET "http://XXX/api/demoAPI" 
1

Cookie 的场景 使用 cookie，在认证成功后，后端会返回 cookie给前端，前端可以把该 cookie 保存成为文件，当需要再次使用该 cookie 时，再用-b cookie_File的方式在 request 中植入 cookie 即可正常使用；

// 将 cookie 保存为文件
curl -i -X POST -d username=robin -d password=password123 -c ~/cookie.txt "http://XXX/auth"

// 载入 cookie 到 request 中
curl -i -H "Accept:application/json" -X GET -b ~/cookie.txt "http://XXX/api/demoAPI" 
1
2
3
4
5

Postman

相对于cURL，postman用的比较频繁，官网地址点这里；

结果验证 点击Test右侧的SNIPPETS，挑选一些需要验证的场景，代码就会自动生成，当然也可以自己写；

基于postman的测试代码自动生成 点击右侧的code，选择需要的语言，保存即可；

又或者，使用newman工具，直接执行postman的collection；

newman run examples/sample-collection.json; 
1

复杂场景的api测试

多个api调用协助

通过代码将上个 API 调用返回的response中的某个值传递给下一个 API；

api依赖第三方

mock server；

异步api

异步 API 是指，调用后会立即返回，但是实际任务并没有真正完成，而是需要稍后去查询或者回调的API；

• 测试异步调用是否成功，检查返回值和后台工作现成是否被创建即可判断；
• 测试异步调用的业务逻辑处理是否正确，去访问、操作数据库或者消息队列看对应的数据是否被创建或更新，没权限就直接访问日志文件看记录；

23）API自动化测试框架的前世今生

早期的基于 Postman 的 API 测试在面临频繁执行大量测试用例，以及与 CI/CD 流水线整合的问题时，显得心有余而力不足。

为此，基于命令行的 API 测试实践，也就是 Postman+Newman`，具有很好的灵活性，解决了这两个问题。

但是，Postman+Newman 的测试方案，只能适用于单个 API 调用的简单测试场景，对于连续调用多个 API 并涉及到参数传递问题时，这个方案就变得不那么理想和完美了。随后，API 测试就过渡到了基于代码的 API 测试阶段；

respons结果发生变化时自动识别

具体实现的思路是，在 API 测试框架里引入一个内建数据库，推荐采用非关系型数据库（比如 MongoDB），然后用这个数据库记录每次调用的 request 和 response 的组合，当下次发送相同 request 时，API 测试框架就会自动和上次的 response 做差异检测，对于有变化的字段给出告警；

24）微服务模式下API测试要怎么做？

单体架构

单体架构是将所有的业务场景的表示层、业务逻辑层和数据访问层放在同一个工程中，最终经过编译、打包，并部署在服务器上。

缺点：

• 灵活性差，每次都要整包编译；
• 可扩展性差，不能以模块为单位扩展容量；
• 稳定性差，某模块出错会导致整体不可用；
• 可维护性差；

微服务架构

在微服务架构下，一个大型复杂软件系统不再由一个单体组成，而是由一系列相互独立的微服务组成；

测试的挑战

庞大的测试用例数量