无障碍（Accessibility）测试与可用性测试

• WCAG 的四个原则（POUR）与具体成功标准
• AA/AAA 级别差异
• 测试用例如何映射到 POUR

WCAG 2.1 的四个原则（POUR）是测试用例设计的骨架：Perceivable（可感知）——内容可被感知，映射到文本替代（alt）、非文本内容、对比度、音频/视频替代、自适应布局的用例；Operable（可操作）——交互可操作，映射到键盘可达、焦点管理、无超时陷阱、可跳过重复内容、可返回的用例；Understandable（可理解）——内容可理解，映射到语言属性、一致性导航、输入错误提示、可预测行为（如焦点变化不意外）的用例；Robust（健壮）——内容可被可靠解析，映射到语义化 HTML、正确的 ARIA、无效值处理、兼容辅助技术的用例。系统化测试分两级：AA 是常见合规目标（如对比度 4.5:1、键盘可达），AAA 更严格（如对比度 7:1、无任何时间限制），测试时先按 AA 建立基线，再按业务需要提升到 AAA。用例设计以"每条成功标准对应若干用例"为原则，并同时用自动化扫描与人工（键盘/屏幕阅读器）验证。

POUR 是把 WCAG 成功标准"组织化"的框架，测试要以"成功标准→用例"的映射来保证覆盖，而不是零散地测几个端点。AA/AAA 是严重度阈值，测试目标需明确到某个级别。

• 屏幕阅读器测试的操作步骤与验证要点
• 动态内容（SPA/AJAX）的无障碍通知机制
• 焦点管理、aria-live、静态提示

屏幕阅读器测试的操作步骤：用键盘操作（Tab/Shift+Tab/方向键/Enter）在 NVDA、VoiceOver、JAWS 上逐一读取页面，验证朗读顺序、控件标签、标题层级、状态提示；重点验证表单控件可读可操作、图片有替代文本、表头与单元格关联、错误提示可感知。验证要点包括：朗读内容与视觉一致、焦点可见、aria-label/aria-labelledby 正确、无冗余朗读。动态内容（SPA/AJAX）的无障碍通知是重点：SPA 内容异步更新时，屏幕阅读器默认不会感知，需用 aria-live 区域（如 aria-live="polite"/"assertive"）主动通知，或用 role="status"/role="alert"；还需验证焦点在新增内容、弹窗、路由切换时正确移动（自动聚焦到新标题或弹窗），以及加载状态（aria-busy）的通知。测试时用真实屏幕阅读器进行人工验证，因为自动化难覆盖朗读细节。

屏幕阅读器测试的核心是"用辅助技术真实走一遍"，验证的是"可感知、可操作"。动态内容的难点在于"更新必须主动通知"，靠 aria-live 与焦点管理实现，这是 SPA 无障碍最容易遗漏的地方。

• 键盘可达性与焦点顺序的测试
• "Tab 陷阱"与"焦点丢失"的识别
• 焦点可见性与焦点返回

键盘可达性测试：仅用键盘（Tab、方向键、Enter、Space、Esc）完成所有功能，验证每个可交互元素都能被聚焦与操作，没有鼠标也能完成全部流程。焦点顺序测试：按 Tab 的顺序应遵循视觉/逻辑顺序（通常从上到下、从左到右），验证焦点在弹窗、表单、导航间移动正确。常见问题及测试方法：Tab 陷阱——焦点被困在某个区域（如弹窗、自定义控件、iframe）无法跳出，测试方法是连续 Tab 并确认能到达并离开每个区域，弹窗需支持 Esc 关闭并返回；焦点丢失——交互后焦点无去处（如点击删除后焦点消失、页面刷新后焦点跳到页面顶部），测试方法是操作后检查焦点是否还可见、是否移动到合理位置；还需验证焦点可见（focus 样式明显）、焦点不移入隐藏元素、:focus-visible 的合理使用。

键盘可达是"可操作"原则的核心。测试的要点是"只靠键盘完成全流程 + 焦点处处可见可追踪"，Tab 陷阱与焦点丢失是键盘用户最常遇到的阻断性问题。

• Moderated 与 Unmoderated 可用性测试的定义与区别
• 在成本、数据深度、样本量、任务复杂度上的对比
• 场景选择与取舍

