理解验收方法做好软件验收管理

第一篇：理解验收方法做好软件验收管理

帮助用户实现IT投资价值最大化

理解验收方法做好软件验收管理

软件验收管理工作是软件质量保障交付的最后一个阶段，也是软件正式投入使用的最后一道防火墙，软件验收管理工作是软件质量保障的重要环节。

山东省软件评测中心韩庆良主任曾总结：软件项目验收管理是对软件项目成果的检验和确认，也是对软件项目范围的再确认，做好软件验收管理应从正确理解软件验收方法开始，软件验收应是一个过程的概念，包括验收前的系统测试、数据移植、系统上线和正式验收四个阶段。

1.软件系统测试

系统测试是对系统进行全面的测试，应在测试环境中进行，以确保系统的功能和技术设计满足企业的业务需求，并能正常运行。系统测试阶段应包括以下主要流程:

(1)制订测试计划，包括编制测试用例，建立测试环境。

(2)测试：在测试环境中，项目组根据需要，对系统依次进行单元测试、集成测试、压力测试和用户接受测试，记录测试结果并由相关测试人签字确认，编制相应的测试报告。对于未通过测试的内容，项目组应查找失败的原因，并修改相应程序或设置，重新进行测试。除了进行充分的系统功能测试，测试应包含与内部控制相关的测试内容，如系统认证和授权、交易完整性及数据真实、完整性的有关功能。

(3)提交测试报告、用户确认签字。项目组撰写测试报告，将测试报告提交给各相关用户，用户应在测试报告上签字确认。

2.数据移植

新系统上线时如需要将原始数据移植到新系统，则应完成以下主要工作: 地址：济南市高新区齐鲁软件园D座4层 电话：*** 张凯丽

邮箱：zhangkl@keylab.net 网址：http://www.sdstc.net/

帮助用户实现IT投资价值最大化

(1)制订数据移植/转换计划。除了要定义数据收集的格式、范围、进度外，还要考虑系统接口的影响，并建立了数据移植完整性和准确性测试方法以及意外事件处理程序。

(2)数据收集。如果项目实施涉及到数据收集，应由数据收集小组根据数据收集格式，对数据进行收集，数据收集小组在收集数据时应培训业务部门的数据提供人员，以确保数据提供人员了解和掌握对数据收集的各项规定和要求。

(3)数据移植前的测试。在测试环境中对数据移植方法进行测试，书面记录测试结果，解决测试中发现的问题，进行问题记录并归档。

(4)数据导入并核查结果

项目组成员将数据导入系统，并在导入后按照事先制定的数据移植完整性和准确性测试方法对系统中的数据做进一步的核查，确保导入数据的质量。如有意外，按照事先制定的意外事件处理程序处理，并留下记录。数据移植完成之后，用户应对数据移植结果签字确认。

(5)数据移植后要进行适当时间的试运行，确认数据移植的真实性和完整性。试运行时间视具体系统的规模、影响程度而定。对影响较大的系统，至少应试运行三个完整的月结周期。

3.系统上线

系统上线阶段应包括以下的主要流程:

(1)上线前准备工作：在上线前，软件开发方应制定系统上线计划，包括上线检查清单、上线支持人员、退回机制等，并提交《上线申请表》。系统上线计划和《上线申请表》应经过信息技术部门和业务部门管理层的正式批准，并通知各相关部门。

地址：济南市高新区齐鲁软件园D座4层 电话：*** 张凯丽

邮箱：zhangkl@keylab.net 网址：http://www.sdstc.net/

帮助用户实现IT投资价值最大化

(2)系统上线：所有的上线准备工作做好之后，由软件监督人员确认上线系统版本正确性后，与用户确认系统上线时间，下达上线指令。系统上线操作人员将最后版本的系统程序移植到生产环境。

4.正式验收

