今天是礼拜天,分享一段文字避免自己成为高知识低文化的工程师有人尊重你你要清楚他是尊重你的人品还是你的位置。有人喜欢你你要清楚他是喜欢你的才华还是你的财富。有人佩服你你要清楚他是佩服你的能力还是你的权力。有人羡慕你你要清楚他是羡慕你的幸福还是你的运气。人品、才能、幸福是属于你的可以主宰其余都是浮云不足炫耀。测试计划与报告说白了就是硬件测试的剧本和成绩单。我见过太多工程师上来就闷头测结果测到一半发现漏了关键项目或者报告写得像流水账别人根本看不懂。今天我就把这几年的经验掰开揉碎跟你聊聊怎么写一份靠谱的测试计划、记一份规范的测试记录、出一份有说服力的测试报告以及怎么管好缺陷这个烫手山芋。一、测试计划编写模板别让计划变成纸老虎很多公司的测试计划就是走个过场写完就扔抽屉里了。我个人习惯是计划必须能指导执行甚至能用来吵架——比如开发说这个功能不用测你拿出计划说这里明确写了要测。这才是计划的价值。1. 测试计划的核心要素一份合格的测试计划至少包含以下7个部分测试范围明确测什么、不测什么。我曾经吃过亏计划里没写「不测电源纹波」结果开发拿这个来质问为什么没发现纹波超标。所以「不测范围」一定要写清楚。测试环境硬件版本、软件版本、仪器型号、线缆规格。你想想看同样的板子换根USB线结果可能完全不同。测试项清单每个测试项要有编号、名称、测试方法、通过标准。别写「测试功能正常」这种废话要写「输入5V时输出3.3V±2%」。资源与排期谁负责、什么时候测、需要什么仪器。我建议留出20%的缓冲时间因为总会有意外。风险与应对比如「某芯片可能缺货备选方案是...」。交付物测试报告、测试记录、缺陷清单等。审批流程谁签字确认计划生效。2. 我常用的计划模板结构# 测试计划 - [项目名称] v1.0 ## 1. 概述 - 项目背景 - 测试目标 - 测试范围含不测范围 ## 2. 测试环境 - 硬件配置主板版本、外设型号 - 软件版本固件、驱动、测试工具 - 仪器清单示波器型号、探头规格 ## 3. 测试项清单 | 编号 | 测试项 | 测试方法 | 通过标准 | 优先级 | 负责人 | |------|--------|----------|----------|--------|--------| | TC01 | 上电时序 | 用示波器测量各电源轨 | 各电源上升时间10ms | P0 | 张三 | ## 4. 测试排期 - 第一轮3月1日-3月5日功能测试 - 第二轮3月8日-3月12日性能测试 - 回归测试3月15日-3月16日 ## 5. 风险与应对 - 风险1测试样机数量不足 → 提前协调备件 - 风险2某测试项依赖新固件 → 与开发对齐时间 ## 6. 交付物与审批 - 交付物测试报告、缺陷清单 - 审批人项目经理、硬件主管我的小技巧计划写完后找开发同事花15分钟过一遍。不是为了走形式而是让他们知道你要测什么避免后续扯皮。测试记录规范好记性不如烂笔头测试记录是测试报告的基础也是追溯问题的唯一凭证。我见过最离谱的记录是「测试通过」四个字连日期都没有。这种记录在法庭上就是废纸——嗯没错有些产品出问题是要上法庭的。1. 记录的基本要求可追溯性每条记录必须包含测试时间、测试人、测试环境、测试结果。最好加上测试时的环境温度、湿度。原始数据不要只写「通过/不通过」要保留原始数据。比如测电压要记录实际测到的值而不是只写「3.3V正常」。异常记录任何异常现象都要记录哪怕你觉得是偶然。我曾经忽略过一次偶发的通信失败结果量产时批量出现。签名与日期纸质记录要手写签名电子记录要有电子签名。这是合规要求。2. 记录模板示例测试记录表 - [项目名称] 测试日期2024-03-01 测试人李四 环境温度25℃ 湿度45%RH 硬件版本PCB v2.1 固件版本FW v1.0.3 仪器示波器 Tektronix MDO3104校准有效期至2024-06 | 测试项编号 | 测试描述 | 预期结果 | 实际结果 | 结论 | 备注 | |------------|----------|----------|----------|------|------| | TC01 | 上电时序 | VCC上升10ms | VCC上升8.5ms | 通过 | 波形见附件 | | TC02 | 复位信号 | 低电平持续100ms | 低电平持续95ms | 不通过 | 需调整RC参数 |避坑指南我曾经因为测试记录里没写「探头衰减比」导致后续分析时数据对不上。所以记录仪器设置时一定要写清楚探头倍率、耦合方式、带宽限制等细节。三、测试报告撰写要点让数据说话测试报告是给谁看的项目经理、开发团队、客户甚至可能给老板看。所以报告要兼顾「专业」和「易懂」。我写报告的原则是让一个不懂技术的人也能看懂结论让懂技术的人能找到细节。1. 报告的结构摘要用3-5句话概括测试结论。比如「本次测试共执行50个测试项通过48项2项不通过。不通过项已提交缺陷预计下个版本修复。」测试范围与环境简要说明测了什么、用什么测的。不要复制计划里的全部内容但要保证信息完整。测试结果汇总用表格展示各模块的通过率。我习惯用颜色标记绿色通过、黄色警告、红色不通过。详细结果每个测试项的详细数据、波形截图、分析说明。不通过的项要重点分析原因。缺陷清单列出所有未关闭的缺陷包括严重等级、状态、责任人。结论与建议明确给出「是否通过测试」的结论以及后续建议。比如「建议修复缺陷后重新进行回归测试」。2. 报告的常见问题我审过上百份测试报告发现几个通病只有结论没有数据写「测试通过」却不给原始数据这跟没测有什么区别波形图没有标注贴一张波形图不标时间轴、电压轴、测量值别人根本看不懂。缺陷描述模糊写「功能异常」却不写具体现象、复现步骤、环境条件。没有版本信息报告里不写硬件版本、固件版本后续根本没法追溯。我的经验写报告时把自己当成一个「侦探」。每个结论都要有证据支撑每个异常都要有分析过程。这样即使半年后有人翻出这份报告也能看懂当时发生了什么。四、缺陷管理流程从发现到关闭的闭环缺陷管理是测试中最容易出问题的环节。很多团队的问题不是发现不了缺陷而是缺陷「烂」在系统里没人管。我见过一个缺陷挂了半年最后产品都上市了还没修。1. 缺陷的生命周期一个标准的缺陷生命周期包括提交测试人员发现缺陷填写缺陷报告。确认开发人员确认缺陷是否真实存在。分配项目经理将缺陷分配给对应的开发人员。修复开发人员修复缺陷。验证测试人员验证修复是否有效。关闭验证通过后关闭缺陷。这里有个关键点只有测试人员才能关闭缺陷。开发不能自己修完就关掉必须经过测试验证。我曾经遇到过开发说「我改好了你测一下」结果我测完发现根本没改好——他改的是另一个分支。2. 缺陷报告的要素一份好的缺陷报告应该让开发拿到后就能复现。我建议包含以下内容标题简洁明了比如「上电时VCC电压跌落至2.8V持续5ms」。严重等级P0致命、P1严重、P2一般、P3轻微。优先级紧急、高、中、低。环境信息硬件版本、固件版本、测试条件。复现步骤详细描述如何复现包括前置条件、操作步骤、预期结果、实际结果。附件波形截图、日志文件、照片等。发现人、发现时间方便追溯。3. 缺陷管理的常见坑我曾经踩过的坑缺陷描述太简单写「电压异常」四个字开发根本不知道从何查起。后来我要求必须写「在XX条件下用XX仪器测量XX点测得XX值预期XX值」。不区分严重等级所有缺陷都标P0结果开发不知道先修哪个。我建议P0是「导致系统崩溃或安全风险」P1是「功能不可用」P2是「功能异常但有替代方案」P3是「界面或体验问题」。没有回归测试开发修完缺陷后只验证了那个缺陷本身没有做回归测试。结果修了一个bug引出三个新bug。所以缺陷修复后必须做一轮回归测试。4. 缺陷管理工具推荐小团队用Excel也能管但建议用专业工具Jira功能强大适合中大型团队。禅道国产工具适合敏捷开发。GitLab Issues如果代码托管在GitLab可以直接用。Excel 共享文件夹小团队临时方案但要注意版本管理。我的建议不管用什么工具关键是流程要跑通。我见过用Jira但流程形同虚设的团队也见过用Excel但管理得井井有条的团队。工具只是手段流程和执行力才是核心。总结测试计划、测试记录、测试报告、缺陷管理这四个环节构成了硬件测试的完整闭环。计划让你知道测什么记录让你知道怎么测的报告让你知道测的结果缺陷管理让你知道问题怎么解决。少了任何一个环节测试都是不完整的。最后说一句别把测试当成找茬的工作。我们的目标是帮团队交付一个可靠的产品。一份好的测试计划能帮开发少走弯路一份清晰的缺陷报告能帮开发快速定位问题。这才是测试工程师的价值所在。← 上一章