27 lines
1.3 KiB
Gherkin
27 lines
1.3 KiB
Gherkin
Feature: supplement-request-response
|
||
|
||
Scenario: Happy Path
|
||
Given Client 收到缺件提醒并进入资料提交与进度页
|
||
When Client 查看补件响应处理区并按提示补交缺失资料
|
||
Then 系统应明确说明缺什么、为什么缺,以及补交完成后的最新状态
|
||
|
||
Scenario: Permission Case
|
||
Given Accountant 尝试响应当前 Client 的补件提醒
|
||
When Accountant 进入补件响应处理区
|
||
Then 系统应限制其访问与补件操作,并保持响应链路只服务对应 Client
|
||
|
||
Scenario: Error Case
|
||
Given Client 打开补件响应处理区时缺件原因未成功加载或再提交失败
|
||
When Client 尝试完成补件
|
||
Then 系统应提示补件异常,并避免把未成功的再提交误标为已完成
|
||
|
||
Scenario: Edge Case
|
||
Given Client 同时收到多项补件要求,且不同资料项的补充原因不同
|
||
When Client 查看补件响应处理区
|
||
Then 系统应把每项缺件原因与对应补交动作区分清楚,避免 Client 误补或漏补
|
||
|
||
Scenario: Accessibility Case
|
||
Given Client 依赖键盘导航或屏幕阅读器完成补件响应
|
||
When Client 浏览缺件原因、补交入口与再提交结果
|
||
Then 系统应让补件结构、原因说明与状态反馈可以被顺序访问并清晰朗读
|