正式验收前，软件开发方应向信息技术管理部门提交软件开发过程中各阶段性文档，包括需求分析说明书、概要设计说明书、详细设计说明书、数据库设计说明书、源程序代码、可供安装使用的系统安装程序、系统管理员手册、用户使用手册、测试计划、测试报告、用户报告、数据移植计划及报告、系统上线计划及报告、用户意见书、验收申请等。

信息技术管理部门接到验收申请后，组织专家对项目进行初审。初审通过后，组织管理层领导、业务管理人员和信息技术专家成立项目验收委员会，负责对软件项目进行正式验收。

软件监督应根据软件开发方在整个软件开发过程中的表现，向验收委员会提出全面的软件监督报告，并根据开题设计书、软件开发合同以及《需求分析说明书》，制定验收标准，提交验收委员会。信息技术管理部门组织由验收委员会、软件监督、软件开发方参加的项目验收会，软件开发方以项目汇报、现场应用演示等方式汇报项目完成情况，验收委员会根据验收标准对项目进行评审，形成最终验收意见。

以上软件验收方法是我们山东省软件评测中心多年的经验总结，我们秉承“帮助用户实现IT投资价值最大化”的企业理念，努力将科研成果转化为社会服务，欢迎社会各界专家学者批评指正。

地址：济南市高新区齐鲁软件园D座4层 电话：*** 张凯丽

邮箱：zhangkl@keylab.net 网址：http://www.sdstc.net/

第二篇：如何做好软件项目的验收管理？

如何做好软件项目的验收管理？

项目验收，也称范围核实或移交（Cutover）。它是核查项目计划规定范围内各项工作或活动是否已经全部完成，可交付成果是否令人满意，并将核查结果记录在验收文件中的一系列活动。怎样做好软件项目验收管理工作是本文的重点，根据多年验收管理经验，总结了做好软件项目验收管理的一些方法，希望能给大家带来帮助。

1、在软件项目实施过程中注重里程碑的确定，制定阶段性目标

如果要做好一个软件项目，完成项目的验收条件，主要还是以业务是否可用作为衡量的。不是一定得实现所有用户的需求（这里指的是口头上的需求，如果落实到文字上的还是要实现的），也不是只有将一些所谓的技术难点解决用户就会同意验收，而是可以完成一定的阶段应用业务目标。

进行需求调研的时候就要主动控制项目的边界，将一个一个业务流根据客户方的实际情况合理组织实施顺序，形成软件项目实施计划中的里程碑点，明确达到里程碑点的条件，并得到双方一致正式认可。

没有双方高度达成一致的里程碑认可，也就是没有项目目标约定，没有目标约定的项目实施计划一定会经常变更内容、变更初始设定目标，导致计划不可控制，更谈不上验收。

很多人希望通过详细的系统需求规格说明书来定义项目要实现的内容和业务目标，这是很有必要的，但需求规格说明书得到认可并非是通过用户审核就可以的结果，应该想办法让用户一起参与到需求规格说明书的制定过程中来，变成用户自己推导出来的业务实施目标，未来才不容易变形。

2、积极主动地与客户进行沟通

项目中一定要有沟通策略，和高管如何汇报工作进展，取得支持？和中层如何就业务目标不断确认，逐步清晰？和基层如何就项目应用操作模式达成一致，持续改进？都需要通过沟通反馈完成。

沟通的作用对于高管是让他们清楚项目一直按照目标前进，每个阶段工作进展是否顺利，影响项目正常运做原因是什么，需要哪些资源帮助。和高管沟通比较多的话，第一个好处是高管经常听汇报就知道项目进展程度，可以安排反馈检查，看是否具备项目所说的进展，这样一旦认可了各个阶段目标后，最终要求高管签字确认也就顺理成章了。

给高管汇报技巧就是简洁明了，真实客观，有理有据分析问题，提出对策建议请其决策即可。中层往往是项目主要的推动力量和实际执行者，也往往是对具体业务需求最主要的要求者，他们对企业实际运做过程最清楚，提出要求最具体，而且项目验收与否没有中层的同意往往也是不太容易做到的。

