文档权限回归测试要同时证明两件事：权限变更后，该拒绝的访问被拒绝，仍有权限的人能继续协作。把账号、空间、单文档授权和分享链接放进同一张权限测试矩阵，再覆盖搜索、已打开会话和撤权后再访问，才能检查到同一变更在不同入口的执行结果。
每条用例都应写清授权来源、变更动作、生效时点、允许与拒绝的预期，以及服务端观测证据。测试通过的依据不能只有按钮变灰或页面报错，还要确认服务端没有返回受保护内容、没有接受无权写入，且正常协作对照仍然成功。
文档权限回归测试前，怎样确定正确预期
在文档中台私有部署项目里，账号、组织和空间可能由宿主业务系统管理，编辑、预览等能力由文档服务承接。先列清身份映射、授权判定、内容交付和协同会话分别由谁负责，再沿真实集成链路测试，不能假定这些能力都属于同一个组件。
预期应来自业务负责人确认的权限规则，不能直接抄被测接口的返回值。一个人可能同时拥有组织角色、空间成员资格、单文档授权和链接访问资格；撤掉其中一个来源后，要按约定的权限合并、继承和显式拒绝规则重新计算结果。
建议用下列测试账号和文件建立可重复的测试环境。账号、文件和空间都使用测试数据，每条用例开始前恢复基线，避免上一条授权残留改变下一条的预期。
| 测试对象 | 准备方式 |
|---|---|
| 变更账号 A | 用来调岗、降权、移出空间或撤销单文档授权 |
| 对照账号 B | 对同一文件保留合法权限，用来验证正常协作 |
| 无权账号 C | 同组织、无目标资源授权；有多租户边界时另备其他租户账号 |
| 匿名访客 | 使用无登录态的独立浏览器上下文，验证外链 |
| 文件 F1 | 仅通过空间继承授权，关闭外链并移除其他直接授权 |
| 文件 F2 | 同时具有空间继承和直接授权，用来验证多来源权限 |
| 文件 F3 | 用于链接授权测试，分别建立有效、关闭、过期、限成员的链接状态 |
把查看、编辑、评论、下载或导出、转分享拆成独立动作，再填各自的允许或拒绝预期。不要假设"可编辑"必然包含"可下载"或"可转分享"；目标系统没有的功能标记"不适用"并说明原因。
账号、空间、文件和分享链接怎么列成测试矩阵
下表将越权测试与正常协作回归放在一起，所有预期都按前面确认的权限规则和生效时点填写。每行都要测试受影响主体或无权主体，并测试正常对照；同一浏览器窗口切换账号容易混入旧登录态，建议为各测试主体使用隔离的会话。
| 编号与变更 | 应拒绝的检查 | 仍应允许的检查 | 关键观测点 |
|---|---|---|---|
| R01 账号停用 | A 的旧登录态与新登录路径均不能取得受保护文件或提交变更 | B 按原授权继续读写 | 身份映射、会话状态、内容响应、写入结果 |
| R02 调离组织或业务组 | 仅来自旧组织或旧组的权限失效 | 新组明确授予的动作可用；B 不受影响 | 组织映射、角色来源、实际命中的授权规则 |
| R03 编辑角色降为只读 | A 编辑或保存被拒绝；评论、导出另按规则判断 | A 仍能查看，B 仍能编辑 | 保存请求、服务端版本、权限提示 |
| R04 从空间移除 A，访问 F1 | 列表、直达链接和内容请求均不能取得 F1 的受保护信息 | B 作为合法空间成员仍可访问 | 空间成员状态、权限继承、响应内容 |
| R05 从空间移除 A，访问 F2 | 失去的继承权限不得继续生效 | 若规则允许直接授权独立存续，保留的动作仍可用 | 各授权来源、合并结果、最终允许的动作 |
| R06 撤销 F2 的直接授权 | 仅靠直接授权获得的动作失效 | 若继承仍有效，继承授予的动作保留 | 直接授权记录、继承路径、操作结果 |
| R07 关闭或使 F3 的外链过期 | 仅靠旧链接获权的匿名访客和登录用户均不能继续访问 | 持有独立文件授权的 B 仍可从合法入口访问 | 链接状态、服务器时间、最终内容响应 |
| R08 外链改为仅指定成员可用 | 非指定成员 C 和匿名访客被拒绝，即使拿到完整链接 | 被指定的有效成员可访问 | 链接限制、身份绑定、内容交付 |
| R09 撤权后重新搜索 | 无其他授权的 A 不能通过新查询取得受保护的标题、摘要、缩略图或内容 | B 仍能检索并打开目标文件 | 搜索原始响应、建议词、结果缓存、点击后的授权校验 |
| R10 撤权时 A 已打开文件 | 全部读写权被撤销后，A 不能接收后续受保护更新或提交新操作 | B 的后续协同编辑仍成功 | 长连接收发、保存结果、其他客户端视图 |
| R11 撤权后刷新、重连、重登 | A 用旧标签页、书签、旧请求或重连后的待发操作不能恢复已撤权限 | B 的刷新和重连仍可恢复正常协作 | 重连鉴权、待发操作处理、内容与版本 |
| R12 同级账号或其他租户换资源标识 | C 在获准测试的接口中替换文件、空间或租户标识，不能访问无权对象 | 对照账号访问各自获权对象成功 | 主体与资源归属、服务端判定、跨资源副作用 |
| R13 撤权后重新授权 | 超出本次新授权范围的动作仍被拒绝 | A 恢复本次明确授予的动作，B 不受影响 | 新旧授权状态、拒绝缓存、重新建立的会话 |
R07 还应检查页面跳转后的最终内容入口，例如预览资源或下载地址。若系统会签发可独立使用的临时地址，需要单列旧地址的有效期和撤销方式；关闭分享页并不能作为最终内容已停止交付的证据。
外链到期测试要分别覆盖到期前、到期边界和到期后，并按约定的时区与服务器时间判断。到期边界的判定规则应写进用例，不能用测试人员电脑上的倒计时替代。
R09 要先约定哪些元数据也属于受保护信息，再覆盖相应的搜索结果、建议词和聚合结果。即使搜索列表已经隐藏文件，也要单独验证直达访问；反过来，点击后被拒绝，也不能抵消列表已经泄露摘要的问题。
撤权生效与已打开会话，按什么时间线验证
把 t0 定义为权威权限来源确认变更提交的时刻，并记录权限版本或可关联的变更标识。再为内容访问、搜索和协同会话写出约定的生效截止点；需要立即撤权的路径以 t0 为界，允许传播窗口的路径则填写经业务与安全负责人确认的 Δ，不能把实测延迟反过来当作合格标准。
执行时保留撤权前已打开的页面和已建立的连接，同时增加全新的访问会话。只测重新登录会漏掉旧会话，只测旧页面也无法覆盖新请求的授权路径。
- 在 t0 前，用 A 和 B 完成各自允许的动作，保存基线证据。
- 提交权限变更，取得确认结果；若只收到异步受理状态，继续核对实际提交状态，不把受理当作生效。
- 从 t0 起采样旧会话、新会话、搜索和内容入口，记录每次请求时间、结果与服务端证据。
- 在约定截止点及之后继续验证拒绝结果，同时让 B 执行正常读写，防止把服务整体不可用误判为权限控制成功。
- 对撤权前已发出但尚未完成的写入，记录请求发起、授权判定、撤权提交和写入提交的先后顺序，按事先约定的并发语义判定。
如果系统使用 WebSocket 等长连接，不应把连接仍然存在等同于操作仍然获权。测试应分别检查连接中的读、写和订阅动作，尤其关注重新连接后，客户端是否把撤权期间积压的操作重新提交并写入。
撤权验收应检查后续内容获取和写入，不能承诺收回用户此前已经合法读取、下载或截图保存的信息。旧页面仍显示撤权前的文字时，要区分本地已有内容与服务端新交付的内容，再按产品约定检查是否遮罩或退出页面。
权限依赖异常时，失败关闭怎么测
失败关闭是指无法确认请求拥有当前所需权限时，不交付受保护内容，也不执行相应写入。失败关闭与"正常协作不受误伤"需要分别验收：异常期间记录受影响范围，依赖恢复后重跑拒绝用例和合法对照，不能把所有请求都失败当作整组通过。
| 故障分支 | 建议预期 | 失败证据与恢复检查 |
|---|---|---|
| 授权依赖超时或报错 | 无法确认权限的请求停止；不把旧的允许结果或默认公开权限作为兜底 | 记录依赖错误与客户端状态；恢复后合法请求可重试，无权请求仍被拒绝 |
| 组织映射缺失或租户上下文不一致 | 不凭用户名相同或默认租户放行 | 检查映射失败原因；修复后只恢复正确主体的授权 |
| 撤权通知丢失、缓存或索引未更新 | 仍须满足约定的生效截止点；无法确认权限时不输出受保护结果 | 保留旧状态与实际响应；超出截止点仍可访问则判失败 |
| 撤权后保存或重连失败 | 不把未获权写入标记为"已保存"，不在后台静默写入 | 核对错误反馈与服务端版本；恢复连接后旧操作不能绕过当前权限 |
错误码只是一项观测值，预期状态码应按实际接口契约填写。还要检查错误响应、重定向后的资源和异步任务结果是否包含受保护内容，并确认被拒绝的写入没有产生版本、评论或导出产物。
一条回归记录要留下哪些字段
建议把下列字段放进测试用例系统或自动化结果中，字段名仅作为自定义记录模板。它们不是某家产品的 API 参数；实际日志没有权限版本等字段时，应补充可关联的变更证据，无法关联的部分保留为证据缺口。
| 字段组 | 建议记录字段与含义 |
|---|---|
| 用例与环境 | case_id、run_id、部署版本、集成版本、配置版本、测试时间 |
| 主体与对象 | actor_ref、tenant_ref、space_ref、file_ref；使用脱敏标识 |
| 权限基线 | grants_before、grants_after、授权来源、继承或冲突规则、规则确认人 |
| 变更与时序 | change_ref、t0、约定截止点、请求与响应时间、权限版本或替代证据 |
| 入口与动作 | entry、action、旧/新/重连会话、链接状态、缓存冷热状态 |
| 预期与实得 | expected_decision、actual_decision、业务状态、内容是否交付、写入是否提交 |
| 关联与结论 | request_id 或 trace_id、日志引用、对照用例结果、首次观测到拒绝的时间、最终结论 |
首次观测到拒绝的时间只能说明该次采样结果，不能证明此前所有访问都已被拒绝。建议保留"最后一次观测到允许"和"之后的连续拒绝样本"，同时记录采样间隔；缺少服务端证据时，结论应标记为待验证。
日志和截图不要保存原始 Token、Cookie、带访问凭据的完整分享链接或真实文档内容。使用测试文档中的唯一标记核对内容和版本，账号、会话及链接只保留受控的脱敏引用。
FAQ：怎样补齐矩阵以外的验收条件
需要跑完所有角色、动作和文件的笛卡尔积吗？
优先按授权来源、角色层级、资源边界和会话状态划分等价类，再覆盖关键组合与已知缺陷。高风险路径不能只靠抽样：跨租户访问、账号停用、最终内容入口和撤权后写入应作为明确的必测项。
自动化用例应该放在哪一层？
建议让服务端集成测试负责主体、资源和动作的批量组合，让浏览器测试负责登录态、搜索展示、旧标签页和重连路径。界面用例与服务端用例通过用例编号和请求关联标识对应，避免只看到提示变化，却找不到实际授权与写入证据。
某项能力在目标部署版本中不存在，算通过吗？
应记为"不适用"，并写出目标版本、缺失能力和判断依据，不能记为通过。如果业务需求要求这条访问路径，而当前部署尚未提供或尚未打通，则记为需求缺口或阻塞，留到目标版本的 POC 验收中确认。
满足哪些条件，才能放行权限变更
文档权限回归测试的放行条件应同时包含拒绝正确、允许正确、生效时序符合约定，以及关键证据可追溯。任何越权读写、超出约定的撤权窗口、正常协作被误拒或关键路径证据缺失，都应按预先约定的门槛处理，不能被整体通过率掩盖。
落地时，把矩阵中的抽象账号、文件、入口和动作映射到当前集成环境，补齐权限规则与截止点，再从高风险路径开始执行。只有当前部署版本及其实际集成链路完成这些验证，才能据此判断这次权限变更是否可以放行。