经典场景设计题

• 六维度的测试设计
• 功能/安全/兼容的要点
• 测试用例的完整性

登录页测试从六个维度设计：功能——正确账号密码登录成功、错误密码提示、空用户名/密码校验、记住我、忘记密码、注册入口、回车提交、登录后跳转；UI——界面元素位置、文案、错误提示样式、输入框长度限制、密码掩码、无障碍；安全——SQL 注入（' OR 1=1--）、XSS 注入、暴力破解（连续失败锁定/验证码/限流）、明文传输（HTTPS）、密码加密存储、会话安全（token 过期、登出清会话）、越权；性能——登录接口响应时间、并发登录、高并发下不崩溃、数据库连接池；兼容——不同浏览器、不同操作系统、不同分辨率、移动端/PC 端、不同语言；异常——网络断开、服务器错误、超时、验证码错误、账号锁定、重复提交（防抖）、数据库异常。六个维度交叉设计，覆盖登录的完整行为。重点验证安全（注入/暴力破解）与异常（各种失败路径）。

六维度框架是"功能→UI→安全→性能→兼容→异常"的完整覆盖，登录是经典高频场景。测试设计的关键是"不漏维度、突出重点"——安全与异常是登录最易出缺陷的维度，需重点覆盖。这个框架可作为通用场景测试模板。

• 文件上传的测试维度
• 边界与安全
• 性能考量

文件上传测试从功能、边界、安全、性能四方面：功能——上传成功（合理文件）、上传失败提示、取消上传、拖拽/选择文件、进度条、上传后可预览/下载、文件类型校验提示、重复上传；边界——文件大小（0字节、1字节、恰好上限、上限+1、超大）、文件格式（白名单内/外、空文件、无扩展名、多扩展名如 .tar.gz）、文件名（超长、特殊字符、中文、空格）、同时上传多个文件、上传数量上限；安全——后缀绕过（把 .exe 改名 .jpg，验证是否按内容/魔数校验而非仅扩展名）、木马/恶意文件（上传可执行文件、脚本，验证是否被拦截）、超超大文件（占满磁盘、拒绝）、文件类型欺骗（MIME 与内容不符）、路径遍历（文件名含 ../ 写入非预期目录）、病毒扫描；性能——上传大文件的耗时、并发上传、内存占用、上传过程中服务端响应、超时与断点续传。核心是"安全校验必须基于内容而非仅扩展名"。

文件上传是安全与边界的高风险面。功能验证正常流程，边界验证大小/格式，安全验证"绕过与伪装"（这是重点），性能验证大文件与并发。测试的核心是"校验的可靠性（基于内容魔数）+ 边界防御 + 恶意文件拦截"。

• 下单支付流程的测试维度
• 库存、优惠券、支付回调、退款、对账
• 一致性与幂等

电商下单支付流程测试要点覆盖：库存扣减——下单时扣库存、支付成功/失败后库存是否回滚、超时未支付释放库存、并发下单不超卖、库存与订单数据一致；优惠券叠加——不同优惠券叠加规则、满减/折扣/立减组合、使用后优惠券核销、退款后优惠券返还、优惠券过期与金额计算；支付回调——支付成功/失败/超时回调、重复回调（幂等）、回调顺序乱序、回调金额与订单不一致、回调丢失；退款——全额/部分退款、退款后库存/优惠券/金额状态、退款幂等、退款失败重试；对账——支付渠道对账单与订单对账、金额核对、差异处理、对账任务执行。核心是"数据一致性 + 幂等 + 状态机正确"。测试重点是各环节的异常与并发，尤其支付回调的幂等与重复、库存扣减的并发安全。

下单支付是核心资金链路，测试重点是"数据一致性（库存/金额/优惠券）、幂等（支付回调/退款）、状态机正确（各状态流转）"。并发（超卖、重复回调）与对账（前后台一致）是最高风险。测试需覆盖"正常流程 + 各异常/并发 + 对账一致性"。

• 秒杀系统的测试维度
• 超卖、防重、限流、库存扣减、幂等
• 高并发与一致性

秒杀/抢购系统测试要点：超卖——高并发下验证库存不超卖（库存扣减的原子性/乐观锁/Redis 预扣）、同一商品并发下单、库存为0时正确拒绝；防重——同一用户重复抢购被拦截（一人一单）、重复提交防抖、同一请求去重；限流——秒杀接口限流（令牌桶/漏桶）、超过并发上限被拒绝、限流提示正确、防刷（验证码/黑名单）；库存扣减——预扣/扣减/回滚时机正确、扣减失败回滚、库存与订单一致、超时未支付释放库存；幂等——重复请求/重复下单不产生多单、重复扣减不重复扣库存、支付回调幂等。测试需用高并发压测（多线程并发下单）验证不超卖、用重复请求验证幂等、用限流压测验证限流生效。核心是"高并发下的一致性（不超卖）+ 防重 + 幂等 + 限流"。

