确认测试需要提交哪些文档？第三方检测机构如何开展确认测试？

确认测试

很多企业到了确认测试这一步就卡住了——不知道到底要交啥材料？如何配合第三方机构？也搞不清机构那边到底怎么操作的。两头都糊里糊涂的，周期一拖再拖，项目验收卡在这过不去。那我们今天把这事儿掰开了说。

一、确认测试跟普通测试有啥不一样？

先搞清楚一个前提。确认测试不是随便测测就完了，它的核心目的就一个：证明这个软件确实满足了需求规格说明书里写的那些东西。说明白一点就是开发说"我做完了"，甲方说"我不信"。那就找个第三方来，拿着需求文档一条一条对，看你说的和你做的是不是一回事。所以软件确认测试对文档的要求特别高。如果你需求写得模糊，测试就没法执行，版本号对不上，报告直接打回来。

二、需要提交哪些文档？

这块很多企业栽跟头，不是东西太多，是东西不对。

（一）如果是必须交的，缺一个都不行。那么哪些是必须交的呢？

1.需求规格说明书，这是确认测试的命根子。测试用例全从这上面来，功能点怎么定义的、性能指标是多少、业务逻辑怎么走的，全都得写清楚。你拿一份模棱两可的文档过去，测试人员没法干活，只能打回来让你重写。

2.软件本身。安装包、可访问的URL、小程序代码包，什么形式都行，但版本号必须跟需求文档里写的完全一致。我见过太多次了，需求写的V2.1，交过去的包是V2.3，直接被退回来。

3.用户操作手册或者使用说明。测试人员不是你公司的人，他得知道这软件怎么用、每个功能在哪、操作流程是啥。你不给说明，他就只能瞎猜，测出来的东西你也不敢认。

4.软著证书也得带上。证明这软件是你的，报告上的名称、版本号要跟软著一个字不差。

5.测试委托函，找机构要模板填就行，写清楚你测这个是干嘛用的——验收？退税？高企认定？目的不同，测试侧重点也不一样。

（二）看情况要交的。

如果系统比较复杂，还得补架构设计文档、数据库设计、接口文档这些。特别是做性能测试的时候，没有这些东西，测试环境都搭不起来。

还有测试账号，不同角色的都得有。管理员一个、普通用户一个、审批人员一个，角色不全，权限相关的测试就做不了。

三、第三方机构到底怎么开展确认测试？

很多人以为确认测试就是把软件装上跑一遍，没那么简单。

第一步，先评审需求文档。 机构拿到材料之后，不是上来就测，而是先过一遍需求。看功能点覆盖全不全、描述清不清晰、有没有矛盾的地方。这一步很多企业跳过了，结果测到一半发现需求本身就有问题，白干。

第二步，编写测试用例。 根据需求文档，一条一条拆成可执行的测试用例。每个功能点对应几条用例、预期结果是什么、怎么判断通过还是失败，全得写清楚。这份用例一般会发给委托方确认，没问题才开始执行。

第三步，执行测试。 按照用例一条一条跑。功能对不对、数据准不准、流程通不通，全部记录下来。发现问题就记缺陷，截图、日志、复现步骤全留着。

第四步，出具报告。 测试完了，把结果汇总成报告。哪些通过了、哪些没过、没过的问题严重程度怎么样，全部写明。报告最后盖CMA和CNAS的章，这才算有效。

确认测试的周期，很大程度上取决于你交的材料质量。材料齐、需求清，7到10个工作日就能出报告。材料有问题，光补材料就得拖好几天，周期直接翻倍。所以别等到要交报告了才着急备材料，项目做到一半就该开始整理了。需求文档、操作手册、软著证书，这些东西平时就该备好，关键时刻才不抓瞎。说到底，确认测试不难，难的是你自己那边别掉链子。只要我们得材料给到位，测试机构就可以快起来。

标签：确认测试、确认测试报告