UI自动化问题（一）

最新推荐文章于 2025-06-03 11:28:08 发布

圆满测试

最新推荐文章于 2025-06-03 11:28:08 发布

阅读量904

点赞数 17

CC 4.0 BY-SA版权

文章标签：自动化运维面试 ui

本文链接：https://blog.youkuaiyun.com/xiaoshi757/article/details/146505087

1.自动化测试怎么做的？
   时间点:
   在需求分析阶段,跟前端沟通好,规范前端代码,避免造成后期自动化工作无法开展的问题.
   在用例设计阶段,挑选出适合做自动化的用例,单独整理到一个文件保存.
   在项目中后期,趋于稳定之后,就可以开始设计自动化脚本了.
   语言python+自动化测试工具selenium+单元测试框架unittest+分层模型PO+测试报告HTMLTestRunner
   脚本分为七层:
   1) common/base   公共方法层
   2) page       业务流程,元素定位
   3) data       测试数据
   4) case    用例和断言
   5) log       自动生成的日志
   6) report   自动生成的报告
   7) run.py   程序的主入口批量执行用例.(使用unittest产生discover测试套件.利用HTMLTestRunner生成执行对象,执行对象会生成报告)

2.selenium是什么，具体怎么用？

selenium是一个开源的自动化测试工具，主要用于Web应用程序的测试。它能够模拟真实用户在浏览器中的操作，支持多种浏览器和操作系统，包括IE、FireFox、Chrome、Edge等。Selenium通过WebDriver控制浏览器行为，实现点击、输入、打开页面等操作，从而测试应用程序的功能和兼容性‌。

3.Selenium IDE 是什么？

Selenium IDE（Integrated Development Environment）是 Selenium 生态中的一个轻量级浏览器插件，主要用于快速录制和回放用户在浏览器中的操作，生成自动化测试脚本。它不需要编程基础，适合初学者或快速验证简单场景。

Selenium IDE 的核心特点

零代码录制
- 通过浏览器插件直接录制用户操作（点击、输入、跳转等），自动生成可复用的测试脚本。
- 支持导出为 Python、Java、C# 等编程语言代码，方便与 Selenium WebDriver 集成。
跨浏览器支持
- 支持 Chrome、Firefox、Edge 等主流浏览器（需安装对应插件）。
直观的图形界面
- 提供时间轴视图、断言/验证点插入、调试工具，无需手动编写代码。
快速调试与回放
- 单步执行、断点调试，实时查看每一步的操作结果。

4.手工测试和自动化测试的认识？

手工测试：

优点：1.灵活性高,适应需求频繁变更的场景2.适合探索性测试和用户体验(UI/UX)验证3.无需编程能力,学习成本低4.快速验证新功能或边界条件

缺点：1.重复执行耗时,效率低2.人为误差可能导致测试结果不一致3.难以覆盖大规模数据或复杂场景4.长期维护成本高(如回归测试)

适用场景

探索性测试：需求不明确时，通过人工探索发现潜在问题。
用户体验测试：验证界面交互、易用性、视觉设计等主观指标。
短期项目或原型验证：需求快速迭代，自动化成本不划算。
复杂业务逻辑验证：需要人工判断逻辑合理性（如业务流程分支）

自动化测试：

优点：1.高效执行重复性任务(如回归测试)2.支持大规模数据驱动测试3.结果一致性高,减少人为误差4.可集成CI/CD流程,实现持续测试
缺点：1.初期开发脚本的时间和经济成本高2.无法替代人工判断(如UI美观度、用户体验)3.维护成本高(需随需求变更同步更新脚本)4.需要编程能力和测试框架知识

适用场景

回归测试：频繁验证核心功能是否因代码变更而失效。
性能测试：模拟高并发请求（如JMeter）。
数据驱动测试：批量验证不同输入组合的输出结果。
跨平台/浏览器兼容性测试：同时验证多环境下的功能一致性。

5.什么是分层自动化？

底层（单元测试）：占比最大（约70%），快速验证代码逻辑。
中间层（接口测试）：占比约20%，确保模块间协作正确。
顶层（UI测试）：占比约10%，覆盖关键用户流程。

为什么需要分层自动化？

提升效率
- 单元测试执行快，可频繁运行；UI测试用于最终验证，减少冗余。
降低维护成本
- 分层后，UI变动仅影响顶层测试，底层逻辑无需修改。
精准定位问题
- 测试失败时，通过分层快速判断是代码逻辑、接口还是UI问题。
支持持续集成（CI）
- 单元和接口测试可集成到CI流水线，快速反馈代码质量。
资源优化
- 将耗时长的UI测试集中在必要场景，节省计算资源。