秒杀系统测试的核心挑战是"高并发下的数据一致性（不超卖）与防重"。测试需用并发压测验证库存原子扣减、用重复请求验证幂等与防重、用限流压测验证限流。库存扣减的原子性与幂等是最高风险，直接决定资金与库存安全。

• 搜索功能测试维度
• 分词、同义词、特殊字符、排序
• 性能与空结果

搜索功能测试要点：分词——中文分词（人名、地名、多义词）、英文单词/大小写、组合词、长词、停用词；同义词——同义词的搜索（如"手机"与"移动电话"）、近义词、别名；特殊字符——%、_、引号、反斜杠、空格、emoji、SQL 注入字符、HTML 标签（XSS）；空结果——搜索无匹配时正确提示、空输入、前后空格、全角/半角；排序——相关度排序、按时间/价格/销量排序、排序稳定性、分页；性能——大索引下搜索响应时间、并发搜索、超时、模糊搜索开销；此外还有：搜索历史、联想词、大小写忽略、搜索结果的准确性（无无关结果）。核心是"分词/同义词的正确性 + 特殊字符的转义处理 + 空结果与排序逻辑 + 性能"。特殊字符要防注入与 XSS。

搜索功能的核心是"检索正确性（分词/同义词/排序）与安全性（特殊字符转义防注入）与性能"。特殊字符既是功能问题（转义）也是安全问题（注入），需重点验证。空结果与排序是易忽视的分支。

• 开放题考察点
• 答题框架（章节化）
• 测试设计思维

测试"电梯/笔/水杯"这类开放题考察的是"系统化测试设计思维"而非具体功能，答题框架是"按维度/章节系统枚举"。通用框架：1）明确被测对象与用户/使用场景（who uses it, how）；2）功能测试——基本功能（笔能写字、水杯能装水、电梯能升降）、各功能的正反验证；3）边界测试——极限值（电梯最大载重、最高楼层、水杯容量上限、笔芯长度）；4）分类/场景测试——按使用场景（雨天、高温、不同人群）划分；5）异常/安全测试——损坏、故障、超载、漏水、安全装置（电梯急停、超载报警）；6）性能/耐用性——反复使用、寿命、压力；7）兼容/环境——不同环境（温度、湿度、海拔）；8）可用性/UI——易用性、标识、无障碍。答题时"先建框架再填充细节"，体现"按维度枚举、不遗漏"的思维。核心是"展示测试设计的系统性、分层与边界意识"。

开放题考察的是"测试设计方法论"而非题目本身。答题关键是"建立覆盖功能/边界/异常/安全/性能/环境的框架，再逐项填充"，体现"系统性、不遗漏、有边界意识"。用"章节化"组织答案，正是测试设计完整性的体现。

• 各类验证码的测试要点
• 验证码的生成/校验/过期
• 自动化处理策略

验证码测试要点：图形验证码——生成正确（可识别）、刷新、扭曲度（过于难识别/过于简单）、大小写、过期、错误提示、通过后失效；短信验证码——发送频率限制（防刷）、有效期、一次性使用、重复发送、发送失败、号码格式校验、运营商异常；滑块验证码——滑块轨迹校验、拖拽精度、防机器（是否被绕过）、每次一次性、异常拖动。自动化处理策略：图形验证码——测试环境用"万能验证码/测试白名单"或关闭验证码（避免 OCR 不稳定），或接入打码平台；短信验证码——测试环境固定验证码/由测试接口获取；滑块——用模拟拖拽或绕过（测试环境关闭滑块校验）。核心策略是"测试环境禁用或绕过验证码校验，聚焦业务逻辑测试；验证码本身的校验逻辑单独用少量用例验证"。自动化避免被验证码阻塞，保证稳定。

验证码测试分"验证码机制本身"与"业务集成"两部分。自动化处理的关键是"测试环境绕过/固定验证码，分散验证码本体的校验"——否则自动化会被验证码阻塞、不稳定。图形/滑块类验证码的 OCR 不稳定，故多用白名单/固定码策略。

• 支付回调的测试维度
• 重复、乱序、超时、金额不一致、对账
• 幂等与一致性

