测试规则 ROE 是什么
测试规则约定（Rules of Engagement，ROE）是双方开工前就执行阶段“怎么做事”达成的书面细则，把授权书里“允许测试”这句原则性表述，拆成一条条能现场比对的条款：允许哪些技术手段、禁止哪些动作、发现高危与异常如何通报、谁能在什么情况下叫停、测试节奏与限速要求如何。ROE 的价值在于把判断前移——工程师不必在压力下临时权衡“这个动作能不能做”，对照条款执行即可。ROE 越具体，现场争议越少；只写允许不写禁止，等于把边界交给临场感觉。
基本信息
| 涵盖内容 | 范围、时间、允许技术、禁止项、沟通与应急、限速 |
|---|---|
| 禁止项示例 | DoS、破坏数据、社工、物理入侵（未单独授权时） |
| 沟通机制 | 日报 + 高危即时通报通道 + 失联暂停约定 |
| 确认方式 | 双方负责人签字，项目组全员知悉并留签到记录 |
| 效力 | 与授权书、合同附件同等，作为执行与验收依据 |
典型使用场景
- 项目开工前：把口头共识固化为条款，避免现场各自理解
- 多方参与项目：在测试、运维、蓝队、业务方之间划清动作边界
- 高风险项目：对可能影响可用性的动作预设审批与限速
- 跨地域协作：远程与现场人员的动作口径统一
- 复盘与验收：出现争议时以 ROE 条款为准绳
ROE 要点示例
ROE 要点示例
# 允许：漏洞验证（无害 PoC）、配置核查、只读信息收集
# 禁止：拒绝服务、删改数据、植入程序、社工与物理入侵
# 限速：并发不超过 5，每秒请求不超过 10，遇抖动立即降速
# 窗口：主动扫描 20:00-24:00，高风险项单独申请
# 沟通：每日日报 + 高危 15 分钟内电话通报
# 例外：任何超出本规则的测试须追加书面授权ROE 条款要素
| 要素 | 写什么 | 不写会怎样 |
|---|---|---|
| 允许技术 | 可用的手段与工具类别 | 工程师凭经验判断，动作口径不一 |
| 禁止动作 | 明确列出不可做的动作 | 破坏性动作可能被误当作允许测试 |
| 限速与窗口 | 并发、速率、可执行时段 | 高峰期扫描导致业务抖动 |
| 通报机制 | 谁通报、通报谁、多久内 | 发现高危无人知晓，错过处置窗口 |
| 中止与升级 | 什么情况暂停、按什么顺序升级 | 现场犹豫不决，小问题拖成事故 |
ROE 越具体，现场判断越简单：不确定的动作先对照 ROE，再联系授权人。全员签字确认是防止队友不了解规则的最低成本手段。
ROE 只写允许不写禁止，边界就靠现场自由发挥；只写禁止不写允许，工程师又可能过度保守而漏掉关键验证。允许与禁止都要落到条款上。