做软件确认测试需要准备哪些材料？流程复不复杂？

经常有客户打电话过来问："我们要做确认测试，到底要准备啥材料？流程是不是很复杂？要搞很久吗？"说实话，这个问题被问的频率真的很高，尤其是第一次做确认测试的客户，普遍会觉得"是不是要准备一大堆东西，搞半天才能开始"。其实没那么夸张，今天就把需要准备的材料和整个流程给大家捋清楚，看完你就知道，提前把东西备齐的话，整个过程其实很顺畅。

确认测试

一、确认测试到底是测什么？

很多人把确认测试和验收测试搞混，其实两个东西目的不一样。确认测试的核心就一句话：验证你的软件是不是和需求规格说明书里写的一模一样。它不是在测"软件好不好用"，而是在测"软件是不是合同上写的那个软件"，需求文档里写的每一个功能点都实现了吗？合同里承诺的技术指标都达到了吗？业务流程和需求描述一致吗？

所以确认测试的适用范围很广：项目结题、科技成果鉴定、创新基金申报、自主创新产品认定、需求方对开发方的验收，都可以用确认测试报告来证明。

二、需要准备哪些材料？

第一类：必须准备的核心材料，少了开不了工

• 软件需求规格说明书（SRS）：这个是确认测试的"圣经"，所有的测试用例都是对着它来设计的，没有它测试机构没法干活。如果你们项目有需求变更，一定要把最终版的、双方确认过的需求文档给过来，别给个半年前的旧版本。

• 软件安装包或部署包：要测试的当然是你的软件本身，给过来能正常安装运行的版本就行，注意版本号要和需求文档对应上，别给个开发环境的包过来。

• 产品功能列表：把你软件有哪些功能模块、每个模块下面有哪些功能点，列一个清单出来，方便测试机构快速了解你的系统全貌，也能核对测试覆盖是不是完整。

• 用户手册/操作说明：最终用户拿到手的那个版本就行，测试机构会对照手册验证操作流程是不是和文档描述一致。

• 软件测试委托书：这个一般测试机构会提供模板，你填好盖个章就行，主要是明确测试的范围、依据、交付要求这些基本信息。

第二类：有的话更好，能加快进度、减少返工

• 设计文档（概要设计、详细设计、数据库设计）：有的话测试机构能更快理解你的系统架构，测试效率会高很多，尤其是复杂的系统，没得设计文档的话，测试人员光搞清楚系统逻辑就要多花好几天。

• 接口文档：如果你的系统和其他系统有对接，把接口文档给过来，方便测试机构验证接口调用是不是正常。

• 测试环境要求说明：你的软件运行需要什么配置，操作系统版本、数据库版本、中间件、浏览器要求这些，提前说清楚，测试机构搭环境的时候就不用反复问你。

• 测试账号和权限：管理员账号、普通用户账号这些要准备好，测试的时候需要用到不同权限的角色来验证权限控制是不是正确。

• 历史测试记录：如果你们内部已经做过一轮测试了，把内部的测试报告、bug清单给过来，测试机构可以针对性地重点验证，避免重复劳动。

说句实在话，很多项目测试延期，不是测试机构慢，而是客户这边材料没备齐，今天缺个需求文档，明天缺个安装包，后天说需求又变了要重新测，来回折腾反而更费时间。

三、流程复不复杂？一共就这几步，搞清楚就不慌

测试流程

第一步：提交资料，签合同

你把上面说的材料准备好提交给测试机构，双方签保密协议和测试服务合同，明确测试范围、依据、交付时间这些。这一步很简单，材料齐的话一两天就能搞定。

第二步：测试机构确认资料，分析需求

测试机构收到材料之后，会先核查你的软件是不是具备可测试条件，版本对不对、文档全不全、环境要求明不明确。如果发现问题会第一时间反馈给你补材料，没问题的话就开始分析需求，制定测试计划。

第三步：搭建测试环境，设计测试用例

测试机构按照你提供的环境要求搭建测试环境，然后对照需求规格说明书设计测试用例，每一条需求都要有对应的测试用例，正向的测正常操作，逆向的测异常场景，确保覆盖完整。

第四步：执行测试，记录结果

测试人员按照测试用例逐条执行，真实记录每个用例的执行结果。发现和需求不一致的地方，会提交缺陷报告给你，你这边安排开发修复。

第五步：回归测试

你这边修复完缺陷之后，测试机构会对修复的内容做回归测试，确认问题确实修好了，同时验证修复没有引入新的问题。

第六步：出具测试报告

所有测试都通过之后，测试机构出具正式的确认测试报告，由授权签字人签字批准，盖CNAS认可标识，交付给你。

整个流程下来，如果你的材料准备充分、需求明确、bug修复及时，柯信检测一般3-7天就能出报告；如果系统比较复杂、需求变更频繁、bug修得慢，周期会相应拉长。

我们出具的确认测试报告具备CNAS认可资质，覆盖项目验收、科技成果鉴定、创新基金申报、产品推广等所有场景，报告全国通用。如果你不确定自己的项目需要准备哪些材料，或者想评估下测试周期和费用，把项目情况发给我们，我们免费帮你梳理材料清单，出方案和报价，保证不花冤枉钱。

标签：确认测试、测试流程