缺陷生命周期与测试文档

• 缺陷状态流转的典型路径
• 各状态转换的责任人与触发条件
• 分支状态（Rejected/Deferred/Duplicate）的处理

缺陷的典型状态流转路径为：New（新建）→ Open（已确认/打开）→ Fixed（已修复）→ Retest（待复测）→ Closed（已关闭），期间可能进入分支状态。各状态转换的责任人与触发条件：New：由测试人员（Tester）提交缺陷，触发条件为发现缺陷并登记；New→Open：由测试负责人（或缺陷评审）确认缺陷有效，触发条件为缺陷被接受、有效、非重复；Open→Fixed：由开发人员（Developer）修复，触发条件为修复完成并提交代码；Fixed→Retest：由开发标记"已修复"，等待测试复测；Retest→Closed：由测试人员复测通过，触发条件为复测确认缺陷已修复；若复测失败则回到 Open（或 Reopened）。分支状态：New→Rejected（开发/评审认为按设计、不可复现或无效，驳回）；Open→Duplicated（确认是重复缺陷，合并关闭）；Open→Deferred（延期，因优先级低或资源不足，延后处理）。每个状态转换都有明确责任人（谁操作）与触发条件（凭什么转），保证缺陷可追溯。

核心是"状态流转+责任人+触发条件"三要素。回答要给出典型路径与分支，并说明每个转换的职责。

• 缺陷报告模板的关键字段
• 首次复现率的概念与提升手段
• 每个字段对复现/定位的必要性

要使开发人员首次复现率最大化，缺陷报告模板应包含便于复现与定位的关键字段：标题（精炼概括问题+模块+等级，便于快速识别）；复现步骤（精确到点击/输入/操作的最小步骤，按顺序编号）；前置条件（环境、账号、数据、初始状态，如"需 A 账号登录后进入订单页"）；实际结果（可观察到的错误现象，含错误信息）；期望结果（正确行为）；环境信息（操作系统、浏览器/设备、版本、分辨率、网络）；缺陷证据（日志、截图、录屏、抓包文件，标注时间点）；版本信息（被测版本/构建号）。每个字段的必要性：复现步骤与前置条件直接决定能否复现，是首次复现率的核心；环境信息决定是否环境相关；实际/期望结果决定是否真缺陷；证据加速定位。模板通过强制填写"复现所需的最小信息"，减少"无法复现"的驳回，从而最大化首次复现率。

核心是"复现所需的最小信息"。模板的关键是完整复现三要素（步骤+前置+环境）与证据。

• 严重度与优先级的定义区别
• 两者分开的原因
• 高严重低优先级与低严重高优先级的典型场景

严重度（Severity）衡量缺陷"技术/影响层面"的严重程度，即缺陷对系统功能、数据、安全的破坏程度，由测试人员评估、相对客观；优先级（Priority）衡量缺陷"需被修复的紧迫程度"，即先修哪个，由产品/项目团队结合业务影响、资源与进度决定、相对主观。两者必须分开定义，因为严重度高不一定优先级高，严重度低也可能优先级高。典型场景：高严重低优先级——如"系统在'闰年 2 月 29 日'崩溃"或因极端罕见场景导致的致命错误，严重度高但当前业务极少触发、近期无此场景，故优先级低；低严重高优先级——如"页面按钮文字拼写错误"出现在首页/面向大量用户的营销页，严重度低但影响公信力、上线前必须修复，故优先级高。分开定义使"严重程度"与"修复顺序"解耦，避免仅凭严重度排序导致资源错配。

核心是"严重度=影响程度，优先级=修复顺序"。用"少见却致命"与"常见却不致命"两类场景说明必须分离。

• 缺陷 SLA 与业务影响的映射
• 不同严重度缺陷的响应与修复时限
• SLA 的设定依据与监控

缺陷 SLA（服务级别协议）将缺陷的响应与修复时限与业务影响程度映射，即"缺陷影响业务越严重，SLA 越紧"。映射方式：先按严重度/优先级把缺陷与业务影响关联（如 P0 影响核心业务不可用、P1 影响主要功能、P2 影响次要功能、P3 轻微影响），再分别为不同等级设定响应（首次响应）与修复（解决）时限。典型设定：P0（核心业务中断）——响应 15 分钟、修复 4 小时；P1（主要功能受损）——响应 1 小时、修复 24 小时；P2（次要功能问题）——响应 4 小时、修复 3-5 个工作日；P3（轻微问题）——响应 1 个工作日、修复下个版本。设定依据是业务影响、成本与历史修复能力，并随业务重要度调整。SLA 需有监控与告警（超时升级）、负责人与复盘，防止 SL、SLA 成为空谈。本质是"用业务影响驱动资源投入与时限"。

