授权渗透测试功能测试计划编写教程：正向/负向用例、停止条件与证据复核

授权渗透测试的功能测试计划，本质上是委托方与测试方共用的一份工作文档。它不负责罗列工具，也不承诺发现多少漏洞，而是把委托目标翻译成双方都能逐条核对的测试条目：测哪些资产和业务功能、用什么角色和前置条件、预期看到什么结果、什么情况下必须停下来、证据如何保存和复核。计划写不到这个粒度，执行阶段就只能靠临场判断，测试影响和结论都难以追溯。

这里的“功能测试”不是业务验收测试，也不是把扫描器报告换个封面。它指的是围绕关键业务功能和安全控制编写的正反用例：正向用例证明合法操作能够通过、控制没有误伤业务；负向用例证明不符合策略的操作会被拒绝、不会泄露数据、能够留下审计痕迹。计划的价值在于让“测什么、怎么判、何时停、如何复核”在测试开始前就有共同答案。

先固定目标、范围与前置条件

目标写成可验证的断言

“提升系统安全性”不是测试目标。可执行的目标应该对应到具体功能和判断标准，例如：验证普通用户无法通过替换对象标识读取他人订单；验证后台管理接口只对约定角色开放并记录审计事件；验证文件上传的类型、大小和存储隔离策略按设计生效；验证登录失败和超限请求会触发约定的限制与告警。每个目标都应能对应到至少一条正向用例和一条负向用例，否则后续很难判断测试是否完成。

目标还要说明“不测什么”。不把渗透测试当作漏洞发现的唯一手段，也不把未授权的第三方系统、员工终端、物理环境或社会工程纳入默认范围。范围之外的目标即使偶然可达，也只记录观察，不继续验证。

范围写到资产、角色和环境

范围应是一份可确认归属的资产清单，而不是“公司所有系统”。清单至少包含域名、IP、API 端点、移动端后端、账号角色、环境类型和测试时间窗。生产环境与预发环境要分开写；如果只能在生产环境测试，就要把速率上限、并发上限、只读优先和时间窗口写进计划。第三方托管资产需要同时确认客户授权和平台政策，不能把“客户同意”当成“托管方也同意”。

允许和禁止的测试技术也要列清楚。通常应明确禁止拒绝服务模拟、破坏性数据修改、批量删除、持久化控制、横向移动超出约定网段，以及任何可能影响真实用户的操作。需要写入类操作时，单独列出审批人、测试数据、回滚方式和清理责任人。

前置条件与安全控制要能被执行

前置条件包括测试账号及角色、测试数据、源 IP 白名单、监控放行、备份与回滚安排、双方联系人、升级路径和书面授权。安全控制则包括请求速率、并发数、单用例最长执行时间、敏感数据不落地、证据脱敏、紧急停止口令和变更单机制。把这些写成具体数字和责任人，而不是“注意控制影响”。

公开指南也强调对测试计划实施受控变更。CREST 的《A Guide to Penetration Testing》提到，渗透测试项目应有机制处理范围、时间和技术变更。执行中一旦扩大目标、延长窗口或增加写入操作，应更新计划版本并通知双方，而不是在聊天窗口里口头确认。

把业务功能拆成可测试的条目

先建立一张矩阵：资产或业务功能、角色、安全控制、正向用例、负向用例。矩阵的作用是防止只测登录页和公开接口，却漏掉后台管理、导出、第三方集成和对象级授权。

业务功能	角色	安全控制	正向用例	负向用例
订单查询	普通用户	对象级授权	查询本人订单成功	替换为他人测试订单被拒
后台用户管理	管理员	功能级授权与审计	管理员操作成功且留痕	普通用户访问被拒
文件上传	普通用户	类型、大小、存储隔离	合法文件上传成功	非法类型或超大文件被拒
API 数据读取	服务账号	令牌作用域与速率限制	合法令牌按范围读取	过期或越权令牌被拒

拆解时优先覆盖高风险业务：身份认证、权限管理、支付与订单、文件上传下载、数据导出、后台管理、第三方回调。对每个条目写一句“测试假设”，例如“假设对象级授权由服务端校验，而不是只靠前端隐藏按钮”。假设明确后，正向和负向用例才知道该验证什么。

正向用例：证明控制生效且不误伤

正向用例按设计路径使用功能，断言要可观察：HTTP 状态码、响应字段、业务状态、权限边界、审计事件和日志记录。不要只写“页面正常”，也不要只截图首页。正向用例同时承担回归职责：整改修复后，用它确认安全控制没有把合法用户挡在外面。

编号	场景	预期断言	证据重点
POS-AUTH-001	普通用户使用正确凭据登录	登录成功；会话 Cookie 属性符合设计；审计记录登录成功；响应不回显敏感信息	请求 ID、状态码、Cookie 属性、审计事件时间
POS-AUTHZ-001	查询本人测试订单	返回 200；仅包含本人测试订单；归属字段与测试账号匹配	响应字段白名单、订单归属、截图哈希
POS-ADMIN-001	管理员执行约定管理操作	操作成功；权限判断正确；审计日志包含操作者、对象和结果	操作前后状态、审计日志片段
POS-UP-001	上传符合策略的测试文件	上传成功；类型和大小符合策略；存储路径不可预测；无脚本执行	文件元数据、存储响应、清理记录

正向用例的测试数据应使用专门创建的测试账号和测试订单，避免把真实用户数据带入证据。对会话 Cookie 属性、错误页行为等检查项，具体预期以系统设计为准；环境不同，不能把某一种实现当成唯一正确答案。

负向用例：证明控制会拒绝并留下痕迹