支付回调测试设计：重复通知——支付渠道多次回调同一订单，验证系统幂等处理（不重复发货/加单/扣款），只更新一次状态；乱序回调——回调顺序与业务顺序不一致（如重复通知先来、成功通知后到），验证系统能正确处理不依赖顺序；超时——回调超时（网络延迟、渠道重试），验证系统超时处理、重试机制、前端兜底轮询；金额不一致——回调金额与订单金额不一致，验证系统拒绝并告警（防篡改）；对账——渠道对账单与系统订单对账，验证金额核对、差异发现、补偿处理。验证手法：用 mock 渠道模拟各种回调（重复、乱序、超时、金额错误），用对账脚本核对一致性。核心是"幂等 + 顺序无关 + 超时补偿 + 金额校验 + 对账"，保证支付状态与资金一致。

支付回调是异步、不可靠的外部通知，测试重点在"幂等（重复通知）、顺序无关（乱序）、超时补偿、金额校验（防篡改）、对账（一致性）"。用 mock 模拟异常回调是核心手法。支付回调的可靠性与一致性直接决定资金安全。

• 聊天机器人的测试维度
• 意图识别、上下文记忆、超时、并发、安全
• 会话正确性

多轮对话聊天机器人测试要点：意图识别——不同表达方式识别同一意图、歧义句、多意图、未定义意图的正确兜底、槽位抽取（参数提取）；上下文记忆——多轮对话中的上下文保持（指代消解如"它"、"那个"）、上下文切换、上下文边界（会话过期/超时后清空）、多轮后的状态一致性；超时——长时间不说话超时、会话超时后回复、超时恢复；并发——多用户并发对话（会话隔离不串场）、同一用户多轮并发、并发下上下文不串；安全边界——恶意输入（注入、越权、敏感信息泄露）、提示注入、滥用（刷接口）、内容安全（不当内容）。验证手法：构造多轮对话数据流，验证意图/槽位/上下文随轮次正确；用超时与并发场景验证会话管理。核心是"意图与上下文正确性 + 会话隔离 + 安全边界 + 超时并发"。

聊天机器人测试的核心是"对话语义正确性（意图/上下文）与工程健壮性（超时/并发/安全）"。上下文记忆是机器人特有的难点（多轮指代/切换），并发要验证会话隔离，安全要防注入与内容不当。测试需构造大量多轮对话样本。

• 购物车功能用例
• 价格与库存同步
• 跨端一致性与过期清理

购物车模块测试用例：增删改——添加商品（数量、重复添加）、删除商品、修改数量（增/减、上下限）、商品勾选/全选、清空购物车、添加不存在的商品；价格与库存同步——商品价格变化后购物车价格是否同步更新、库存不足/售罄时提示、下单时价格与库存再校验、优惠/满减在购物车中的显示；跨端一致性——同一账号在多种端（Web/App/小程序）购物车数据一致、一端修改另一端同步、离线后同步；过期清理——购物车商品过期（下架/售罄）清理、超时未登录购物车清理、数量超限、数据过期策略。核心是"数据一致性（价格/库存同步）+ 跨端同步 + 过期管理"。测试重点：价格变化后同步正确、库存不足时下单校验、跨端实时同步、过期商品清理。

购物车是"数据+状态"的典型场景，核心是"增删改的正确性、价格/库存同步（数据一致性）、跨端一致、过期清理"。价格与库存同步是易出缺陷点（下单时可能已变价），需验证下单时的二次校验。跨端一致性涉及数据同步机制。

• IM 测试维度
• 消息顺序、送达、离线、群聊、文件
• 一致性与可靠性

IM 聊天功能测试用例：消息顺序——发送方与接收方消息顺序一致（不因网络乱序）、多设备消息顺序一致、历史消息加载顺序；送达——消息送达确认（已读/已送达状态）、发送失败重试、弱网/断网下消息状态、消息不丢失；离线消息——离线时收到的消息、上线后离线消息同步、离线消息数量与顺序、离线状态下的已读；群聊——建群、加人、退群、群消息广播、群成员权限、@提到、群消息历史；文件传输——图片/视频/文件发送与接收、大文件、进度、失败重试、传输中断、文件类型校验。核心是"消息的一致性（顺序/送达/离线）与可靠性（不丢失/不重）"。测试需用弱网、断网、乱序模拟验证消息可靠性，验证 ACK 与重传机制。

IM 测试的核心是"消息可靠性（顺序/送达/离线/不丢失不重复）"与"群聊/文件等功能"。网络不可靠是 IM 的最大挑战，需用弱网/断网/乱序验证消息一致性与重传。消息顺序与送达状态是易出缺陷点。

