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

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

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

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

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

非预计的弹出对话框

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

页面控件属性的细微变化

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

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

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

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

被测系统的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，介于和两者之间的一种形态，在原生内嵌，通过来访问 页，优点是具备跨平台，维护更新，是主流的开发模式；

三类移动应用的测试方法

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

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

交叉事件测试

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

兼容性测试

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

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

流量测试

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

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

常见流量优化的方法：

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

耗电量测试

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

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

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

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

弱 络测试

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

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

边界测试

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

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

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

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

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

cURL

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

返回的内容如图：

常见的参数解析：

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

Session 的场景

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

Postman

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

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

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

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

复杂场景的api测试

多个api调用协助

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

api依赖第三方

mock server；

异步api

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

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

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

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

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

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

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

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

24）微服务模式下API测试要怎么做/h2>

单体架构

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

缺点：

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

微服务架构

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

测试的挑战

庞大的测试用例数量

消费者契约的 API 测试的核心思想是： 只测试那些真正被实际使用到的 API 调用，如果没有被使用到的，就不去测试；

微服务之间的耦合关系

契约的本质就是 Request 和 Response 的组合，基于契约的 Mock Service 完美地解决了 API 之间相互依赖耦合的问题；

25）掌握代码级测试的基本理念与方法

常见代码错误类型：

• 语法特征错误，编译语法发生错误；
• 边界行为特征错误；
• 经验特征错误，根据过往经验发现代码错误；
• 算法错误，代码完成的功能和之前设定的不一致，会直接影响到业务逻辑；
• 部分算法错误，在一些特定的条件或者输入情况下，算法不能准确完成业务要求实现的功能，这是常见的类型；

代码级测试常用方法:

• 静态方法，顾名思义就是在不实际执行代码的基础上发现代码缺陷的方法，又可以进一步细分为人工静态方法和自动静态方法；
• 动态方法是指，通过实际执行代码发现代码中潜在缺陷的方法，同样可以进一步细分为人工动态方法和自动动态方法。

这四类测试方法的特点，以及可以覆盖的错误类型，可以概括如下：

• 人工静态方法，本质上通过开发人员代码走查、结对编程、同行评审来完成的，理论上可以发现所有的代码错误，但也因为其对“测试人员”的过渡依赖，局限性非常大；
• 自动静态方法，主要的手段是代码静态扫描，可以发现语法特征错误、边界行为特征错误和经验特征错误这三类“有特征”的错误；
• 人工动态方法，就是传统意义上的单元测试，是发现算法错误和部分算法错误的最佳方式；
• 自动动态方法，其实就是自动化的边界测试，主要覆盖边界行为特征错误；

评论里面有提及到，Facebook 开源的静态分析工具 Infer，感兴趣的可以看看；

26）深入浅出之静态测试方法

人工静态方法

• 代码走查，code review，开发人员减产代码；
• 结对编程，一个开发实现代码，另一个审查输入的每一行代码；

自动静态方法

常见的工具包括收费的企业级应用，比如Coverity。

其它免费的应用，比如；

自动的特点在于：

• 相比于编译器，可以做到对代码更加严格、个性化的检查；
• 不真正检测代码的逻辑功能，只是站在代码本身的视角，基于规则，尽可能多地去发现代码错误；

能发现很多小问题：

• 使用未初始化的变量；
• 变量在使用前未定义；
• 空指针引用等等；

27）深入浅出之动态测试方法

人工动态方法

也就是单元测试，测试基本用不着，不展开；

自动动态方法

基于代码自动生成边界测试用例并执行来捕捉潜在的异常、崩溃和超时的测试方法；

如何实现边界测试用例的自动生成/p>

28）解读不同视角的软件性能与性能指标

• 终端用户是软件系统的最终使用者；

终端用户眼中的软件性能

• 系统响应时间，细分为应用系统处理时间、数据库处理时间和 络传输时间；
• 前端展示时间，取决于用户端的处理能力；

运维人员眼中的软件性能

软件性能除了包括单个用户的响应时间外，更要关注，以及在负载下的系统健康状态、并发处理能力、当前部署的系统容量、可能的系统瓶颈、系统配置层面的调优、数据库的调优，以及长时间运行稳定性和可扩展性；

开发人员眼中的软件性能

在软件设计开发人员眼中，软件性能通常会包含、、、、这五大方面；

