测试分析
测试分析是根据需求、规则和风险，确定哪些行为需要验证，以及怎样的证据才足以判断结果。它先解决“应该测什么”：同样是上传一张图片，格式能否解析、上传后谁能看到、失败后是否留下半条记录，分别对应不同问题。
准备测试开发面试时，要能把笼统的功能名称转成明确的输入、状态、操作和预期结果。脚本执行得再快，也不能补上没有被识别的规则。
1. 面试核心
先记住这几条，再读正文- 测试依据可以是需求、接口契约、业务规则和已确认的约束。有歧义先澄清，未确认的假设需要标明，不能用当前实现代替产品要求。卡 · 测试依据与范围
- 一个可执行用例需要说明前置状态、输入与操作、预期结果。“功能正常”不是可核对的期望值。卡 · 综合题
- 黑盒方法依据外部行为，白盒方法依据内部结构；静态与动态则区分是否运行被测对象。这些分类描述不同维度，可以组合使用。卡 · 方法与执行范围
- 测试结果需要独立的判定依据，可能是明确值、业务不变量或可信对照。照抄当前输出会把实现错误写进期望结果。卡 · 预期结果与可测试性
- 优先级由影响、出现条件和变更风险共同决定。先保住关键行为，再扩展输入和环境范围，并留下未验证部分。卡 · 风险与结束条件
- 相同设计方法可以用于不同产品，但领域规则和失败代价决定检查重点。游戏帧率、支付金额和图片可见范围不能用同一套“正常使用”结论替代。卡 · 风险与结束条件
- 测试活动从评审到交付反馈持续发生；左移提前验证可提前检查的风险，不能替代真实集成与运行环境的证据。卡 · 迭代中的测试活动
2. 测试依据与范围
测试依据是用来确定应有行为的材料，例如已确认的需求、接口定义、权限规则和验收约定。先找依据，才能知道一次失败是程序缺陷、测试理解错误，还是需求没有说明白。
假设需求只写“用户可以上传图片”。至少还缺少这些决定用例的条件：
| 需要确定的规则 | 对测试的影响 |
|---|---|
| 谁可以上传，谁可以查看 | 未登录、越权查看与分享范围 |
| 允许的格式、大小和数量 | 有效输入、无效输入与边界 |
| 以扩展名还是文件内容识别格式 | 文件名与实际内容不一致的输入 |
| 上传完成的含义 | 只接收字节，还是已经可访问、可显示 |
| 中途失败后如何处理 | 重试、临时文件和记录清理 |
| 同一操作重复提交的要求 | 重复记录、重复计数或幂等行为 |
这里不应该自行补出“最多九张”之类规则，再当成既定需求。面试里可以说明：“以下按单次最多三张、单张不超过 5 MiB 分析，实际以需求为准。”随后所有取值都要服从这个假设。
范围还包括测试对象的边界。只测上传 API，可以验证服务端校验和持久化，却不能据此断言浏览器拖拽交互正常；只看到页面缩略图，又不足以证明其他账号没有访问权限。
3. 测试条件与用例
测试条件是要核验的一项行为或约束；测试用例把这个条件落实为一次可以执行和判定的检查。
例如，“拒绝超过单张大小上限的图片”是测试条件。若规则已经确认上限为 5 MiB，具体用例可以是：
| 字段 | 内容 |
|---|---|
| 前置 | 已登录普通用户，配额足够，没有同名历史记录 |
| 输入 | 内容合法、可解析，大小为 5 MiB + 1 字节的图片 |
| 操作 | 调用上传接口一次 |
| 期望 | 返回约定的大小超限错误；不新增可访问图片；配额不扣减 |
| 证据 | 请求标识、响应、按该标识查询的记录与配额变化 |
选择合法图片内容，是为了让这条用例主要验证大小校验。如果输入本身已经无法解析，系统可能先返回格式错误，大小限制是否有效仍然未知。
随后再为其他条件选方法：输入类别用等价类，范围交界用边界值，多条件决定一个结果用判定表，操作顺序影响结果用状态迁移。方法帮助推导用例，不替代对需求的理解。
需求变化时，要能追溯到受影响的检查。例如大小上限调整，只需找到引用大小规则的用例、数据与断言；若用例只叫“上传测试 1”，维护者很难确认它究竟保护哪条规则。
4. 预期结果与可测试性
测试预言（test oracle）是判断实际结果是否正确的依据。这里的“预言”不是预测未来，而是说明凭什么把一次结果判为通过。
对于价格计算，可以根据确认过的计价规则手工推导一个小例子的金额。对于排序，除了与一组明确结果比较，还可以检查两个性质：输出非递减，而且元素及其出现次数与输入一致。只检查“有序”会漏掉把全部元素丢掉后返回空列表的错误。
预期结果不一定总是一个固定值：
| 结果类型 | 可以核对的依据 | 需要保留的限制 |
|---|---|---|
| 精确输出 | 确定的输入输出对 | 只覆盖这些输入 |
| 状态变化 | 余额减少量等于已确认订单金额 | 还需检查关联记录与重复操作 |
| 不变量 | 任意成功操作后库存不为负 | 满足不变量不代表所有业务都正确 |
| 关系 | 同样条件下增加商品不应降低未优惠总价 | 关系必须服从真实定价规则 |
| 可信对照 | 与独立实现或经过确认的样本比较 | 两个实现可能共享同一错误假设 |
可测试性指系统让测试建立条件、执行操作并观察结果的难易程度。要测“一小时后过期”，可注入受控时钟；要测“第三次重试成功”，可控制依赖的响应序列。否则每次等待一小时、碰运气触发故障，会让验证既慢又不稳定。
观察能力也必须对应问题。响应里返回了 ID，可以证明服务给出了标识；要证明数据已经保存，还需要读取最终记录。异步处理要规定完成期限和查询方式，不能把任意固定等待后的一次结果当成完整判断。
5. 方法与执行范围
测试方法的分类不能混为一谈。“自动化”描述执行方式，“黑盒”描述设计依据，二者并不互斥。
| 维度 | 区分依据 | 例子 |
|---|---|---|
| 静态／动态 | 是否执行被测对象 | 评审权限需求；运行 API 验证权限 |
| 黑盒／白盒 | 根据外部规则还是内部结构设计 | 按金额范围选值；按分支路径补输入 |
| 手工／自动化 | 由人操作还是程序执行 | 人观察交互；脚本重复核验响应 |
| 功能／非功能 | 核验能力还是相应质量特性 | 退款金额；给定负载下的响应时间 |
阅读代码可以发现一个缺少的条件分支，也可以指导构造能触发该分支的输入。但“走到了这一行”仍然需要正确断言配合；覆盖率的解释见 测试金字塔。
静态评审能够在程序运行前发现需求冲突、未处理的输入和明显代码问题。运行测试则能观察真实执行、集成和时序，两类证据互相补充。
6. 风险与结束条件
产品风险是产品可能出错及其后果。安排用例时，可以先比较失败影响、发生条件、使用规模和近期变更，再决定验证顺序；不必为了得到一个分数而假装这些因素都能精确量化。
对于上传功能，越权暴露私人图片、上传成功却丢数据和页面间距偏差，失败代价不同。前两类即使操作次数较少，也可能需要更早验证。最近重写了文件解析代码，则相应输入与异常路径需要增加检查。
一组可审阅的结束条件可以写成：关键流程已在目标环境执行；高风险规则都有结果；已知缺陷及处置意见明确；失败能定位到证据；未执行项与残余风险已列出。这些条件不等于证明产品没有缺陷，而是说明当前结论建立在什么证据上。
领域也会改变风险模型。游戏需要检查状态同步、帧率和长时间运行，交易服务关注金额、重复操作与一致性。两者都能用边界和状态方法，但不能只替换产品名字就复用整份计划。
6.1 迭代中的测试活动
测试活动贯穿一次变更，从澄清要求到交付后核对结果，并且会随新信息反复调整。可以按活动产生的证据来组织回答：
| 活动 | 需要产出的证据 |
|---|---|
| 需求与设计评审 | 业务规则、风险、验收条件和待澄清问题 |
| 测试计划与分析 | 范围、优先级、环境依赖、结束条件和时间安排 |
| 测试设计与实现 | 用例、测试数据、替身或真实依赖、可执行检查 |
| 执行与监控 | 版本与环境、实际结果、阻塞项和缺陷证据 |
| 修复验证与回归 | 原问题是否消失，相关既有行为是否保持 |
| 完成与反馈 | 已验证范围、未解决问题、残余风险和后续改进 |
这不是必须逐项结束才能开始下一项的流水线。评审时可以先写验收例子，编码时可以持续运行单元和组件测试，集成环境具备后再核对跨服务行为。执行中发现需求冲突，也要回到分析阶段确认规则。
测试左移是把能提前完成的检查安排到更早阶段，例如评审含糊规则、检查代码和验证接口契约，减少问题到集成时才暴露的代价。它不能让尚不存在的真实部署环境凭空提供证据，容量、兼容性、真实依赖和上线后的观测仍有各自价值。
提测延期时，先明确剩余时间、实际变更与风险，再协商缩小交付范围、推迟发布或调整验证安排。删掉关键验证却沿用原来的“全部通过”结论，会让决策失去依据。报告应把未执行和受阻项保留下来，具体统计和结论见 测试报告。
7 · 面试题卡片
本页题目与参考回答
7.1 需求只写“支持图片上传”，应先澄清什么？
考察重点：测试依据、范围与未经确认的假设。
相关内容：测试依据与范围。
参考回答
先确定上传与查看权限、输入限制、成功条件和失败处理规则。 格式、大小、数量、可见范围、中断与重复提交都会改变测试内容。
还要明确测的是界面、服务端 API 还是完整流程。暂时无法确认的规则可以作显式假设，用于继续分析，但不能把假设写成已经通过验收的要求。
7.2 怎样为朋友圈图片上传设计测试用例？
题型：综合题
考察重点：从用户流程推导输入、权限、状态和失败结果。
参考回答
先确认产品规则，再按完整上传链路组织检查，并为每类检查给出可观察结果。 输入包括格式、内容、大小与数量；流程包括选择、上传、发布、查看和删除；权限需要覆盖本人、允许查看者和无权限者。
异常检查包括中断、取消、重复提交、部分成功和配额不足，并验证是否留下错误记录或扣错配额。优先验证隐私、数据保存和核心发布流程，再覆盖目标设备、浏览器及性能要求。具体上限由需求决定，不能自行套用一个固定数字。
7.3 黑盒、白盒、静态、动态和自动化测试之间是什么关系？
考察重点：设计依据、执行方式与测试活动的不同维度。
相关内容：方法与执行范围。
参考回答
黑盒与白盒描述设计依据，静态与动态区分是否执行被测对象，自动化描述执行方式。 按接口契约编写并运行脚本，可以同时属于黑盒、动态和自动化测试。
静态代码评审可以利用内部结构发现问题；白盒动态测试则运行代码核验路径及结果。不能因为没有界面操作，就把测试一概归为白盒。
7.4 不知道完整正确输出时，还能设计有价值的测试吗？
考察重点：判定依据、不变量及证据的适用范围。
相关内容：预期结果与可测试性。
参考回答
可以验证已知性质、状态约束和输入变化后的关系，但需要说明它们不能证明什么。 排序可检查有序性与元素计数保持不变；库存操作可检查不超卖和账目变化一致。
性质本身也必须有需求依据。只验证一个必要条件会漏掉满足该条件的错误实现，因此要组合独立性质，并保留可手工推导的小样本。
7.5 时间有限时怎样选择测试范围，什么时候可以结束？
考察重点：风险排序、明确覆盖与残余风险。
相关内容：风险与结束条件。
参考回答
优先检查失败代价高、使用广、最近发生重要变化的行为，并提前约定结束条件。 核心流程和高风险规则必须有实际执行证据，已知缺陷需要明确处理意见。
结束时列出执行环境、未执行项和残余风险。不能用“用例全部通过”替代范围说明，也不能承诺通过有限测试证明不存在缺陷。
7.6 游戏测试与一般业务软件测试有哪些共同点和差异？
考察重点：通用设计方法与领域约束的关系。
相关内容：风险与结束条件。
参考回答
共同点是根据规则、状态和风险设计可判断的检查，差异在具体行为和失败代价。 游戏可能重点检查玩法状态、联机同步、帧率和资源长期占用；交易软件可能重点检查金额、权限、重复提交和数据一致性。
领域之间可以复用边界、状态迁移等方法，但性能目标、判定依据和优先顺序必须重新确定。不能仅因产品属于某一类就省略权限或数据正确性检查。
7.7 一次迭代从需求到上线，测试应参与哪些活动？
考察重点：活动之间的反馈、验证证据、测试左移与剩余风险。
参考回答
从需求和设计评审开始明确规则与风险，随后规划、设计并实现测试，执行时记录结果和缺陷，修复后复测与回归，交付前说明证据及未解决风险。 这些活动可以交错，执行中的发现也会反过来修改需求或测试设计。
左移把评审、静态检查、单元或契约验证尽早开展，但真实环境、容量和上线后的观测仍需相应证据。时间不足时应重新协商范围和风险，不把未执行项计为通过。
8. 参考资料
来源：Coding 101 原文 · 免费阅读，引用请保留出处。内容使用说明