核心是"SLA 与业务影响成正比"。回答要给出不同等级的响应/修复时限示例并说明设定依据。

• ISO/IEC 25010 八个质量特性的含义
• 各特性的测试关注点
• 质量特性对测试设计的影响

ISO/IEC 25010 定义八个产品质量特性，各自测试关注点不同：功能适合性（Functional Suitability）——关注功能是否完整、正确、适合，测试验证功能正确性、完整性、适合性；性能效率（Performance Efficiency）——关注时间/资源行为，测试验证响应时间、吞吐量、资源占用、容量；兼容性（Compatibility）——关注与其他系统/平台的共存与互操作，测试验证跨平台、跨浏览器、与第三方系统互操作；可用性（Usability）——关注用户有效、高效、满意地使用，测试验证易学性、易用性、可访问性、用户满意度；可靠性（Reliability）——关注系统在故障下不失效，测试验证成熟性、容错性、可恢复性、可用性（uptime）；安全性（Security）——关注保密性、完整性、真实性、可追溯性，测试验证鉴权、授权、加密、防注入、防泄露；可维护性（Maintainability）——关注易修改与易测试，测试关注代码可读性、可扩展性、模块化、可测试性；可移植性（Portability）——关注在不同环境运行，测试验证跨操作系统/设备/容器迁移。八个特性指导测试从"仅功能"扩展到多维度质量验证。

核心是"八个特性各有专属测试关注点"。回答要逐一给出各特性的测试重点，体现测试视角的广度。

• 四种测试文档的定义与核心字段
• 各自的受众与编写时机
• 文档之间的层次关系

四种测试文档的字段、受众与时机不同。测试计划（Test Plan）：核心字段有范围、目标、策略、资源、进度、风险、准入准出标准，受众是项目团队与管理层，编写时机在测试开始前（规划阶段）。测试用例（Test Case）：核心字段有 ID、前置条件、步骤、预期结果、优先级，受众是具体执行测试的人员，编写时机在测试设计阶段（计划定稿后、执行前）。测试规程（Test Procedure）：核心字段有执行步骤、数据准备、环境要求、执行顺序，受众是执行人员，编写时机在用例设计后，把用例组织成可执行的流程/脚本。测试报告（Test Report）：核心字段有执行统计、覆盖率、缺陷分布、风险评估、结论与建议，受众是管理层与发布决策者，编写时机在测试执行结束后（准出/发布前）。层次关系：计划定"做什么"，用例定"具体测什么"，规程定"怎么执行"，报告定"结果如何"，四者覆盖从规划到收尾的完整文档链。

核心是"规划/设计/执行/总结"四类文档的定位。回答要点出字段、受众、时机及层次。

• 测试日志与测试报告的区别
• 测试日志的独特价值（审计、回归分析）
• 两者的性质（过程记录 vs 结论总结）

测试日志（Test Log）是测试执行过程的原始记录，逐条记录每次执行的用例、结果、时间、环境、执行者、异常现象，是"过程性、原始性"数据；测试报告（Test Report）是对测试执行结果的汇总分析，提炼出覆盖统计、缺陷分布、风险评估、结论与建议，是"结论性、总结性"文档。区别在于：日志是过程记录、粒度细、重在事实留痕；报告是结果总结、粒度粗、重在判断决策。测试日志在审计中的独特价值：它是可追溯的原始证据，能证明"测试确实执行过、何时执行、结果如何"，支持质量审计与合规要求；在回归分析中的价值：通过比对多次回归的日志，能识别"用例失效趋势、环境波动、缺陷复现规律"，为测试用例优化与缺陷根因分析提供原始数据。没有日志，报告的分析结论就缺乏可追溯的事实支撑。

核心是"过程记录 vs 结论总结"。日志提供可追溯原始证据，支撑审计与回归的根因分析。

• 测试总结报告的核心内容
• 支撑发布决策的关键信息
• 风险与结论的表达

