目录
1. 按照测试目标分类
1.1 界面测试
一款软件, 是通过界面来和用户交互的.
软件的界面, 正如人的外观一样, 往往是决定他人对我们第一印象的根本要素.
界面测试, 就是验证软件的用户界面是否美观、布局是否合理、控件是否正确显示和交互.
软件开发时, 开发人员是参考设计图进行开发的; 测试时, 测试人员也是依据设计图进行测试的.
关注点： 软件的界面元素、颜色、字体、排版等
1.2 功能测试
功能测试, 就是验证软件的功能是否符合需求规格说明书(需求文档)的要求, 是否能按照预期正常工作.
关注点： 软件的各项功能、输入输出、逻辑处理、错误处理等.
比如, 对一个保温水杯进行功能测试, 我们就要测试它是否能盛水, 是否能喝水, 是否能保温.
1.3 性能测试
性能测试, 评估软件在不同负载条件下的性能表现(测试抗压能力怎样), 例如响应时间、吞吐量、资源利用率等.
关注点： 软件的性能瓶颈、稳定性、可伸缩性等。
常见类型： 负载测试、压力测试、容量测试、耐久性测试等。
测试当程序接收高并发的请求量时, 是否会导致程序瘫痪(比如, 我们常常见到某某软件 "崩了", 这就是这个软件的性能不足以承受高并发导致的结果).
1.4 可靠性测试
可靠性, 即可用性, 指系统正常运行的能力或者程度, 一般用正常向用户提供软件服务的时间, 占总时间的百分比表示.
可靠性 = 正常运行时间 / (正常运行时间 + 非正常运行时间) * 100%
可用性指标一般要求达到 4 个或 5 个 "9", 即 99.99% 或者 99.999%
如果可用性为 99.999%, 那么对于一个全年不间断(7 * 24)运行的程序, 在一整年中即 365 * 24 * 60 = 525600 min 中, 正常运行(无故障发生)的时间为 525600 * 99.999% = 525594.744 min, 发生故障的总时长不能超过 525600 - 525594.744 = 5.256 min.
1.5 安全性测试
安全性是指信息安全, 是指计算机系统或网络保护用户数据隐私, 完整, 保护数据正常传输和抵御
黑客, 病毒攻击的能力.
测试目标： 评估软件是否存在安全漏洞，例如 SQL 注入、跨站脚本攻击（XSS）、身份验证绕过等.
关注点： 软件的安全性、保密性、完整性、可用性等.
常见类型： 渗透测试、漏洞扫描、安全审计等.
1.6 易用性测试
易用性测试, 就是评估软件的用户界面是否友好、操作是否便捷、用户是否容易学习和使用.
比如, 现在的游戏, 都会有新用户指导等.
2. 按照执行方法分类
2.1 静态测试
静态测试, 即不运行被测程序, 而是通过人工或工具对程序代码、文档、设计等进行检查和分析, 在程序运行前发现缺陷，例如语法错误、逻辑错误、不符合编码规范等.
静态测试主要是开发人员进行的.
常见的静态测试方式有代码走查(一般由肉眼检查), 代码扫描工具等.
2.2 动态测试
动态测试, 即运行被测程序, 通过输入数据和观察程序的输出, 来验证程序的功能和行为是否符合预期. 在程序运行过程中发现缺陷，例如功能错误、性能问题、安全漏洞等.
判断一个测试属于动态测试还是静态的, 唯一的标准就是看是否运行程序.
大多数软件测试工作都属于动态测试.
3. 按照测试方法
3.1 黑盒测试
黑盒测试, 不关注程序的内部结构和代码实现, 而是将软件视为一个“黑盒子”, 只关心其输入和输出是否符合预期.
3.2 白盒测试
白盒测试(White-boxTesting), 与黑盒测试相对, 它关注程序的内部结构和代码实现. 测试人员需要了解程序的内部逻辑、算法、数据结构等, 然后根据这些信息设计测试用例, 以确保程序的每个部分都能正确工作.
简单来说, 白盒测试是面向代码的, 测试人员需要设计测试用例来验证代码的正确性.
白盒测试分为静态测试和动态测试两种.
其中, 白盒动态测试有以下几种:
- 语句覆盖
- 判定覆盖
- 条件覆盖
- 判定条件覆盖
- 条件组合覆盖
- 路径覆盖
这里给出一段伪代码, 接下来会通过这段伪代码解释以上 6 种白盒测试:
3.2.1 语句覆盖
语句覆盖, 就是设计测试用例, 使得程序中的每条语句都能够执行到.
简单来说, 就是让每条 if 语句的判断结果都为 true, 使得 if 下的语句能够执行:
3.2.2 判定覆盖
判定覆盖, 就是设计用例, 将 if 语句的判断结果(true 或 false)都覆盖到:
3.2.3 条件覆盖
条件覆盖, 即设计测试用例, 确保程序中的每一个条件语句中的每个子条件的结果(真或假)都至少被执行一次。
比如 if 中有 a , b 两个 boolean 的参数, 需要让 a, b 值为 true 和 false 都能执行一次.
3.2.4 判定条件覆盖
判定条件覆盖, 即将判定覆盖和条件覆盖进行结合, 使得测试用例即可以做到判定覆盖, 也可以做到条件覆盖.
如下图所示, 如果将判定覆盖和条件覆盖分开设计, 需要设计 4 个测试用例, 而通过判定条件覆盖将两者结合后, 只需要设计 2 个测试用例即可:
3.2.5 条件组合覆盖
条件组合覆盖, 覆盖程序中每一个判断语句中所有可能的条件组合, 即将每个 if 语句中的子条件的结果(true/false), 进行组合.
3.2.6 路径覆盖
路径覆盖, 即设计测试用例能够覆盖程序中所有可能的执行路径.
要覆盖程序中所有的路径, 通常需要以下几步:
- 判定组合覆盖
- 根据判定的结果, 设计满足的判定结果的条件结果
- 根据条件结果, 设计满足条件结果的具体数据
3.3 灰盒测试
灰盒测试, 是介于白盒测试与黑盒测试之间的一种测试, 灰盒测试多用于集成测试(开发人员进行的)阶段, 不仅关注
输出、输入的正确性, 同时也关注程序内部的情况.
但是, 灰盒测试没有白盒测试那样详细和完整, 也没有黑盒测试那样高的覆盖度. 因此, 灰盒测试不能取代白盒和黑盒.
3.4 面试题
常见面试题: 你知道的测试方法有哪些? 哪种用的比较多?
常见的测试方法有黑盒测试, 白盒测试和灰盒测试. 开发人员主要用白盒测试和灰盒测试, 测试人
员主要用白盒测试和黑盒测试. 对于测试人员来说, 相较于白盒测试, 黑盒测试用的更多一些.
4. 按照测试阶段分类
按照测试阶段, 测试分为:
- 单元测试(开发人员进行) =>
- 集成测试(开发人员进行) =>
- 系统测试(测试人员进行)=>
- 验收测试(产品经理或甲方验收)
4.1 单元测试
单元测试, 是对程序的最小单元进行测试. 其中, "最小单元" 是人为规定的,
单元测试是由开发人员完成的.
4.2 集成测试
集成测试, 就是把单元测试中的 "最小单元" 集成在一起执行测试, 既要保证代码没有问题, 也要保证软件的主要功能没有问题(灰盒测试).
集成测试也是由开发人员完成的.
4.3 系统测试
系统测试是对完整的、集成后的软件系统进行全面的测试，以验证系统是否满足其需求规格说明书所规定的功能和非功能特性。它关注整个系统的行为和性能.
系统测试分为以下两个阶段:
- 冒烟测试
- 回归测试
4.3.1 冒烟测试
冒烟测试, 是为了检查产品是否均有测试的条件.(因为上一个阶段测试, 是由开发人员完成的, 冒烟测试是测试人员接手程序后的第一次测试, 可能程序连运行都不能运行, 因此要进行 "冒烟" 测试)
如果冒烟测试通过, 则测试人员开始进行正式的系统测试, 如果不通过, 则测试人员可以让开发人
员重新修复代码直到冒烟测试通过, 再开始进行系统测试.
在生活中,
购买一个电视, 首先会通电, 查看电视是否能够运行.
购买一个水杯, 首先会灌水, 查看水杯是否漏水.
在工作中,假如有一个博客系统项目提测了, 冒烟测试即只需要测试系统是否能够成功打开, 主流程是否可以走通即可.
冒烟测试, 在软件开发的早期进行, 主要用于验证基本功能是是否正常工作, 是否值得进行更深入的测试.
4.3.2 回归测试
回归测试（Regression Testing） 是指在软件发生变更（例如修复 Bug、添加新功能、优化性能等）后，重新测试之前已经测试过的功能，以确认所做的变更没有引入新的 Bug，并且没有对现有功能产生不利的影响。
也就是说, 只要软件版本每发生一次变更, 就需要测试以往 "旧" 的历史功能是否正常, 因此需要做大量重复的工作, 因此, 回归测试主要包括人工测试和自动化测试两种.
回归测试, 在软件开发的后期进行, 用于确保已有的功能仍然能够正常工作, 防止已有功能因为新增代码而出现问题.
4.4 验收测试
验收测试（Acceptance Testing） 是软件测试的最后一个阶段，也是非常关键的一个环节。 它的主要目的是验证软件是否满足用户的需求和期望，并最终决定是否接受（验收）该软件。
验收测试主要由产品经理或甲方来进行.
- 如果这款软件是公司的内部产品, 那么主要由产品经理来进行验收.
- 如果软件是为外部客户或组织开发的，那么甲方（即购买或定制该软件的组织）是最终的验收者.
5. 按照是否手工测试
分我手工测试和自动化测试两种.
5.1 手工测试
手工测试就是由测试人员去一个一个的输入用例(不借助任何自动化工具), 然后观察结果, 和自动化测试相对, 属于比较原始但是必须的一个步骤.
5.2 自动化测试
自动化测试, 就是利用开发好的专门的自动化测试工具或编写测试脚本，自动执行预先设计好的测试用例，并自动比较实际结果和预期结果，生成测试报告。
适用场景:
回归测试： 在软件变更后，快速、可靠地验证已有功能是否受到影响。
重复性高的测试： 对于需要频繁执行的测试用例，可以大大提高效率。
性能测试： 模拟大量用户并发访问，评估系统的性能指标。
兼容性测试： 在不同的操作系统、浏览器等环境下自动执行测试。
数据驱动测试： 使用不同的输入数据自动执行相同的测试逻辑。
自动化测试, 按照测试对象来分, 分为:
- 接口自动化测试
- UI(界面, User Interface Automation)自动化测试
其中, UI 自动化测试, 又分为:
- Web 界面自动化测试 => Web 界面, 是指网页界面, 如百度网页
- 客户端界面自动化测试 => 客户端界面, 是指 APP 界面, 如手机抖音 APP
5.3 手工测试和自动化测试优缺点对比 [面试题]
| 自动化测试 | 手工测试 | |
|---|---|---|
| 适用场景 | 重复性高、回归测试、压力测试、接口测试等 | 复杂业务流程、探索性测试、UI/UX测试 |
| 执行速度 | 快，可以并行执行 | 慢，需要人工操作 |
| 成本 | 前期投入高，长期成本低 | 低成本，但长期效率低 |
| 灵活性 | 受限于脚本，难应对频繁变化 | 人工判断能力强，适应变化快 |
| 准确性 | 可避免人为错误，但可能因脚本问题导致假阳性/假阴性 | 容易受人为因素影响，出错率较高 |
面试题: 自动化测试可以代替手工测试吗?
不能!!
🔴 探索性测试：人工测试人员可以发现意外的bug，而自动化脚本只能测试预设场景。
🔴 UI/UX体验：用户体验、界面美观、交互流畅性需要人为判断，自动化测试无法精准衡量。
🔴 需求变更快的场景：如果产品界面、交互频繁变化，自动化脚本的维护成本过高。
🔴 异常场景处理：有些特殊情况（如非标准输入、异常弹窗等）可能很难用脚本完全覆盖。
✅ 自动化测试能减少手工测试，但无法完全替代手工测试。
✅ 自动化测试适用于稳定、重复性的测试，而手工测试更适合探索性、UI/UX等复杂场景。
✅ 企业通常会结合两者使用，以提高测试效率和质量。
6. 按照实施组织划分
在大型软件发布前, 通常需要进行 α 测试和 β 测试:
6.1 α 测试
α 测试, 又称为 a 测或内测, 在 开发环境 中由 公司内部人员 进行的测试, 模拟真实用户的使用场景, 目的是找出软件中存在的缺陷和问题, 并进行修复.
6.2 β 测试
β 测试, 又称为 b 测或公测, 由 外部用户 (非公司内部人员，可以是志愿者、早期用户或特定用户群体) 进行的.
β 测试是介于 α 测试和正式发布之间的阶段, 虽然是由真实用户来完成, 使用真实用户的环境, 但它仍然是一个测试环境, 而不是真正的线上环境(正式发行前的测试).
比如: 王者荣耀体验服.
6.3 α 测试和 β 测试的区别
| 特性 | α 测试 (Alpha Testing) | β 测试 (Beta Testing) |
| 环境 | 开发环境 | 真实用户环境 |
| 参与者 | 内部人员 | 外部用户 |
| 主要目标 | 发现缺陷和问题 | 收集用户反馈，评估真实环境表现 |
| 控制程度 | 高 (内部测试, 测试人员可以使用调试工具, 并且可以快速修复发现的问题) |
低 (外部测试, 测试人员只能通过收集用户反馈来了解软件的问题, 修复问题可能需要更多的时间) |
| 时间 | 开发早期阶段(持续时间短) | 开发后期阶段(持续时间长) |
6.4 第三方测试
第三方软件测试是指由独立的第三方公司或组织进行的软件测试活动.
比如: 公司内部开发完成后, 将测试工作外包给外包公司进行测试.
7. 按照测试地域划分
按照测试地域划分, 分为:
- 国际化测试
- 本地测试
国际化测试, 就是对国外版软件进行测试, 确保软件能够适应不同的语言、文化和区域设置, 确保软件能够让海外用户使用.
本地测试, 就是在国内对软件进行测试, 确保软件能够在国内正常使用.
比如: 拼多多. 在国内就是 拼多多. 而海外产品称为 Temu; 抖音, 在国内就是抖音, 在海外版为 Tik Tok.
END