• 算法设计
• • 核心算法的设计与实现是否高效；
• • 设计上是否采用 buffer 机制以提高性能，降低 I/O；
• • 是否存在潜在的内存泄露；
• • 是否存在并发环境下的线程安全问题；
• • 是否存在不合理的线程同步方式；
• • 是否存在不合理的资源竞争；
• 架构设计
• • 站在整体系统的角度，是否可以方便地进行系统容量和性能扩展；
• • 应用集群、缓存集群、数据库的可扩展性是否经过测试和验证；
• 性能
• • 代码实现是否遵守开发语言的性能最佳实践；
• • 关键代码是否在白盒级别进行性能测试；
• • 是否考虑前端性能的优化；
• • 必要的时候是否采用数据压缩传输； 对于既要压缩又要加密的场景，是否采用先压缩后加密的顺序；
• 数据库
• • 数据库表设计是否高效；
• • 是否引入必要的索引；
• • SQL 语句的执行计划是否合理；
• • SQL 语句除了功能是否要考虑性能要求；
• • 数据库是否需要引入读写分离机制；
• • 系统冷启动后，缓存大量不命中的时候，数据库承载的压力是否超负荷；
• 软件性能的可测试性
• • 是否为性能分析（Profiler）提供必要的接口支持；
• • 是否支持高并发场景下的性能打点；
• • 是否支持全链路的性能分析。

性能测试人员眼中的软件性能

三个最常用的指标：、，以及；

并发用户数

并发用户数，包含了业务层面和后端服务器层面的两层含义；

• 业务层面的并发用户数，指的是实际使用系统的用户总数；
• 后端服务器层面的并发用户数，指的是“同时向服务器发送请求的数量”，直接反映了系统实际承载的压力；

获取用户行为模式的方法，主要分为两种：

• 对于已经上线的系统来说，往往采用和等重要信息；
• 而对于未上线的全新系统来说，通常的做法是参考行业中类似系统的统计信息来建模，然后分析；

响应时间

响应时间，可以分为前端展现时间和系统响应时间：

• 前端时间，又称呈现时间，取决于客户端收到服务器返回的数据后渲染页面所消耗的时间；
• 系统响应时间，可以划分为web服务器时间、应用服务器时间、数据库时间，以及各服务器间通信的 络时间；

系统吞吐量

是直接体现软件系统负载承受能力的指标；

以不同方式表达的吞吐量可以说明不同层次的问题：

• 和表示的吞吐量，主要受 络设置、服务器架构、应用服务器制约，考察http或者业务层面；
• 表示的吞吐量，主要受应用服务器和应用本身实现的制约，考察系统层面或 络层面；

一个优秀的性能测试工程师，一般需要具有以下技能：

• 性能需求的总结和抽象能力；
• 根据性能测试目标，精准的性能测试场景设计和计算能力；
• 性能测试场景和性能测试脚本的开发和执行能力；
• 测试性能 告的分析解读能力；性能瓶颈的快速排查和定位能力； – 性能测试数据的设计和实现能力；
• 面对互联 产品，全链路压测的设计与执行能力，能够和系统架构师一起处理流量标记、影子数据库等的技术设计能力；
• 深入理解性能测试工具的内部实现原理，当性能测试工具有限制时，可以进行扩展二次开发；
• 极其宽广的知识面，既要有“面”的知识，比如系统架构、存储架构、 络架构等全局的知识，还要有大量“点”的知识积累，比如数据库 SQL 语句的执行计划调优、JVM 垃圾回收（GC）机制、多线程常见问题等等；

小结

• 终端用户希望自己的业务操作越快越好；
• 系统运维人员追求系统整体的容量和稳定；
• 开发人员以“性能工程”的视角关注实现过程的性能；
• 性能测试人员需要全盘考量、各个击破；

最常用的指标：并发用户数，响应时间，系统吞吐量：

• 并发用户数包含不同层面的含义，既可以指实际的并发用户数，也可以指服务器端的并发数量；
• 响应时间也包含两层含义，技术层面的标准定义和基于用户主观感受时间的定义；
• 系统吞吐量是最能直接体现软件系统承受负载能力的指标，但也必须和其他指标一起使用才能更好地说明问题；

29）性能测试的基本方法与应用领域

并发用户数、响应时间、系统吞吐量之间的关系

后端性能测试的测试负载，一般只会把它设计在内；而压力测试的测试负载，则会将它设计在系统上下，甚至是;

常用的七种性能测试方法

后端性能测试

也叫服务端性能测试，是通过性能测试工具模拟大量的并发用户请求，然后获取系统性能的各项指标，并且验证各项指标是否符合预期的性能需求的测试手段；