• 批量导入导出的测试维度
• 模板校验、部分失败、进度、大数据量、编码
• 数据一致性

批量导入导出功能测试：模板校验——模板下载、模板格式（表头/字段/必填）、模板错误（列缺失/多余/类型错误）、模板版本；部分失败——导入中部分行成功部分失败、失败行错误提示与定位、失败行可修正重新导入、成功与失败互不影响；进度提示——导入/导出进度条、大文件进度、取消/暂停、进度与实际一致；大数据量——万行/十万行导入导出性能、大数据量下不超时不崩溃、内存占用、分批处理；编码问题——中文/特殊字符编码（UTF-8/GBK）、乱码、Excel 特殊字符、前后空格、空行；此外还有：重复数据（更新/跳过/报错）、导入失败回滚、导出文件正确性、权限校验。核心是"数据正确性（模板/编码/部分失败）+ 大数据量性能 + 进度反馈"。测试重点：部分失败的正确处理、大数据量性能、编码与特殊字符。

批量导入导出是"数据+性能"的场景，核心是"模板校验正确性、部分失败的处理（成功失败互不影响、可修正重导）、大数据量性能、编码正确性"。部分失败与大数据量是易出缺陷点，需重点验证。

• 展示型 H5 的测试维度
• 兼容性、加载、展示
• 交互与异常

纯展示型 H5 活动页测试维度：展示——页面内容（文案、图片、活动规则）正确、布局在各分辨率下正常、动画/轮播正常、错别字与链接；兼容性——不同浏览器（Chrome/Safari/微信内置浏览器）、不同机型（iOS/Android 屏占比）、不同屏幕尺寸、横竖屏、系统版本；加载——首屏加载速度、弱网/慢网加载、图片懒加载、加载失败（图片挂、接口失败）的兜底、缓存策略；交互——点击跳转、按钮可点、滚动、二维码/分享、表单（若有留资）；异常——接口超时/失败、网络切换、页面刷新、返回键、重复点击；安全——内容安全、链接安全、无注入。展示型 H5 的核心是"展示正确性 + 兼容性 + 加载性能 + 异常兜底"。测试重点是各机型/浏览器兼容、弱网加载、加载失败的兜底展示。

纯展示型 H5 功能简单，测试重点是"展示正确性（内容/布局）、兼容性（多端）、加载性能（弱网/首屏）、异常兜底（加载失败）"。兼容与加载是 H5 最易出问题的维度，需用真机/模拟器覆盖多机型。

• 场景测试的模板化
• 检查点清单
• 团队资产沉淀

把登录/购物车/搜索等经典场景抽象为可复用模板的方法：从各场景中提取"通用检查点清单"，分为四类——正常流（主流程、分支、各输入取值的正确行为）、安全（注入、越权、敏感信息、防刷）、并发（重复提交、并发一致性、竞态）、兼容（多端、多浏览器、多分辨率）。模板化：把每个场景的"通用检查点 + 场景特有检查点"组织为标准模板，如"功能-正常流-边界-安全-并发-兼容-异常"的章节结构，新场景直接套用模板并补充特有部分。沉淀为团队资产：把模板与检查点清单存入团队知识库（wiki/测试文档库），由团队评审并持续更新（从缺陷反哺新检查点），作为新成员测试设计的参考与评审标准。资产价值：统一测试设计质量、减少遗漏、提升效率、沉淀经验。核心是"把经验固化为结构化清单，让团队复用而非各自摸索"。

场景模板化的核心是"提炼通用检查点（正常流/安全/并发/兼容）+ 场景特有检查点"，形成可复用模板。沉淀为团队资产靠"存储于知识库 + 评审更新 + 缺陷反哺"。这使测试设计从"个人经验"变为"团队标准化资产"，提升质量与效率。

• 正常/异常/边界流的枚举
• 完整性检查
• 用例配比评估

场景设计完整性检查的方法是"系统枚举三类流并核对配比"：正常流（happy path）——主流程、各分支的正常走向，验证功能正确；异常流——错误输入、权限不足、外部失败、超时、取消等异常路径，验证系统对异常的处理与防御；边界流——极限值、最大/最小、空、越界等边界场景，验证边界行为。完整性检查：用"正常流+异常流+边界流"清单逐项核对是否有遗漏，必要时用状态图/判定表辅助枚举（确保分支不漏）。配比评估：正常流用例应有一定比例（确保主流程覆盖），但异常流与边界流通常占更大比例（缺陷多源于异常与边界），常见配比"正常流约 30%、异常流约 40%、边界流约 30%"（依风险调整）；核心是"异常与边界占比不低于正常流"，避免"只测一帆风顺"。配比合理性的评估依据是"是否覆盖了关键异常与边界、缺陷发现率是否健康"。

