IntelliPandora

IntelliPandora 是基于 pytest 的测试框架。pytest 告诉你有没有用例失败，IntelliPandora 还要回答这次的通过结果是否可信：每条用例验证了什么、哪些没有验证、和上次相比少验证了什么、失败应该由谁来修。

用例仍是普通的 pytest 用例，已有的测试套件不用改就能跑。框架不包含任何业务逻辑，用例、业务流程和环境配置都放在使用方自己的仓库里。

覆盖的测试对象：HTTP 接口、gRPC、Kafka、Web（Playwright）、Android（uiautomator2）、截图比对；分布式系统方面有一致性检查、故障注入、依赖服务编排（docker compose）和跨服务调用链路；另外可以评测 AI agent。

为什么不直接用 pytest

pytest 的断言是异常，断言通过时不留任何记录。因此它无法回答：一条通过的用例到底验证了什么？一个断言都没有的用例为什么也是通过？这次比上次少验证了什么？

当用例由 AI agent 编写或修改时，最后一个问题尤其重要：agent 让测试通过的办法，可能是删掉暴露缺陷的测试或放宽断言，而不是修好代码。HackTrace 用 Qwen3-8B 做编程题：测试文件允许修改时，3,040 条轨迹里有 593 条（19.5%）走了捷径，其中 570 条是改测试；测试设为只读，走捷径的比例并没有下降（约两成），只是变成了硬编码答案、针对用例特判。

IntelliPandora 把每一次判定都记录下来，与仓库中提交的基线比较：判定被删除、范围被放宽、期望值被修改、用例被改为跳过，都会在报告中列出，也可以在 CI 中直接拦下。评审的人只需要看被列出的这几条。

📖 定位与对比：pytest 生态已有哪些能力，哪些是这里独有的，为什么这样设计 · 定位与路线 · agent 验证

主要能力

安装

需要 Python 3.10 或更高版本。

pip install intellipandora                # 核心，7 个直接依赖
pip install "intellipandora[web]"         # 按需安装可选组件，可以组合：[web,parallel]

新建一个用例项目，包含配置、可以离线运行的示例、给 agent 看的 AGENTS.md 和带门禁的 CI 配置样例：

ipandora init my-tests && cd my-tests && ipandora run tests

📖 快速开始

使用

ipandora run test/api                        # 运行后生成 HTML、JSON、JUnit XML
ipandora run test/api --junit-xml out.xml    # 把 JUnit XML 写到指定位置，供 CI 读取
ipandora run test/api --exclude-flaky        # 跳过标记为 @pytest.mark.flaky(reason=...) 的用例
ipandora run test/api -e staging             # 本次运行叠加 ./conf/staging.yaml
ipandora run test/api --update-baseline      # 把本次的判定写为基线（conf/judgements.json，提交到仓库）
ipandora run test/api --fail-on-weakened     # 判定比基线弱时运行失败（删除、放宽、修改、新增跳过或排除、零判定通过）
ipandora mcp                                 # 启动 MCP server，供 agent 调用

写一条用例：

from ipandora.core import api
from ipandora.core.assertion import assert_all, field, status_ok

class OrderService:
    @api.http.post(path="api/order/create")
    def create(self, amount):
        return dict(json={"amount": amount})

def test_create_order():
    """下单成功，金额与请求一致，每个明细价格为正"""
    r = OrderService().create(100)
    assert_all(                                   # 一次报出全部失败
        status_ok(r),
        field(r, 'data.amount') == 100,
        field(r, 'data.status').is_in(['created', 'paid']),
        field(r, 'data.items').each('price').decimal() > 0,
    )

失败时的输出：data.items[*].price > 0 — 1 of 3 items failed: data.items[1].price = Decimal('-1') (expected > 0)。

📖 使用指南

命令行和 MCP

命令行和 MCP 调用的是同一个执行入口 run()，测试能力完全相同。只有接入 AI agent 时才需要 MCP。

日常流程

用例失败后，先要分清是用例的问题还是产品的问题，因为两者由不同的人修。只有归为产品缺陷（defect）和接口契约（contract）的失败，报告才算作被测系统的问题；环境、注入的故障、测试数据和用例自身的问题不计入。

LLM 的使用范围

LLM 只用于编写用例和运行之后的分析，执行用例时不调用 LLM。

所以一天运行一万次用例，LLM 调用次数是 0。这一点有四项检查保证：默认安装不包含任何 LLM SDK；配置项 ai.enabled 默认为 false；core/ 不得导入 ai/，CI 用 AST 静态检查；CI 中有一项作业删除 src/ipandora/ai 后运行全部测试，必须通过。

📖 LLM 接入边界

代码结构

代码在 src/ipandora/。各模块的职责和相互关系见 架构。

文档

开发

make install && make install-tools   # 从带哈希的锁文件安装，与 CI 一致
pytest test/                         # 全部测试，不需要网络
python scripts/smoke_import.py       # 每个模块都能导入
python scripts/check_layering.py     # core/ 不依赖 ai/
python scripts/check_docs.py         # 文档链接有效，参考文档与代码一致
python scripts/check_packaging.py    # 必需的数据文件进了 wheel
python scripts/mutation.py core/report/junit.py   # 变异测试：故意改错代码，检查测试能否发现
make security                        # 组件登记检查、漏洞扫描、代码扫描、许可证检查

📖 开发手册

安全

测试框架运行在 CI 中，持有测试账号和密钥，并在被测环境中执行代码，因此是供应链攻击的重点目标。框架引入的每一个第三方组件都要先通过准入审查，引入之后持续扫描：

• 准入：审查必要性、许可证和维护状况，只采用发布满 14 天的版本。所有组件登记在 组件登记表；代码中声明的依赖与登记表不一致时，CI 不允许合入。
• 锁定：CI 和开发环境从带哈希的锁文件安装，安装的正是审查过的文件；CI 中引用的 GitHub Actions 固定到提交 SHA。
• 扫描：每个 PR、每次合入 main 和每天定时扫描依赖漏洞（pip-audit）、自身代码（bandit）和许可证，结果公开在 安全报告。
• 发布：只通过 GitHub Actions 以 PyPI Trusted Publishing 发布，附带来源证明（attestation）；每个版本附 CycloneDX 格式的 SBOM。

规则和理由见 第三方组件安全准入与漏洞扫描。

License

Apache License 2.0