往往通过前期业务调研只能对企业项目目标有一个大的，宏观的认识，但如何细化并最终落实并非是一步到位的过程。因此在整个项目过程中，双方项目组要不断沟通，特别是企业中层沟通，才能逐步认识越来越深刻，最终达成一致。

和基层的沟通主要体现对最终用户的关怀，定期主动和最终用户沟通，消除一些怨气，让用户能坚持用下去，这个时候往往发现很多用户真的是非常好相处，尽管软件还有很多值得改进的地方，但他们一旦认可团队，反而会尽心尽力帮助推动项目的进行。

目前一般要求每个项目经理在项目进行中都要填写详尽的项目月报，反映项目的进度，与计划的偏差，完成的项目内容，投入人力，目前项目存在的问题，以及预计项目下月的进度等等。将进度月报交部门负责人、项目管理中心、总经办审阅。

类似地也要制定针对客户的月报甚至是周报，将相关的信息反应到客户方的负责人，及相关高层。可以先发邮件，然后还要电话落实收到并口头简要汇报，特别是高管层，千万不要以为发了就等于别人会去看，一定要口头跟进汇报一次，保证客户各方面负责人对项目进展做到心中有数。

在项目的过程中，也需要注意平时做人的积累，比如要做到讲诚信，讲原则。主要是三条：1）做不到的事情千万别随意承诺；2）承诺的事情一定要努力做到；3）每次做到的事情都进步一点点。按这三条做事，即使在系统的使用过程中总会有这样或那样的一些不方便，用户也会慢慢接受稍微长一点的响应周期，也会用更多积极性眼光看现在的问题，也相信问题一定有人响应，也一定可以得到解决。进而使卖方和客户之间形成一种较为和谐的关系。

3、验收阶段的准备工作及注意事项

当系统经过一段试运行，具备验收的各项条件之后，就需要着手验收阶段的准备工作了。首先需要把到目前为止完成的工作进行一个总结，列出已经完成的各项目工作成果、各类文档，对合同以及各类约定的技术文档中的相关内容进行自查，要彻底了解系统目前完成的情况如何，是否已经完成了与客户方达成的各项书面约定以及口头约定，没有完成的，如果是书面约定，准备采取什么策略去进一步完成。

做一个详细的验收计划是非常必要的，可以用来作为验收阶段的工作指导。这就需要与客户进行详细的沟通，再次明确验收前需要完成的工作，尽量避免客户方在此阶段提出过多的更改需求，这是极为重要的。验收计划中不光要有需要继续完成的工作，还需要有一个相对固定的工期，使双方都继续朝着这个方向去努力，防止无限制的拖延。

项目验收对任何一个项目管理者都是一个极大的挑战，即使已经采取本文提到的几种手段，也不能保证项目能够顺利验收，本文中提出的这些建议，是希望能够起到抛砖引玉的效果，希望各位同仁可以提出更多更好的方法来促进项目如期验收。

4、写好备忘录和问题跟踪记录

在一个漫长项目周期中，很多工作做了也就做了，认可了也就认可了，时间一长也就忘记了很多承诺和约定，到了验收的时候就可能重新翻出来，这种事情很多人可能都经历过，明明说可以先不做的内容最终验收的时候又成了必要条件。

在收集项目出现的各种问题时，采用问题跟踪记录表的形式，这样可以一目了然地显示出曾经收集到的各种问题，目前的解决情况，以及还有什么问题没有解决，准备什么时候解决。这样客户和卖方都会对目前的情况非常了解，通过不断地解决出现的问题，来收敛可能出现的问题，当存在的问题越来越少时，也就表示系统已经在接近验收的标准了。每次备忘录要口头交流认可后才打印签字确定阶段性工作成果。下次工作则根据前次备忘录的双方约定继续进行，保障项目在每次工作基础上不断前进，并用备忘录约束双方的行为。

第三篇：软件验收标准