完整性检查的关键是"系统枚举正常/异常/边界三类流"，用清单与状态图辅助防遗漏。配比评估的核心是"异常流与边界流占比合理（通常不低于正常流）"，因为缺陷多集中于此。完整性=不遗漏 + 配比合理。

• 测试点与用例的映射
• 产出物管理
• 脱节规避

场景设计的产出物包括"测试点清单（测试点）"与"测试用例（具体步骤+预期）"，二者是"点→例"的映射关系：一个测试点对应一条或多条用例，用例是测试点的具体化。维护映射关系的方法：为每个测试点分配唯一标识（如 TP-01），用例中标注"所属测试点"（如 TC-01-001 对应 TP-01），建立"测试点↔用例"关联表；用测试管理工具（TestRail/禅道）维护双向关联，支持从测试点查用例、从用例查测试点。避免脱节的关键：变更时同步更新——测试点变更（需求/设计变化）时，同步更新对应的用例（新增/删除/修改），并更新关联；定期核对"测试点是否有对应用例、用例是否有对应的测试点"，用"测试点覆盖率"（有用例的测试点/总测试点）检查；评审时验证"测试点与用例的一致性"。核心是"唯一标识 + 双向关联 + 变更同步 + 定期核对"，防止测试点与用例脱节。

测试点与用例是"设计→落地"的两层，脱节会导致"设计说了却不测"或"测了却无依据"。维护靠"唯一标识+双向关联表+变更同步+定期核对（测试点覆盖率）"。这是测试产出物可追溯、可管理的关键。

• 自动补全的测试维度
• 触发时机、防抖、缓存、空结果、键盘选择
• 交互正确性

搜索框自动补全/联想功能测试：触发时机——输入多少字符触发联想（首字符/多字符）、停顿时触发、输入即时触发、清空输入后联想消失；防抖——快速连续输入时请求合并/节流（只发最后一次）、防抖时间正确、中途输入不产生过多请求；缓存——联想结果缓存（相同输入不重复请求）、缓存命中、缓存过期、缓存不一致（数据更新后）；空结果——无匹配时提示"无结果"、不显示联想、空输入时不触发；上下键选择——按上下键遍历联想项、回车确认、鼠标点击、Esc 关闭、选中后输入框更新、键盘操作与防抖/缓存不冲突；此外还有：联想项展示（高亮关键词）、点击跳转、请求失败兜底。核心是"触发时机与防抖（性能）、缓存（效率）、空结果与键盘选择（交互）"。测试重点：防抖是否正确合并请求、缓存是否一致、键盘交互是否顺畅。

自动补全测试的核心是"触发时机（何时触发）、防抖（避免请求风暴）、缓存（效率与一致性）、空结果（兜底）、键盘选择（交互）"。防抖与缓存是性能相关的易错点，键盘交互是易漏的交互细节。测试需验证请求频率与结果一致性。

• 推荐/信息流的测试维度
• 非确定性内容的断言
• 多样性、时效性、无重复、可回放

推荐/信息流内容非确定（算法、实时变化），断言策略不能断言"具体某条内容"，而应断言"内容属性与结构"：多样性——返回内容来源/类型/作者是否多样（不全是同一来源）、结果是否覆盖多个类别；时效性——返回内容是否包含最新内容、新旧内容比例、过时内容是否被过滤；无重复——同一请求/滑动加载中内容不重复、分页不重复、刷新后去重；可回放——相同输入/相同用户在同一条件下，返回结果可复现（用于 bug 定位）或至少结构稳定。测试方法：用"属性断言"（结果数量、类型分布、无重复、时效性、多样性指标）替代"内容断言"；为便于可回放，测试时固定种子/用户/时间或记录请求参数，重现结果；用批量样本统计验证多样性与时效性是否符合预期分布。核心是"断言内容属性而非具体值，用统计与可回放机制保证可测性"。测试重点：无重复、多样性、时效性、可回放性。

非确定性内容无法用"具体值断言"，需改用"属性/统计断言"（多样性、时效性、无重复、可回放）。可回放性通过固定种子/记录请求参数实现，保证缺陷可复现。这是对"非确定性"系统的测试策略——测"结构"而非"个例"。