软件测试基础面试问答（三）

1、UI测试是什么？

UI测试（用户界面测试）是软件测试的一种类型，专注于验证应用程序的用户界面（UI）是否按照设计要求正常显示和交互。它的核心目标是确保用户界面的功能、视觉效果、易用性和一致性符合预期，从而提供良好的用户体验。

UI测试的主要内容：

功能测试：验证界面元素（按钮、输入框、下拉菜单等）是否能正确触发操作。例如：点击登录按钮是否能跳转到目标页面。
布局与视觉测试：检查UI组件的位置、大小、颜色、字体等是否符合设计稿。例如：文本是否对齐，图片是否适配不同屏幕尺寸。
兼容性测试：确保UI在不同设备（手机、PC、平板）、浏览器（Chrome、Firefox）或操作系统（Windows、iOS）上正常显示。
交互测试：测试用户操作（滑动、拖拽、长按等）的响应是否符合预期。例如：下拉刷新功能是否正常加载数据。
无障碍测试（Accessibility）：验证界面是否支持屏幕阅读器、键盘导航等，满足残障用户需求。

2、UI的测试方法？

手动测试：人工操作界面并验证结果，适合复杂交互或主观体验测试。
自动化测试：通过工具（如Selenium、Cypress、Appium）编写脚本自动执行重复性测试，提高效率。
快照测试：对比当前UI与基准截图，检测意外变更（常用工具：Jest、Storybook）。

典型工具示例

Web端：Selenium, Playwright, Cypress
移动端：Appium, Espresso (Android), XCTest (iOS)
视觉回归：Percy, Applitools

3、UI测试与普通测试方法使用边界值方法有什么区别？

维度		UI测试	普通测试（功能/单元测试）
测试对象不同	测试焦点	用户界面的显示、交互和兼容性	代码逻辑、数据处理、API接口等底层功能
	示例场景	输入框的字符限制是否在UI层生效	函数对输入参数的边界值处理是否正确
	测试示例	测试一个输入框允许输入的最大字符数（如100字），需验证：输入99/100/101字符时，UI是否显示正确提示（如“超出限制”）。输入超长文本时，界面布局是否错乱。	测试一个处理字符串的函数：输入空字符串、最大长度字符串、超长字符串，验证函数是否抛出异常或截断。
边界值类型不同	典型边界	屏幕尺寸(如最小/最大分辨率) 输入字段长度(如0/最大/超长字符) 多语言文本(超长翻译词)	数值范围(如0、负数、最大值) 集合的空/满状态时间戳的极值
边界值类型不同	测试示例	移动端横竖屏切换时，按钮是否可见。不同语言环境下（如德语长单词），文本是否被截断。
验证方式不同	判断标准	视觉表现、交互响应、兼容性	输出结果、返回值、异常处理
	工具差异	需要截图对比、视觉回归工具（如Percy）	通过断言直接验证（如JUnit、Pytest）
	测试示例	输入框输入边界值后，通过自动化工具（如Selenium）检查页面是否显示错误提示。使用Appium测试移动端按钮在屏幕边缘的点击区域是否有效。	单元测试中，调用函数并断言其返回值是否符合预期（如assertEquals(result, expected)）
执行效率与稳定性	执行速度	较慢（依赖渲染、网络、设备）	极快（直接运行代码）
执行效率与稳定性	稳定性	较低（易受环境变化影响，如分辨率、浏览器版本）	较高（隔离性强）
核心区别心	目标	确保界面表现和交互正确	确保逻辑和功能正确
	边界值重点	视觉、布局、输入限制、多端兼容性	数据范围、算法健壮性、异常流程
	工具链	Selenium, Cypress, Appium	JUnit, Pytest, Jest
	维护成本	较高（需适配UI变更）	较低（逻辑稳定时）

4、判断三个整数能否构成三角形，黑盒设计测试用例？

设计判断三个整数能否构成三角形的黑盒测试用例，只关注输入（三个整数a, b, c）和输出（布尔值：true 表示能构成三角形，false 表示不能）。三角形的构成条件是：任意两边之和必须严格大于第三边，即必须同时满足：a + b > c，a + c > b，b + c > a。

覆盖关键场景：
有效三角形（输出 true）：所有条件满足。
无效三角形（输出 false）：至少一个条件不满足（包括两边之和等于或小于第三边）。
边界值：测试输入在边界附近（如最小值、最大值、零、负数、等式边界）。
输入顺序：确保函数对输入顺序不敏感。
特殊值：零、负数、大整数（测试溢出或性能）。

	测试用例ID	输入 (a, b, c)	预期输出	设计理由（验证点）