目前，国内软件的验收没有可参照的强制性标准，就软件测试和评价来说，参照的标准是GB/T 17544 和GB/T 16260，它们都是推荐性标准，且都是定性而非定量的标准，这样，对于软件的验收来说，存在很大的分歧和不确定性。为此，我们在参考了大量的实践案例和文献的基础上，结合我司实际制定本验收试用办法，用于规范我司软件系统验收。

软件系统的验收可通过我司组织验收或通过第三方验收两种办法。

1、验收原则

验收参与部门：信息部门、使用部门、技术部门、专家小组或第三方验收人员；开发单位。

在软件开发合同的签订阶段就提出软件验收项目和验收通过标准的意见；在软件的需求评审阶段，仔细审阅软件的需求规格说明书，指出不利于测试和可能存在歧义的描述；在开发方开发完软件并经过开发方内部仔细的测试后，对完成的软件进行评审或第三方的验收测试，提供完整的错误报告提交给用我司，我司根据之前签订的开发合同中相应的验收标准判断是否进行验收。

2、验收项目和验收标准 2.1 验收项目 a)功能项测试

对软件需求规格说明书中的所有功能项进行测试； b)业务流程测试

对软件项目的典型业务流程进行测试； c)容错测试

容错测试的检查内容包括: 1)软件对用户常见的误操作是否能进行提示；

2)软件对用户的的操作错误和软件错误，是否有准确、清晰的提示； 3)软件对重要数据的删除是否有警告和确认提示；

4)软件是否能判断数据的有效性，屏蔽用户的错误输入，识别非法值，并有相应的错误提示。

d)安全性测试

安全性测试的检查内容包括: 1)软件中的密钥是否以密文方式存储；

2)软件是否有留痕功能, 即是否保存有用户的操作日志； 3)软件中各种用户的权限分配是否合理； e)性能测试

对软件需求规格说明书中明确的软件性能进行测试。测试的准则是要满足规格说明书中的各项性能指标。

f)易用性测试 易用性测试的内容包括: 1)软件的用户界面是否友好，是否出现中英文混杂的界面； 2)软件中的提示信息是否清楚、易理解，是否存在原始的英文提示； 3)软件中各个模块的界面风格是否一致；

4)软件中的查询结果的输出方式是否比较直观、合理。g)适应性测试

参照用户的软、硬件使用环境和需求规格说明书中的规定，列出开发的软件需要满足的软、硬件环境。对每个环境进行测试。

h)文档测试

用户文档包括: 安装手册、操作手册和维护手册。对用户文档测试的内容包括: 1)操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块；

2)用户文档描述的信息是否正确, 是否没有歧义和错误的表达； 3)户文档是否容易理解, 是否通过使用适当的术语、图形表示、详细的解释来表达；

4)用户文档对主要功能和关键操作是否提供应用实例； 5)用户文档是否有详细的目录表和索引表； i)

2.2 验收标准

2.2.1 软件错误的严重性等级 有特别要求的测试 1：不能执行正常功能或重要功能, 或者危及人身安全； 2：严重地影响系统要求或基本功能的实现, 且没有办法解决； 3：严重地影响系统要求或基本功能的实现, 但存在合理的解决办法； 4：使操作者不方便或遇到麻烦, 但不影响执行正常功能或重要功能； 5 ：其它错误；

2.2.2错误与严重性等级对应表 a)1 级错误的描述

这一级别的错误一般包括以下内容: 没有实现或错误地实现重要的功能；业务流程存在重大隐患；软件在操作过程中由于软件自身的原因自动退出系统或出现死机的情况；软件在操作过程中由于软件自身的原因对系统或数据造成破坏；在现有的软、硬建设环境下不能实现应有的功能；特殊软件在操作过程中可能危及系统和人身安全等。

b)2 级错误的描述

这一级别的错误一般包括: 没有实现基本功能，并且不存在替代办法；没有实现重要功能中的部分功能，并且不存在替代办法；业务流程衔接错误；密钥以明文方式存储；没有留痕功能；用户的权限分配不合理；在现有的环境下，不能实现部分功能且没有替代方案；没有满足系统的性能要求。

c)3 级错误的描述

