Debian系统Python自动化测试如何进行

在Debian生态下做Python自动化测试，其实是个挺有意思的话题。很多朋友一上来就急着写用例、搭框架，结果往往环境没整利索，依赖冲突搞得人头疼。今天咱们就从环境准备开始，一步步把这事儿捋清楚。

环境准备与项目初始化

系统层面的准备工作其实就两行命令：sudo apt update && sudo apt install -y python3 python3-pip。不过，这里有个关键点——一定一定要用虚拟环境。别图省事直接在系统级装包，后面依赖冲突起来有你受的。

创建虚拟环境很简单：python3 -m venv venv && source venv/bin/activate。激活后，顺手更新下pip：pip install -U pip。然后安装pytest（如果需要覆盖率报告，再加个pytest-cov）：pip install pytest pytest-cov。

依赖管理这块，建议养成好习惯——项目一开始就跑一下 pip freeze > requirements.txt，把当前环境的包版本锁死。后续别人接手项目，直接 pip install -r requirements.txt 就能还原环境，省心省力。

项目结构可以参考这个模板：

my_project/
├── src/ （或 my_module/）
├── tests/
│   ├── __init__.py
│   └── test_*.py
├── requirements.txt
└── pytest.ini / tox.ini （可选）

这样的分层清晰明了，源码和测试互不干扰，后续做CI/CD也很方便。

编写与运行测试

咱们先看一个用Python内置unittest框架的最小示例。在 tests/test_math.py 里写：

import unittest

def add(a, b):
    return a + b

class TestMath(unittest.TestCase):
    def test_add(self):
        self.assertEqual(add(1, 2), 3)

运行的话，可以用 python -m unittest discover -s tests 自动发现所有测试用例，或者指定文件：python -m unittest tests.test_math。

不过在实际项目中，我更推荐pytest。它的语法更自然，写起来像这样：

from src.math import add

def test_add():
    assert add(1, 2) == 3

运行：pytest tests/ -v，想看看代码覆盖情况就加个 --cov=src --cov-report=term-missing。

这里有几个小技巧，用熟了效率提升不少：

• 测试发现：pytest默认找 test_*.py 或 *_test.py 文件；unittest用 discover。根据自己的习惯选一个就好。
• 标记与选择：给用例打标签是个好习惯。比如 @pytest.mark.slow 标记慢测试，日常调试时用 pytest -m slow 单独跑；只想跑某个函数，用 pytest tests/test_math.py::test_add -v 精准定位。
• 并行与报告：测试多的时候，加个 pytest -n auto（需要安装pytest-xdist）并行跑，节省时间。生成JUnit报告用 pytest --junitxml=report.xml，CI流水线要用它。

集成与持续化

在实际项目中，简单跑一下测试是不够的。我们需要把测试自动化，融入到代码提交、合并的流程里。这里提供两种常见的方案。

本地预提交钩子

在 .git/hooks/pre-commit 里写个脚本，提交前自动跑测试：

#!/usr/bin/env bash
set -e
source venv/bin/activate
pytest tests/ --maxfail=1 || { echo "Tests failed"; exit 1; }

这样每次提交代码前都会先跑一遍测试，通过才能提交，从源头上防止坏代码入库。

CI流水线

团队协作时，Jenkins是常用的选择。在Jenkinsfile里这么写：

pipeline {
    agent any
    stages {
        stage('Checkout') { steps { git 'https://github.com/example/my-python-app.git' } }
        stage('Install') { steps { sh 'python -m pip install --upgrade pip && pip install -r requirements.txt' } }
        stage('Test') { steps { sh 'pytest --junitxml=report.xml' } }
        stage('Archive') { steps { junit 'report.xml' } }
    }
}

GitHub Actions的配置也类似，在 .github/workflows/ci.yml 里：

name: Python CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-python@v5
      with: { python-version: '3.11' }
    - run: pip install -r requirements.txt
    - run: pytest --junitxml=report.xml
    - uses: actions/upload-artifact@v4
      with: { path: report.xml, name: pytest-report }

核心逻辑都一样：拉代码 -> 装依赖 -> 跑测试 -> 归档报告。区别在于CI工具的语法细节，理解了这个模式，换到其他平台也很快能上手。

专项测试场景

常规的单元测试和集成测试之外，还有一些特定场景需要单独处理。

Web UI自动化（Selenium）

对于Web应用，Selenium是绕不开的选择。安装：pip install selenium，浏览器驱动（比如geckodriver）要放在PATH里。一个简单的示例：

from selenium import webdriver

def test_title():
    driver = webdriver.Firefox()
    try:
        driver.get("https://example.com")
        assert "Example" in driver.title
    finally:
        driver.quit()

注意用 try...finally 保证浏览器能正常关闭，不然测试跑多了内存容易爆。

打包与多版本测试（Debian打包与pybuild）

如果项目要打包成Debian包，建议用pybuild来管理构建和测试。先装依赖：sudo apt-get install python3-all-dev python3-all-dbg python3-dev。然后在 debian/rules 或构建流程里调用 pybuild --test，它可以结合tox或stestr做多版本Python的矩阵测试，确保项目在不同Python版本下都能正常工作。

性能与剖析

性能测试不是锦上添花，而是项目上线的安全保障。基准测试可以用timeit模块：

import timeit
print(timeit.timeit('sum(range(1000))', number=10000))

CPU剖析：python -m cProfile -o profile.out app.py。生成的分析文件可以用 pstats 或 snakeviz 查看，定位性能瓶颈非常直观。

常见问题与最佳实践

最后，结合经验总结几条“铁律”：

• 虚拟环境是底线。系统包和项目包混在一起，最后大概率会出事。requirements.txt和锁文件建议分层管理，比如用requirements-dev.txt放开发工具，requirements.txt放运行依赖。
• CI必须跑测试，报告必须上传。JUnit XML格式是CI集成的标配，每次提交都能在流水线上看到测试通过数量、失败原因，问题排查效率翻倍。
• 快慢测试分离。给慢测试、集成测试打上标记（比如 @pytest.mark.slow），日常开发用 pytest -m "not slow" 快速跑；CI里全量回归，确保覆盖。
• pytest.ini配置统一。在项目根目录放一个pytest.ini，指定测试路径、标记和覆盖率选项。比如：[pytest] testpaths=tests, integration。这样团队成员跑测试时行为一致，减少沟通成本。
• Debian打包记住pybuild。它原生支持多Python版本测试，比自己写脚本跑省事多了，也能避免因为环境差异导致的神秘失败。

自动化测试这件事，关键在于形成习惯，而不是追求花哨的工具。先把环境搞干净，再让测试跑起来，最后集成到CI里，这套流程走通了，项目质量就有了最基本的保障。