6.如何筛选、标识自动化测试用例？

筛选适合自动化的用例

适合自动化的用例特征	不适合自动化的用例
高频重复执行（如每日回归测试）	一次性验证或临时需求
业务核心功能（如登录、支付）	探索性测试或用户体验验证
稳定且需求变更少的功能模块	频繁修改的界面或流程
数据驱动测试（多输入组合场景）	需要人工主观判断（如UI美观度）
跨平台/浏览器兼容性验证	涉及硬件交互（如摄像头调用）

标识维度

分类维度	示例标识方式	用途
测试类型	`@smoke`（冒烟）、`@regression`（回归）	按测试阶段分组执行
功能模块	`@login`、`@checkout`	模块化维护和针对性验证
优先级	`@P0`（最高）、`@P1`、`@P2`	按紧急程度分批运行
测试环境	`@prod`、`@staging`、`@dev`	区分环境配置
自动化层级	`@unit`、`@api`、`@e2e`	分层执行（如CI中仅运行单元和接口测试）

7.怎样提高自动化的运行速度和效率?
   1. 少用sleep,多用元素等待.
   2. 在case层,把连接数据库的代码写到setUpClass里面.
   3. 如果涉及到多个elif,把最有可能出现的条件写到前面.
   4. 如果不是大量的测试数据,尽量减少文件IO(input/output)操作.
   5. 对于一些页面.必须全部加载完成后才会继续执行,可以使用显示等待,这一个元素找到后就继续执行,不必等所有元素加载成功.
   6. 提高脚本的稳定性,避免因为脚本不稳定影响效率.

8.python装饰器是什么?有哪些？
装饰器: 在不修改代码的前提下,让代码实现更多的功能.
@classmethod @staticmethod @ddt @data @unittest.skip

9.自动化测试开展的时间点和步骤?

（1）项目刚开始的时候（别急着动手，先想清楚）
这时候需求还在变，UI可能一天改三回，直接上自动化容易做无用功。但也不能闲着，重点做三件事：

拉着开发、产品一起盘一盘，哪些功能最核心、最容易出问题（比如支付流程、用户登录）。
提前选好趁手的工具（别跟风，团队用Python就选Playwright或Pytest，用Java就考虑Selenium+TestNG）。
定个章程：单元测试谁写？接口测试覆盖到什么程度？免得后面扯皮。

（2）开发中期（偷偷打基础的好时机）
等核心功能代码写得差不多了，就可以开始铺垫了：

逼着开发小哥写单元测试（比如用JUnit测工具类，用Pytest测计算逻辑），不写不准合并代码。
接口文档一定型，立马用Postman搭自动化检查（参数校验、错误码这些最容易埋雷）。
先挑两三个稳定的页面（比如后台管理系统）试水UI自动化，积累经验。

（3）功能稳定后（全面铺开的关键阶段）
这时候改需求没那么频繁了，适合大规模铺自动化：

把手工用例筛一遍，优先转化高频执行的回归用例（比如每天要测的登录、下单）。
接口测试加压力检查（用JMeter模拟高并发，提前发现性能瓶颈）。
UI自动化重点保主干流程（别纠结边边角角的样式，主要看流程能不能跑通）。

（4）上线后维护期（保持自动化鲜活）
这时候最容易松懈，但其实是自动化价值最大的时候：

每次迭代新功能，要求至少带3-5个自动化用例进来（就当交"保护费"）。
定时清理过时脚本（特别是XPath定位的元素，前端改个class名就能让脚本挂掉）。
把自动化测试钉进CI/CD流程（比如Git push触发测试，失败就卡住发布）。

踩过的坑：

新手最容易犯的错就是贪多，一上来就想自动化所有用例。结果需求一变，维护成本直接爆炸。
UI自动化别当万能药，曾经有个项目70%的自动化都是E2E测试，后来前端框架升级，全组人加班改脚本改到凌晨。
一定要让开发参与进来，测试单打独斗搞自动化，最后容易变成烂尾工程。

10.自动化脚本编写过程中遇到过什么问题?
   1. 检查自己定位方式是否有误?
   2. 程序加载过快,页面来不及反应? -- 元素等待
   3. 有些输入框必须先点击,再输入
   4. 需要操作的元素在新窗口? -- 切换到新窗口
   5. 需要操作的元素在frame/iframe标签内? -- 切换表单
   6. 需要操作的元素被其他元素遮挡了? -- 修改display的值为none
   7. 需要操作的元素是个只读元素? -- 修改value的值.或者删掉readonly属性.
   8. 需要操作的元素在页面靠下位置?-- 操作滚动条