功能测试报告：功能对不对，报告说了算

“功能有没有”：是否实现需求中的所有功能点（如“电商系统需支持‘一键退款’”）；

“功能对不对”：功能逻辑是否符合业务规则（如“退款金额计算与订单实付一致”）；

“功能稳不稳”：边界场景（如“输入非法字符”）、异常操作（如“重复提交”）下是否容错。

范围覆盖：列出被测功能模块（如“投保管理、理赔核算、数据统计”）、子功能（如“农户信息录入、保费自动计算”），确保“无遗漏”；

用例设计：按“正常流程+异常场景”设计用例（如“正常投保：填写信息→提交→审核通过”“异常投保：重复提交同一保单→系统拦截并提示”），附“预期结果”（如“拦截成功，提示‘请勿重复投保’”）。

作用：让测试“有章可循”，避免“随意测、漏测”。

通过率：统计“用例总数、通过数、失败数”（如“100条用例，95条通过，5条失败”），直接反映功能实现度；

问题清单：按“高/中/低”分级记录失败用例，含“问题描述（如‘理赔模块未校验灾害等级’）、复现步骤、影响（如‘错误定损致理赔金多发’）、责任方（开发/需求）”。

案例：某政务系统报告中“农户信息录入”模块12条用例，3条失败（因“身份证号校验规则与需求不符”），明确“功能不对”的具体表现。

综合结论：基于测试结果，判定“功能是否符合需求”（如“核心功能（投保/理赔）实现率95%，符合验收标准；非核心功能（数据导出）存在3处逻辑缺陷，需修复”）；

优化建议：针对问题提出方案（如“补充身份证号校验规则”“增加重复提交拦截机制”）。

功能覆盖：需求中“5种灾害定损公式”实现4种，缺失“冰雹灾害公式”（未实现）；

逻辑错误：3种公式参数取值错误（如“暴雨灾害按‘降雨量’而非‘积水深度’计算”）；

通过率：20条用例，12条失败（未实现+逻辑错误）。

结果：开发方按报告修复缺失公式、修正参数，复测通过后用户认可，项目顺利验收。