软件系统测试记录模板

软件系统测试记录模板一、模板设计定位与适用范围测试记录不是事后补写的流水账，而是缺陷追溯、回归判断、上线决策与责任认定的唯一原始凭证。本模板按「可审计、可复现、可统计」三个目标设计：任何一条记录，三个月后由未参与测试的人员依据记录内容，应能在测试环境中复现该次执行结果。适用于功能测试、接口测试、回归测试及UAT（用户验收测试）的记录管理；性能测试、安全测试因工具输出与判定标准差异较大，参照本模板附录C的专用表单执行。使用规则：•测试执行人员须在每轮测试当日24:00前完成记录填写，测试负责人次日10:00前完成当日记录审核并签字（电子签或系统确认均可）。•记录一经审核，修改须经测试负责人书面批准并保留修改痕迹（系统操作日志或版本号递增），严禁直接覆盖原记录。•全部记录按「项目编号-轮次-日期」规则归档，项目结项后保存期不少于2年。二、测试记录主表主表是每次测试执行的最小记录单元，一轮测试包含若干条主表记录。填写粒度为：一个用例在一个测试环境的一次执行，对应一条记录。2.1表头信息（每轮测试填写一次）项目填写内容填写要求项目编号xxx-2025-001与立项编号一致项目名称xxx客户管理系统二期全称，不用简称测试轮次第2轮回归首轮功能/第N轮回归/UAT测试环境TEST-ENV-02填环境标识号，不写「测试环境」环境版本号v2.3.1-rc2与部署记录中的构建号一致测试负责人张某某姓名或工号测试起止时间2025-06-10至2025-06-12精确到日参测人员张某某、李某某、王某某与用例分配表对应测试依据《xxx项目测试计划》v1.2、《需求规格说明书》v2.0列出全部依据文档及版本号2.2用例执行记录（每用例一条）字段填写要求示例用例编号与用例库编号一致，不得自编TC-ORD-013用例名称摘要即可，与用例库一致提交订单-库存不足拦截前置条件实际准备情况，与用例库不一致须注明账号U001已登录，SKU1002库存为0（用例库原定库存5，现场调整）执行步骤仅在与用例库不一致时填写实际差异；一致时填「按用例库执行」按用例库执行预期结果从用例库带出，不得改写返回4001错误码，页面提示「库存不足」实际结果客观描述，含关键返回值、页面状态，禁止只写「不符合预期」返回500错误码，响应体message为null，页面空白3秒后弹「系统异常」执行结果通过/失败/阻塞/未执行失败关联缺陷编号失败、阻塞必填，无缺陷单的失败记录视为无效记录BUG-2025-0117测试数据使用的账号、数据集编号测试账号U001，数据集DS-2025-06执行人/执行时间精确到分钟李某某2025-06-1114:32证据编号截图、日志、录屏的存档编号EV-0611-0322.3执行结果判定标准四种状态的判定口径须全组统一，防止「同一现象有人记失败、有人记阻塞」：•通过：实际结果与预期结果完全一致，含边界值、响应时间在用例约定阈值内。•失败：前置条件满足、步骤可完整执行、实际结果与预期不符。此状态必须提交缺陷单。•阻塞：因前置条件无法满足或依赖功能失败，用例无法开始执行。阻塞须注明阻塞源（缺陷编号或环境问题编号），阻塞源解决后1个工作日内补测。•未执行：本轮未安排或因人员、时间原因未执行，须在轮次总结中说明原因及补测安排。严禁将「偶现失败」记为通过。偶现现象按失败处理并提交缺陷单，缺陷单中注明「偶现，已复现N/M次」；无法复现的，保留证据编号并标记「待复现」，3个工作日内组织专项复现，仍不能复现的由测试负责人决定是否降级为观察项并书面记录理由。三、缺陷记录表缺陷记录是主表失败记录的延伸，二者通过缺陷编号一一对应。记录缺陷时须完成归因初判，否则开发与测试之间会陷入「无法复现」的往返消耗。3.1缺陷记录字段字段填写要求示例缺陷编号系统自动生成，不得手工改动BUG-2025-0117标题「模块+现象」结构，20字内订单提交-库存不足时返回500而非4001严重等级按表3.2判定一般优先级紧急/高/中/低高复现步骤1、2、3分步列出，任何人照做可复现1.登录U001；2.向SKU1002下单（库存0）；3.点击提交复现概率必现/偶现（已复现N/M次）必现初步归因测试方基于现象的判断，供开发参考，不作结论疑似异常处理分支未捕获业务异常提交人/提交时间精确到分钟李某某2025-06-1114:45处理状态新建/已确认/修复中/待回归/已关闭/驳回待回归回归结果回归用例编号、执行人、结论TC-ORD-013，李某某，通过3.2严重等级判定标准等级判定标准典型示例响应要求致命核心业务流程中断、数据丢失或损坏、资金计算错误、系统崩溃支付成功但订单状态未更新开发4小时内响应，当日修复，修复前冻结相关模块回归严重主要功能未实现或错误，但有替代路径；次要功能整体失效退货申请无法提交，但可线下登记1个工作日内响应，2个工作日内修复一般次要功能缺陷、错误提示不准确、边界条件处理不当库存不足提示文案错误3个工作日内响应轻微界面瑕疵、错别字、对齐问题按钮文字换行下轮迭代统一处理3.3缺陷争议处理测试与开发对缺陷定性不一致时（典型如「需求未明确，不算缺陷」），按下述流程闭环，严禁口头争拗后私自关闭缺陷单：1.提交方在缺陷单中引用需求文档具体条目；需求确未覆盖的，转入需求澄清流程，由测试负责人在1个工作日内提交产品经理确认。2.产品经理2个工作日内给出书面结论：属缺陷的按原流程处理；属新需求的转需求池并编号；属需求变更的更新需求文档并补充用例。3.结论记录在缺陷单「处理状态」备注中，无论哪种结论，缺陷单均不得删除，驳回状态保留完整。四、测试轮次总结记录轮次总结是上线评审的直接输入，核心价值在于用数据回答「能否进入下一阶段」，而非罗列现象。每轮测试结束后1个工作日内，由测试负责人完成并提交。4.1轮次度量数据指标计算口径本轮示例值阈值要求用例执行率已执行用例数/计划用例数96.4%（539/559）≥98%，未达标须逐条说明原因首轮通过率首次执行通过数/已执行数89.2%回归轮≥97%方可申请转UAT缺陷密度有效缺陷数/千行代码（据开发提测量）2.1与历史基线对比，超基线50%触发质量专项分析致命/严重缺陷占比（致命+严重）/有效缺陷总数8.5%超15%须评审是否继续测试或回退版本缺陷修复率已关闭缺陷/有效缺陷总数94.3%出口准则要求遗留致命、严重缺陷为0用例阻塞数状态为阻塞的用例数7阻塞超5%须评估环境与依赖方问题4.2遗留缺陷与风险评估每条遗留缺陷须单列说明，格式为：缺陷编号、等级、遗留理由（如「影响面仅限后台配置页」「复现条件为并发500以上，生产预期不触发」）、规避措施、责任人与关闭时限。评估结论分三档：•具备出口条件：执行率、通过率、修复率均达标，遗留缺陷无致命、严重级，可提交上线评审。•有条件出口：遗留严重级缺陷≤2个且均有书面规避措施并经产品、开发、测试三方会签，须在上线评审中专项表决。•不具备出口条件：任一核心指标未达标或存在未修复致命缺陷，回退开发修复，安排下一轮测试，并给出下一轮计划时间与范围。五、UAT用户验收测试记录UAT记录的法律与商务属性强于技术属性，是验收付款与责任划分的依据，填写要求比内部测试更严格：•由用户方指定的验收人员执行操作，测试方人员只提供环境支持与记录协助，严禁代为操作后在记录上签署用户姓名。•每条验收项须有用户方签署意见：通过/不通过/有条件通过，签署方式为签字或系统电子确认，日期精确到日。•「有条件通过」必须同时列明条件清单（问题编号、责任人、完成时限），条件全部闭环并经原签署人复核后，方可转为「通过」。•验收会议须形成纪要，含参会人员签到表、结论及待办事项，纪要在会后1个工作日内发给全部干系人。六、归档与模板使用检查表6.1归档清单归档编号规则：项目编号-TEST-轮次-日期，电子档与纸质档（需签字表单）同步归档，由测试负责人在项目结项后5个工作日内移交配置管理员。6.2记录质量检查表（测试负责人每轮审核用，逐项打勾）•[]表头信息完整，环境版本号与部署记录一致•[]每条「失败」记录均有对应缺陷编号•[]每条「阻塞」记录均注明阻塞源及补测计划•[]每条记录均有证据编号且证据可打开、与描述一致•[]实际结果为客观描述，无「异常」「不正常」等含糊表述•[]缺陷严重等级按3.2标准判定，无随意升级或降级•[]轮次总结数据与主表逐条核算一致•[]遗留缺陷均有遗留理由、规避措施、责任人、时限四要素七、附录A空白主表模板（可直接复制使用）【表头】

项目编号：项目名称：

测试轮次：测试环境：

环境版本号：测试负责人：

测试起止时间：参测人员：

测试依据：

【用例执行记录】

用例编号：

用例名称：

前置条件：

执行步骤：

预期结果：

实际结果：

执行结果（通过/失败/阻塞/未执行）：

关联缺陷编号：

测试数据：

执行人/执行时间：

证据编号：

【审核】

测试负责人签字：审核日期：八、附录B缺陷单空白模板缺陷编号：

标题：

严重等级（致命/严重/一般/轻微）：

优先级（紧急/高/中/低）：

复现步骤：

1.

2.

3.

复现概率：

初步归因：

提交人/提交时间：

处理状态：

回归结果（回归用例编号/执行人/结论）：九