自动化理论篇介绍

概述：

对本人过往做过自动化项目、做一些基本的介绍、也方便以后自己回忆，大佬请绕路！

 

1.适合自动化项目：

1.系统维护周期比较长
2.测试任务明确，不会频繁变动。
3.需求变动不频繁、变动少
4.比较频繁的回归测试(需要经常回归的)
5.项目进度压力不太大(时间不是太紧 有时间做的)
6.测试人员具备较强的编程能力
7.自动化测试脚本可重复使用

 

2.不适合自动化项目：

1.需求频繁更新的（需求频繁更新系统就会不稳定，测试脚本需要经常改，最终效果比较差）
2.项目周期很短的项目（项目周期很短，测试周期很短，就不值得花精力去投资自动化测试，好不容易建立起的测试脚本不能得到重复的利用是不现实的。）
3.业务规则复杂（业务规则复杂，有很多逻辑关系、运算关系，很难测试）
4.定制型项目&交付性的项目(这种都是一次性的也不合适自动化)

 

3.关键字驱动和数据驱动的区别：

 数据驱动:是从数据文件（excel,csv,yaml,数据库）读取输入，输出的数据，然后通过变量传入自动化测试用例中，在整个过程中，数据的读取，测试状态，测试信息全部在测试用例里面，测试数据都是数据文件中，通过修改数据达到驱动自动化用例执行的方式叫做数据驱动。
 关键字驱动:是从面向对象的思维出发，同样的业务逻辑会封装成一个函数，这个函数的名字就叫关键字，不同的关键字实现不同的业务逻辑，当所有的业务逻辑都可以通过调用关键字来实现的时候，就是关键字驱动框架。
一般情况下企业里面都是数据驱动和关键字驱动一起使用。

 

4.如何提高自动化稳定性：

1.运行前可以做初始化，执行后可以做后处理，来保证环境一致性
2.加入失败重跑机制，如遇到失败，设置重试次数
3.将测试环境独立出来，可灵活配置运行环境，调试等
4.异常捕获处理，有异常跳过、或标记
5.依赖第三方服务的接口需要设置合理的超时时间
6.有页面跳转可以加隐式等待、判断跳转至目标页面
7.降低 UI 自动化复杂度，UI 自动化测试更多的是在验收测试或回归测试中，完全可以降低测试功能覆盖率，仅对主功能进行回归验证
8.可以把随机弹框、场景加入白名单数据库，后面进行检测白名单场景即可

 

5.为啥需要学习po模式

1 完整的规范化的框架设计模式
2 便于维护和升级
3 便于公司的产出
4 实现高内聚，低耦合

 

6.PO模式三层结构：

BasePage
基础层，用于提供最为底层的功能，让其他页面队形可以直接进行继承的
Page
页面层，用于提供元素的获取，各个元素的操作方法的封装
业务层
通过这一层耳朵调用，传入参数，进行自动化的运行


优点：针对于指定的被测业务系统的流程，执行自动化时比较便捷
缺点：针对于多个系统复用性较差

 

 7.自动化脚本项目怎么接入测试平台：

1.确定平台需要的功能菜单
2.把用例、元素、版本、配置、报告等写入平台
3.脚本通过获取平台数据来完成用例的组装

 

 8.什么数据驱动测试：

相同的测试脚本使用不同的测试数据来执行，测试数据和测试行为完全分离，这样的测试脚本设计模式称为数据驱动。
比如pyrhon下的ddt

 

9.性能测试请求数越大，tps也越高吗？

不一定。TPS（每秒事务处理量）是衡量系统处理能力的指标，表示系统每秒能够处理的事务数量。虽然通常情况下，请求的增加会导致系统的负载增加，从而提高系统的TPS，但这并不是绝对的。

系统的TPS受到多个因素的影响，包括但不限于以下几个方面：

1. 硬件资源：系统的硬件资源，如CPU、内存、磁盘、网络带宽等，会对系统的TPS产生影响。如果系统的硬件资源有限，即使请求增加，也可能无法提高系统的TPS。

2. 系统架构和设计：系统的架构和设计对其处理能力有重要影响。如果系统的架构和设计不合理，存在性能瓶颈或瓶颈组件，即使请求增加，也可能无法提高系统的TPS。

3. 并发处理能力：系统的并发处理能力决定了其能够同时处理的请求数量。如果系统的并发处理能力有限，即使请求增加，也可能无法提高系统的TPS。

4. 业务逻辑和处理复杂度：系统的业务逻辑和处理复杂度对其处理能力也有影响。如果系统的业务逻辑复杂，处理过程需要大量计算或IO操作，即使请求增加，也可能无法提高系统的TPS。

因此，虽然通常情况下，请求的增加会导致系统的TPS增加，但要提高系统的TPS，还需要综合考虑系统的硬件资源、架构设计、并发处理能力和业务逻辑等多个因素。

 

 

 

相关连接：

https://blog.csdn.net/u010454117/article/details/118369960  .................................................UI自动化稳定性用例实战经验干货分享！

https://blog.csdn.net/u011417723/article/details/118674962 .................................................PO设计模式介绍案例 ，PO设计模式详解