负向用例在授权范围内尝试不符合策略的操作，验证系统拒绝、不泄露、可审计。关键是“证明到拒绝即止”：看到 403、404、401 或通用错误页后，不继续尝试绕过，不扩大读取范围，不执行破坏性载荷。若意外读到真实个人信息、密钥或生产数据，立即停止相关用例，按事件流程上报，不保存原始数据。

编号	场景	预期结果	停止与记录
NEG-AUTHN-001	未认证访问受保护接口	401 或跳转登录；不返回业务数据	出现业务数据即停止并上报
NEG-AUTHZ-001	普通用户访问后台管理接口	403；记录拒绝审计；不泄露接口细节	返回管理数据即停止
NEG-IDOR-001	将路径中的订单标识替换为另一测试账号的订单	403 或 404；不泄露对象是否存在	读到非本人数据立即停止，不继续枚举
NEG-TOKEN-001	使用过期或签名错误的测试令牌	401；不进入业务逻辑	记录状态码和响应摘要即可
NEG-RATE-001	按约定上限之上发送请求	429 或临时限制；不影响其他测试	触发封禁影响业务时暂停
NEG-UP-001	上传策略禁止的类型或超大文件	拒绝；不落地可执行内容；记录审计	出现存储写入异常时停止并清理
NEG-ERR-001	触发业务错误	通用错误页；无堆栈、路径、版本或内部标识	泄露敏感信息时保留脱敏证据

负向用例要有正向对照。业务正常的拒绝和真正的安全缺陷容易混淆：例如某些接口对不存在对象统一返回 404 是设计选择，不应直接判为漏洞；但如果低权限用户能读到他人数据，或者拒绝响应里带出完整对象信息，就需要按影响判断。每个负向用例都应写明“拒绝的判定标准”，避免测试人员凭感觉下结论。

每个用例写全字段

用例模板不需要复杂，但字段要稳定，方便执行、复核和复测。下面是一个只读查询用例的占位示例，目标使用保留域名，令牌使用占位值：

case_id: AUTHZ-USER-001
title: 普通用户读取本人订单详情
asset: api.example.internal
role: user_a
preconditions:
  - 使用测试账号 user_a，已绑定测试订单 ord_test_001
  - 已确认该订单不含真实个人信息
steps:
  - 发送 GET /api/orders/ord_test_001
  - 请求头携带 user_a 的测试会话，不使用真实用户令牌
expected:
  - HTTP 200
  - 响应仅包含 ord_test_001，归属字段与 user_a 对应
  - 审计日志记录访问者、对象和结果
evidence:
  - UTC 时间、请求 ID、状态码、响应字段白名单
  - 截图文件名与 SHA-256
stop:
  - 响应出现非本人订单或真实个人信息时立即停止并上报
cleanup:
  - 注销测试会话，删除测试订单，确认无临时数据残留

字段中最容易被省略的是停止条件和清理步骤。停止条件应分为全局和用例级：全局条件包括生产错误率或延迟超过约定阈值、发现真实个人信息或密钥、测试账号被封禁影响业务、触发重大告警且无法抑制、客户叫停或授权变更；用例级条件包括已达到证明点、响应出现敏感数据、写入或删除操作超出预期、请求超时或触发封禁。出现任一条件，先停止并记录时间点，再决定是否继续。

影响控制要写成可核查的数字和动作：每秒请求数、并发连接数、单用例最长时间、是否允许写入、测试数据范围、时间窗口、变更单编号。清理步骤要指定负责人和完成时间，包括测试账号、上传文件、创建的记录、缓存、临时规则和数据恢复。清理完成后在计划中标记状态，而不是只在聊天里说“已处理”。

证据复核：把“我看到”变成“可复核”

证据要能回答四个问题：什么时间、谁、对哪个目标、做了什么、结果是什么。原始证据只读保存，工作副本脱敏；截图应包含 URL、时间、账号角色和关键响应，请求 ID 要能对应到服务端日志。对原始截图或导出文件计算哈希，写入报告，避免后续争议。

复核可以分三层：测试人员自检、委托方抽检、争议项由双方共同复核。复核清单包括：能否按步骤复现；预期与实际是否对应；操作是否在授权范围；是否出现越界读取或写入；清理是否完成；影响判断是否有证据支持。无法复现的发现标记为“观察项”，不要直接按高危漏洞处理。

覆盖是否充分，用矩阵判断

覆盖充分性不看用例数量，而看矩阵是否填满：高风险资产和关键控制是否有正向与负向结论；每个角色是否至少覆盖其权限边界；未覆盖项是否写明原因。低风险功能可以抽样，但身份认证、对象级授权、后台管理、文件上传和数据导出不宜只做表面检查。

退出标准可以写成：所有高优先级条目已有结论；停止条件触发均有记录；证据字段完整且可复核；未覆盖范围明确；整改建议可执行；清理状态已确认。还要在报告中说明渗透测试的局限，结合代码审计、配置核查、DAST/SAST、日志告警验证和威胁建模补充判断。把“没测”写成“没问题”，比漏测本身更危险。

整改复测：把用例变成回归资产

每个发现应转为缺陷单，包含编号、复现条件、影响、修复建议、责任方和期限。复测不只跑原用例，还要增加变体：修复了对象级授权，就同时验证列表、导出和详情接口；修复了上传限制，就同时验证合法文件仍能正常上传。负向用例确认拒绝生效，正向用例确认功能没有误伤，审计日志仍能记录关键操作，关闭标准才算满足。

计划执行中的范围、时间和技术变更要走审批并更新版本，保留变更记录。这样一份计划既能约束本次测试，也能成为下一次评估的基线：测试结果可比较，问题可复测，影响可追溯。