Moderated（有主持人）可用性测试由主持人引导用户执行任务并实时提问、追问，Unmoderated（无主持人）可用性测试让用户按脚本自行完成并录制。四维度对比：成本——Moderated 成本高（需主持人、专用设备、时间同步），Unmoderated 成本低（可批量、异步、规模化）；数据深度——Moderated 数据深度高（能洞察动机、追问困惑、捕捉非言语信息），Unmoderated 数据较浅（只能观察到行为与表露的问题）；样本量——Moderated 样本量小（通常 5-15 人，受资源限制），Unmoderated 可大样本（几十到几百，覆盖更广）；任务复杂度——Moderated 适合复杂、探索性、需要澄清的任务（如新流程、复杂表单），Unmoderated 适合简单、明确、可量化的任务。取舍原则：探索与洞察用 Moderated，验证与规模化用 Unmoderated，两者常结合使用。

两者的本质是"深度"与"规模"的权衡。Moderated 换深度，Unmoderated 换样本与成本。选择取决于研究目标——是理解"为什么"还是确认"有多少"。

• 启发式评估与认知走查的定义与步骤
• 两者的差异（专家与用户视角、广度与深度）
• 各自的最佳使用阶段

启发式评估（Heuristic Evaluation）由评审专家依据 Nielsen 十大启发式原则（如系统的可见性、用户控制与自由、一致性与标准、错误预防）系统检查界面，发现明显的可用性问题，属于"专家评审、广度优先、发现已知问题"的方法；认知走查（Cognitive Walkthrough）则从"新手用户第一次使用"的视角，逐步走查用户在完成某个任务时每一步的动作、可发现性、反馈，评估"用户能否学会并完成"，属于"任务导向、深度优先、发现学习与理解问题"的方法。阶段使用：启发式评估适合在早期设计/原型阶段快速排查整体结构问题，成本低、覆盖面广；认知走查适合在任务流程设计阶段，重点验证关键任务的"可学习性"与"可完成性"，尤其适合新手引导、复杂流程。两者都属低成本专家方法，可在用户测试前先做一轮。

差异核心是"视角与粒度"：启发式评估是专家按原则扫全界面，认知走查是模拟新手按任务逐步走。启发式用于早期整体排查，认知走查用于任务流程的可用性验证。

• WCAG 2.2 新增的成功标准
• 目标尺寸、焦点外观、拖动操作的具体要求
• 对测试用例设计的更新

WCAG 2.2 新增了若干成功标准，直接影响无障碍测试用例：目标尺寸（2.5.8 Target Size Minimum）——可交互目标的最小尺寸（如至少 24×24 CSS 像素，或以足够间距等替代），测试用例需验证按钮、链接、输入框的点击区域尺寸，避免小目标难以点击；焦点外观（2.4.11 Focus Not Obscured 与 2.4.13 Focus Appearance）——焦点必须清晰可见且不被遮挡、焦点指示的最小对比度与面积，测试用例需验证 :focus 样式是否明显、是否被其他元素遮挡；拖动操作（2.5.7 Dragging Movements）——不能只支持拖动，必须提供单指点击/键盘替代方式，测试用例需验证拖动/拖拽功能有非拖动替代。此外还有"不基于字符的快捷键"（2.1.11）等。测试用例需按这些新增标准补充专项验证，并更新扫描工具的规则或人工检查清单。

WCAG 2.2 的新增标准聚焦"移动端与认知无障碍"（目标尺寸、焦点、拖动），测试用例需相应扩展。这些标准往往需要人工验证或专门的自动化规则，不能只依赖旧的扫描规则。

• 对比度与色盲友好设计的验证方法
• axe-core 等工具的能力与局限
• 人工验证的必要性

色彩对比度验证：用工具计算前景色与背景色的对比度比值，满足 WCAG 的 4.5:1（正常文本 AA）或 3:1（大文本/UI 组件），并考虑文字在图片/渐变背景上的实际对比。色盲友好验证：用色盲模拟工具（如 Color Oracle、Stark）查看有无色盲用户无法区分的颜色组合（如红绿混用传达信息），并确保信息不只靠颜色传达（如同时用图标/文字/形状）。axe-core 等自动化工具能准确计算对比度、检测常见失败，但局限性在于：无法准确判断"实际经 alpha 混合后的有效对比"（如透明色叠加的真实背景）、无法评估图形的感知对比、无法验证色盲下的可读性、无法判断"信息是否仅靠颜色传达"这类语义问题。因此需要人工验证：以真实用户/模拟视角检查对比度、色盲可读性、以及颜色之外的信息传达。

对比度是"可计算"的，色盲友好是"需感知"的。自动化工具擅长计算与规则检查，但无法替代人工对"颜色是否作为唯一信息通道"和"感知可读性"的判断。

• 自动化扫描工具的能力范围
• 无法被自动化检测的成功标准类型
• 自动化与人工验证的分工

