📑目录（俏皮版）
- 🤔为啥测试要搞这么多分类？
- 🎯按测试目标分：我们要测软件哪些方面？
- 2.1 UI 界面测试｜软件的 “颜值质检员”
- 2.2 功能测试｜软件会不会干活
- 2.3 性能测试｜软件跑的快不快
- 2.4 可靠性测试｜软件扛不扛造
- 2.5 安全性测试｜软件安不安全，防不防小偷
- 2.6 易用性测试｜软件用着爽不爽
- ▶️按执行方式分：跑不跑程序是分界线
- 3.1 静态测试｜不运行代码，火眼金睛找 bug
- 3.2 动态测试｜跑起来软件，实测看结果
- 🔍按测试方法分：看盒子还是看内部
- 4.1 白盒测试｜拆开盒子看内部逻辑
- 4.2 黑盒测试｜闭盒只看输入输出
- 4.3 灰盒测试｜半开半闭，介于两者中间
- 🧩按测试阶段分：造车类比，一步一步测
- 5.1 单元测试｜检查每一颗零件
- 5.2 集成测试｜零件拼一起测接口
- 5.3 系统测试｜整车完整大体检
- 5.4 冒烟测试｜新版本先通电亮个机
- 5.5 回归测试｜改完代码，防止旧毛病复发
- 5.6 验收测试｜客户验车，确认可以交付
- ✍️按操作手段分：人来测 or 机器帮我们测
- 6.1 手工测试｜人肉点点点
- 6.2 自动化测试｜让机器重复干活
- 👥按实施组织分：谁来做这个测试
- 7.1 Alpha 测试（α 内测）｜公司内部先玩一玩
- 7.2 Beta 测试（β 公测）｜真实用户线上体验
- 7.3 第三方测试｜外人中立做测评
- 🌍按地域划分：国内用还是全球跑
- 8.1 国际化测试｜出海软件适配全世界
- 8.2 本地测试｜只适配本土环境
- 📝萌新复习小结｜测试阶段执行顺序 & 面试高频考点
1 🤔为啥测试要搞这么多分类？
软件项目复杂，不同开发阶段、不同侧重点需要不同测试手段。把测试划分类别，可以让我们清楚：什么时间、测什么对象、用什么手段，方便管理测试工作，不漏掉质量风险。
📌举例子：开发写完单个方法的时候，我们做单元测试；全部模块拼完，做系统测试。
✨例子作用：区分不同阶段该干什么活，不会拿到版本不知道从哪里下手测试。
2 🎯按测试目标分：我们要测软件哪些方面？
核心：我们希望软件既要好看、能用、跑得快、不出错、又安全还好上手。
2.1 UI 界面测试｜软件的 “颜值质检员”
UI 测试（界面测试）：对照 UI 设计稿，检查页面展示，关注完整性、一致性、准确性、友好性；测试布局、字体、图片、各类控件（输入框、弹窗、滚动条、按钮）。
📌举例子：设计稿按钮文字是【百度一下】，实际页面按钮写成【百度】；导航栏少了 “知道” 栏目，这就是 UI 缺陷。
✨例子作用：保证产品页面和设计师产出保持一致，用户视觉体验统一，不会出现 “买家秀 vs 卖家秀”。
2.2 功能测试｜软件会不会干活
验证产品功能是否满足需求文档，不关注内部代码，只看操作之后结果是否符合预期；使用黑盒用例设计方法：等价类、边界值、场景法、错误猜测等写测试用例。
📌举例子：登录功能，输入正确账号密码应该登录成功；输入错误密码提示密码错误。
✨例子作用：保证软件业务可以正常运转，这是软件最基础的质量，功能崩了其他体验再好也没用。
2.3 性能测试｜软件跑的快不快
关注系统响应速度，并发压力；分析性能需求，设计执行测试，完成调优。日常现象：网页打开慢，查询列表加载很久。
📌举例子：博客系统，100 个人同时访问首页，页面加载需要 3 秒，需求要求必须 1 秒以内打开，这就是性能不达标。
✨例子作用：高并发场景下保障用户等待时间可控，防止用户因为卡顿流失。
2.4 可靠性测试｜软件扛不扛造（可用性）
可靠性（可用性）：系统正常对外提供服务的时间占总运行时间百分比。
公式：可靠性 = 正常运行时间/(正常运行时间+非正常运行时间)*100%
行业常用指标：99.99%、99.999%（4 个 9、5 个 9）。故障来源：硬件、断电、网络、软件 bug。
📌举例子：全年 7*24 运行系统，可用性 99.99%，全年允许故障停机时间约 52 分钟；如果网站一到晚上就崩溃，可用性就很差。
✨例子作用：衡量系统稳定程度，金融、军事系统对可用性要求极高。
2.5 安全性测试｜软件安不安全，防不防小偷
保护用户数据隐私、数据完整传输，抵御攻击；常见风险：SQL 注入、脚本输入、权限越权、数据篡改、身份伪造。手段：代码评审、渗透测试。
📌举例子：用户不需要登录，直接修改 URL 就可以看到别人的个人订单数据，属于权限控制的安全漏洞。
✨例子作用：防止用户信息泄露、被黑客篡改数据，规避重大安全事故。
2.6 易用性测试｜软件用着爽不爽
遵循 ISO25020 标准，包含：规范性、直观性、灵活性、舒适性。通俗讲：软件好不好学，好不好懂，操作反不反人类。
📌举例子：打开软件删除数据，没有二次确认弹窗，一点就直接删掉数据，普通用户很容易误操作，易用性差；手机键盘支持九宫格 / 全键盘 / 手写，属于灵活性做得好。
✨例子作用：降低用户学习成本，同样功能，易用性好的产品更受用户欢迎。
3 ▶️按执行方式分：跑不跑程序是分界线
唯一判断标准：有没有实际运行被测软件！
3.1 静态测试｜不运行代码，火眼金睛找 bug
不运行程序，检查代码、文档、界面；手段：代码走查、代码审查、静态扫描工具。
📌举例子：开发写完代码，测试 / 同事一起读代码，发现变量没有初始化、注释写的混乱，没有启动程序就发现问题。
✨例子作用：在程序运行之前就揪出缺陷，bug 发现越早修复成本越低。
3.2 动态测试｜跑起来软件，实测看结果
运行被测程序，输入测试数据，比对实际输出和预期结果；绝大多数日常测试都属于动态测试。
📌举例子：打开 APP，输入账号点击登录，观察是否登录成功，软件实实在在运行起来。
✨例子作用：模拟真实用户操作，发现运行时才会暴露出来的 bug。
4 🔍按测试方法分：看盒子还是看内部
4.1 白盒测试｜拆开盒子看内部逻辑
也叫结构测试、逻辑测试；看透程序内部代码逻辑，针对逻辑路径设计用例；分为静态白盒、动态白盒。
动态白盒覆盖：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖；多用于单元测试阶段。
📌举例子：一段 if 判断代码，设计用例把每一行代码、每一条分支都执行一遍，检查代码逻辑是否出错。
✨例子作用：挖掘代码逻辑里面隐藏分支漏洞，很多功能测试覆盖不到的代码路径靠白盒覆盖。
4.2 黑盒测试｜闭盒只看输入输出
完全不关心内部代码实现，只依据需求文档，给输入看输出；测试人员日常使用最多。
方法：等价类、边界值、场景法、因果图、错误猜测法。
优点：站在用户视角；缺点：无法覆盖全部代码。
📌举例子：测试注册功能，不知道后台代码怎么写，只输入不同手机号，看注册结果是否符合需求。
✨例子作用：模拟真实用户视角，保障业务需求全部实现，测试人员工作主体。
4.3 灰盒测试｜半开半闭，介于两者中间
兼顾输入输出结果，同时简单了解部分内部程序；多用于集成测试阶段。
📌举例子：做接口测试，我们调用接口传参看返回结果，同时简单看接口日志，了解内部部分处理逻辑，但不去逐行分析全部源码。
✨例子作用：弥补纯黑盒看不到内部、纯白盒工作量巨大的问题；但是不能替代黑盒测试。
💡萌新面试小笔记：开发更多使用白盒、灰盒；测试工程师日常工作黑盒使用最多。
5 🧩按测试阶段分：造车类比，一步一步测
执行顺序：单元测试 → 集成测试 → 系统测试（冒烟测试、回归测试穿插） → 验收测试
类比造车：零件检测 → 组装整车 → 车企完整质检 → 通电开机初检 → 修改之后复查 → 用户 4S 店验车。
5.1 单元测试｜检查每一颗零件
测试对象：软件最小单元（一个类、一个方法）；一般开发人员编写，白盒测试；编码阶段同步开展。
测试内容：接口、局部数据、路径、错误处理、边界。常用工具 JUnit。
📌举例子：冒泡排序方法，单独写代码测试：空数组、有序数组、重复元素数组，校验排序结果是否正确。
✨例子作用：把最小模块的 bug 提前消灭，模块本身没问题，后续集成才不容易踩坑。
5.2 集成测试｜零件拼一起测接口
把多个单元模块组装起来，重点测试模块之间接口、数据传递；单元测试完成之后执行，黑白盒结合。
📌举例子：登录模块和个人信息模块，单独都没问题；登录完成跳转个人主页，拿不到用户信息，属于模块之间接口传参出错，集成测试发现该问题。
✨例子作用：很多 bug 不是模块本身坏了，而是模块之间配合出问题，专门解决接口交互缺陷。
5.3 系统测试｜整车完整大体检
全部模块集成完毕，对完整软硬件系统做测试；黑盒，依据需求规格说明书；覆盖功能、UI、性能、安全、兼容性、易用性全部内容。
📌举例子：完整电商 APP，从头到尾测浏览商品、加购、下单、支付、退款整套全部业务，同时测卡顿、页面显示、安全性。
✨例子作用：完整模拟真实使用场景，确认整个系统整体质量达标。
5.4 冒烟测试｜新版本先通电亮个机
新版本提测之后正式系统测试之前执行；只跑核心主流程，验证版本能不能测，如果主流程直接崩，直接打回开发。
📌举例子：博客新版本提测，冒烟测试只测：能不能打开网站、登录、发布一篇文章；如果网站直接打不开，不开展详细测试，退回开发修复。
✨例子作用：避免测试人员在一个完全跑不起来的版本浪费大量时间。
5.5 回归测试｜改完代码，防止旧毛病复发
每当修复 bug、新增功能，重新测试原有业务；确认修改代码没有搞坏老功能。可手工、可自动化，各个阶段都会做。
📌举例子：修复 “登录报错” bug 之后，不仅测登录，还要回头测试收藏、下单这些老功能，确认没有被改崩。
✨例子作用：代码改动很容易牵一发而动全身，防止修复一个 bug 引出一堆旧功能 bug。
📝萌新区分冒烟 & 回归：
- 冒烟：新版本第一关，只看核心流程能不能跑，快速判断版本可不可测。
- 回归：代码改动后，校验老功能不受影响，范围比冒烟大很多。
5.6 验收测试｜客户验车，确认可以交付
系统测试全部通过之后；由用户 / 需求方执行，黑盒测试，交付上线前最后一步，看产品是否满足合同和用户需求。
📌举例子：公司采购一套 OA 系统，甲方业务人员实际上手操作全部业务，确认符合自己办公需求，签字确认验收。
✨例子作用：站在客户视角确认产品达到交付标准，客户说合格才可以上线交付。
6 ✍️按操作手段分：人来测 or 机器帮我们测
6.1 手工测试｜人肉点点点
测试人员手动输入用例，观察软件结果，最基础的测试方式。
✅优点：可以发散探索测试，不需要很强代码基础；❌缺点：重复工作效率低，人力成本高。
📌举例子：测试同学手动点击 APP 每一个按钮，输入各种数据，记录 bug。
✨例子作用：很多探索性、UI 主观体验，自动化很难替代手工测试。
6.2 自动化测试｜让机器重复干活
写脚本，机器自动执行测试步骤；适合重复执行的场景，接口自动化、UI 自动化、性能自动化。
✅优点：重复用例效率高，节省人力；❌缺点：需要代码能力，不适合做发散探索。
📌举例子：写自动化脚本，每次版本更新自动跑一遍登录、下单流程，不需要人重复点点点，常用于回归测试。
✨例子作用：大量重复回归场景，解放人力；接口自动化投入产出比高于 UI 自动化。
7 👥按实施组织分：谁来做这个测试
7.1 Alpha 测试（α 内测）｜公司内部先玩一玩
内测，公司内部人员，模拟用户环境，环境开发可控，用户数量少，时间集中，程序员、专职测试不能做 α 测试。
📌举例子：APP 新版本还没对外，公司其他部门同事内部下载试用，收集反馈。
✨例子作用：对外公测之前，内部先发现一批问题。
7.2 Beta 测试（β 公测）｜真实用户线上体验
公测，真实外部用户，在自己真实的环境使用软件，环境不受开发管控，用户数量多，时间分散；Alpha 测试完成之后才进行 Beta。
📌举例子：APP 发布公测邀请，普通用户拿到邀请码下载新版本体验反馈 bug。
✨例子作用：在多种多样真实用户环境，发现公司内部复现不了的问题。
7.3 第三方测试｜外人中立做测评
独立第三方测评机构，不属于开发方，中立评估软件质量，产出测试报告。
📌举例子：政务软件上线前，委托专门测评公司完成安全、功能测评，拿到官方测评报告。
✨例子作用：中立客观，很多项目上线要求必须第三方测评。
8 🌍按地域划分：国内用还是全球跑
8.1 国际化测试｜出海软件适配全世界
验证软件在不同国家语言、地区正常工作；关注点：翻译、页面布局、时间、日期、货币、数字格式。
📌举例子：打车软件出海墨西哥，切换西班牙语，日期格式、货币比索符号展示正确，文字不会超出界面。
✨例子作用：软件出海，适配不同地区的习惯，不会出现文字乱码、布局错乱。
8.2 本地测试｜只适配本土环境
软件只面向本国用户，我们前面学的大部分测试都属于本地测试。
📌举例子：只面向国内用户的 OA 系统，只需要适配中文、人民币、国内时间格式。
✨例子作用：聚焦本土用户习惯，不需要做多语言多地区适配。
