软件测试报告要让读者知道：针对哪个版本、在什么环境下测了哪些内容，发现了什么，哪些问题仍未解决。用例表、自动化结果和缺陷清单都是材料，但单独一张“通过率”截图很难说明这些问题。
先把本轮材料对应到同一版本和测试范围，再写结果解释。报告采用什么栏目，可以依项目或课程要求调整。
先连接用例、执行和缺陷
用例说明准备检查什么；执行记录说明是否真的测过；缺陷记录说明发现的问题怎样处理。三者需要能够互相找到，不能只保留最后一张汇总表。
整理时区分以下状态：
| 材料中的状态 | 报告中需要说明的内容 |
|---|---|
| 本次执行通过 | 对应版本、环境及检查条件 |
| 执行失败或超时 | 观察结果、证据及已确认的原因范围 |
| 跳过或未执行 | 没有获得本轮结果，必要时说明原因 |
| 重试后通过 | 前次失败与重试情况，是否仍需调查 |
| 缺陷已修改 | 是否完成重测，不能自动当作已验证解决 |
这些区分可以直接从实际工具报告中提取。例如Playwright官方报告说明区分通过、失败、超时、跳过和重试后通过，并提供HTML报告。使用其他工具或手工测试时，也应按自己的真实记录整理，不必为了写报告更换测试系统。
统计口径决定数字能表达什么
同一用例在多个浏览器或环境执行，可能产生多条结果。写通过率之前，先明确分母是用例数、执行次数还是其他范围，不能将重试次数算成新增覆盖，再把未执行部分隐去。
结论也需要留在实际覆盖范围内。功能测试通过，不自动说明性能、兼容性和恢复能力都已经验证；某项失败若尚不能区分产品问题与测试环境问题，应保留这个未决状态。
报告正文可以先说明范围与主要发现，再列关键未决问题和建议动作。机器日志作为核对依据保留，正文不必粘贴全部输出；读者应能从一个结论找到相应执行记录和缺陷。
已确认的结果说明可以做表达处理
结论和统计核定后，如果文字重复、生硬或有降低AI痕迹的需要，可以用PaperMomo处理作者的说明部分。进入文本工作台，先选定处理范围并查看预计积分；需要Word流程时，查看功能说明。
错误码、日志片段、用例标识、缺陷状态和数字继续以原始材料为准。尤其检查“已修改，待重测”是否被改成“问题已解决”，以及“本轮范围内未发现”是否被扩大成“系统不存在”。
报告交付前打开其引用的结果文件，检查附件或链接能否读取。能追溯到实际执行的结论，才方便接手人判断下一步应该修复、补测还是接受当前结果。