axe-core、pa11y、Lighthouse 等自动化工具能检测"语法和结构性"的无障碍问题：如缺失的 alt、错误的 ARIA 属性、表单无 label、对比度不足、iframe 无 title、heading 层级错误等。但其能力边界在于：只能检测"可规则化"的问题，无法检测需要"语义判断或人工感知"的成功标准——例如：文本替代是否准确描述了图像内容（工具只能检查 alt 是否存在，不能判断含义是否恰当）、aria-live 是否在正确时机触发、焦点顺序是否逻辑合理、键盘操作是否真的能完成复杂任务、对比度在真实渲染下的感知、视频有无字幕、语言内容是否准确、以及"是否可理解"（简明性、帮助）等。因此自动化扫描只能作为"第一道防线"，测得约 30-50% 的问题，其余需人工用键盘、屏幕阅读器、真实用户做补充验证。

自动化的边界是"可规则化"——能写成确定性规则的问题可自动测，需语义、感知、逻辑判断的问题必须人工。这是无障碍测试"自动化+人工"分工的根基。

• 语义化 HTML 与 ARIA 的关系
• 验证语义化 HTML 与 ARIA 正确性的方法
• ARIA 误用的危害

语义化 HTML 是原生无障碍的基础（如用 <button> 而非 <div onclick>、用 <nav> 而非 <div>、用 <label> 关联输入），测试要验证关键交互元素是否用了正确的语义标签、heading 结构是否合理、landmark 是否准确。ARIA 用于补充语义化 HTML 无法表达的信息（如 role="dialog"、aria-expanded、aria-live），测试要验证 ARIA 属性是否与实际交互一致、与状态同步。ARIA 误用（如给原生 button 加冗余的 role="button"、错误的值、缓存状态、aria-hidden 误用）比不用更糟的原因：错误的 ARIA 会覆盖原生语义，误导屏幕阅读器用户，造成误导性朗读与操作失效；冗余 role 尽管无害但无意义，真正的危害是"错误的覆盖"——例如给可交互元素任意加 role="link" 却无链接行为，会让用户以为可跳转却无法操作。验证方法：用 a11y 工具检查 ARIA 用法，人工用屏幕阅读器确认朗读与行为一致，并审查"ARIA 是否真的解决了一个语义问题"。

ARIA 的第一原则是"能用原生 HTML 就不用 ARIA"，第二原则是"ARIA 必须正确"。误用之所以更糟，是因为它会覆盖原生语义并误导辅助技术，制造"表面无障碍、实际误导"的假象。

• SUS/UMUX 量表的结构与施测
• 得分的计算与解读
• 得分如何指导改进优先级

SUS 是 10 题、5 点（1-5）的李克特量表，奇数题正向、偶数题反向，得分按公式换算为 0-100 分；解读时参考业界基准（如均值约 68，70+ 算良好，85+ 优秀），并按"可接受性（可接受/边缘/不可接受）"与"等级（A-F）"解释。UMUX 是更精简的 4 题量表（包含有效性与易用性维度），同样按公式换算。施测要点：在用户完成真实任务后立即施测，避免提示调查目的，保证样本量足够。得分指导改进：先按任务维度细分——把自评数据与具体任务表现（完成率、时间）关联，定位得分低的具体流程；再结合问题严重度，把"低 SUS 关联的流程"和"高影响问题"排为高优先级改进项，改进后复测对比得分是否提升。

量表的价值是把"主观满意"量化成可比较的数字，并用于纵向（改版前后）与横向（对标基准）对比。改进优先级要靠"得分 × 任务影响 × 问题严重度"综合决定，而非只看总分。

• 可用性指标的定义与度量方法
• 任务完成率、错误率、完成时间的度量口径
• 基准值的设定方法与比较

可用性指标的定义与度量：任务完成率——用户成功完成任务的百分比，度量需先定义"成功"标准（完全成功/部分成功/失败），可用二元（完成/未完成）或分级（成功/部分成功/失败）计分；错误率——用户操作中出错的比例，度量需定义"错误"口径（如走错路径、输入错误、提交失败），可统计发生错误的用户比例或每次任务的错误次数；完成时间——用户完成任务所需时间，度量需剔除误操作与客服猜测，并注意异常值（超时/放弃）。基准值（Baseline）的设定：用当前版本或竞品在同一样本与任务下的测量结果作为起点，用"目标值"（如完成率提升到 90%、时间缩短 30%）设定可检验的改进目标；基准需与任务定义、样本特征、测量方式一致，才能纵向比较。

指标的可靠性取决于"口径一致"——成功、错误、任务的精确定义决定了数据的可比性。基准值不是为了绝对绝对值，而是为了"改版前后可比较"，因此测量标准化是前提。

