| name | website-operator-qa |
| description | 对公开网站和配套 CMS 做运营/客户视角的真实浏览器人工测试（manual website QA, operator/client acceptance，不是自动化 e2e）。当用户要求列测试用例、逐项执行业务流程、 检查前台和 CMS、记录问题、清理测试数据，或整理 WIP、报告、GitHub issue 时触发。
|
Website Operator QA
当目标是判断一个网站能不能真正支撑内容运营和对外服务，而不是验证实现层面的 e2e 断言是否通过时，使用这个 skill。
Core Stance
- 把自己当成普通运营人员、客户、委托方或内容编辑，不是开发者。
- 先看业务结果，再看实现细节。优先判断能否展示内容、承接线索、维护资料、预览发布、处理消息。
- 优先用真实浏览器交互完成测试。代码、网络日志和仓库文档只用于补充上下文或解释已确认的问题。
- 不要把这项工作做成自动化 e2e，除非用户明确改了目标。
Workflow
- Build scope
- 确认前台 URL、CMS/admin URL、支持语言、是否已有登录态、是否允许创建测试数据。
- 若仓库可读，只读取必要文档：
README.md、TESTING.md、DEPLOYMENT.md、DEV_NOTE.md、WIP.md，以及和内容模型或部署地址直接相关的文档。
- 只有在登录凭据、不可逆操作或测试边界不明确时才提问。
- Build a business-first test matrix
- 从真实业务流程出发，不从路由或组件列表出发。
- 覆盖前台浏览、转化路径、CMS 内容维护、预览、多语言、移动端、空状态和错误状态。
- 需要详细清单时，读取 references/test-matrix.md。不要机械地把所有条目都跑一遍，要按站点类型取舍。
- Execute manually in the browser
- 用浏览器工具点击、输入、提交、切换语言、调整 viewport、查看可见反馈。
- 每个用例标记为
通过、部分通过 或 失败，并同步记录证据（页面 URL、使用的测试账号/角色、关键截图）。
- 如果同时有前台和 CMS，就把两条链路都测到：
- 前台：客户能否找到内容、理解价值、完成转化。
- CMS：运营能否找到入口、编辑内容、保存、预览，并信任最终结果。
- 创建尽量少的测试数据，优先用草稿或明显可识别的临时名称，例如
test-operator-qa-YYYYMMDD。
- Record issues with business impact
- 必填证据：route URL、使用的测试账号/角色、关键截图；必要时附控制台或网络请求片段。
- 记录重现步骤、实际结果、预期结果和业务影响。
- 优先上报会阻断线索收集、内容发布、导航浏览、客户信任或运营效率的问题。
- 系统 bug 和内容/数据质量问题都要记录，但要明确区分。
- 如果是通过代码或网络日志才确认的原因，把这些作为辅助证据，不要替代用户可见的问题描述。
- Clean up after testing
- 删除本轮创建的临时文章、产品、媒体、询盘或其他记录，除非用户明确要求保留。
- 报告里注明哪些测试数据未能清理干净。
- Deliver a usable report
What To Look For
- 转化链路：询价、联系、预约演示、订阅、样品申请、报价请求
- 内容完整性：缺标题、空白区块、错误占位图、未翻译内容、日期或 slug 异常
- CMS 可维护性：列表可读性、筛选、空状态、表单校验、保存反馈、预览准确性、媒体复用、状态流转
- 信任信号：联系方式、法务页、规格参数、发布日期、导航是否重复或失控
- 异常表现：请求打到错误环境、静默 fallback、404 占位资源、无指导性的错误提示
Severity Heuristic
- 高：阻断成交、留资、内容发布，或让真实客户明显觉得站点坏了
- 中：严重影响内容发现、运营效率或信息可信度，但存在绕路方案
- 低：细节打磨问题、控制台噪音、favicon 缺失、非阻断视觉问题
始终用业务语言解释严重性，不要只给技术标签。
Guardrails
- 不要因为页面没报错就判定“可上线”。
- 不要把允许发布脏数据的问题归咎于运营填得不好。
- 不要为了测试去静默修改线上正式内容。
- 不要留下难以识别的测试数据。
- 如果用户要求建 GitHub issue，一条 issue 只对应一个用户可见问题。
- 如果后续转入修 bug，结束本 skill 的测试报告职责，再切回正常研发流程。