测试总结报告要支撑发布决策（Go/No-Go），必须包含能回答"是否可发布"的内容：测试范围与执行情况（测了什么、执行了多少、覆盖率）；执行统计（用例通过/失败/阻塞数、通过率）；缺陷分布与状态（按严重度/模块分布、未关闭缺陷数、严重缺陷是否清零）；残留风险与未测项（已知未解决缺陷、风险评估、遗留风险说明）；测试环境与数据（环境是否达标、结论的前提）；结论与建议（明确给出 Go / No-Go / Conditional-Go 及理由）。其中"残留风险与结论建议"是支撑决策的核心——不仅报告测试结果，更要明确"在已知风险下是否可发布"，让管理层能基于事实做知情决策。报告应客观、数据支撑、风险透明，避免"只报通过率"而掩盖风险。

核心是"风险透明+明确结论"。报告要给出执行统计、缺陷分布、残留风险与 Go/No-Go 建议。

• 实际结果与预期结果的撰写规范
• 模糊描述的危害
• 规范化描述对复现与修复的作用

缺陷报告中"实际结果"与"预期结果"的撰写规范：实际结果应客观、具体、可观察地描述实际发生的行为，包括错误信息、现象、数据、复现时的表现，避免主观臆断（如"很慢"应写"响应 5 秒"）；预期结果应依据需求/规格明确描述正确行为，给出可判定的标准（如"应返回成功码 200 且数据正确保存"）。两者应形成清晰差异，便于开发判定缺陷。模糊描述的危害：如"页面显示不对""会卡一下""好像有问题"这类模糊描述，开发无法确认真实行为与期望，无法复现、无法定位，只能反复询问或直接驳回（Cannot Reproduce / Not a Bug），导致缺陷被反复驳回、循环沟通，浪费大量时间。规范写法用"具体现象+量化数据+明确期望"消除歧义，提高缺陷被接受与修复的效率。

核心是"客观具体+可判定"的规范。模糊描述导致无法复现与判定，是缺陷被驳回的主因。

• 质量特性之间的权衡关系
• 提升安全性牺牲的特性
• 如何在测试中验证权衡

质量特性之间存在权衡（Trade-off），提升安全性可能牺牲其他特性：性能效率（加密、鉴权、审计增加开销拖慢响应）、可用性（繁琐的验证流程降低易用性）、兼容性（严格安全策略可能影响跨平台/第三方互操作）、有时还有功能适合性（安全裁剪功能）。例如强密码策略+多因素认证降低可用性，字段级加密增加性能开销。要在测试中验证这种权衡：建立多特性联合的度量与测试方案——在安全测试之外同时做性能基线（在启用/关闭安全措施下对比响应时间与吞吐量）、可用性测试（评估安全流程的易用性、用户完成率）、兼容性测试（验证安全策略下各平台兼容），量化"牺牲程度"；用风险矩阵与需求评审阶段明确权衡的取舍与优先级；通过专项测试（如安全下的压测、安全流程的可用性调查）验证权衡是否可接受。本质是"在测试中把多个质量维度的指标同时度量，用数据支撑权衡决策"。

核心是"权衡需用数据验证"。回答要点出安全性牺牲的特性，并说明联合测试方法。

• 缺陷报告的质量要素
• 可复现步骤、环境、证据的作用
• 质量要素对缺陷处理的影响

缺陷报告的质量要素主要包括可复现步骤、环境与证据。可复现步骤：精确、完整、按顺序的最小操作序列，让开发者能稳定重现问题，是缺陷被接受与修复的前提；环境：操作系统、浏览器/设备、版本、配置、数据、账号等，说明问题发生的上下文，识别环境相关缺陷；证据：日志、截图、录屏、抓包文件等，直观呈现问题现象、加速定位根因。三要素齐备共同决定缺陷报告质量，要素缺失会导致缺陷无法复现、难以定位，降低缺陷被接受与修复的效率。

核心是"步骤、环境、证据"三要素。回答要说明各要素的作用及其对缺陷处理效率的影响。

• 四种缺陷关闭方式的判定标准
• 各自的适用场景
• 争议处理流程