这里的性能指标，除了包括并发用户数、响应时间和系统吞吐量外，还应该包括各类资源的使用率，比如系统级别的 CPU 占用率、内存使用率、磁盘 I/O 和 络 I/O 等，再比如应用级别以及 JVM 级别的各类资源使用率指标等；

后端性能测试的场景设计主要包括以下两种方式：

• 基于性能需求目标的测试验证；
• 探索系统的容量，并验证系统容量的可扩展性；

前端性能测试

通常来讲，前端性能关注的是、、、、等内容，希望借此找到页面加载过程中比较耗时的操作和资源，然后进行有针对性的优化，最终达到优化终端用户在浏览器端使用体验的目的；

而业界普遍采用的前端测试方法，是根据雅虎前端团队总结的优化规则，可以点击这里查看；

• 减少http请求次数，http请求数量越多，执行过程越长；
• 减少dns查询次数，dns作用是将URL转化为实际IP地址，是分级查找，需要耗费20ms+；
• 避免页面跳转；
• 使用内容分发 络CDN；
• Gzip压缩传输文件，压缩可以减少传输文件大小，减少；

代码级性能测试

代码级性能测试，是指在单元测试阶段就对代码的时间性能和空间性能进行必要的测试和评估，以防止底层代码的效率问题在项目后期才被发现的尴尬；

最常使用的改造方法是：

• 将原本只会执行一次的单元测试用例连续执行 n 次，这个 n 的取值范围通常是 2000~5000；
• 统计执行 n 次的平均时间。如果这个平均时间比较长（也就是单次函数调用时间比较长）的话，比如已经达到了秒级，那么通常情况下这个被测函数的实现逻辑一定需要优化；

压力测试

压力测试，通常指的是后端压力测试，一般采用后端性能测试的方法，不断对系统施加压力，并验证系统化处于或长期处于临界饱和阶段的稳定性以及性能指标，并试图找到系统处于临界状态时的主要瓶颈点，压力测试往往被用于系统容量规划的测试；

配置测试

用于观察系统在不同配置下的性能表现，通常使用后端性能测试的方法：

• 通过性能基准测试建立性能基线；
• 调整配置；
• 基于同样的性能基准测试，找到特定压力模式下的最佳配置；

这里的配置是广义，包含且不止：

• 宿主操作系统的配置；
• 应用服务器的配置；
• 数据库的配置；
• JVM的配置；
• 络环境的配置；

并发测试

指的是在同一时间，同时调用后端服务，期间观察被调用服务在并发情况下的行为表现，旨在发现诸如资源竞争、资源死锁之类的问题；

可靠性测试

验证系统在常规负载模式下长期运行的稳定性，本质就是通过长时间模拟真实的系统负载来发现系统潜在的内存泄漏、链接池回收等问题；

性能测试的应用领域

这里“应用领域”主要包括能力验证、能力规划、性能调优、缺陷发现四大方面；

能力验证

主要是验证，通常要求在明确的软硬件环境下，根据明确的系统性能需求设计测试方案和用例；

能力规划

能力规划关注的是，如何才能使系统达到要求的性能和容量，通常情况下会采用探索性测试的方式来了解系统的能力；

能力规划解决的问题，主要包括以下几个方面：

• 能否支持未来一段时间内的用户增长；
• 应该如何调整系统配置，使系统能够满足不断增长的用户数需求；
• 应用集群的可扩展性验证，以及寻找集群扩展的瓶颈点；
• 数据库集群的可扩展性验证；
• 缓存集群的可扩展性验证；

性能调优

性能调优主要解决性能测试过程中发现的性能瓶颈的问题，通常会涉及多个层面的调整，包括硬件设备选型、操作系统配置、应用系统配置、数据库配置和应用代码实现的优化等等；

缺陷发现

通过性能测试的各种方法来发现诸如内存泄露、资源竞争、不合理的线程锁和死锁等问题；

最常用的测试方法主要有并发测试、压力测试、后端性能测试和代码级性能测试；

30)后端性能测试工具原理与行业常用工具简介

完整的后端性能测试应该包括性能需求获取、性能场景设计、性能测试脚本开发、性能场景实现、性能测试执行、性能结果 告分析、性能优化和再验证；

使用性能测试工具获得性能测试 告只是性能测试过程中的一个必要步骤而已，而得出 告的目的是让性能测试工程师去做进一步的分析，以得出最终结论，并给出性能优化的措施；

性能测试场景设计

常用的工具

业内有很多成熟的后端性能测试工具，比如、、 等，还有很多云端部署的后端性能测试工具或平台，比如 、、 等；

