先把“有权限”拆成具体动作

服装门店谈收银系统权限，最容易卡在一句“员工只能看自己需要的信息”。这句话方向没错，却不能直接拿来验收。需要先逐项说清：某岗位能查看什么、能不能改动、可不可以导出、操作范围是一家店还是多家店。能够打开一个页面，并不代表可以编辑其中每个字段；看见顾客联系方式，也不等于可以批量下载全部记录。

权限设计从真实工作任务出发。收银岗位可能需要完成结账和查询本店当前商品信息；店长可能要复核部分业务记录；财务岗位要核对交易来源；区域人员可能需要比较几家门店的汇总数据。这里列的是常见岗位讨论框架，不意味着每家服装店都采用同一组织。先请经营者把本店实际岗位列出来，再注明每一项任务需要访问什么内容、需要执行什么动作。

不要只按“经理”“员工”这种职称一次性分组。两个同名岗位可能一个要跨店支援，一个只在固定门店接待；店长临时调班后，原有账号范围也可能不再合适。矩阵记录岗位、门店范围、数据类型和操作种类，可以让负责人发现一个角色是否被授予了不必要的查看或修改能力。实际权限是否可按这些维度设置，要在目标系统里逐项演示。

把查看、修改和导出分开验

查看是最常见的起点，但需要说明具体范围。员工查一笔当前交易与查看所有门店的历史记录不是同一任务；查找某件商品的款号、颜色和尺码，也不等于查看全部会员联系资料。整理权限表时，尽可能用任务名称而不是泛泛的“业务数据”，这样测试人员知道要打开哪个页面、输入什么条件、应当看到哪些字段。

修改动作还要问清哪些字段可以变更，改变后谁能确认结果。比如门店要调整一条商品信息，录入人与复核人是否分开，应由店内真实流程决定。若系统不支持角色分工，不要在说明中写成已实现双人审核；可以记录现有替代核对方式、负责人和适用时段，再向产品方确认是否支持所需配置。

导出应单独测试，不能从页面看起来有限就推断文件也有限。让不同账号尝试执行业务确实需要的导出任务，记录可选范围、可见字段、是否能跨门店选取，以及无法执行时出现的结果。对于不需要导出的岗位，确认操作入口是否隐藏或受限制。没有实际测试，不写“数据绝不会外流”或“已经全面保护”之类结论。

门店还需要区分临时查看、长期保留与分享给同事。员工把页面截图发到工作群，不一定经过系统的导出限制；权限之外的工作约定同样要说清，哪些情况可转发、接收人是谁、多久后删除或归档。本文不解释法律义务，也不替门店制定信息安全标准；涉及适用要求时，应由机构负责人另行核对。

用真实岗位账号走一遍，而不是只看管理员演示

管理员账号通常权限最全，适合配置，不适合代表普通员工验证。验收时准备一组不含真实顾客资料的演练记录，分别用收银、店长和财务岗位账号完成各自任务。每位测试者先说清自己要做什么，再实际查看入口和结果；只看演示者点击，并不能证明该岗位有能力完成工作。

测试可以包含几个容易被混淆的情况：店员只查当前门店商品时，会不会误入其他分店；要更正一项已保存信息时，页面是否清楚显示修改后的状态；需要跨店汇总的负责人能否看到必要范围，但不必打开无关的明细。遇到无法访问时，要确认是权限配置问题、账号尚未分配岗位，还是本身没有相应功能。看到“无权访问”只是测试结果，还需记录由谁接手开通或解释。

有些差异出现在操作之后。测试者完成一项业务，另一位员工再登录查看，确认哪些信息被共享、当前责任人是谁、原来的修改还在不在。员工能看到某条记录，不代表一定能处理后续动作；也不能假设收银提交后系统会自动把任务分配给某个岗位。将每一步拆开检查，才能找出权限边界与交接流程之间的空隙。

调岗、代班和跨店支援要设复核点

临时支援很常见，但不要为了让一项任务尽快做完，就把主管账号交给代班员工。应先确认有无适合的临时身份或授权办法，授权由谁确认、针对哪项任务、何时结束。系统若无法限制期限，需把回收账号权限作为明确的人工待办，记录具体负责人，完成后再用员工账号回测。

员工调店或改变岗位时，旧范围是否还适用要重新核对。原来能查本店款色码资料，换到另一家店后是否仍要保留原访问范围？临时负责两店时，是否只需要汇总，还是确实需要逐笔明细？这些问题的答案由经营安排决定，不应因为账号方便沿用就默认全都开放。授权变更前后保留操作记录或内部确认单，才能让接手人知道为何范围发生变化。

员工离职或不再承担该项工作后，账号处理是交接的一部分。负责人核对当前岗位名单、仍在用的账号、共享设备和由他人代为操作的情况，完成停用后用其他实际账号确认流程仍可运行。若离职员工原本是唯一会操作的人，权限回收之外还要安排业务交接；账号关闭不等于知识已经转移。

权限检查要留下可继续处理的记录

发生一次误操作或有人看不到必要资料时，先保存最小范围的事实：时间、账号所属岗位、所做任务、界面实际显示以及这项任务目前由谁承接。不要先把原因写成员工疏忽或系统缺陷。负责人确认范围后，再决定是修改角色、补充培训、变更操作约定还是请求供应方检查配置。

复核周期不必照搬某个固定数字。组织调整、门店合并、临时人员增加或重要流程改变时，可以立即触发一次检查；日常则由指定岗位按内部节奏回看。每次复核记录新增岗位、已撤销的范围、尚未确认的账号和后续责任人。发现配置问题之后，重新使用普通岗位账号做同一任务，验证调整确实解决了原问题。

汇报时讲清测试用了哪些角色和任务，哪些范围已经验证、哪些仍待供应方回答。不能把有限的几次操作称为“全店所有权限安全”，也不应把没有发生过问题说成权限已经足够。权限管理不是一个开关，而是角色、任务、数据范围和人员变化共同构成的工作约定。

可以用明确标注为假设的换班情境做一次检查：收银员下班前发现一笔退换记录仍需店长确认。接班员工是否能找到待办、看见当前状态，是否会误以为能直接修改原交易？店长处理后，收银员再次查看时能否辨认结论？这次演练关注岗位能否在必要范围内接续，而不是假设某个系统一定有“审批流”或自动提醒。

如果岗位任务需要访问更宽的范围，先写明为何需要、由谁同意、何时复核。跨门店支援可能只需知道某项事项的负责人和进度，并不必然需要查看全部顾客明细。主管现场协助也尽量使用本人账号完成允许的操作，避免员工共用账号后无法解释谁执行了修改。

测试者遇到权限不足时，要保留当时的账号岗位和任务步骤，交给管理员按现有配置核查；不要通过直接开放整个角色来快速消除提示。配置调整后，由原岗位重新走一遍具体任务，同时用另一岗位确认不需要的部分仍不可见。这样每一次“方便了”，都能说明便利发生在哪件工作上。

产品模块名称不能代替权限演示

企雀服装公开产品介绍列有顾客管理、连锁管理、预约、收银排班、进销存和数据分析，可查看企雀服装系统产品说明了解公开模块范围。公开页面没有逐项证明本文讨论的查看、修改、导出或跨店授权粒度；门店若正评估权限，应拿本店岗位任务让供应方按实际方案演示并复核。

最后选一条日常任务，从员工登录开始，到查阅、修改或完成、换另一岗位接手结束，检查每个步骤是否明确、结果是否能回看、未授权时谁负责继续处理。能把这些具体动作说明白，门店才知道当前权限适合什么工作，也知道需要追加核对的地方在哪里。