缺陷关闭的常见处理方式及判定标准：按设计（As Designed）——当缺陷行为与需求/规格一致、是设计意图而非错误时，判定为按设计关闭，需有设计依据支持；无法复现（Cannot Reproduce）——当按复现步骤无法重现问题时，判定为无法复现关闭，需测试侧确认复现步骤与环境完整；重复缺陷（Duplicate）——当缺陷与已存在缺陷相同或等价时，判定为重复，关联到原缺陷后合并关闭；延期（Deferred）——当缺陷有效但优先级低、资源不足或影响可接受时，判定为延期，记录在案待后续版本处理。争议处理流程：当测试与开发对关闭方式有分歧（如测试认为可复现、开发认为不可复现）时，应升级到缺陷评审会或测试负责人裁决，由双方提供证据（复现步骤、日志、需求依据）进行复核，必要时共同现场复现，经评审确认后再关闭；对延期需明确责任人与计划时间，避免延期变成永久搁置。规范的处理流程保证关闭决策有依据、可追溯。

核心是"各关闭方式的判定标准+争议升级"。回答要点出四种方式的标准与争议处理机制。

• 各状态的责任人
• 分支状态的处理规范
• 状态流转的职责边界

缺陷生命周期状态流转 New→Open→Fixed→Verified→Closed 各状态的责任人：New 由测试人员（Tester）提交；Open 由测试负责人/缺陷评审确认其有效（由测试侧确认）；Fixed 由开发人员（Developer）修复并标记；Verified 由测试人员（Tester）复测验证修复；Closed 由测试人员确认修复有效后关闭。分支状态的处理规范：Rejected（拒绝）——开发/评审认为按设计、不可复现或为无效缺陷时驳回，测试若不同意可升级争议；Deferred（延期）——缺陷有效但优先级低，由评审决定延期，记录并设定后续处理时间；Rebuilt（重新打开/再建）——复测失败或缺陷再现时，缺陷从 Verified/Fixed 回到 Open 或重新打开，由测试人员触发，重新进入修复循环。处理规范的核心是"每个状态转换有明确责任人、有触发条件、有证据支撑"，保证缺陷闭环可追溯。

核心是"状态-责任人-触发条件"的规范。回答要点出各状态责任人及分支处理规则。

• 测试报告的核心内容
• 各内容如何支撑发布决策
• 报告的表达方式

测试报告的核心内容包括：测试范围（明确测了什么、未测什么、范围边界）；执行统计（用例执行数、通过/失败/阻塞数、通过率、覆盖率）；缺陷分布（按严重度、模块、状态统计，未关闭缺陷情况）；风险评估（残留风险、未测项、已知问题的影响）；发布建议（基于以上给出 Go/No-Go/Conditional-Go 及理由）。要让报告支撑发布决策，需做到：数据化——用统计指标量化执行与缺陷，而非模糊描述；风险透明——如实呈现残留风险与未测项，不掩盖问题；结论明确——给出清晰的发布建议与依据，允许管理层基于充分信息做知情决策；可追溯——报告结论有测试日志与数据支撑。报告的价值在于把"测试的质量信息"转化为"发布决策依据"，让管理层在知道风险的前提下决定是否发布，而非仅凭主观判断。

核心是"数据+风险透明+明确结论"。报告要量化、透明化并给出可追溯的发布建议。

• 各缺陷度量指标的计算与解读
• 单一指标的局限
• 多指标组合解读

常见缺陷度量指标及计算：缺陷密度（Defect Density）——缺陷数/代码规模（如千行），反映单位代码质量，密度过高说明质量问题；缺陷发现率（Defect Detection/Removal Rate）——某阶段发现的缺陷/总缺陷（或阶段检出效率），反映阶段测试有效性；缺陷逃逸率（Defect Escape Rate）——发布后发现的缺陷/总缺陷，衡量测试"漏测"比例，逃逸率高说明测试不足（含发布前未覆盖）；平均修复时长（Mean Time to Repair）——缺陷从发现到关闭的平均时间，反映修复效率与流程顺畅度。要避免被单一指标误导：单一指标各有盲区——缺陷密度高可能因测试充分而非质量差，缺陷发现率低可能因测试覆盖不足，逃逸率低可能因测试覆盖面窄，修复时长短可能因缺陷简单。正确做法是组合多指标交叉解读（如密度+逃逸率+修复时长），结合业务背景与测试投入判断，避免用单一数字做绝对结论。

核心是"多指标交叉解读"。回答要点出各指标计算与解读，并说明单一指标的误导风险。

• 优先级与严重级的矩阵组合
• 修复顺序的确定
• 资源紧张时的取舍原则