• 统计效力（Statistical Power）的概念
• 样本量计算与显著性水平的关系
• 对可用性结论可靠性的影响

保证统计效力需在测试前计算所需样本量：确定显著性水平（α，通常 0.05）、期望的效力（Power，通常 0.80）、预估的效应量（业务上关心的最小差异），用这些参数计算每组样本量；必要时用序贯分析或更小效应假设。显著性水平选择直接影响结论——α 小（如 0.01）更保守但需更大样本，α 大（如 0.1）更易出现假阳性。Power 不足会导致"功效低"：真实差异被误判为无差异，是可用性 A/B 最常见的隐蔽错误。实践上还应先做先验样本量估算，执行时监控指标，对关键结果报告置信区间与效应量，而非只看 p 值。

统计效力（Power）是在"效应真实存在"时正确拒绝原假设的概率，核心是"避免第二类错误（漏检）"。样本量与 α、Power、效应量四者联动，测试前必须规划，否则"不显著"不代表"无效"，结论不可靠。

• Nielsen 五用户法则的由来与适用
• 五用户法则的边界
• 何时需要更大样本

Nielsen 五用户法则认为"5 个用户就能发现约 85% 的可用性问题"，其依据是"发现问题的累积收益递减"的曲线模型。但该法则有适用边界：它适用于"定性、任务型、早期发现大部分主要问题"的迭代式测试，即每个用户发现相似问题的场景。需要更大样本的场景包括：需要统计显著性——要量化完成率、时间等指标并做统计比较时，5 个样本远不够（需几十个）；用户群体异质性大——不同用户类型（新手/专家、不同角色、不同设备）对系统的使用差异大，需覆盖各群体的样本；问题出现率低——罕见或极端场景的问题用 5 个用户难以发现；需要覆盖多个关键任务和复杂流程。实践中常采用"5 个用户 + 多轮迭代"或"每类用户 5 个"的组合。

五用户法则的前提是"发现定性问题"且"用户同质"。当目标是"量化指标、统计比较、覆盖异质群体"时，样本量必须显著增大。法则的边界恰恰是"定性 vs 定量"与"同质 vs 异质"。

• axe-core 在 CI 中的门禁配置
• 基线（Baseline）管理与误报治理
• 回归与趋势监控

无障碍回归测试接入 CI 的做法：在构建流程中配置 axe-core（如集成到 Puppeteer/Playwright 测试或axe CLI，或 Lighthouse CI），对每个关键页面运行扫描，作为门禁（gate）——若发现严重（critical）或新的无障碍问题则构建失败。基线管理：由于存量问题可能很多，需先建立基线（记录已知问题清单），门禁只拦截"新增"问题而不阻塞存量，通过"基线快照"对比 diff，只允许基线清单内的问题通过。误报治理：axe 的规则有误报（如误报对比度、误报 aria），需建立"规则豁免/抑制"的白名单机制，对确认为误报的规则或特定元素做豁免，并记录原因；同时把扫描结果与源码/特性关联，便于排查。还应做趋势监控（问题数量随时间变化）与定期复审基线，防止基线无限膨胀。

CI 门禁的关键是"只拦新增、不阻塞存量"——用基线快照管理存量问题，用 diff 拦截新增。误报治理靠白名单豁免与原因记录，避免门禁因噪声而失效。

• 移动端屏幕阅读器（TalkBack/VoiceOver）与桌面端的差异
• 触摸手势、焦点与朗读方式
• 移动端特有的无障碍场景

移动端无障碍测试与桌面端的主要差异：交互方式——移动端用触摸手势（单指/双指滑动）而非键盘，TalkBack（Android）与 VoiceOver（iOS）用不同的手势体系（如单指滑动、双击激活、双指滚动），焦点移入方式不同；屏幕尺寸——小屏导致内容密度、目标尺寸、对比度、滚动更敏感，需关注触控目标大小与间距；朗读与舵式浏览——移动端用"滑动浏览"逐项朗读，依赖元素顺序与触摸目标，桌面端用 Tab 键；动态与跳出——移动端弹窗、键盘弹出、手势返回等的无障碍处理不同；系统差异——两平台的自定义动作（如 iOS 的 rotor、Android 的 actions）与无障碍焦点（accessibility focus）机制不同。测试需分别用 TalkBack 与 VoiceOver 在真实设备上验证，并兼顾触摸手势的可用性。

移动端差异的本质是"触摸手势替代键盘、屏幕阅读器交互模型不同"。因此测试要针对 TalkBack/VoiceOver 各自的手势与焦点机制，并在真实设备上验证，而非复用桌面测试。

