Python测试体系看似庞大、细节繁多，但入门门槛并不高。对于已经完成基础功能开发、尚未编写任何测试的应用，本教程将从最基础的实践入手，逐步过渡到更高级的测试技巧，重点介绍如何利用Python自带工具构建自动化测试体系。
内容将涵盖：基础测试的编写与执行方法、相关工具的使用方式、应用性能的检查手段，以及常见安全问题的排查思路。本文主要参考资料包括：
测试是通过运行程序并验证其实际行为是否符合预期结果的过程。许多开发者可能已在无意中实践过测试，例如在首次运行应用程序时检查各项功能。这种不依赖预设计划、自由探索的方式属于手动测试。若对手动测试进行系统化组织，可以形成如下流程：
那么，为什么要从手动测试转向自动化测试？手动测试存在两个主要局限：
自动化测试正是为解决这类问题而生。它以脚本替代人工执行测试流程，自动运行功能并比对实际与预期结果，输出校验结论。其核心价值在于一次编写、重复复用，可在代码迭代中快速反馈，并在构建后持续扩展与完善。
在软件测试领域，术语繁多，概念容易混淆。在理解了自动化测试与手动测试的区别之后，有必要进一步认识两个构成软件质量基石的核心概念：集成测试与单元测试。之所以优先讨论这两者，是因为它们分别定义了整体协作与局部细节的检验逻辑。其他类型的测试，如端到端测试、性能测试等，大多建立在对这两者的理解之上。关于两者的详细对比，可参考：What Is a Unit Test? Unit vs Integration Testing Guide。
为了直观说明两者的区别，可以以做一道番茄炒蛋为例。将准备好的食材下锅翻炒，属于测试步骤；在菜出锅前尝一口咸淡是否合适，属于核对结果。
一道成功的番茄炒蛋，需要多个环节的紧密配合：鸡蛋要打散均匀，番茄要切块适中，火候要控制得当，盐和糖的比例要准确，出锅时间要恰到好处。像这样验证所有环节能否协同完成一道菜的检验过程，就是集成测试。这些环节就好比软件中的各个函数或模块，必须环环相扣，才能最终端出一盘可口的菜。
集成测试面临的典型困境在于问题定位。假如最后炒出的菜味道不对，原因可能分散在多个环节：
如果无法将问题缩小到具体的步骤，整道菜从备料到出锅就可能需要全部推倒重来。此时，单元测试的价值便凸显出来。想象在正式做菜之前，我们可以单独测试每一个环节：单独炒一份鸡蛋以检查是否嫩滑，单独尝一口切好的番茄以确认是否够熟够味，单独用少量油试一下火候是否足够猛烈。这种抛开整道菜、只针对某一环节独立检验的方式，正是单元测试的精髓。它的范围极小，目的单一，却能提前发现潜在的问题。
通过这一对比，两种测试的边界便一目了然：集成测试负责回答所有步骤配合起来之后整道菜是否好吃，而单元测试负责回答每一个步骤本身是否做对。
在Python中，可以同时编写集成测试和单元测试。以针对字符串方法upper()编写单元测试为例，需要将其输出与已知的正确结果进行比对。例如，下面演示了如何验证"world".upper()的结果是否等于"WORLD"：
>>> assert "world".upper() == "WORLD", "结果应为 WORLD"
由于结果正确，这条断言语句在Python交互式环境中不会产生任何输出。但如果upper()的结果有误，断言就会失败，并抛出AssertionError异常。我们可以故意传入一个错误的值来触发这个异常：
>>> assert "world".upper() == "WORLd", "结果应为 WORLD"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AssertionError: 结果应为 WORLD
然而，实际开发中不应依赖交互式环境进行手动测试，而是将测试代码放入一个Python文件，例如test_upper.py中，然后执行该文件：
def test_upper():
assert "hello".upper() == "HELLO", "结果应为 HELLO"
def test_upper_mixed():
assert "Hello World".upper() == "HELLO WORLd", "结果应为 HELLO WORLD"
if __name__ == "__main__":
test_upper()
test_upper_mixed()
print("全部测试通过")
执行后会得到类似这样的错误输出：
$ python test_upper.py
Traceback (most recent call last):
File "test_upper.py", line 9, in <module>
test_upper_mixed()
File "test_upper.py", line 5, in test_upper_mixed
assert "Hello World".upper() == "HELLO WORLd", "结果应为 HELLO WORLD"
AssertionError: 结果应为 HELLO WORLD
从输出中可以清晰地看到代码中的错误：控制台会给出错误所在位置以及预期结果与实际结果之间的差异。如果希望在编写文档的同时测试代码，并确保代码与文档始终保持一致，可以使用Python内置的doctest模块。
对于简单的检查，上述使用assert的方式已经足够。但当有多个测试可能失败时，就需要引入测试运行器（test runner）。测试运行器是专门用于运行测试、检查输出、帮助调试和诊断测试用例及其所在应用程序的工具。
Python生态中有多种测试运行器可供选择。当前最为流行、使用最广泛的三款测试运行器如下：
unittest
作为Python标准库的一部分，unittest无需额外安装，具有良好的兼容性。其主要优点是与标准库无缝集成，适合在依赖受限或环境封闭的项目中使用。缺点在于编写测试时需要较多的样板代码，且插件生态相对薄弱。尽管如此，unittest仍然被广泛用于大型项目以及Python标准库自身的测试中，具有较高的受欢迎程度。
pytest
pytest是目前功能最强大、社区最活跃的测试运行器之一。其优点包括强大的参数化测试功能、丰富的插件生态，以及简洁的代码风格和清晰明了的断言失败信息。缺点在于部分高级特性的学习曲线相对陡峭。pytest在当前Python测试框架中受欢迎程度最高，被大量开源项目和企业广泛采用。
nose2
作为对 unittest 的扩展，nose2支持自动发现测试用例，并提供比原生unittest更丰富的插件系统。其优点在于减少了手动组织和配置测试套件的工作量，断言方式也更为简洁。缺点是项目维护不活跃，社区支持有限，遇到问题难以获得及时更新或帮助。
尽管pytest更为流行，本教程仍选择以unittest作为教学工具，主要基于两点考虑。首先，unittest是Python标准库的一部分，无需额外安装即可使用，从而降低了环境配置成本。其次，它的结构清晰、行为显式，有助于初学者建立对测试基本概念与生命周期的理解。
在掌握unittest之后，再迁移到pytest或nose2会更加自然和轻松。因此，以unittest作为起点，是一条稳健且具有通用性的学习路径。
unittest是Python标准库内置的测试框架，自Python 2.1起便随发行版一同提供。它集测试用例组织与测试运行于一体，在商业应用和开源项目中均有广泛使用。
unittest对测试编写有以下要求：
unittest.TestCase的类中，每个测试方法须以test_开头。TestCase类提供的方法（如assertEqual），而非Python内置的assert语句。编写一个unittest测试用例的基本步骤如下：
unittest模块。unittest.TestCase的测试类。test_开头的方法，第一个参数为self。self.assertEqual()等断言方法验证结果。if __name__ == '__main__':块中调用unittest.main()，以便直接运行脚本时启动测试。假设我们有一个现成的功能类，保存在math_tools.py文件中：
# math_tools.py
class MathTools:
"""一个简单的数学工具类"""
def double(self, n):
"""返回一个数字的两倍"""
return n * 2
针对该类编写配套单元测试代码。新建文件test_math_tools.py并写入如下内容：
# test_math_tools.py
import unittest
from math_tools import MathTools
# 新建测试类，必须继承unittest.TestCase
# 该类统一管理MathTools对应的全部测试用例
class TestMathTools(unittest.TestCase):
# 编写测试方法，方法名必须以test_作为前缀
# unittest框架会自动识别并运行所有符合命名规则的方法
def test_double(self):
"""校验double方法计算逻辑"""
# 实例化待测试类
tool = MathTools()
# 调用目标方法，获取运行产生的实际结果
result = tool.double(3)
# 借助断言比对实际结果与预期结果
# 可传入自定义提示文本，便于测试异常时快速定位问题
self.assertEqual(result, 6, "double(3)运算结果不符合预期")
# 编写异常演示用例，模拟代码校验失败场景
def test_double_fail_demo(self):
"""模拟测试失败，展示框架报错效果"""
tool = MathTools()
result = tool.double(4)
# 设置错误的预期值，触发断言失败
self.assertEqual(result, 10, "double(4)预期结果配置错误，用于失败演示")
if __name__ == "__main__":
unittest.main()
由于测试文件中同时包含一个正常用例和一个故意写错的演示用例，终端将输出如下混合结果：
.F
======================================================================
FAIL: test_double_fail_demo (__main__.TestMathTools)
模拟测试失败，展示框架报错效果
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_math_tools.py", line 34, in test_double_fail_demo
self.assertEqual(result, 10, "double(4)预期结果配置错误，用于失败演示")
AssertionError: 8 != 10 : double(4)预期结果配置错误，用于失败演示
----------------------------------------------------------------------
Ran 2 tests in 0.001s
FAILED (failures=1)
对照上述输出，各部分含义如下：开头的.F表示共执行两项测试，.代表第一个用例通过，F代表第二个用例失败。FAIL: test_double_fail_demo指明了失败所在的测试方法。AssertionError: 8 != 10展示了实际结果与预期值的具体差异。末尾的Ran 2 tests统计了总用例数，FAILED (failures=1)汇总了失败数量。
⚠️⚠️⚠️注意unittest框架默认的执行顺序遵循字符串的升序（ASCII码）规则，即首先按类名排序，然后在每个测试类内部再按方法名排序。在本例中，test_double因字母d排在f之前，会先于test_double_fail_demo执行，输出结果开头的.F也正是这一顺序的体现。理解这一点有助于正确解读测试报告中的执行顺序信息。
理解输出格式后，可以进一步提炼单元测试的核心逻辑，可概括为五个步骤：首先导入待测试的目标类，其次实例化目标类，然后调用被测方法获取实际结果，接着通过断言将实际结果与预期值进行比对，最后根据比对结果判定用例状态。若数据一致则测试通过，若不一致则测试失败，并抛出包含自定义提示信息的异常。更多unittest用法可参考其官方文档：unittest官方文档。
pytest不仅能兼容并执行unittest编写的测试用例，还支持以test_开头的函数或类两种方式组织测试，实现更灵活的管理。pytest具备以下突出特性：
assert语句，无需借助self.assert*等专用断言方法，失败时自动展示丰富的上下文信息。pytest风格相较于unittest更加简洁，使用pytest后不再需要继承TestCase类、也无需强制定义类结构，也不必编写命令行入口。但pytest是第三方库，需要提前安装：
pip install pytest
将前面unittest风格的测试用例改用pytest原生风格重写后，同样的测试逻辑可以表达得更加精简：
# test_math_tools.py
from math_tools import MathTools
# 无需继承任何类，直接定义以 test_ 开头的函数即可
def test_double():
"""校验double方法计算逻辑"""
# 实例化待测试类
tool = MathTools()
# 调用目标方法，接收实际结果
result = tool.double(3)
# 直接使用Python内置assert语句进行断言
# 将预期结果与自定义错误信息写在断言表达式中
assert result == 6, "double(3)运算结果不符合预期"
def test_double_fail_demo():
"""模拟测试失败，展示框架报错效果"""
tool = MathTools()
result = tool.double(4)
# 配置错误的预期值，故意触发断言失败
assert result == 10, "double(4)预期结果配置错误，用于失败演示"
# 添加执行入口，使该文件既可通过pytest命令运行，也可直接作为Python脚本执行
if __name__ == "__main__":
import pytest
pytest.main([__file__, "-v"])
若代码中未包含上述执行入口，可在终端中执行以下命令来运行测试：
pytest test_math_tools.py -v
若已添加执行入口，则可以直接作为普通Python脚本运行：
python test_math_tools.py
两种方式均会执行文件中的所有测试用例，且输出结果一致。前者为 pytest 的标准命令行用法，后者则更适合在 IDE 中通过点击运行按钮进行调试。更详细的使用说明可参考 pytest 官方文档：pytest官方文档。
综合对比unittest和pytest两种编写风格，可以清晰地看到pytest在代码简洁性和可读性方面的显著优势：
| 对比项 | unittest | pytest |
|---|---|---|
| 框架依赖 | 需导入unittest模块 |
通常无需显式导入，直接编写测试函数即可 |
| 代码结构 | 必须继承unittest.TestCase类 |
支持普通函数，也可使用类组织测试（无需继承特定基类） |
| 断言方式 | 使用self.assertEqual()、self.assertTrue()等专用断言方法 |
直接使用Python原生assert语句，失败信息更直观 |
| 入口代码 | 需包含if__name__=="__main__": unittest.main()才能直接运行脚本 |
通常无需入口，通过pytest命令运行；若需直接运行脚本，调用pytest.main()即可 |
| 测试发现 | 默认收集test*.py文件中以test开头的方法（类需继承TestCase） |
自动收集test_*.py或*_test.py文件中的test_前缀函数，以及Test类中的test_方法 |
| 插件与扩展 | 需借助第三方工具集成 | 拥有丰富的插件生态，可轻松集成覆盖率、并行测试、报告生成等功能 |
测试步骤
学习一门新技术，最怕只见树木，不见森林。前面逐一认识了测试的基本概念，区分了单元测试与集成测试的职责，也动手体验了Python中的断言语句和测试运行器。但在实际工程中，仍然可能继续追问：测试用例为什么重要？测试的主要工作到底落在哪里？工具能不能自动生成测试用例？又该怎样评价一个测试写得好不好？
无论使用何种测试框架，也无论被测功能多么复杂，一个结构良好的测试都可以归结为三个核心步骤（Arrange-Act-Assert）。一个测试用例，正是这三步的显式封装，可以理解为一个可重复执行的小实验：
由此可以看出，测试的主要工作其实集中在第一步和第三步：设计具有代表性的输入，以及明确什么是正确的预期输出。这正是测试用例的核心价值，它将原本较为模糊的验证过程，固化为可复用、可追踪的契约，从而成为代码质量的一道安全保障。现代IDE和各类工具虽能根据函数签名自动生成测试用例的基础结构，但无法替开发者判断结果是否符合业务预期。正因为这一点，测试用例的价值不仅在于能不能跑，更在于是否定义了正确的行为边界。
这一模式可以类比为实验：将一杯水放入冰箱，随后检查水是否结冰。输入对应水的初始状态，执行对应冷冻过程，验证对应结冰与否的检查。一个好测试，就像这个实验一样，条件清晰、判定明确、每次运行都能稳定复现。如果不仅测了常温水的结冰，还覆盖了0℃附近结冰的边界条件，那这个测试用例就更接近优秀。
测试类型
明确了测试方法后，关于测试内容的思考便会自然衔接，这涉及测试的首个分类维度，即检验范围。在此维度下，主流测试分为三个层次，它们共同构成了由小而快到大而慢的测试金字塔。
测试层次越低，执行速度越快、稳定性越高，因此应覆盖更多用例；层次越高，执行成本更高、也更容易受环境影响，因此数量应相对减少。日常开发中，应将主要精力投入到单元测试的构建中，同时配合适量集成测试，并辅以少量端到端测试，以形成稳定且高效的测试结构。更系统的说明可参考 The Practical Test Pyramid。
在理解了单元测试和集成测试各自的侧重点之后，一个自然的问题便是：两种测试应该各写多少？测试金字塔为这个问题提供了直观的指导。
/\
/ \ ← 少量端到端测试（E2E）
/ \
/------\
/ \ ← 适量集成测试
/ \
/------------\
/ \ ← 大量单元测试
/________________\
金字塔出自Mike Cohn的《Succeeding with Agile》，其核心思想是：
遵循金字塔意味着，当你发现一个bug时，优先尝试补充一个单元测试；只有当bug确实由模块交互引发时，才添加集成测试。这种分配能让你在快速反馈和全面覆盖之间取得平衡。
除了按范围划分，测试还可以根据执行目的与时机进行分类，这些术语与测试金字塔并不冲突，而是回答在何时以及出于何种目的选择哪些测试执行：
上述分类主要用于说明不同执行策略，更完整的类型说明可参考：Software testing types explained simply
这两组分类并不冲突，而是从两个正交维度刻画测试体系：测试金字塔回答测试应该如何分布，而冒烟、回归等概念回答在什么阶段执行什么测试。两者结合，才能构建既高效又全面的测试策略。
测试目的
除了范围与时机，测试还可以从“目的”维度进行划分，从而指导用例设计方式：
正面测试
验证正常输入是否产生预期结果。
负面测试
验证异常输入是否被正确处理。例如输入字符串时应抛出 TypeError，而不是导致程序崩溃。
在实践中，仅关注正面测试是一种常见误区，因为真实系统中异常输入往往不可避免。
前面内容介绍了测试的基本概念，接下来将所有知识点串联起来。与之前测试内置函数不同，本节将自行实现一个计算乘积的函数，并为其编写完整的测试用例。
首先，创建一个新的项目文件夹，并在其中新建一个名为 my_math 的子文件夹。在my_math内创建一个空的__init__.py文件，该文件的存在标志着my_math是一个Python包，可以被父级目录中的其他模块导入。此时的项目结构如下所示：
project/
│
└── my_math/
└── __init__.py
打开my_math/__init__.py，定义一个product()函数。该函数接收一个可迭代对象（如列表、元组或集合），遍历其中的所有数值并计算它们的乘积：
def product(arg):
total = 1
for val in arg:
total *= val
return total
有了待测代码之后，需要确定测试文件的存放位置。最简单的做法是在项目根目录下创建一个test.py文件，其中包含第一个测试用例。由于该文件需要导入被测试的包，因此通常放置在包文件夹的上一层，目录结构如下：
project/
│
├── my_math/
│ └── __init__.py
└── test.py
当然，随着测试用例逐渐增多，单个文件会变得杂乱且难以维护。此时可以创建一个tests/文件夹，将测试拆分到多个文件中。按照业界惯例，每个测试文件的名称都以test_开头，以便测试运行器能够自动识别哪些文件包含待执行的测试。一些大型项目还会按功能模块，将测试用例进一步拆分到不同子目录中。
对于单脚本场景，也就是项目只有一个.py文件而没有包结构的情况，导入被测代码的方式略有不同。此时可以使用内置的__import__()函数导入脚本中的类、函数或变量。例如，假设待测文件名为my_math.py，其中定义了product()函数，则导入方式如下：
target = __import__("my_math")
product = target.product
使用__import__()的优势在于：无需将项目文件夹转换为包，且可以直接通过模块名（不含.py后缀）导入。当脚本文件名与标准库模块重名时（例如自定义的math.py与Python标准库的math模块冲突），这种方式可避免误导入标准库模块而非自定义模块的错误。
测试用例是验证代码行为、覆盖边界异常、防止回归的核心保障。针对product()函数，需验证以下行为：
最基础的测试用例是验证对整数列表求乘积。创建test.py文件，写入以下代码：
import unittest
from my_math import product
class TestProduct(unittest.TestCase):
def test_list_int(self):
"""测试整数列表的乘积"""
data = [2, 3, 4]
result = product(data)
self.assertEqual(result, 24) # 2*3*4 = 24
def test_single_element(self):
"""测试只有一个元素的列表"""
data = [7]
result = product(data)
self.assertEqual(result, 7) # 单个元素的乘积即元素本身
def test_empty_list(self):
"""测试空列表的乘积——应按数学约定返回1"""
data = []
result = product(data)
self.assertEqual(result, 1) # 空乘积定义为1
def test_list_float(self):
"""测试浮点数列表的乘积"""
data = [1.5, 2.0, 3.0]
result = product(data)
self.assertAlmostEqual(result, 9.0) # 使用assertAlmostEqual处理浮点数精度
def test_tuple(self):
"""测试元组的乘积"""
data = (2, 4, 5)
result = product(data)
self.assertEqual(result, 40) # 2*4*5 = 40
def test_set(self):
"""测试集合的乘积（注意：集合会自动去重）"""
data = {2, 3, 2} # 集合会去重，实际元素为{2, 3}
result = product(data)
self.assertEqual(result, 6) # 2*3 = 6
def test_negative_numbers(self):
"""测试包含负数的列表"""
data = [-2, 3, -4]
result = product(data)
self.assertEqual(result, 24) # (-2)*3*(-4)=24
if __name__ == "__main__":
unittest.main()
以上代码依次完成了模块导入、测试用例类定义、测试方法的编写，以及命令行入口的设置。
测试的核心步骤是通过断言将实际输出与预期的正确结果进行比对。编写断言时应遵循以下最佳实践：
unittest模块提供了丰富的断言方法，用于比较值、检查类型以及验证变量是否存在。以下是测试中最常用的断言方法：
| 方法 | 等价于 |
|---|---|
.assertEqual(a, b) |
a == b |
.assertTrue(x) |
bool(x) is True |
.assertFalse(x) |
bool(x) is False |
.assertIs(a, b) |
a is b |
.assertIsNone(x) |
x is None |
.assertIn(a, b) |
a in b |
.assertIsInstance(a, b) |
isinstance(a, b) |
.assertAlmostEqual(a, b) |
round(a-b, 7) == 0（适用于浮点数比较） |
其中以下断言方法均有对应的否定形式：
.assertIs() → .assertIsNot().assertIsNone() → .assertIsNotNone().assertIn() → .assertNotIn().assertIsInstance() → .assertNotIsInstance()测试时还需留意副作用，即代码除了返回值之外，对类属性、文件系统、数据库或全局状态等外部环境所造成的改变。在编写断言前，应先明确是否需要验证这些副作用。如果一段代码的副作用过多，通常意味着职责耦合，违反了单一职责原则，此时更适合进行重构。遵循该原则能让单元测试更简单、更可重复，从而构建出更可靠的应用。
针对应用中副作用较多的部分，可以从以下三个方向进行处理：首先，通过重构代码，使其遵循单一职责原则，将副作用拆分并隔离到独立的函数或类中；其次，采用集成测试，在真实或接近真实的环境中验证相关行为；最后，引入模拟技术（Mock），通过模拟方法或函数调用来消除实际副作用的影响，具体可参考：Mock与单元测试的深入应用。
完成测试代码的编写后，下一步是执行测试。在运行更复杂的测试套件之前，应首先确认基本的测试能够成功执行。
执行测试代码、运行断言并将结果输出到控制台的Python程序称为测试运行器，例如test.py文件底部的代码段：
if __name__ == "__main__":
unittest.main()
构成了一个命令行入口。这意味着直接在终端中执行python test.py时，程序会调用unittest.main()，该方法会自动发现文件中所有继承自unittest.TestCase的类，并执行其中的测试方法。
对于单一的测试文件test.py，运行python test.py是最便捷的入门方式。此外也可以直接使用unittest模块的命令行接口：
$ python -m unittest test
该命令通过命令行执行指定的测试模块（即test，无需加.py后缀）。还可以添加-v选项来开启详细模式（verbose mode），该模式会先列出所有被执行测试的名称以及每个测试的结果（如OK或FAIL）。
除了显式指定测试模块，还可以使用测试自动发现功能：
$ python -m unittest discover
该命令会搜索当前目录及其子目录下所有符合test*.py命名模式的文件，并尝试运行其中的测试。当项目中的测试文件数量增多且均遵循此命名规范时，这种方式尤为高效。可以使用-s标志直接指定测试目录：
$ python -m unittest discover -s tests
上述命令会扫描tests目录下的所有测试文件，统一收集并执行其中的测试用例。
如果源代码不在项目根目录，而是位于子目录中（例如src/文件夹），可用-t标志指定顶层目录，以确保模块导入路径正确：
$ python -m unittest discover -s tests -t src
此命令会先切换至src作为顶层目录，然后扫描tests目录中所有test*.py文件并执行。这种配置在大型项目中非常常见，有助于保持源代码与测试代码的清晰分离。
当测试对象不再只是一个简单的数字，而是一个复杂的环境或多个模块的协作时，就需要引入两个核心工具：
举例说明：测试一个加法函数。用夹具可以提前设定好固定的数字3和5作为测试材料；用参数化可以一次性跑多组不同的运算。在实际测试工作中，百分之九十的情况都会用到夹具或参数化。它们不是可有可无的高阶技巧，而是让测试代码更简洁、更专业的核心工具。
回顾之前编写的测试用例，每个测试方法内部都重复编写了实例化代码。例如 TestProduct 类中，每个方法都写了 data = [...] 和 result = product(data)。当测试用例数量增多时，这类重复代码会显著增加维护成本。此时，测试夹具便能派上用场。
在 unittest 中，夹具主要通过以下三个方法实现：
| 方法 | 调用时机 | 适用场景 |
|---|---|---|
setUp() |
每个测试方法执行前调用一次 | 为每个测试准备干净、独立的初始状态 |
tearDown() |
每个测试方法执行后调用一次 | 清理测试产生的副作用，如关闭文件、断开数据库连接 |
setUpClass() / tearDownClass() |
在当前测试类的所有方法执行前后各调用一次 | 准备开销较大的资源，如建立数据库连接池、启动测试服务器 |
以下示例将前文的TestProduct测试类使用setUp进行重构，避免在每个测试方法中重复实例化：
import unittest
from my_math import product
class TestProduct(unittest.TestCase):
def setUp(self):
"""在每个测试方法运行前执行，准备基础测试数据"""
# 创建一份通用的测试数据，供多个测试方法复用
self.base_data = [2, 3, 4]
self.base_expected = 24
def test_list_int(self):
"""测试整数列表的乘积——直接使用setUp准备好的数据"""
result = product(self.base_data)
self.assertEqual(result, self.base_expected)
def test_single_element(self):
"""测试只有单个元素的列表"""
result = product([7])
self.assertEqual(result, 7)
def tearDown(self):
"""在每个测试方法运行后执行，清理测试痕迹（本例中可省略）"""
pass
if __name__ == "__main__":
unittest.main()
要点说明：
setUp在每个测试方法执行前都会运行一次。这意味着每个测试方法拿到的 self.base_data都是全新初始化的，一个测试对属性的修改不会污染另一个测试。tearDown在每个测试方法执行后运行。对于涉及文件读写、数据库操作的测试，可在此处统一执行清理逻辑，确保测试之间完全隔离。setUpClass和tearDownClass类方法，它们在整个测试类中仅运行一次。使用夹具后，测试方法的职责更加单一：只需关注具体的测试逻辑，前置准备和事后清理均由框架统一管理。
观察TestProduct类中的多个测试方法，它们本质上都是在验证product()函数能否对不同输入返回正确的乘积值。如果每次新增一种输入类型都要编写一个完整的新方法，代码会迅速膨胀。更理想的做法是：只编写一份测试逻辑，让它自动遍历多组输入数据。
虽然unittest本身不提供专用的参数化装饰器，但其内置的subTest上下文管理器可以优雅地实现同一目的。以下示例展示了如何将多个独立的测试方法合并为一个参数化测试：
import unittest
from my_math import product
class TestProduct(unittest.TestCase):
def test_product_various_inputs(self):
"""使用subTest一次性覆盖多种输入场景"""
# 定义测试用例列表：每个元素是一个元组（输入数据， 预期结果， 用例描述）
test_cases = [
([2, 3, 4], 24, "整数列表求积"),
([7], 7, "单元素列表"),
([], 1, "空列表"),
([-2, 3, -4], 24, "包含负数的列表"),
((2, 4, 5), 40, "元组求积"),
({2, 3, 2}, 6, "集合求积（注意去重）"),
]
for data, expected, description in test_cases:
# subTest会在循环中区分每一次迭代
# 即使某个子用例失败，其他子用例仍会继续执行
with self.subTest(description=description, data=data):
result = product(data)
self.assertEqual(result, expected)
def test_product_float(self):
"""浮点数乘积单独测试——使用assertAlmostEqual处理精度问题"""
result = product([1.5, 2.0, 3.0])
self.assertAlmostEqual(result, 9.0)
if __name__ == "__main__":
unittest.main()
subTest 的关键优势在于：
在常规测试中，我们通常验证函数是否返回正确结果。然而，在某些场景下，期望的行为并非正常返回，而是函数主动抛出异常。例如，当传入非法参数时，函数应当抛出TypeError或ValueError来提示调用者。
但unittest框架默认的行为是：只要测试执行过程中抛出任何未被捕获的异常，都将被视为测试失败。这意味着：测试期望抛出异常 → 实际也抛出了异常 → 测试却显示失败。这显然不符合测试异常场景的需求。
为解决此问题，unittest提供了assertRaises方法，推荐以上下文管理器的形式使用。它能够捕获代码块中抛出的指定异常，并将其视为测试通过的条件。
以下示例展示了assertRaises的正确与错误用法：
import unittest
from my_math import product
class TestProduct(unittest.TestCase):
"""测试 my_math.product 函数的单元测试用例"""
def test_1_product_of_integers(self):
"""正常情况：计算整数列表的乘积"""
data = [1, 2, 3, 4]
result = product(data)
self.assertEqual(result, 24) # 测试通过 ✅
def test_2_product_with_single_element(self):
"""错误示范：预期单元素列表应返回该元素本身，此处却误用 assertRaises"""
# product([42]) 实际上会正常返回 42，不会抛出任何异常，
# 但 assertRaises 期望抛出 TypeError，因此该测试失败。
# 运行结果：失败 ❌ (AssertionError: TypeError not raised)
with self.assertRaises(TypeError):
product([42])
def test_3_non_iterable_input(self):
"""正确用法：传入非可迭代对象（整数）应抛出 TypeError"""
# product(42) 会因为传入整数（不可迭代）而抛出 TypeError，
# assertRaises 成功捕获该异常，因此测试通过。
# 运行结果：通过 ✅
with self.assertRaises(TypeError):
product(42)
def test_4_catch_any_exception(self):
"""不推荐：捕获过于宽泛的 Exception 基类"""
# 使用 Exception 可以捕获几乎任何异常类型，
# 但这种写法会掩盖具体的异常类型，降低测试的精确性。
# 本例中 product([42]) 未抛出异常，因此测试失败。
# 运行结果：失败 ❌ (AssertionError: Exception not raised)
with self.assertRaises(Exception):
product([42])
if __name__ == "__main__":
unittest.main()
with self.assertRaises(TypeError): 的语义是：执行该代码块必须抛出TypeError类型的异常，否则测试判定为失败。只有当预期的异常被抛出且类型匹配时，测试才会通过。
assertRaises的第一个参数可以灵活指定：
ValueError、KeyError或自定义异常类；(TypeError, ValueError)，表示捕获其中任意一种异常即算通过；Exception可捕获几乎全部异常，但因其过于宽泛，会掩盖代码中潜在的异常类型错误，一般仅在调试或临时验证时使用，正式测试中强烈推荐指定明确的异常类型。
到目前为止，主要学习的是单元测试。单元测试专注于验证一个独立的小功能，比如一个加法函数。单元测试能帮助构建出可预测、稳定的代码。
但程序在真正启动运行时也需要不出差错。只测试单个函数是不够的，因为应用程序是由许多模块共同协作的，一个函数能正常工作，不代表它和其他模块合在一起也能正常工作。
集成测试是对应用程序的多个组件进行测试，以验证它们能否协同工作。集成测试通常需要模拟真实用户或外部系统的行为，例如调用消息队列、读写文件系统、调用数据库存储过程、发送电子邮件或短信。
这些集成测试可以采用与单元测试相同的方式编写，即遵循输入、执行、断言的模式。集成测试与单元测试最大的区别在于：
下面通过一个具体案例，直观感受两者的区别。
被测试的代码如下：
# calculator.py
class Calculator:
"""计算器 - 包含计算与文件存储功能"""
def add(self, a, b):
return a + b
def save_result(self, result):
"""保存计算结果到本地文件"""
with open('result.txt', 'w', encoding='utf-8') as f:
f.write(str(result))
def calculate_and_save(self, a, b):
"""完整业务流程：计算结果并自动保存"""
result = self.add(a, b)
self.save_result(result)
return result
单元测试只关注核心计算逻辑，不依赖真实文件系统。在下面的例子中，每个测试方法都会获得一个新的Calculator实例，其save_result方法被替换为模拟对象，不会产生任何文件副作用。
# tests/unit/test_calculator_unit.py
import sys
from pathlib import Path
sys.path.append(str(Path(__file__).parent.parent.parent))
import unittest
from unittest.mock import Mock
from calculator import Calculator
class TestCalculatorUnit(unittest.TestCase):
"""单元测试：使用Mock隔离文件操作，只校验纯逻辑"""
def setUp(self):
self.calc = Calculator()
# 模拟替换保存方法，避免真实生成文件
self.calc.save_result = Mock()
def test_add(self):
"""单独测试加法逻辑"""
result = self.calc.add(2, 3)
self.assertEqual(result, 5)
def test_calculate_and_save(self):
"""测试整体流程调用逻辑，不操作真实文件"""
result = self.calc.calculate_and_save(2, 3)
self.assertEqual(result, 5)
self.calc.save_result.assert_called_once_with(5)
if __name__ == '__main__':
unittest.main()
集成测试则使用真实文件系统，测试文件操作并验证组件间的协作，确保完整的计算与保存流程无误：
# tests/integration/test_calculator_integration.py
import sys
from pathlib import Path
sys.path.append(str(Path(__file__).parent.parent.parent))
import unittest
import os
from calculator import Calculator
class TestCalculatorIntegration(unittest.TestCase):
"""集成测试：使用真实文件系统，校验完整业务流程"""
def setUp(self):
self.file_name = "result.txt"
# 前置清理残留文件
if os.path.exists(self.file_name):
os.remove(self.file_name)
self.calc = Calculator()
def tearDown(self):
# 测试结束后自动清理，避免环境污染
if os.path.exists(self.file_name):
os.remove(self.file_name)
def test_full_workflow(self):
"""完整流程：计算 + 保存文件 全链路校验"""
result = self.calc.calculate_and_save(4, 5)
self.assertEqual(result, 9)
self.assertTrue(os.path.exists(self.file_name))
with open(self.file_name, 'r', encoding='utf-8') as f:
content = f.read()
self.assertEqual(content, "9")
def test_multiple_calculations(self):
"""测试多次计算，文件内容自动覆盖"""
self.calc.calculate_and_save(1, 2)
self.calc.calculate_and_save(10, 20)
with open(self.file_name, 'r', encoding='utf-8') as f:
content = f.read()
self.assertEqual(content, "30")
if __name__ == '__main__':
unittest.main()
推荐的文件结构如下：
project/
│
├── calculator.py # 要测试的代码
│
└── tests/
├── unit/ # 单元测试（快，用 Mock）
│ └── test_calculator_unit.py
│
└── integration/ # 集成测试（慢，真实操作）
└── test_calculator_integration.py
运行方式如下：
# 每次改完代码快速跑单元测试
python -m unittest discover -s tests/unit
# 提交代码前跑集成测试
python -m unittest discover -s tests/integration
在2.4.1的集成测试中，测试数据是直接硬编码在测试代码里的。但在实际项目中，很多业务逻辑依赖于预置的测试数据，比如数据库中必须存在特定用户、订单或配置，测试才能运行。
这类集成测试的核心特点是：测试逻辑由外部数据文件驱动，数据一变，测试结果随之改变。为此，推荐在集成测试目录下创建一个fixtures文件夹，用于存放测试数据文件，然后在测试代码中加载这些数据。
下面是一个优惠券管理系统的示例，展示如何用JSON文件驱动集成测试。
核心代码（coupon.py）如下：
import json
class CouponManager:
"""从 JSON 文件加载优惠券并提供基础操作"""
def __init__(self, data_path):
"""
初始化时直接加载 JSON 文件中的优惠券数据
:param data_path: fixtures 目录下的 JSON 文件路径
"""
with open(data_path, encoding='utf-8') as f:
data = json.load(f)
# 假设 JSON 格式为 {"coupons": [{"code":..., "discount_percent":..., ...}]}
self.coupons = data['coupons'] # 每一项都是 dict，方便直接使用
def active_count(self):
"""返回 is_active 为 True 的优惠券数量"""
# 使用生成器表达式统计
return sum(1 for c in self.coupons if c['is_active'])
def apply(self, code, amount=0):
"""
应用优惠码，计算折扣
:param code: 优惠券码
:param amount: 订单金额
:return: dict 包含 success 状态、msg 或 discount 金额
"""
# 遍历所有优惠券（数据量小，直接线性查找）
for c in self.coupons:
if c['code'] == code:
# 检查是否失效
if not c['is_active']:
return {'success': False, 'msg': '已失效'}
# 检查是否达到最低消费门槛（JSON中可缺省min_order，默认0）
min_order = c.get('min_order', 0)
if amount < min_order:
return {'success': False, 'msg': f"需满{min_order}元"}
# 计算折扣金额，四舍五入保留两位小数
discount = amount * c['discount_percent'] / 100
return {'success': True, 'discount': round(discount, 2)}
# 未找到对应优惠码
return {'success': False, 'msg': '优惠码不存在'}
测试夹具(fixtures/coupons.json)如下：
{
"coupons": [
{
"code": "SAVE10",
"discount_percent": 10,
"message": "10% off applied",
"is_active": true,
"min_order_amount": 0,
"category": "general"
},
{
"code": "SAVE20",
"discount_percent": 20,
"message": "20% off applied",
"is_active": true,
"min_order_amount": 200,
"category": "general"
},
{
"code": "EXPIRED50",
"discount_percent": 50,
"message": "50% off applied",
"is_active": false,
"min_order_amount": 0,
"category": "general"
},
{
"code": "VIP100",
"discount_percent": 30,
"message": "VIP 会员专享 7 折优惠",
"is_active": true,
"min_order_amount": 500,
"category": "vip"
}
]
}
集成测试（test_coupon.py）代码如下：
import unittest
import sys
import os
sys.path.insert(0, os.path.dirname(os.path.dirname(os.path.dirname(__file__)))) # 将 project/ 加入路径
from coupon import CouponManager
class TestCoupon(unittest.TestCase):
"""集成测试：使用真实的 JSON 夹具验证优惠券逻辑"""
def setUp(self):
"""每个测试方法执行前都会运行：构造 CouponManager 并加载夹具"""
# 构造 fixtures 目录下 coupons.json 的绝对路径
# __file__ 是当前文件（test_coupon.py）的路径
fixture_dir = os.path.join(os.path.dirname(__file__), 'fixtures')
fixture_path = os.path.join(fixture_dir, 'coupons.json')
self.mgr = CouponManager(fixture_path)
def test_active_count(self):
"""验证活跃优惠券数量统计正确"""
# 根据 fixtures/coupons.json 中的数据，有两个活跃优惠券
self.assertEqual(self.mgr.active_count(), 2)
def test_apply_valid(self):
"""验证有效优惠券能正确计算折扣"""
res = self.mgr.apply('SAVE10', 100)
self.assertTrue(res['success'])
# 10% 折扣，100 元 -> 10.0
self.assertEqual(res['discount'], 10.0)
def test_apply_below_min(self):
"""验证未达到最低消费门槛时返回失败"""
res = self.mgr.apply('SAVE20', 100) # SAVE20 需要满 200 元
self.assertFalse(res['success'])
self.assertIn('200元', res['msg'])
def test_apply_expired(self):
"""验证已失效优惠券返回失败"""
res = self.mgr.apply('EXPIRED', 100)
self.assertFalse(res['success'])
self.assertEqual(res['msg'], '已失效')
if __name__ == '__main__':
# 运行所有测试
unittest.main()
目录结构如下：
project/
├── coupon.py
└── tests/
└── integration/
├── fixtures/
│ └── coupons.json
└── test_coupon.py
在项目根目录下执行代码：
python tests/integration/test_coupon.py
Tox工具的使用
考虑一个常见场景，开发者在本地环境的Python 3.11上编写了一个小工具，运行一切正常。然而，同事仍在使用Python 3.9，一运行就报错。另一个潜在问题是，所依赖的某个第三方包升级后，新版本与原有代码不兼容。这些情况都会导致所谓在我电脑上明明可以运行的尴尬局面。
如何在发布代码之前就主动发现这类兼容性问题呢？Tox就是解决这个问题的利器。它能够自动在多个Python版本下运行你的测试套件，只需一条命令即可完成跨版本兼容性检查。安装命令如下：
$ pip install tox
假设我们有一个工具文件 str_utils.py，里面实现了一些字符串处理和日期计算的函数。再编写一个对应的测试文件，来验证这些函数的正确性。项目结构如下：
str_utils/
├── str_utils.py ← 你的业务代码
├── test_str_utils.py ← 你的测试代码
└── tox.ini ← Tox 的配置文件
业务代码str_utils.py中定义了三个函数：
from datetime import datetime
def to_title_case(text):
"""将字符串转换为首字母大写的标题格式"""
return text.title()
def remove_punctuation(text):
"""移除字符串中的所有标点符号"""
import string
return text.translate(str.maketrans("", "", string.punctuation))
def days_until(target_date_str):
"""计算当前日期距离目标日期还有多少天（负数表示已过去）"""
target_date = datetime.strptime(target_date_str, "%Y-%m-%d")
today = datetime.now()
delta = target_date - today
return delta.days
测试代码 test_str_utils.py 用于验证上述函数的正确性：
import unittest
from unittest.mock import patch
from datetime import datetime
from str_utils import to_title_case, remove_punctuation, days_until
class TestStrUtils(unittest.TestCase):
def test_1_to_title_case(self):
self.assertEqual(to_title_case("hello world"), "Hello World")
def test_2_remove_punctuation(self):
self.assertEqual(remove_punctuation("Hello, World!"), "Hello World")
self.assertEqual(remove_punctuation("a.b,c?d!e;f:"), "abcdef")
@patch("str_utils.datetime") # 模拟 str_utils 模块中的 datetime
def test_3_days_until(self, mock_datetime):
# 创建一个固定的日期对象作为模拟的“当前时间”
fixed_date = datetime(2026, 1, 1)
# 设置模拟对象的 now 方法返回该固定日期
mock_datetime.now.return_value = fixed_date
# 保留 strptime 的真实功能，用于正常解析输入的日期字符串
mock_datetime.strptime = lambda x, y: datetime.strptime(x, y)
# 调用被测试函数：计算从 2026-01-01 到 2026-01-10 还有多少天
result = days_until("2026-01-10")
self.assertEqual(result, 9)
if __name__ == "__main__":
unittest.main()
在配置Tox之前，建议先手动运行一次测试，确认代码在当前环境下一切正常：
$ python -m unittest discover
接下来，若要支持多Python环境测试，需要配置Tox。在项目根目录下新建一个名为tox.ini的配置文件，并写入以下内容：
[tox]
# 定义要运行的 Python 版本环境列表
envlist = py38, py39, py310, py311
# 跳过打包步骤（适用于没有 setup.py 的项目）
# 当项目无需安装即可直接测试时使用
skipsdist = True
[testenv]
# 在每个测试环境中执行的命令
commands =
# 使用 unittest 框架自动发现并运行所有测试用例
python -m unittest discover
配置完成后，在终端中执行：
$ tox
正常情况下，会看到类似下面的输出：
py38: commands[0]> python -m unittest discover
...
----------------------------------------------------------------------
Ran 3 tests in 0.002s
OK
py39: commands[0]> python -m unittest discover
...
----------------------------------------------------------------------
Ran 3 tests in 0.002s
OK
py310: commands[0]> python -m unittest discover
...
----------------------------------------------------------------------
Ran 3 tests in 0.002s
OK
py311: commands[0]> python -m unittest discover
...
----------------------------------------------------------------------
Ran 3 tests in 0.002s
OK
___________________________________ summary ___________________________________
py38: commands succeeded
py39: commands succeeded
py310: commands succeeded
py311: commands succeeded
congratulations :)
Tox通常会为每个指定的Python版本创建独立虚拟环境，这些环境默认存放在项目目录下的.tox/文件夹中，并在各环境中分别安装依赖（如有）后运行测试。首次运行时会相对较慢，因为需要创建虚拟环境并安装基础包，后续运行则会明显加快。Tox的具体使用方法可参考官方文档：tox 。
当所有指定版本的测试都通过后，终端会显示congratulations :)。如果某个环境的测试失败，Tox会立即停止并报告错误详情。造成失败的常见原因之一是缺少外部依赖。例如，代码中包含了import django，那么Django就是该测试所必需的外部依赖。此时需要在tox.ini配置文件中明确告知Tox先安装这些依赖，再运行测试。配置示例如下：
[tox]
envlist = py38, py39, py310
skipsdist = True
[testenv]
deps =
django>=3.2,<4.0
requests
pytest
commands =
python -m unittest discover
此外，Tox还提供了多种命令行参数，以适应不同的开发和调试场景。常用命令及其含义如下：
| 命令 | 含义 | 适用场景 |
|---|---|---|
tox |
在所有指定环境中运行测试 | 常规使用，全面检查兼容性 |
tox -e py310 |
仅针对Python 3.10环境运行测试 | 需要快速测试单个版本时 |
tox -r |
删除并重建所有虚拟环境 | 依赖发生变化或环境出现异常时 |
tox -q |
减少输出信息，仅显示最终结果 | 只关心测试是否通过 |
tox -v |
增加输出信息，显示详细执行过程 | 出现错误，需要深入排查问题时 |
Tox与自动化测试集成
到目前为止，测试主要依赖手动执行命令完成，但在实际开发流程中，更常见的做法是当代码提交到Git等版本控制系统后，由自动化工具自动触发测试流程。这类工具可以在每次提交时自动运行测试，从而减少人工操作并提高反馈效率。
在Python生态中，TravisCI是常用的持续集成服务之一。通过将Tox集成到.travis.yml配置文件中，可以在每次代码提交时自动执行多版本测试，从而提前发现不同Python版本之间的兼容性问题并提升代码质量。TravisCI的使用方法可参考官方文档：Travis CI。
此外，可以结合Python库tox-travis，让TravisCI自动根据当前运行的Python版本选择对应的Tox环境，从而实现本地开发环境与测试环境配置的一致性。
覆盖率测试
写了测试之后，一个关键问题是是否覆盖到了所有代码路径，coverage.py是Python生态中常用的覆盖率测量工具，用于分析测试执行过程中哪些代码被触达、哪些没有被执行。
安装方式如下：
pip install coverage
使用coverage run执行测试并收集覆盖率数据：
coverage run -m unittest discover
生成覆盖率报告的方式如下：
coverage report，用于快速查看整体覆盖率情况coverage html，生成htmlcov/index.html，可在浏览器中逐行查看代码覆盖情况报告会标注哪些代码被执行过，哪些从未触及，从而帮助定位未覆盖的代码路径，尤其是异常处理和边界条件等容易遗漏的逻辑。
初次提升覆盖率时不必追求100%，更重要的是优先补齐关键逻辑的缺失部分。随着测试逐步完善，可以持续提高覆盖率，并在自动化流程中设置最低阈值，例如80%，避免后续修改导致覆盖率下降。更多使用方法可参考：coverage。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。