学习软件测试的第一天

我会首先用通俗易懂的语言解释这个概念，然后再总结为面试术语。

一.黑盒/白盒测试的区别：

1.通俗解释

（1）黑盒测试：把系统当作一个“黑盒子”，只关心输入和输出，不关心内部代码怎么实现的。

可比喻为，用一个咖啡机：你只管按按钮（输入），看有没有出咖啡（输出），不会拆开机器研究里面电路。

（2）白盒测试：把系统当成“透明盒子”，测试人员需要了解内部结构/逻辑/代码流程，从而设计测试用例。

可比喻为，检查一个咖啡机的内部电路、是否电线正确连接，程序逻辑有没有死循环、分支是否都能跑到。

2.表格比较

维度	黑盒测试	白盒测试
是否了解代码	❌ 不需要	✅ 必须了解
测试关注点	输入和输出	程序内部结构
设计依据	需求文档、功能说明	代码逻辑、流程图
测试粒度	功能级别、接口级别	代码级别、单元级别
常用方法	等价类、边界值、因果图、状态迁移等	条件覆盖、路径覆盖、分支覆盖等
使用者	测试工程师	开发、白盒测试人员
优势	更贴近用户，易发现功能问题	覆盖更彻底，能发现隐藏逻辑漏洞

3.面试术语

面试官提问：“你能讲讲黑盒测试和白盒测试的区别吗？”

（1）黑盒测试是从用户角度出发，不关心程序的内部结构和实现逻辑，而是根据需求文档、接口文档等，关注系统是否按预期功能运行。我们常用的黑盒测试方法有等价类划分、边界值分析、错误推测法等，适用于功能测试、接口测试、系统测试等场景。
（2）白盒测试则是从程序内部角度出发，测试人员需要了解源码，基于代码逻辑来设计测试用例，确保每个判断分支、路径都被覆盖。它适用于单元测试、模块测试阶段。常见的白盒测试方法包括语句覆盖、分支覆盖、条件组合覆盖等。
（3）总的来说，黑盒测试注重功能正确性，白盒测试注重逻辑完整性。实际工作中，我们会结合使用，比如先白盒测试单元模块，再用黑盒测试系统功能。

举个通俗易懂的例子：

比如你要测试一个 ATM 机： 黑盒测试：你在机器上插卡 → 输入密码 → 提钱，看系统是否正常工作，卡有没有被吞。 白盒测试：你打开 ATM 的程序源代码，看密码校验函数是否有逻辑漏洞，是否有非法路径。

二.如何制定测试计划：

1.整体流程

测试计划是对软件测试活动的整体安排文档，内容涵盖：测试目标、测试范围、测试方法、测试资源、人力安排、时间进度、风险预案、交付物等。

（1）明确测试目标：是验证新功能？回归测试？性能评估？或者等等

假设是，验证App用户登录模块的正确性与安全性。

（2）确定测试范围：要测哪些模块？不测哪些部分？

示例，本次测试包括注册、登录、忘记密码功能，不包括支付模块。

（3）明确测试策略

测试类型：功能测试、接口测试、性能、安全测试等

测试方法：黑盒 / 白盒 / 手动 / 自动化 / 探索式测试等

（4）人员与资源分配

测试负责人、执行人、开发支持

所需工具：Postman、JMeter、模拟数据平台、测试环境等

（5）测试进度安排（测试日程表）：包括各阶段开始结束时间

（6）测试准入和退出标准

准入条件：代码完成、环境部署好、接口联调完成

退出条件：测试用例

（7）风险识别与预案

如需求变动大、接口不稳定、测试人员不足等；制定应对方案：如临时增加人手、自动化辅助等

（8）交付物和总结

输出物包括：测试计划、用例文档、缺陷报告、测试报告

项目测试结束后要有总结复盘

2.示例总结

测试目标：验证“订单管理模块”是否满足功能需求
测试范围：订单创建、查询、取消；不包括物流配送接口
测试方法：功能测试、接口测试（Postman）、边界值分析、负向用例
测试人员：1名测试+1名开发支持
时间计划：用例设计2天、执行3天、回归2天
风险：接口文档不完整 → 提前协调产品补全
交付物：测试计划、用例文档、测试日报、测试总结报告

3.面试术语

制定测试计划时，我通常会从以下几个方面来考虑：
（1）首先是明确测试目标和测试范围，明确哪些模块需要测试、哪些模块不测。
然后制定测试策略，包括采用哪些测试方法（如黑盒、接口测试、自动化测试等），需要哪些工具和环境支持。
（2）接着是安排人员分工和测试时间进度，确保每一阶段有明确的时间节点。同时我也会设定准入和退出标准，比如代码是否提测、缺陷关闭比例等。
（3）此外，测试计划还需要识别潜在风险，并制定预案。
（4）最后明确测试交付物，如测试报告、缺陷列表等，保证测试活动有始有终、有据可查。

三.在项目中如何保证软件质量：

综合性问题，回答时要突出“流程 + 方法 + 沟通 + 工具”四大维度。

1.四个方面

（1）规范测试流程，提前介入：

在需求评审阶段参与进来，及时发现逻辑漏洞与歧义；编写高质量测试用例，确保覆盖率；保证测试按计划、按阶段有序推进。

（2）多层次测试覆盖

功能测试、接口测试、UI测试、性能测试、安全测试；引入正向 + 负向用例，覆盖极端情况与异常场景；回归测试 + 自动化测试，减少重复出错。

（3）缺陷管理和质量闭环

缺陷分类、分级处理，确保严重问题优先修复；缺陷复测与回归策略清晰；输出测试报告，总结质量状况。

（4）跨角色协作和质量文化

