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

最新推荐文章于 2025-04-30 15:30:23 发布

Jinmindong

最新推荐文章于 2025-04-30 15:30:23 发布

阅读量757

点赞数

CC 4.0 BY-SA版权

文章标签：前端

本文链接：https://blog.youkuaiyun.com/text2207/article/details/126329783

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，分析具体的流量使用情况；

常见流量优化的方法：

压缩图片；
优化数据格式，比如使用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 平台上的原生测试框架完成测试。

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"

返回的内容如图：

常见的参数解析：

参数	含义
-i	显示response的header信息；
-H	设置request中的header；
-X	执行执行方法，如get、post、Put，不指定-X，则默认使用get；
-d	设置http参数，参数之间用&串接；
-b	需要cookie时，指定cookie文件路径；

Session 的场景

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

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"

Postman

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

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

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

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

newman run examples/sample-collection.json;

复杂场景的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 做差异检测，对于有变化的字段给出告警；