这一级的错误是与第2 级别的错误相对应的，而第3 级错误则存在替代方法；对误操作或错误操作没有提示，导致非法数据进入数据库。

d)4 级错误的描述

这一级别的错误通常为易用性方面的错误。比如界面不友好、前后风格不一；中英文混杂；查询结果输出不直观等。

e)5 级错误的描述

通常为文档方面的错误，如安装手册、操作手册、维护手册中的描述错误。其次，对发现的每一个错误都要确定相应的严重性等级，如表2 中的说明。全部改正方可；如错误的级别和数量在合同可接受的范围外，用户方认为软件不可验收，要求开发方在规定的时间内全面整改软件, 提交给软件评测中心再次进行完整的验收测试。2.2.2 验收标准

1)测试用例不通过数的比例< 1.5 %； 2)不存在错误等级为1 的错误； 3)不存在错误等级为2 的错误； 4)错误等级为3 的错误数量≤ 5； 5)所有提交的错误都已得到更正； 2.3 验收标准的详细说明

验收项目的划分参照GB/T 16260 标准。在该标准中，将软件的质量特性分为6 大特性、21 个子特性，而对于具体的软件，并非都要进行这21 个特性的测试和评价。本文选取的是最通用的子特性部分，针对各种不同的软件，可以对验收项目进行剪裁或扩充。

需要制定的验收标准，即每一级别的错误量的可接受范围。一般来说，不允许存在1 级和2级错误，而3 级错误的数量则可按本标准确定或由用户方和开发方根据软件的规模和复杂程度进行商定，并在软件开发合同中明确地列出。

在软件验收测试中，测试的依据包括软件的投标文件、开发合同、需求规格说明书, 同时还包括特定软件的相关行业标准(这些行业标准应在开发合同中明示出来)。

在进行第三方的验收测试后，软件评测中心将发现的所有错误进行总结和归纳，并提交完整的错误报告，在错误报告中包括每一级别的错误数量和错误清单(所有的错误都需经过用户方和开发方的确认)。

用户方根据错误报告中每一级别的错误数量和错误清单与软件开发合同中的验收标准进行对照，如错误的级别和数量在合同中没有约定，可按本办法的规定进行。用户方认为软件可以验收，但要求开发方对错误报告中的所有错误进行整改，并提交给软件评测中心进行回归测试，确认错误报告中的所有错误全部改正方可；如错误的级别和数量在合同可接受的范围外，用户方认为软件不可验收，要求开发方在规定的时间内全面整改软件，提交给软件评测中心再次进行完整的验收测试。

3、验收资料

（1）工程立项批准文件（2）项目验收申请报告；（3）软件需求说明书；（4）概要设计说明书；

（5）数据及数据库设计要求说明书；（6）详细设计说明书；（7）软件测试报告；（8）核心算法说明文档；（9）操作手册；（10）用户手册

（11）项目用户评价过程意见；（12）软件接口规范；（13）原代码或安装盘；（14）编译、安装等配置说明；（15）专家组要求的其他材料

4、其他

在有条件的情况下，还应该进行安装测试、压力测试和数据恢复测试。若进行子系统验收或部分验收，可参照以上方法和资料，双方共同协商确定。

参考文献：

GB/T 17544 ；GB/T 16260；《软件验收标准探讨》

第四篇：软件项目验收申请

***软件股份有限公司

项目验收申请

尊敬的院领导：

您好！

**医院信息化建设从2011年5月进院到现在，历时2年零5个月时间。在医院信息科以及各个临床科室、管理科室与我项目组的共同努力下，目前项目已经实施已完成。

我院的信息化建设有着模块多，任务重，业务流程复杂的特点。在院领导的带领下，院方相关科室和项目组攻克了一个又一个难关，经过两年的实施和使用目前医院的信息化系统已经稳定，各个部门都已经正常运用信息化系统进行日常业务操作；同时医院的信息化系统在完成医院正常业务的同时为医院各个部门提供了符合医院特色的统计数据，发挥到了应有的作用，各个模块已达到预期效果。所以项目组特申请进行项目验收，请领导批准。