测试不是最后一环，而是贯穿整个开发周期的质量保障者；与产品、开发、运维保持高效沟通，推动质量左移；推进代码评审、单元测试覆盖、CI集成等质量体系。

2.面试术语

在项目中，我会从以下几个方面来保障软件质量：

第一，测试流程规范化：从需求评审阶段开始介入，编写高质量测试用例，确保覆盖所有业务流程；

第二，多层级测试覆盖：不仅做功能测试，还结合接口测试、性能测试、负向测试等全方位验证系统；

第三，缺陷管理严格：对缺陷进行分级处理，高优先级问题立即跟进并回归验证，避免重复返工；

第四，强调跨团队沟通：和产品、开发保持紧密配合，推动测试左移和质量前置，同时利用自动化和工具提升效率；
最终通过这些方式形成从需求到上线的全流程质量保障闭环，确保项目高质量交付。

四.功能测试用例一般包含哪些内容？设计方法有那些？

1.功能测试用例一般包含哪些内容？

功能测试用例是用于验证一个功能点是否按照预期正常工作的测试文档，一条完整的用例应包含以下内容：

用例字段	说明	示例
用例编号	每条用例唯一标识	TC_Login_001
用例名称	简要描述该测试目标	登录成功测试
测试模块/功能点	所属的功能模块	用户模块 - 登录功能
前置条件	执行该用例之前需要满足的条件	用户已注册；APP已安装
测试步骤	用户操作过程	打开登录页→输入账号→输入密码→点击登录
输入数据	需要输入的值	账号：admin，密码：123456
预期结果	系统预期返回的行为	登录成功，跳转首页，显示用户名
实际结果	执行后的真实结果	登录成功，页面跳转正常
是否通过	判断测试是否成功	Pass / Fail
优先级	用例执行的重要程度	高 / 中 / 低
备注	其他补充说明	如数据来源说明

2.功能测试用例设计方法有哪些？

（1）等价类划分（Equivalence Partitioning） ✅

• 把输入数据划分为“有效类”和“无效类”，每类选一个代表

• 示例：手机号输入框 → 有效：11位数字；无效：空、字母、特殊符号、超长

（2）边界值分析（Boundary Value Analysis） ✅

• 边界值往往是系统容易出错的地方

• 示例：年龄限制 18-60 → 测试 17、18、60、61

（3）判定表法（Decision Table）

• 当输入条件较多时，将各种组合列成表格，覆盖所有业务规则

• 示例：会员是否享受优惠 =（是否登录 + 是否会员 + 是否活动日）

（4）状态迁移法（State Transition）

• 系统存在状态变化时使用，如订单状态：已下单 → 已支付 → 已发货 → 已签收

• 测试各种状态跳转是否正确、非法跳转是否被禁止

（5）因果图法（Cause-Effect Graphing）

• 用图的方式找出条件与结果之间的关系，生成判定表

• 适合复杂业务逻辑（如贷款审批系统）

（6）场景法 / 用户流程法（Scenario Testing）

• 模拟用户实际操作流程，如“用户注册 → 登录 → 下单 → 支付”

• 更贴近真实业务、适合覆盖端到端流程

（7）错误推测法

• 根据经验推测容易出错的情况进行测试，如空格、特殊字符、并发提交等

3.面试术语

（1）功能测试用例通常包括编号、名称、测试步骤、输入数据、预期结果、实际结果、优先级和备注等内容。用例的核心是清晰、覆盖全面，能有效验证功能是否符合预期。
（2）在设计方法上，我常用的包括等价类划分和边界值分析，这是最基础也是最常见的两种。另外像判定表法适用于复杂业务判断、状态迁移法适用于流程类系统，比如订单或审批流程。我在实际工作中也经常结合用户场景做端到端流程测试，用于发现跨模块逻辑错误。

五.APP测试和web测试的区别

1.整体比较

维度	App 测试	Web 测试
运行环境	手机终端（Android/iOS）	浏览器（Chrome、Edge、Firefox等）
访问方式	需下载安装	直接通过 URL 访问
操作复杂度	多种手势操作：滑动、长按、拖拽等	鼠标点击 + 键盘输入为主
兼容性测试	不同机型、不同系统版本差异大	主要是浏览器兼容（HTML/CSS/JS 渲染差异）
网络依赖	网络波动更影响体验	相对稳定
更新方式	需重新打包上传应用市场，用户下载	服务器端更新即可，用户自动访问最新版本
自动化工具	Appium、uiautomator、XCUITest	Selenium、Playwright、Puppeteer
安装/卸载测试	有（检查残留文件、注册表）	无需安装，不涉及卸载问题
资源占用关注点	电池、内存、CPU、发热等	主要关注浏览器资源占用
调试难度	相对较高（需要真机、模拟器）	较方便，可直接浏览器 F12 开发者工具
崩溃日志抓取	使用 logcat（Android）或 Xcode 控制台（iOS）	浏览器 Console 即可查看错误日志

2.面试术语

App 测试和 Web 测试的主要区别在于运行平台和测试关注点不同。

• App 是运行在手机上的，需要关注不同机型、不同系统版本下的兼容性、流畅度、电池消耗等问题，同时操作方式更加多样，比如滑动、拖拽、横屏等；

• 而 Web 应用则运行在浏览器中，测试更关注的是浏览器兼容性、页面响应速度、前后端交互逻辑等。
  此外 App 的安装、升级、卸载流程也需要测试，而 Web 系统则可以通过服务器更新直接生效。
  在测试工具方面，App 主要用 Appium、ADB、XCUITest 等，Web 则常用 Selenium、Postman、Chrome DevTools 等。