目录
朋友们请记住，
人生除了死都没大事，
死了更没事哈哈。
------ 25.10.29
一、为什么要对软件测试进行分类
软件测试是软件生命周期中的一个重要环节，具有较高的复杂性，对于软件测试，可以从不同的角度加以分类，使开发者在软件开发过程中的不同层次、不同阶段对测试工作进行更好的执行和管理测试的分类方法。
二、按照测试目标分类
1.界面测试
界面测试（简称UI测试)，指按照界面的需求（一般是UI设计稿）和界面的设计规则，对我们软件界面所展示的全部内容进行测试和检查，一般包括如下内容：
• 验证界面内容显示的完整性，一致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示；
• 验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求；
• 对界面不同控件的测试，比如，对话框，文本框，滚动条，选项按钮等是否可以正常使用，有效和无效的状态是否设计合理；
• 界面的布局和色调符合当下时事的发展。
2.功能测试
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试，通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。
如何进行功能测试？
设计功能测试用例，参考产品规格说明书进行用例的编写，具体的测试用例需要使用黑盒设计测试用例的方法，如等价类、边界值、判定表法、正交法、场景法、错误猜测法等。
3.性能测试
我们在使用软件的时候有时会碰到软件网页打开时越来越慢，查询数据时很长时间才显示列表，软件运行越来越慢等问题，这些问题都是系统的性能问题引起的。要进行软件产品的性能问题，要对产品的性能需求进行分析，然后基于系统的性能需求和系统架构，完成性能测试的设计和执行，最后要进行持续的性能调优。
4.可靠测试
可靠性（Availability）即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务的时间占总时间的百分比表示。
可靠性 = 正常运行时间 /（正常运行时间+非正常运行时间）* 100%
隔壁村有个人叫老王，让老王请吃饭，要求了十次，但是他只请了一次，那么我们说老王的可靠性是10%，那么我们称老王这人不可靠
如果让老王请吃饭，要求了十次，每次他都请客了，可靠性是100%，那么老王是个可靠的人
系统非正常运行的时间可能是由于硬件，软件，网络故障或任何其他因素（如断电）造成的，这些因素能让系统停止工作，或者连接中断不能被访问，或者性能急剧降低导致不能使用软件现有的服务等。
可用性指标一般要求达到4个或5个"9"，即99.99%或者99.999%
如果可用性达到99.99%，对于一个全年不间断（7*24的方式）运行的系统，意味着全年
（252600min）内不能正常工作的时间只有52min，不到一个小时。
如果可用性达到99.999%，意味着全年不能正常工作的时间只有5min。
不同的应用系统，可用性的要求是不一样的，非实时性的信息系统或一般网站要求都很低，99%和
99.5%就可以了，但是军事系统，要求则很高
5.安全性测试
安全性是指信息安全，是指计算机系统或网络保护用户数据隐私，完整，保护数据正常传输和抵御黑客，病毒攻击的能力。
安全性测试属于非功能性测试很重要的一个方面，系统常见的安全漏洞和威胁如下
• 输入域，如输入恶性或者带有病毒的脚本或长字符串；
• 代码中的安全性问题，如SQL / XML注入
• 不安全的数据存储或者传递
• 数据文件，邮件文件，系统配置文件等里面有危害系统的信息或者数据；
• 有问题的访问控制，权限分配等
• 假冒ID：身份欺骗
• 篡改，对数据的恶意修改，破坏数据的完整性
安全性测试的方法有代码评审，渗透测试，安全运维等，常用的静态安全测试工具有，Coverity，IBM Appscan Source，HPFortify，常用的动态安全测试有OWASP的ZAP，HP WebInspect等。其中静态安全测试是常用的安全性测试的方法。
6.易用性测试
许多产品都应用人体工程学的研究成果，是产品在使用起来更加灵活和，舒适。软件产品也始终关注用户体验，让用户获得舒适，易用的体验，针对软件这方面的测试称之为易用性测试。
易用性在ISO25020标准中指容易发现，容易学习和容易使用。易用性包含七个要素：**符合标准和规范，直观性，一致性，灵活性，舒适性，正确性和实用性。**我们主要讨论以下几个方面
Ⅰ、标准性和规范性
对于现有的软件运行平台，通常其UI标准已经不知不觉地被确立了，成为大家的共识。多数用户已经习惯并且接受了这些标准和规范，或者说已经认同了这些信息所代表的的含义。比如安装软件的界面的外观，在什么场合使用恰当的对话框等。
所以用户界面上的各中信息应该符合规范和习惯，否则用户使用起来会不舒适，并得不到用户的认
可。测试人员需要把与标准规范，习惯不一致的问题报告为缺陷
Ⅱ、直观性
用户界面的直观性，要求软件功能特性易懂，清晰。用户界面布局合理，对操作的响应在用户的预期之中。比如数据统计结果用报表的形式（条形图，扇形图等）展示清晰直观；现在主流的很多搜索引擎和日历的设计也有直观性的特点；
Ⅲ、灵活性
软件可以有不同的选项以满足不同使用习惯的用户来完成相同的功能。但是灵活性的设计要把握好
度，不然可能由于太多的用户状态和方式的选择，增加了软件设计的复杂性，和程序实现的难度。 例如：手机键盘有九宫格和全键盘，还支持手写，满足了不同用户的需求
Ⅳ、舒适性
舒适性主要强调界面友好，美观，操作过程顺畅，色彩用运恰当，按钮的立体感等。
三、按照执行方式进行分类
1.静态测试
所谓静态测试（static testing）就是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。
不以测试数据的执行而是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻
辑、代码风格和规格等来检查程序的正确性。
常见的静态测试方式有代码走查，代码扫描工具等。
2.动态测试
动态测试（dynamic testing），指的是实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。
大多数软件测试工作都属于动态测试
四、按照测试方法
1.白盒测试
白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。
白盒测试的测试目的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
白盒测试主要分为静态测试和动态测试两种。静态测试常见于桌面检查、代码审查、代码走查、代码扫描工具
动态测试方法主要包含六种测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
总结
• 白盒测试主要应用于单元测试阶段
• 先执行静态设计用例的方法，再执行动态设计测试用例的方法
• 设计用例一般使用路径测试，重点模块追加使用逻辑覆盖方法
2.黑盒测试
黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果，满足规范需求。
所以，黑盒测试又称之为数据驱动测试，只注重软件的功能
黑盒测试的优点
不需要了解程序内部的代码以及实现，不关注软件内部的实现。
从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维
测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。
黑盒测试的缺点 是不可能覆盖所有代码。
黑盒测试用到的测试方法有：等价类，边界值，因果图，场景法，错误猜测法等
3.灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
但是，灰盒测试没有白盒测试详细和完整，黑盒测试是覆盖产品范围最广的测试，因此灰盒测试基本是不能够替代黑盒测试，否则需要很大的代价，设计非常多的用例。
⭐常见面试题：你知道的测试方法有哪些？哪种用的比较多？
常见的测试方法有黑盒测试，白盒测试和灰盒测试。开发人员主要用白盒测试和灰盒测试，测试人员主要用白盒测试和黑盒测试。对于测试人员来说，相较于白盒测试，黑盒测试用的更多一些。
4.三者的区别和特点
黑盒测试
-
特点 ：把软件当"黑盒"，只关心输入和输出，不看内部代码。
-
优势：从用户视角验证功能，简单直接，无需编程知识。
-
一句话 ："不知道内部，只测对不对。"
白盒测试
-
特点 ：把软件当"透明盒"，必须查看内部代码和结构进行测试。
-
优势：能发现深层的代码逻辑错误、路径覆盖问题。
-
一句话 ："透视看内部，专找代码错。"
灰盒测试
-
特点 ：介于黑白之间，知道部分内部结构（如接口、数据库），但测试时仍聚焦于外部行为。
-
优势 ：结合两者优点，能设计更高效的测试用例，尤其擅长发现集成和接口问题。
-
一句话 ："略懂内部事，主抓连接错。"
通俗比喻：
-
黑盒：像用户开车，只管踩油门能不能走，不管引擎怎么工作。
-
白盒：像修车工打开引擎盖，检查每一个零件。
-
灰盒：像懂车的司机，知道大概原理，能听声音判断是变速箱还是轮胎出了问题。
五、按照测试阶段分类
1.单元测试
与编码同步进行，针对**软件最小组成单元（人为规定）**进行测试，主要采用白盒测试方法，从被测对象的内部结构出发设计测试用例。
**• 测试阶段：**编码后或者编码前（TDD）
**• 测试对象：**最小模块
**• 测试人员：**白盒测试工程师或开发工程师
**• 测试依据：**代码和注释+详细设计文档
**• 测试方法：**白盒测试
**• 测试内容：**模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
unittest单元测试
python
# test_bubble_unittest.py
import unittest
from bubble_sort import bubble_sort # 导入冒泡排序函数
class TestBubbleSort(unittest.TestCase):
"""冒泡排序的单元测试类，继承自unittest.TestCase"""
def test_empty_list(self):
"""测试空列表"""
self.assertEqual(bubble_sort([]), []) # 断言结果是否符合预期
def test_single_element(self):
"""测试单个元素的列表"""
self.assertEqual(bubble_sort([5]), [5])
def test_already_sorted(self):
"""测试已排序的列表（正向）"""
self.assertEqual(bubble_sort([1, 2, 3, 4, 5]), [1, 2, 3, 4, 5])
def test_reverse_sorted(self):
"""测试逆序排列的列表"""
self.assertEqual(bubble_sort([5, 4, 3, 2, 1]), [1, 2, 3, 4, 5])
def test_with_duplicates(self):
"""测试包含重复元素的列表"""
self.assertEqual(bubble_sort([3, 1, 4, 1, 5, 9, 2, 6, 5]), [1, 1, 2, 3, 4, 5, 5, 6, 9])
def test_with_negative_numbers(self):
"""测试包含负数的列表"""
self.assertEqual(bubble_sort([-2, -5, 0, -1, 3]), [-5, -2, -1, 0, 3])
if __name__ == '__main__':
# 运行所有测试用例
unittest.main()
pytest单元测试
python
# test_bubble_pytest.py
from bubble_sort import bubble_sort # 导入冒泡排序函数
def test_empty_list():
"""测试空列表"""
assert bubble_sort([]) == [] # 直接使用Python原生assert断言
def test_single_element():
"""测试单个元素的列表"""
assert bubble_sort([5]) == [5]
def test_already_sorted():
"""测试已排序的列表（正向）"""
assert bubble_sort([1, 2, 3, 4, 5]) == [1, 2, 3, 4, 5]
def test_reverse_sorted():
"""测试逆序排列的列表"""
assert bubble_sort([5, 4, 3, 2, 1]) == [1, 2, 3, 4, 5]
def test_with_duplicates():
"""测试包含重复元素的列表"""
assert bubble_sort([3, 1, 4, 1, 5, 9, 2, 6, 5]) == [1, 1, 2, 3, 4, 5, 5, 6, 9]
def test_with_negative_numbers():
"""测试包含负数的列表"""
assert bubble_sort([-2, -5, 0, -1, 3]) == [-5, -2, -1, 0, 3]
unittest 需要你在代码中"告诉它什么时候运行"，而 pytest 只需要你"按约定写测试"，然后通过命令行"让它运行"。这种设计差异让 pytest 更简洁，尤其在大型项目中能减少重复的入口代码。
python
`unittest` 和 `pytest` 是 Python 中最常用的两个单元测试框架，两者各有特色，适用场景不同。以下从 **语法设计、功能特性、扩展性、适用场景** 四个维度对比，并总结各自的优势。
### 一、核心区别与特色
#### 1. 语法设计：规范严格 vs 灵活简洁
- **unittest**（内置库，基于 JUnit）
语法严格遵循"面向对象"设计，必须通过 **继承 `unittest.TestCase` 类** 组织测试用例，测试方法必须以 `test_` 开头。
例：
```python
import unittest
class TestDemo(unittest.TestCase): # 必须继承TestCase
def test_add(self): # 方法名必须以test_开头
self.assertEqual(1 + 1, 2) # 必须使用框架提供的断言方法
```
- **pytest**（第三方库，更灵活）
支持 **函数式测试** 和 **类测试**，无需继承任何类，测试函数/方法只需以 `test_` 开头（类名通常以 `Test` 开头）。
例：
```python
def test_add(): # 无需继承，直接定义函数
assert 1 + 1 == 2 # 直接使用Python原生assert
```
**核心差异**：unittest 强制结构化，适合规范统一；pytest 语法极简，降低编写门槛。
#### 2. 断言方式：专用方法 vs 原生语句
- **unittest**：提供一套专用断言方法（如 `self.assertEqual(a, b)`、`self.assertTrue(cond)`、`self.assertIn(a, b)` 等），断言失败时会自动生成详细错误信息。
例：
```python
self.assertEqual(1 + 2, 3) # 正确
self.assertNotIn(4, [1, 2, 3]) # 正确
```
- **pytest**：直接使用 Python 原生 `assert` 语句，且通过"智能重写"技术增强错误信息------断言失败时会自动显示变量值、表达式上下文等，比 unittest 更直观。
例：
```python
assert 1 + 2 == 3 # 正确
assert 4 not in [1, 2, 3] # 正确
```
**核心差异**：unittest 需记忆专用方法，pytest 用原生语法，学习成本更低，错误信息更友好。
#### 3. 测试前置/后置：固定钩子 vs 灵活 Fixture
- **unittest**：通过固定的"钩子方法"实现测试前置（准备）和后置（清理）逻辑，作用域仅支持 **方法级**（`setUp()`/`tearDown()`）和 **类级**（`setUpClass()`/`tearDownClass()`）。
例：
```python
class TestDB(unittest.TestCase):
@classmethod
def setUpClass(cls): # 类级前置：所有测试方法执行前运行1次
cls.db = connect_db()
def setUp(self): # 方法级前置：每个测试方法执行前运行
self.db.clear_data()
def tearDown(self): # 方法级后置：每个测试方法执行后运行
self.db.commit()
```
- **pytest**：通过 **Fixture** 机制实现前置/后置逻辑，支持 **更细粒度的作用域**（函数、类、模块、包、会话），且可跨测试用例复用，灵活性远超 unittest。
例：
```python
import pytest
@pytest.fixture(scope="module") # 作用域：整个模块执行前运行1次
def db_connection():
db = connect_db() # 前置：创建连接
yield db # 返回资源给测试用例
db.close() # 后置：关闭连接（yield后代码在测试结束后执行）
def test_query(db_connection): # 直接传入fixture使用
result = db_connection.query("SELECT 1")
assert result == 1
```
**核心差异**：Fixture 是 pytest 的"杀手级特性"，支持复杂的资源管理和跨用例复用，而 unittest 的钩子方法灵活性有限。
#### 4. 参数化测试：繁琐 vs 简洁
参数化测试（用多组数据重复执行同一测试逻辑）是高频需求，两者实现方式差异显著：
- **unittest**：需借助 `subTest` 上下文管理器或第三方库（如 `parameterized`），语法繁琐。
例（用 `subTest`）：
```python
def test_add(self):
test_cases = [(1, 2, 3), (0, 0, 0), (-1, 1, 0)]
for a, b, expected in test_cases:
with self.subTest(a=a, b=b): # 标记每组数据，失败时显示参数
self.assertEqual(a + b, expected)
```
- **pytest**：内置 `@pytest.mark.parametrize` 装饰器，语法简洁，支持多参数组合。
例：
```python
@pytest.mark.parametrize("a, b, expected", [
(1, 2, 3),
(0, 0, 0),
(-1, 1, 0)
])
def test_add(a, b, expected):
assert a + b == expected
```
**核心差异**：pytest 原生支持参数化，使用成本远低于 unittest。
#### 5. 扩展性与生态：基础 vs 丰富
- **unittest**：作为 Python 标准库，扩展性有限，主要依赖继承和自定义 `TestCase`，无官方插件机制，功能较基础（如无并行测试、代码覆盖率集成等）。
- **pytest**：拥有 **极其丰富的插件生态**（超过 1000 个官方插件），可轻松扩展功能：
- `pytest-cov`：集成代码覆盖率分析；
- `pytest-xdist`：支持多 CPU 并行测试，大幅提速；
- `pytest-mock`：简化单元测试中的 mock 操作；
- `pytest-html`：生成 HTML 测试报告；
- `pytest-django`/`pytest-flask`：适配 Web 框架的专用插件。
#### 6. 测试发现：固定规则 vs 灵活配置
"测试发现"指框架自动识别并执行测试用例的逻辑：
- **unittest**：规则固定且严格，仅识别：
- 文件名以 `test` 开头的模块（如 `test_demo.py`）；
- 模块中继承 `unittest.TestCase` 的类；
- 类中以 `test_` 开头的方法。
- **pytest**：规则更灵活，默认识别：
- 文件名匹配 `test_*.py` 或 `*_test.py` 的模块；
- 模块中以 `test_` 开头的函数；
- 类名以 `Test` 开头的类中，以 `test_` 开头的方法。
同时支持通过配置文件（`pytest.ini`）自定义规则，适应复杂项目结构。
### 二、哪一个更好？适用场景分析
两者没有绝对的"更好"，需根据 **项目规模、团队习惯、功能需求** 选择：
#### 优先选 `unittest` 的场景：
1. **小型项目或脚本**：无需额外安装（Python 内置），语法规范，足够满足基础测试需求；
2. **团队熟悉 Java 风格测试框架**：unittest 设计模仿 JUnit，习惯 `TestCase` 类和专用断言的团队更容易上手；
3. **依赖标准库**：项目严格限制第三方库引入（如嵌入式环境），unittest 是唯一选择；
4. **与其他标准库集成**：如需结合 `doctest`（文档测试）或 `unittest.mock`（官方 mock 库），unittest 兼容性更好。
#### 优先选 `pytest` 的场景：
1. **中大型项目**：需要复杂的测试组织（如 Fixture 复用、参数化、并行测试），pytest 能显著提升效率；
2. **追求测试编写效率**：原生 `assert`、极简语法、自动发现测试用例，减少重复代码；
3. **需要扩展功能**：如代码覆盖率分析、HTML 报告、与 CI/CD 工具（Jenkins、GitHub Actions）集成，pytest 插件生态可一键满足；
4. **已有 unittest 用例**：pytest 完全兼容 unittest 用例，可平滑迁移，逐步享受 pytest 特性。
### 三、总结
| 特性 | unittest | pytest |
|---------------------|-----------------------------------|-------------------------------------|
| 语法 | 严格（类继承、专用方法） | 灵活（函数/类、原生语法） |
| 断言 | 专用方法（如 `self.assertEqual`） | 原生 `assert`（增强错误信息） |
| 前置/后置 | 固定钩子（`setUp`/`tearDown`） | Fixture（多作用域、可复用） |
| 参数化 | 繁琐（需 `subTest` 或第三方库） | 简洁（`@pytest.mark.parametrize`） |
| 扩展性 | 弱（无插件） | 强（丰富插件生态） |
| 兼容性 | 仅支持自身用例 | 兼容 unittest/doctest 用例 |
| 适用场景 | 小型项目、标准库依赖 | 中大型项目、需扩展功能 |
简单说：**unittest 是"规范的基础款"，pytest 是"灵活的增强款"**。对于大多数现代 Python 项目，pytest 凭借更高的效率和扩展性，是更优选择。2.集成测试
集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。
**• 测试阶段：**一般单元测试之后进行
**• 测试对象：**模块间的接口
**• 测试人员：**白盒测试工程师或开发工程师
**• 测试依据：**单元测试的模块+概要设计文档
**• 测试方法：**黑盒测试与白盒测试相结合
**• 测试内容：**模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
3.系统测试
对通过集成测试的系统进行整体测试，验证系统功能性和非功能性需求的实现。
**• 测试阶段：**集成测试通过之后
**• 测试对象：**整个系统（软、硬件）
**• 测试人员：**黑盒测试工程师
**• 测试依据：**需求规格说明文档
**• 测试方法：**黑盒测试
**• 测试内容：**功能、界面、可靠性、易用性、性能、兼容性、安全性等
如果不具备可测试性，直接打回，如果具备可测试性，则执行测试
Ⅰ、冒烟测试
这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒
烟，则该组件就通过了测试。在软件中，"冒烟测试"这一术语描述的是在将代码更改嵌入到产品的
源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本 ，目的是确认软件主要功能和核心流程正常，在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。
如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试。
在生活中，购买一个电视，首先会通电，查看电视是否能够运行。
购买一个水杯，首先会灌水，查看水杯是否漏水。
在工作中，假如有一个博客系统项目提测了，冒烟测试即只需要测试系统是否能够成功打开，主流程是否可以走通即可。
Ⅱ、回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错
误。在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
回归测试主要由人工测试和自动化测试进行。
在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些回归测试将变得非常令人厌烦，而在大多数回归测试需要手工完成的时候尤其如此，因此，需要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。为了支持多种回归测试策略，自动测试工具应该是通用的和灵活的，以便满足达到不同回归测试目标的要求。
4.验收测试
针对用户需求，对通过系统测试的软件进行交付性测试，以确定系统是否满足验收标准，由用户
或其他授权机构决定是否接受系统。验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。
**• 测试阶段：**系统测试通过之后
**• 测试对象：**整个系统（包括软硬件）。
**• 测试人员：**主要是最终用户或者需求方。
**• 测试依据：**用户需求、验收标准
**• 测试方法：**黑盒测试
**• 测试内容：**同系统测试(功能...各类文档等)
六、按照是否手工分类
1.手工测试
手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。
2.自动化测试
就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说，自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。 自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化。 自动化测试按照测试对象来分，还可以分为接口测试、UI测试等。接口测试的ROI（产出投入比）要比UI测试高。
3.手工测试和自动化测试的优缺点
| 维度 | 手工测试 | 自动化测试 |
|---|---|---|
| 初始成本 | ✅ 低 - 无需编写脚本，立即开始测试 | ❌ 高 - 需要开发测试框架和脚本 |
| 执行速度 | ❌ 慢 - 人工操作，逐项测试 | ✅ 快 - 批量执行，并行运行 |
| 测试覆盖率 | ❌ 有限 - 受限于测试人员时间和精力 | ✅ 全面 - 可覆盖大量测试用例和场景 |
| 重复性测试 | ❌ 差 - 重复劳动，易疲劳出错 | ✅ 优秀 - 精准重复，不会疲劳 |
| 发现缺陷能力 | ✅ 强 - 人类直觉能发现意外问题 | ❌ 有限 - 只能发现预设场景的问题 |
| 用户体验测试 | ✅ 优秀 - 能评估界面友好性和易用性 | ❌ 差 - 无法评估主观用户体验 |
| 维护成本 | ✅ 低 - 用例变更时直接修改测试步骤 | ❌ 高 - 代码需要随系统变更而更新 |
| 灵活性 | ✅ 高 - 随时调整测试策略和重点 | ❌ 低 - 脚本固定，修改需要重新开发 |
| 技能要求 | ✅ 低 - 基础测试理论即可 | ❌ 高 - 需要编程和工具使用能力 |
| 回归测试 | ❌ 效率低 - 重复执行耗时耗力 | ✅ 效率高 - 快速执行大量回归用例 |
| 探索性测试 | ✅ 适合 - 自由探索，发现隐藏问题 | ❌ 不适合 - 需要预先定义测试路径 |
| 性能测试 | ❌ 无法进行 - 难以模拟高并发 | ✅ 非常适合 - 可模拟大量用户并发 |
| 测试精度 | ❌ 可能出错 - 人为操作可能失误 | ✅ 精确 - 严格按照脚本执行 |
| 立即反馈 | ❌ 延迟 - 需要时间整理测试结果 | ✅ 实时 - 执行完立即生成报告 |
| 投资回报率 | ✅ 短期高 - 立即见效 | ✅ 长期高 - 重复使用次数越多回报越高 |
七、按照实施组织划分
大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试
1.α测试
α测试又叫内测或者叫a测，其实都是一个涵义
α测试通常是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的
FLURPS(即功能、可使用性、可靠性、性能和支持)。 α测试不能由程序员或测试员完成。
2.β测试
β测试又叫公测或者叫b测
β测试由软件的最终用户们在一个或多个场所进行，这里就可以理解为，β测试是正式用户中的一部分，他们在任意的场合来使用软件，目的是为了发现软件是否存在一系列的问题
通常会发送一些邀请码，来邀请用户参与项目测试
3.α测试和β测试的区别
| 特性 | α测试 (Alpha Testing) | β测试 (Beta Testing) |
|---|---|---|
| 测试环境 | 开发环境或受限的测试环境 | 真实用户环境 |
| 测试地点 | 开发组织内部 | 用户的实际使用场所 |
| 测试人员 | 内部测试人员、QA团队、开发人员 | 真实终端用户、潜在客户 |
| 测试阶段 | 开发末期，β测试之前 | α测试之后，正式发布之前 |
| 主要目的 | 发现重大缺陷，验证基本功能 | 收集用户反馈，验证市场接受度 |
| 测试范围 | 核心功能、稳定性、性能 | 用户体验、兼容性、实际工作流 |
| 缺陷类型 | 功能性缺陷、崩溃问题、性能问题 | 用户体验问题、兼容性问题、需求匹配度 |
| 测试时长 | 相对较短（几天到几周） | 相对较长（几周到几个月） |
| 可控性 | 高 - 开发团队直接控制 | 低 - 用户自主测试 |
| 成本 | 较低 - 内部资源 | 较高 - 可能涉及用户激励 |
| 反馈速度 | 快 - 直接与开发团队沟通 | 慢 - 需要通过反馈渠道收集 |
| 保密性 | 高 - 仅限于内部人员 | 较低 - 外部用户参与 |
| 测试深度 | 深入 - 关注技术细节 | 广度 - 关注整体体验 |
4.第三方测试
第三方软件测试是指由独立的第三方公司或组织进行的软件测试活动。
通过第三方测试，可以确保软件的质量，节省成本，确保软件尽快上线
八、按照测试地域划分
按照测试地域划分，一般会将测试划分为国际化测试和本地测试
1.国际化测试
简言之，测试人员需要测试软件在不同语言和地区是否能正常工作
国际化测试需要关注软件的哪些特性：
• 布局
• 时间
• 日期
• 数字格式
• 货币
• 机器型号
• .....
2.本地测试
之前所讲的都属于本地测试