IntelliPandora

AI 时代的测试判定层，建在 pytest 之上：agent 写，框架判，人审。

pytest 回答「有没有测试失败」；IntelliPandora 回答「这次通过可不可信」：验证了什么、没验证什么、比上次少验证了什么、失败该谁修。

目前支持 HTTP 接口测试和 Web 自动化（Playwright）；App 自动化在规划中。框架不绑定任何业务，业务相关的用例、流程、环境配置放在使用方自己的仓库里。

agent 同一轮里既写代码又写测试，绿灯就可以被「做」出来。框架需要做的不只是执行测试，而是为测试结果提供可信的依据：判定确定、可复现、不调 LLM，而且判定本身的变化要能被看见。人、CI、agent 三个入口调用同一套 runner，跑出来的结果一致。

为什么不直接用 pytest

pytest 回答「有没有测试失败」，IntelliPandora 回答「这次通过可不可信」。 用例照样是 pytest 用例，现有套件不用改就能跑。

pytest 的断言是异常：通过时什么都不留下。所以它回答不了：一个通过的测试验证了什么？一个 assert 都没写的测试为什么也是绿的？这次比上次少验证了什么？

AI 写测试之后，最后这个问题变成了关键：允许修改测试时，agent 走捷径的做法 96% 是改测试本身（HackTrace）。我们的分工是 agent 写，框架判，人审：框架给出两个结论，一是结果，二是判定强度有没有变弱；人只审被标出来的几条。

另一条腿是开箱的全栈方案：HTTP 今天可用，Web / App 按"集成，不封装"接入，驱动 API 原样暴露，框架只补配置、证据、判定和归因。

📖 定位：为什么不直接用 pytest：哪些能力 pytest 生态已经有、哪些是独有的、为什么这样设计 · 路线（含并发）· 前瞻：agent 验证

它解决什么

安装

pip install intellipandora            # 内核，依赖只有 8 个
pip install intellipandora[ai]        # 可选：失败归因接 LLM
pip install intellipandora[mcp]       # 可选：agent 入口
pip install intellipandora[system]    # 可选：系统信息工具（psutil）
pip install intellipandora[parallel]  # 可选：并行执行 --workers、单条用例超时 --timeout
pip install intellipandora[web]       # 可选：Web 自动化（Playwright），之后 python -m playwright install chromium
pip install intellipandora[visual]    # 可选：图像判定 matches_golden()

从零开始一个用例项目（配置、能离线跑通的示例、给 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    # 给 CI 的那份放到指定位置
ipandora run test/api --exclude-flaky        # 门禁模式：已知不稳定的用例不参与判定
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

两条路调的是同一个 run()，测试能力完全一样。MCP 是可选的，只有接 AI agent 时才需要。

日常工作流

失败之后第一件事是分清是用例错还是产品错——这两件事是不同的人该去修的。归因层做的就是这个判定，blames_system_under_test 为假时，报告不会把它算成产品缺陷。

LLM 的成本边界

LLM 只出现在「编写时」和「运行后」，绝不出现在「运行时」。

一天跑 10000 次用例，LLM 调用 0 次。这不是约定，是四条结构性保证：默认安装不含任何 LLM SDK；ai.enabled: false；core/ 不得 import ai/（CI 用 AST 检查）；rm -rf src/ipandora/ai && pytest 必须全绿（CI 里真的在跑）。

📖 docs/design/decisions/03-LLM接入边界.md

代码结构

代码在 src/ipandora/：

文档

开发

make install && make install-tools   # 锁定版本、校验哈希，与 CI 一致
pytest                               # 全部密闭，零网络依赖
python scripts/smoke_import.py       # 每个模块都 import 得进来
python scripts/check_layering.py     # core/ 不得依赖 ai/
python scripts/check_secrets.py $(git ls-files)
python scripts/check_packaging.py    # 必需数据文件要真的进 wheel
python scripts/mutation.py core/report/junit.py   # 变异测试：故意改坏，看测试抓不抓得住
make security                        # 依赖漏洞、代码扫描、许可证、组件登记

📖 开发手册

安全

测试框架会进 CI、拿着测试账号和密钥在被测环境里执行代码，是投毒的高价值目标。所以框架引入的每一个第三方组件都先过准入，进来之后持续扫描：

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

规则与理由见 docs/design/decisions/15。

License

Apache License 2.0