一，资质陷阱：机构出示了CMA证书，但能力范围不包括软件，或使用的标准已废止。

查能力附表：必须在证书附件里确定，能力范围确定包含软件性能压力测试效率测量等和验收相关的表述。

核对检测标准：确定其使用的标准是现行有效且适用于验收的，如：

GB/T 25000.51《系统和软件工程 系统和软件质量要求和评价 就绪可用软件产品(RUSP)的质量要求和测试细则》

GB/T 15532《计算机软件测试规范》

项目合同中约定的其他标准

忌用过时标准、机构自编且未经认可的内部规范。

超出能力范围出具的带标报告，法律上视为无效，无法作为验收依据。

二、检测机构和项目的开发方、总集方或有确定的利益关联，可能丧失公正性。

要求机构出具书面的《独立性声明》，承诺和项目开发方、供应方无直接或间接的利益关系（如控股、同一母公司等）。

通过天眼查、企查查等工具，检查检测机构股东、高管是不是和项目中任何一方存在关联。

如果某机构是开发商强烈推荐的，必须加倍警惕，直接独立寻找、比对。

三、测试机构被动接收开发商提供的测试用例，或只用冒烟测试冒充全面验收。

要求机构在理解《项目合同》《需求规格说明书》等文件基础上，独立制定详细的《测试方案》和测试用例，并由建设方、开发方、检测机构三方共同评审、签字确定。

方案中必须确定，测试要100%包括合同约定的重要业务功能、重点性能标准。对非重要功能可协商，但途径不可遗漏。

压力测试不能只测能不能登录，必须把并发用户数、事务响应时间、CPU/内存占用率、吞吐量、事务成功率等标准写入方案。

四、过程不透明，出现缺陷后机构私下通知开发商赶紧改却不留记录直接出具合格报告。

合同中要求机构使用独立的缺陷管理工具（如Jira、禅道等），并给建设方开通只读权限，全程可实时查看缺陷状态。

确定必须经过提交缺陷-开发方修复-机构回归测试的流程，所有缺陷都要有编号、状态、修复记录，体现在报告里。

开发方声称现场调参数就修复了性能问题，必须要求机构在完全相同的环境下重新执行完整性能测试场景，证实修复效果。

五、初期用低价中标，进场后以环境不符合要求、工具需要采购、需求变更为由不断要求增项增费，或无限拖延。

要求报价单列清所有费用-人员人天单价、测试工具使用费、环境搭建费、差旅费、报告费等，要求一口价。

在合同中写明，如果因检测机构失误导致环境不满足条件重新搭建，责任由谁承担。最稳妥是约定由机构协助做一次免费的准入勘验。

合同中必须约定确定的入场、初测、回归测试、报告交付各节点时间，以及延期交付的违约金条款。

任何需求变更导致的测试范围、周期变化，必须通过三方签字确定的变更单生效后，再执行。

六、报告坑点：

坑点1：报告无法律效力。

机构用不带CMA/CNAS标识的所谓咨询报告、内部报告来交差。

验收支付、项目终验步骤，绝大多数要求带有CMA或CNAS标识的盖章报告。签约前就确定要求最后交付物为带CMA/CNAS章的正本报告。

坑点2：报告结构结果含糊。

只写通过，不列具体测试数据、缺陷分布、遗留问题。

合格的验收测试报告必须结构完整，应包含：

测试环境描述（软硬件配置、网络拓扑）

测试根据和工具列表

测试用例执行统计（通过/失败/阻塞数量及比例）

缺陷等级分布和处理结果（遗留的缺陷需逐条说明并给出风险建议）

确定的、有数据支撑的测试结果（如：“在10个并发下，平均事务响应时间为0.8秒，事务成功率100%，满足合同中≤2秒的要求”）

七、转包陷阱：

坑点：签约的是有资质的机构，实际执行测试的团队却是外包人员或临时工，专业能力堪忧。

避坑做法：

在合同中要求写明项目经理及技术人员的姓名，并要求其本人必须全程驻场。

确定约定，重要人员变更必须经过建设方书面同意，且替换人需面试通过。

建设方可以在签约前要求面试其拟派的测试项目经理，考察对业务领域、标准规范、工具掌握的熟练度。

验收检测机构选择自查清单

机构名称和CMA/CNAS证书一致，且能力范围包括软件测试

检测根据标准确定、现行有效，并写入方案

和开发方无任何利益关联，已出具独立性声明

测试方案由三方评审签字，重点标准100%包括

合同已确定报价细节、人员、交付节点和延期违约金

交付物为带有CMA/CNAS标识章的正式检测报告

报告需有完整的测试数据和确定的合格性结果

选择一家靠谱的软件验收检测机构，本质上是在选择过程的透明性和公正性。