• Section 508/EN 301 549 等合规法规
• 合规在测试计划中的体现
• 合规报告的生成与证据

Section 508（美国）与 EN 301 549（欧盟）是约束政府/公共采购软件的无障碍法规，通常以 WCAG 为技术基准。在测试计划中体现：把合规要求转化为测试范围与验收标准（如"满足 WCAG 2.1 AA"），在测试策略中明确自动化扫描 + 人工测试（键盘、屏幕阅读器）的结合，列出合规测试用例与工具，规定测试环境（真实设备、辅助技术）、缺陷分级（阻断合规的缺陷）与退出准则。合规报告生成：汇总测试结果——自动化扫描报告、人工测试记录、缺陷清单与修复状态、覆盖的页面/功能清单、批准的豁免（如遗留问题）、以及测试结论（是否符合某级别）；报告需可追溯（每个成功标准的验证证据），并附测试方法、工具版本、样本信息，供合规审计与采购方核查。

合规的核心是"可追溯的证据链"——从法规（Section 508/EN 301 549）→技术标准（WCAG）→测试范围→用例→证据→结论。合规报告要能回答"每个成功标准是否验证、如何验证、证据在哪"。

• Think Aloud 的操作规范
• 引导性提问对效度的影响
• 减少干扰的提问技巧

Think Aloud（发声思考法）要求用户在完成任务时"边做边说"，把内心想法（判断、困惑、预期）说出来，以洞察认知过程。操作规范：先向用户解释并演示（演示时不干扰用户），用中性提示（如"请继续想出声"）鼓励，在用户完成任务期间不打断、不帮忙、不纠正；记录时用录音/录屏，主持人只观察。避免引导性提问：不用"你觉得这个按钮是不是不好点？"这类暗示答案的问题，而用开放式、中性的问题（如"你现在在想什么？""你刚才遇到了什么？"）；提问不应在任务中途打断流畅性，应在自然停顿或任务结束后进行；不透露自己的假设与预期答案，保持中立，避免"点头/摇头"等暗示；用完后再追问，避免影响任务行为本身。

Think Aloud 的效度取决于"真实的认知过程"被捕捉，而非"用户给主持人想要的答案"。引导性提问会污染行为与言语，因此规范是"中性提示、不打断、开放式提问、事后追问"。

• 远程可用性测试的工具选择
• 远程测试的操作注意事项
• 与实验室测试相比的效度损失

远程可用性测试工具：分"有主持人"（如 Zoom、UserTesting、UserZoom 的远程 moderated，可共享屏幕/录屏）和"无主持人"（如 UserTesting、Userlytics 的 unmoderated 平台，用户自助完成并录制）。操作注意事项：确保用户网络与设备稳定、预先测试链接与录音、清晰告知任务与免责、处理好屏幕共享与录制权限、留意用户环境干扰（噪声、多任务）、对无主持人测试设计好引导脚本与任务提示。与实验室测试相比的效度损失：环境不可控——用户环境千差万别（网络、设备、干扰），难以复现与控制；观察受限——无法观察非言语线索（表情、身体语言）、环境行为；技术风险——录屏/网络问题导致数据缺失；任务执行真实度——用户可能在真实环境/设备上操作更接近真实，但也可能因环境差异失真。优点是样本广、成本低、更贴近真实使用场景。

远程测试的效度损失主要来自"环境不可控"与"观察受限"，但换来的是样本规模与真实场景。取舍在于"深度洞察"（实验室）与"规模与真实"（远程）的平衡。

• 语音界面的可用性测试维度
• 唤醒词、误识别、多轮打断、无声环境的用例设计
• 语音无障碍的特殊性

语音界面（VUI）测试需覆盖：唤醒词——用不同口音、语速、音量、噪声环境测试唤醒词的识别率与误唤醒（无唤醒词时被误触发）；误识别——输入带噪声、口音、同音词、含糊语音时，系统的识别错误是否被合理处理（如请求澄清、给出选项），而非静默失败；多轮打断——用户说话被打断、系统播报被用户打断、转向（barge-in）时对话状态是否正确更新，多轮对话中用户中途改口是否被正确理解；无声环境——静音/低音量、无回应时系统是否超时、是否提示、是否合理退出，避免无限等待。还需测试无障碍：视觉用户与视障用户都能通过语音完成操作、语音播报与屏幕反馈一致、错误恢复的引导。用例设计按"输入类型×环境×对话状态"矩阵构造。

语音界面的核心是"对话状态机"与"识别不确定性"。测试要覆盖唤醒、识别错误与恢复、多轮打断、静默超时这些语音特有的边界，而不只是"正常指令一次成功"。