第3章 自动化测试框架选型：Pytest+Requests、Postman+Newman、Selenium对比与SOP

在B2B权限验收中，测试框架的选型直接影响自动化覆盖率和维护成本。Pytest+Requests、Postman+Newman、Selenium三个体系在协议支持、交互深度、团队门槛上差异显著。本章通过选型决策流程、多维度对比表和标准SOP，帮助团队在权限验收场景下做出可复现的框架选择。

3.1 适用场景

三种框架在B2B权限验收中的定位各不相同，选型前需准确匹配测试需求。下表从核心能力、典型场景和团队要求等维度进行对比。

3.2 前置条件

在启动框架选型前，需完成以下环境与信息准备。不同框架的前置依赖差异较大，建议按候选框架分别检查。

python -m pytest --version
pip show requests

newman --version
npm list -g newman

python -c "import selenium; print(selenium.__version__)"
chromedriver --version

此外，还需准备以下非环境类前置条件：

• 权限需求清单： 已评审通过的B2B权限案例库，包含角色、资源、操作、预期结果。
• 接口文档/UI原型： 被测系统的API Swagger/OpenAPI文档，或前端权限设计原型图。
• 测试账号池： 涵盖所有权限角色的测试账号（超管、管理员、普通用户、受限用户等）。
• CI/CD通道： 若选型结果需集成流水线，提前确认Jenkins/GitLab CI/GitHub Actions的可用性。

3.3 操作步骤

框架选型遵循以下标准化SOP，共7个步骤，每一步均需记录关键决策依据。

1. 步骤1：梳理权限测试需求矩阵
   将权限案例按“是否依赖UI交互”和“API逻辑复杂度”两个维度分类，标记出纯API校验类和UI交互类案例的数量与占比。
2. 步骤2：初筛候选框架
   根据需求矩阵确定候选框架：
   - 若存在UI交互类案例 → 必须纳入Selenium
   - 若纯API案例占比 > 70% → 优先Pytest+Requests或Postman+Newman
3. 步骤3：评估团队技术栈与学习成本
   对照团队现有技能图谱，排除学习周期无法满足交付节奏的框架。记录技术风险评估。
4. 步骤4：搭建框架验证原型
   选择1～2个典型权限案例，分别用候选框架编写验证脚本。对比执行效率、脚本可读性和维护成本。
   示例：对一个“管理员可创建用户”的API权限案例，三种框架的实现风格如下：
   

   # Pytest+Requests 风格
   def test_admin_can_create_user():
       token = get_admin_token()
       resp = requests.post("/api/users",
           headers={"Authorization": f"Bearer {token}"},
           json={"role": "editor", "email": "new@corp.com"})
       assert resp.status_code == 201
       assert resp.json()["user"]["role"] == "editor"

   // Postman Tests 脚本风格
   pm.test("创建用户成功", function () {
       pm.response.to.have.status(201);
       pm.expect(pm.response.json().user.role).to.eql("editor");
   });

   # Selenium 风格（UI权限校验）
   def test_admin_can_see_create_button():
       driver = login_as_admin()
       btn = driver.find_element(By.CSS_SELECTOR, "[data-testid='create-user-btn']")
       assert btn.is_displayed() and btn.is_enabled()

5. 步骤5：CI/CD集成适配验证
   将原型脚本接入CI流水线，检查框架在容器化环境中的依赖安装、报告输出和失败重试能力。
6. 步骤6：框架决策与评审
   综合需求匹配度、团队能力、维护成本、CI兼容性四个维度进行加权评分，输出选型建议并组织技术评审会。
7. 步骤7：输出选型决策报告
   将评审确认的框架选型结果、支撑数据、遗留风险统一写入报告，归档至知识库。

3.4 输入输出物

3.5 责任边界

3.6 记录材料

选型过程中产生的以下材料需归档至项目知识库，保留期限不低于项目交付后12个月：

• 框架选型评估表（含需求匹配矩阵、加权评分原始数据）
• 技术预研报告（包含原型脚本、执行日志、对比数据）
• 技术评审会议纪要（含参会人员、决策意见、待办事项）
• 框架选型决策报告（最终审批版，含风险登记册）
• CI/CD适配验证记录（流水线配置、运行截图、问题列表）

3.7 异常处理

• 异常1：框架不支持特定认证协议（如OAuth2 PKCE、SAML断言）
  处理措施：检查框架扩展生态（如Pytest的requests-oauthlib插件、Postman的Pre-request Script）；若生态不支持，降级为半自动化+人工复核，并在选型报告中标记为已知风险。
• 异常2：团队缺乏某框架技术储备，学习周期超出交付窗口
  处理措施：优先选择团队已有经验的框架；若必须更换，安排短期技术集训（3～5天），并引入框架导师制。
• 异常3：框架与现有CI/CD工具链集成报错（如Docker镜像缺少浏览器内核）
  处理措施：对Selenium，切换到无头模式并使用预装浏览器的镜像；对Newman，检查Node版本兼容性；记录适配方案至基础设施文档。
• 异常4：框架社区活跃度低，遇到阻塞问题48小时未响应
  处理措施：启动备用框架方案（须提前在选型报告中指定备选），将原框架降级为观察清单，待社区修复后再评估是否切换。
• 异常5：框架性能不满足大规模权限案例执行要求（如Selenium执行千级案例耗时过长）
  处理措施：对Selenium案例进行分级，仅保留UI交互类案例使用Selenium；将纯API权限案例迁移至Pytest+Requests或Newman，实现框架混跑。

3.8 验收标准

框架选型完成且通过以下全部验收项后，方可进入下一阶段（测试框架搭建与脚本开发）：

• 验收项1：需求覆盖 —— 所选框架的能力矩阵覆盖全部权限案例分类，无明显盲区（覆盖率≥90%）。
• 验收项2：原型验证通过 —— 至少完成2个典型权限案例的端到端原型脚本，且执行结果与预期一致。
• 验收项3：CI/CD集成成功 —— 原型脚本在CI流水线中运行通过，报告生成正常，失败重试机制有效。
• 验收项4：风险登记册闭环 —— 选型过程中识别的技术风险均有对应措施或降级预案，且经技术经理签字确认。
• 验收项5：材料归档完整 —— 本章3.6节列出的所有记录材料已提交至知识库，且内容完整、版本正确。
• 验收项6：团队技能就绪 —— 核心测试人员已完成框架技术集训（如适用），并通过内部代码评审能力考核。