在接下来的维护期工作中我们将再接再厉，力争为医院提供更加优质的服务。

项目经理：

申请日期：

第五篇：软件工程项目验收系列文档

软件验收标准

2.1 验收内容

a)功能项测试

对软件需求规格说明书中的所有功能项进行 测试。

b)业务流程测试

对软件项目的典型业务流程进行测试。

c)容错测试

容错测试的检查内容包括: 1)软件对用户常见的误操作是否能进行提示;2)软件对用户的的操作错误和软件错误, 是 否有准确、清晰的提示;3)软件对重要数据的删除是否有警告和确认

提示;4)软件是否能判断数据的有效性, 屏蔽用户的错误输入, 识别非法值, 并有相应的错误提示。

d)安全性测试

安全性测试的检查内容包括: 1)软件中的密钥是否以密文方式存储;2)软件是否有留痕功能, 即是否保存有用户的操作日志;3)软件中各种用户的权限分配是否合理。

e)性能测试

对软件需求规格说明书中明确的软件性能进行测试。测试的准则是要满足规格说明书中的各项性能指标。

f)易用性测试

易用性测试的内容包括: 1)软件的用户界面是否友好, 是否出现中英文混杂的界面;2)软件中的提示信息是否清楚、易理解, 是否存在原始的英文提示;3)软件中各个模块的界面风格是否一致;4)软件中的查询结果的输出方式是否比较直 观、合理。

g)适应性测试

参照用户的软、硬件使用环境和需求规格说明书中的规定, 列出开发的软件需要满足的软、硬件环境。对每个环境进行测试。h)文档测试 用户文档包括: 安装手册、操作手册和维护手册。

对用户文档测试的内容包括: 1)操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块;2)用户文档描述的信息是否正确, 是否没有歧义和错误的表达;3)用户文档是否容易理解, 是否通过使用适当的术语、图形表示、详细的解释来表达;4)用户文档对主要功能和关键操作是否提供应用实例;5)用户文档是否有详细的目录表和索引表。6)用户有特别要求的测试。

2.2 验收标准

1)测试用例不通过数的比例< 3 %;2)不存在错误等级为1 的错误;3)不存在错误等级为2 的错误;4)错误等级为3 的错误数量≤10;5)所有提交的错误都已得到更正。6)错误响应时间

通过关于软件验收方面资料的查阅主要心得有一下几点： 1.软件的验收主要通过需求规格说明书和关键业务流程

2.在验收过程中出现BUG或者需求变更，需要通过问题跟踪记录和备忘录进行查阅 3.在验收之前，外包商必须做一下工作：

(1).软件开发已经完成，并全部解决了已知的软件缺陷。

(2).验收测试计划已经过评审并批准，并且置于文档控制之下。

(3).对软件需求说明书的审查已经完成。

(4).对概要设计、详细设计的审查已经完成。

(5).对所有关键模块的代码审查已经完成。

(6).对单元、集成、系统测试计划和报告的审查已经完成。

(7).所有的测试脚本已完成，并至少执行过一次，且通过评审。(8).使用配置管理工具且代码置于配置控制之下。(9).软件问题处理流程已经就绪。

(10).已经制定、评审并批准验收测试完成标准。

4.验收外包商需求提供的文档有：a.开发类文档：

(1).需求分析说明书

(2).概要设计说明书

(3).详细设计说明书(4).数据库设计说明书

(5).源代码

(6).安装程序

(7).程序员开发手册

(8).软件架构文档

b.管理类文档

(1).项目计划书

(2).质量控制计划

(3).配置管理计划

(4).用户培训计划

(5).数据移植计划及报告

(6).系统上线计划及报告

(7).系统管理员手册（程序维护手册）

(8).用户使用手册

(9).测试报告

(10).用户意见书

(11).验收申请

(12).质量总结报告

(13).评审报告(14).会议记录(15).开发进度月报