有效三角形	1	(3, 3, 3)	TRUE	等边三角形（所有边相等，所有条件满足）
	2	(5, 5, 8)	TRUE	等腰三角形（两等边，所有条件满足：5+5>8, 5+8>5, 5+8>5）
	3	(3, 4, 5)	TRUE	直角三角形（满足勾股定理，所有条件满足：3+4>5, 3+5>4, 4+5>3）
	4	(7, 10, 5)	TRUE	一般三角形（所有条件满足：7+10>5, 7+5>10, 10+5>7）
	5	(1, 1, 1)	TRUE	最小正整数（所有条件满足）
	6	(1000000, 1000000, 1000000)	TRUE	大整数等边（测试大数处理和性能，所有条件满足）
	7	(10, 10, 19)	TRUE	边界有效（10+10>19, 10+19>10, 10+19>10，严格大于）
	8	(5, 3, 4)	TRUE	输入顺序不同（与(3,4,5)相同，验证顺序不敏感）
	9	(4, 5, 3)	TRUE	输入顺序不同（与(3,4,5)相同，验证顺序不敏感）
无效三角形	10	(1, 2, 3)	FALSE	两边之和等于第三边（1+2=3，不满足严格大于）
	11	(1, 2, 4)	FALSE	两边之和小于第三边（1+2=3<4）
	12	(2, 3, 5)	FALSE	两边之和等于第三边（2+3=5，边界退化）
	13	(2, 3, 6)	FALSE	两边之和小于第三边（2+3=5<6）
	14	(0, 1, 2)	FALSE	包含零（边长必须为正，0+1=1<2）
	15	(0, 0, 0)	FALSE	所有零（非正边长无效）
	16	(-1, 2, 3)	FALSE	包含负数（边长必须为正）
	17	(1000000, 500000, 500000)	FALSE	大数无效（500000+500000=1000000，等于第三边）
	18	(1000000, 1, 2)	FALSE	大数无效（1+2=3<1000000）
	19	(1, 1, 3)	FALSE	条件失败顺序1（a+b=2<3，验证 a+b>c 失败）
	20	(1, 3, 1)	FALSE	条件失败顺序2（a+c=2<3，验证 a+c>b 失败，输入顺序敏感测试）

5、Bug的提交流程，Bug的生命流程示意图，Bug严重性分级标准

Bug流程管理：

发现Bug ——> 本地验证 ——> 填写Bug表单 ——> 分配跟进 ——> 修改验证（回归测试） ——> 闭环归档

Bug的生命流程示意图：

Bug严重性分级标准：

`P0-致命`	核心功能瘫痪、数据丢失、安全漏洞	2小时内	全部用户无法支付、数据库被删
`P1-严重`	主路径阻塞，影响关键业务	24小时内	30%用户提交订单失败
`P2-一般`	非核心功能异常，有替代方案	3天内	个人中心头像显示错位
`P3-轻微`	界面错别字、边缘场景体验问题	下一版本	深色模式下按钮边框颜色不协调

6、手工测试和自动化测试哪个时间更长？

首次执行	短（直接操作）	长（需开发脚本）	✅ 手工胜出
重复执行	长（每次人工重测）	短（一键触发）	✅ 自动化胜出
维护成本	低（需求变更时无需额外操作）	高（脚本需随需求更新）	⚠️ 手工占优
执行速度	慢（受限于人工速度）	快（并行执行+毫秒级响应）	✅ 自动化胜出
覆盖范围	窄（难以覆盖大量数据/组合）	广（可覆盖百万级数据组合）	✅ 自动化胜出
环境等待	长（依赖测试环境就绪）	短（可定时/触发执行）	✅ 自动化胜出

影响时间效率的关键因素：

高迭代频率	每次需全量重测 → 时间线性增长	维护脚本 → 但远低于手工重测成本
复杂数据组合	人工组合易漏 → 返工耗时	参数化测试 → 一次性覆盖所有组合
跨平台兼容性	重复测试每台设备 → 时间倍增	云平台并行执行 → 时间几乎不变
非功能测试	难以手工压测/7*24监控	自动化必选方案（如JMeter脚本）

选择哪种测试方式：

#测试面经##测试#

测试岗面经文章被收录于专栏

整理面试过程中的测试问答，常看常新，多多学习！有些问题是从其他人那里转载而来，会在文章下面注明出处，希望大家多多支持~~，觉得满意的话就送一朵小花花，谢谢！内容目录：https://www.nowcoder.com/discuss/779856598809264128?sourceSSR=users