目前最主流的是jmeter，因为开源免费、灵活、功能也强大，适合互联 企业；

而LR是按照并发用户数收费的，而且LR对定制功能支持不是特别好，传统企业用的会比较多；

原理

• 首先通过虚拟用户脚本生成器生成虚拟用户脚本；
• 然后根据性能测试场景设计的要求，通过压力控制器控制协调各个压力产生器以并发的方式执行虚拟用户脚本；
• 同时在测试执行过程中，通过系统监控器收集各种性能指标以及系统资源占用率；
• 最后，通过测试结果分析器展示测试结果数据；

前端性能测试工具原理与行业常用工具简介

webPagetest

是前端性能测试的利器：

• 可以为我们提供全方位的量化指标，包括页面的加载时间、首字节时间、渲染开始时间、最早页面可交互时间、页面中各种资源的字节数、后端请求数量等一系列数据；
• 还可以自动给出被测页面性能优化水平的评价指标，告诉哪些部分的性能已经做过优化处理了，哪些部分还需要改进；
• 同时，还能提供 视图、 视图、 视图、Request` 详情视图和页面加载视频慢动作；

参数解读

First Byte Time

指的是用户发起页面请求到接收到服务器返回的第一个字节所花费的时间。这个指标反映了后端服务器处理请求、构建页面，并且通过 络返回所花费的时间；

本次测试的结果，首次打开页面（First View）花费的时间是 999 ms，重复打开页面（Repeat View）花费的时间是 860 ms。这两个指标都在 1 s 以下，所以 WebPagetest 给出了 A 级的评分；

Keep-alive Enabled

要求每次请求使用已经建立好的链接，它属于服务器上的配置，不需要对页面本身进行任何更改，启用了 Keep-alive 通常可以将加载页面的时间减少 40%~50％，页面的请求数越多，能够节省的时间就越多；

Compress Transfer

如果将页面上的各种文本类的资源，比如 Html、JavaScript、CSS 等，进行压缩传输，将会减少 络传输的数据量，同时由于 JavaScript 和 CSS 都是页面上最先被加载的部分，所以减小这部分的数据量会加快页面的加载速度，同时也能缩短 First Byte Time。

Compress Images

为了减少需要 络传输的数据量，图像文件也需要进行压缩处理。显然本次测试结果显示（图 5），所有的 JPEG 格式图片都没有经过必要的压缩处理，并且所有的 JPEG 格式图片都没有使用渐进式 JPEG（Progressive JPEG）技术，所以 WebPagetest 给出了 D 级的评分；

Cache Static Content

页面上的静态资源不会经常变化，所以如果你的浏览器可以缓存这些资源，那么当重复访问这些页面时，就可以从缓存中直接使用已有的副本，而不需要每次向 Web 服务器请求资源。这种做法，可以显著提高重复访问页面的性能，并减少 Web 服务器的负载。

WebPagetest 实际使用中需要解决的问题

第一个问题是，如果被测 站部署在公司内部的 络中，那么处于外 的 WebPagetest 就无法访问这个 站，也就无法完成测试。

要解决这个问题，你需要在公司内 中搭建自己的私有 WebPagetest 以及相关的测试发起机。具体如何搭建，点击这里；

第二个问题是，用 WebPagetest 执行前端测试时，所有的操作都是基于界面操作的，不利于与 CI/CD 的流水线集成。

要解决这个问题，就必须引入 WebPagetest API Wrapper；

WebPagetest API Wrapper 是一款基于 Node.js，调用了 WebPagetest 提供的 API 的命令行工具。也就是说，你可以利用这个命令行工具发起基于 WebPagetest 的前端性能测试，这样就可以很方便地与 CI/CD 流水线集成了。具体的使用步骤如下：

• 通过安装该命令行工具；
• 访问 获取你的 ；
• 使用发起测试，该调用是异步操作，会立即返回，并为你提供一个 ；
• 使用查询测试是否完成；
• 测试完成后，就可以通过查看测试 告，但是会发现测试 告是个很大的 JSON 文件，可读性较差；
• 通过安装 工具，这是为了解决测试 告可读性差的问题，将 生成的 JSON 文件格式的测试 告转换成为 HTML 文件格式；
• 使用将 JSON 文件格式的测试结果转换成 HTML 格式;

32-33)基于LoadRunner实现企业级服务器端性能测试的实践

LR的主要模块

Virtual User Generator

用于生成模拟用户行为的测试脚本，生成的手段主要是基于协议的录制，也就是由性能测试脚本开发人员在通过 GUI 执行业