缺陷修复顺序由优先级与严重级的矩阵组合决定。典型矩阵：P0（最高优先级，立即修复）通常对应致命/严重缺陷（如核心业务中断、数据丢失）；P1（高优先级）对应严重或主要缺陷（主要功能不可用）；P2（中优先级）对应中等缺陷（次要功能问题、有规避方法）；P3（低优先级）对应轻微缺陷（界面细节、改进项）。修复顺序：先按优先级分层（P0 立即、P1 尽快、P2 计划内、P3 可延后），同优先级内再按严重度排序（严重度高者优先）。开发资源紧张时的取舍原则：优先修复影响用户核心价值与业务阻断的缺陷（高严重度+高优先级），可接受"非关键缺陷延后或降级"；对"高严重但低优先级"（罕见场景）与"低严重但高优先级"（影响面大）需权衡业务影响；用风险矩阵与业务影响评估决定取舍，必要时通过缺陷评审会协商达成一致，保证关键质量底线不被破坏。取舍的本质是"把有限资源投向业务影响最大、风险最高的缺陷"。

核心是"矩阵组合+资源取舍"。回答要点出矩阵与顺序，并说明基于业务影响的取舍原则。

• 严重级的划分（致命/严重/一般/轻微）
• 优先级 P0-P4 的划分
• 严重级与优先级的对应

缺陷严重级（Severity）通常分四级（或更多）：致命（系统崩溃、数据丢失、核心功能不可用）、严重（主要功能受损、无规避方法）、一般（次要功能问题、有规避方法）、轻微（界面细节、文案、改进项）。优先级（Priority）常见 P0-P4 划分：P0（最高，立即修复，阻塞发布）、P1（高，尽快修复，发布前必须）、P2（中，计划内修复，可带病发布）、P3（低，可延后，下个版本）、P4（极低，改进项/建议，视资源而定）。严重级与优先级既有相关又不完全对应：通常严重级高则优先级高，但有例外——高严重低优先级（罕见且影响小的致命缺陷）与低严重高优先级（影响面大的文案/界面问题）。P0-P4 划分用于统一团队的修复优先级语义，保证资源分配与发布决策一致。两者需分开评估，避免混为一谈。

核心是"严重级与优先级有对应也有例外"。回答要点出 P0-P4 划分及两者关系。

• 缺陷回溯会议的目的
• 从缺陷数据识别测试盲区与开发习惯问题
• 改进措施的效果验证

缺陷回溯会议（Defect Retrospective）通过分析缺陷数据驱动流程改进。第一步是数据收集与分类：按缺陷类型、阶段、模块、根因（如需求遗漏、编码错误、测试覆盖不足、环境原因）归类缺陷数据。第二步是识别问题：从缺陷数据中找测试盲区（如某模块缺陷多但此前测试覆盖少、某类缺陷频繁漏测、逃逸缺陷集中在某环节）与开发习惯问题（如某类代码错误反复出现、接口契约频繁不一致、需求澄清不足）。第三步是制定改进措施：针对根因采取行动（增加某类测试、修订检查清单、改进评审、加强契约测试、完善需求澄清）。第四步是验证效果：在后续周期用度量对比（缺陷逃逸率、缺陷密度、同类缺陷重现率）验证改进措施是否有效，若无效则调整。回溯会议的关键是"用数据说话、定位根因、闭环验证"，避免空谈与形式主义，形成持续改进的飞轮。

核心是"数据→根因→措施→验证"的闭环。回答要点出识别盲区/习惯问题与效果验证方法。

• 附件与复现证据的类型与作用
• 证据的提交方式
• 敏感信息脱敏

缺陷报告的附件与复现证据（日志、截图、录屏、抓包文件）应随缺陷提交，以直观呈现问题现象、加速定位。提交方式：日志要提供关键时间窗口的错误堆栈与异常信息，并标注时间点；截图要抓取问题发生瞬间的画面与错误提示；录屏要记录完整复现过程，便于按步骤重现；抓包文件（如 HAR/PCAP）要记录请求/响应数据，辅助定位接口问题。证据应清晰、有标注、与缺陷对应，避免"清屏后补录"或"无关大量日志"。敏感信息脱敏是关键：日志、截图、抓包中可能含用户隐私（账号、手机号、身份证、密码）、支付信息、token、内部 IP 等，提交前必须脱敏（打码、掩码、替换敏感字段），遵循合规要求（如个人信息保护、数据安全），防止敏感信息经缺陷系统泄露。同时控制附件大小与格式，便于管理。规范"证据提交+脱敏"能提升缺陷质量又保障数据安全。

核心是"证据既有效又安全"。回答要点出各证据类型的作用与脱敏的必要性。