软件项目验收标准和验收方法6篇

软件项目验收标准和验收方法6篇软件项目验收标准和验收方法　ICS35．080L77昏雪中华人民共和国国家标准GB／T28035120112011-10-31发布软件系统验收规范Software下面是小编为大家整理的软件项目验收标准和验收方法6篇,供大家参考。

篇一：软件项目验收标准和验收方法

S 35．080L 77昏雪中华人民共和国国家标准G B／T 28035120 1 1201 1-10-31发布软件系统验收规范Sof tw aresystemacceptance speci fi cati on2012-02-01实施宰瞀鳃紫瓣警矬紫星发布中国国家标准化管理委员会仅111

　目次GB／T28035—201 1前言⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ Ⅲ1范围⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ---⋯ ⋯ ⋯ ⋯ -⋯ ⋯ ⋯ ⋯ ⋯ · -⋯ -⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ 一12规范性引用文件⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ 13术语和定义⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ 14总则⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ · · · ⋯ ⋯ ⋯ ⋯4．1软件系统验收依据⋯ ⋯ ⋯ ⋯ ⋯ · ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ”4．2软件系统验收条件⋯ ⋯ ⋯ · · · ⋯ ⋯ ⋯ ⋯ ·4．3软件系统验收相关方及其职责⋯ ⋯ · ⋯4．4软件系统验收流程⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ·5软件系统验收详细要求⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ·5．1软件系统验收申请⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ·5．2开发方应提交的资料⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ·5．3软件系统验收计划⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ -5．4软件系统验收组织⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ -5．5软件系统验收测试和验收审查⋯ ⋯ ⋯ -5．6软件系统验收评审⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ·5．7软件系统的最终处置⋯ · ⋯ ⋯ ⋯ ⋯ ⋯ ⋯6对本标准的剪裁⋯ ⋯ ⋯ · ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯6．1一般考虑⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ -6．2高完整性级别软件⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ·附录A( 资料性附录)软件系统验收文档格式⋯ · --⋯ ⋯ ⋯ ⋯ · ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ --2⋯．．．⋯⋯⋯⋯⋯．．．⋯⋯⋯⋯．⋯⋯．．9

　前言G B／T 28035--2011本标准依据G B／T 1．1—2009的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由全国信息技术标准化技术委员会( sAc／Tc 28) 提出并归口。本标准主要起草单位：中国电子技术标准化研究所、北京系统工程研究所、克拉玛依红有软件有限责任公司、辽宁北方实验室有限公司、珠海市南方软件测评中心、昆明八六三软件孵化器有限公司、上海鲁齐信息科技有限公司、湖北省软件评测中心、北京天和正通信息技术有限公司。本标准主要起草人：李海波、卢海英、李清辉、粟岚、张为民、吴东亚、杨瑛、韩红强、侯建华、何芳、杨丽春、张露莹、董晓阳、赵明丽。Ⅲ

　1范围软件系统验收规范G B／T 28035--20”本标准规定了软件系统验收的基本要求和流程。本标准适用于软件系统的验收过程和验收环节。配置项或子系统的验收可参照执行。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本( 包括所有的修改单) 适用于本文件。G B／T 8566--2007软件生存周期过程G B／T 8567--2006计算机软件文档编制规范G B／T 11457- - 2006信息技术软件工程术语G B／T 15532--2008计算机软件测试规范G B／T 18492- - 2001信息技术系统及软件完整性级别3术语和定义G B／T 11457--2006、GB／T 18492--2001中界定的以及下列术语和定义适用于本文件。3．1验收acceptance需方对开发方提交的软件系统，按照合同或双方的约定进行测试、审查与评审，决定接收或拒收的活动。3．2验收组织acceptance group由需方指定或委托成立的负责软件系统验收的组织，通常由若干专家组成。3．3验收测试acceptance testi ng确定一软件系统是否符合其验收准则，使需方能确定是否接收此系统的正式测试。3．4验收审查acceptance i nspecti ng为确定被验收软件系统是否符合验收依据而进行的符合性检查。3．5验收评审acceptancerevi ew验收组织对验收测试和验收审查的结果进行复审和评议，并对被验收软件系统做出评审结论。3．6合格性测试qual i fi cati on testi ng由开发方进行并由需方( 适当时) 见证的测试，以证明软件产品满足其规格说明，并可以在其目标环1

　G B／T 28035--2011境中使用或与它的自含系统集成。3．7软件系统softw are system由定制软件集成或由定制软件和商业现货软件集成的软件，通常由系统软件、支持软件和应用软件组成。4总则4．1软件系统验收依据软件系统验收的依据是合同或验收双方约定的验收依据文档或相关标准。注：双方约定的验收依据文档，可以是软件需求规格说明、软件总体设计、软件设计方案等。4．2软件系统验收条件软件系统验收应具备以下条件：a)被验收软件系统已按G B／T 8566--2007进行系统合格性测试并通过评审；b) 合同或双方约定的验收依据文档规定的各类文档齐全并通过评审；c) 被验收软件系统已置于配置管理之下并得到有效控制。4．3软件系统验收相关方及其职责4．3．1需方负责组织实施软件系统验收，包括：审批验收申请、指定或成立验收组织、审批验收计划，并根据验收结论建议决定是否接收软件系统。4．3．2验收组织负责制定验收计划，实施验收测试、验收审查和验收评审，并做出评审结论。4．3．3开发方提出验收申请，提供被验收的软件系统( 包括程序、文档和数据) ；开发方应积极支持、配合完成软件系统验收工作，负责做好验收所需的各项保障工作。4．3．4验收各方应遵守验收保密承诺。4．4软件系统验收流程软件系统验收流程一般包括：开发方提出软件系统验收申请；a)b) 需方批复验收申请并成立软件系统验收组织；c)验收组织制定软件系统验收计划；d) 需方审批软件系统验收计划；e)验收组织进行软件系统验收测试和验收审查；验收组织进行软件系统验收评审；f)g) 验收组织形成软件系统验收报告；h) 验收未通过的处置。具体流程见图1。

　G B／T 28035--20115软件系统验收详细要求5．1软件系统验收申请5．1．1提出验收申请图1软件系统验收流程开发方向需方提交软件系统验收申请表，概要说明申请验收的软件系统满足4．1所要求条件的情况。软件系统验收申请表应由开发方的负责人签字。软件系统的验收申请表( 格式见附录A中A．1) 宜包括以下内容：a) 软件系统名称；b) 软件系统研制任务来源；软件系统用途及组成；d) 主要功能与性能；e) 软件系统研制情况；研制阶段评审情况；c)f)g) 软件系统测试情况；h) 配置管理情况；满足需方业务要求等情况。对于含有的现货软件及其他软件的软件系统，申请表中还应增加：a) 现货软件及其他软件名称，b) 现货软件及其他软件用途及组成；c) 主要功能与性能；i )3

　G B／T 28035--20”d) 文档清单。5．1．2审批验收申请需方在收到软件系统验收申请表后，应及时了解被验收软件系统的功能、性能及文档等方面的内容，检查其是否与4．1和4．2规定的要求相一致，并对开发方提出的软件系统验收申请表进行审查，对符合验收条件的应予以批准，并通知开发方；对不符合验收条件的应退回开发方，并说明原因。5．2开发方应提交的资料5．2．1开发方应提交的瓷料对于定制开发的软件系统，开发方在提交软件系统验收申请表时，应提供被验收软件系统的合格性测试报告及其评审结论，以及合同等文件规定的文档清单和软件系统产品清单等。对于含有现货软件及其他软件的软件系统，开发方在提交软件系统验收申请表时，还应提供现货软件及其他软件的产品规格说明，以及合同等文件规定的文档清单和软件产品清单等。5．2．2被验收软件系统殛相关文档的提交开发方在接到软件系统验收申请的批准通知后，应及时向需方提交4．1所规定的软件系统及相关文档。5．3软件系统验收计划5．3．1验收计划要求验收组织应制定验收计划。验收计划一般包括验收目的、验收内容、技术条件、验收方法、进度安排、人员组成、验收准则等内容。验收计划应充分考虑被验收软件系统的完整性级别( 见G B／T 18492--2001) 。验收计划在验收组织与开发方协商一致、并经需方审批后实施。5．3．2验收准则依据4．1的要求，制定验收准则。验收准则由需方提出，征求开发方意见后，由需方确定。验收准则通常包含；a) 软件系统符合合同规定的全部功能和非功能要求；b) 文档齐全，符合合同要求或相关标准的规定( 见G B／T 8567--2006) ；c) 文档之间一致。程序和文档相符；d) 对被验收软件系统在验收测试中查出的错误总数及在验收审查时查出的交付文档中的错误总数均不得超过双方约定数目；e) 对于高完整性级别( A，B级) 的软件系统，还应通过功能和性能强度测试。5．4软件系统验收组织5．4．1需方在批复同意开发方提出的验收申请表后，成立验收组织。验收组织一般由需方代表、用户代表、相关领域专家及测试专家组成。根据需方的要求和项目的规模，验收组织的组织形式可以灵活多样，通常由验收测试组和验收评审组组成，有时还可设立验收审查组。测试组由独立于软件开发的人员组成。评审组应由具有与被验收软件系统相关的专业知识的专家组成，人数为5人及以上单数。5．4．2验收组织的任务是：制定验收测试计划、验收审查计划；a)4

　b) 进行验收测试和验收审查；c) 进行软件系统验收评审。5．5软件系统验收测试和验收审查5．5．1基本要求G B／T 28035--2011验收测试和验收审查是验收评审前应完成的两项主要检查工作，由验收组织负责实施。验收测试由测试组负责执行，也可委托国家认可的第三方软件测评机构实施。对于完整性为A、B级软件应委托国家认可的第三方软件测评机构实施。验收测试应按G B／T 15532--2008的要求进行。验收组织应根据4．1和软件系统验收计划制订验收测试计划和验收审查计划。验收测试计划文档格式应符合G B／T 8567--2006的规定或满足双方约定的要求。验收审查计划应包括审查目的、审查范围、审查对象、审查内容、审查准则、审查方法、人员分工、进度安排等。验收审查可由测试组进行也可单独成立验收审查组进行。5．5．2验收测试和验收审查步骤验收测试和验收审查的具体步骤如下：制定验收测试计划和验收审查计划，作好验收测试和验收审查准备；b) 进行验收测试和验收审查，建立完整的验收测试记录和验收审查记录编写验收测试报告和验收审查报告。a)c)5．5．3验收测试内容应根据4．1规定的要求和软件完整性级别确定验收测试内容：a) 依据4．1检查功能和非功能要求；b) 对于完整性为A、B级的软件系统还应进行有关功能和性能的强度测试；对于完整性为A级的软件系统还应进行双方商定的一些特殊测试，如强度测试和可靠性测试等。c)5．5．4验收审查内容应依据4．1确定验收审查内容，验收审查主要检查文档的齐套性、完整性和一致性，以及与合同及相关标准符合性等情况。5．6软件系统验收评审5．6．1评审的时机验收评审应在完成验收测试、验收审查后进行。5．6．2评审的形式验收评审一般应采取会议评审形式。根据被验收软件系统的完整性级别等具体情况，验收评审还可采取现场评审或验收双方认可的其他形式。5．6．3评审通过准则评审通过准则如下：a) 被验收软件系统通过验收测试；5

　G B／T 28035--20 1 1b) 被验收软件系统通过验收审查；c) 被验收软件系统满足5．4．z规定的验收准贝! l 。5．6．4评审的程序评审的具体程序如下：验收组织审查验收测试报告、验收审查报告；b) 根据评审通过准则，验收组织就被验收软件系统是否通过验收评审进行表决c) 根据表决情况，做出评审结论。a)5．6．5评审结论评审结论分为两种：a) 评审通过：完整性为A、B级的软件系统需由参加验收评审的成员一致同意}其他软件系统需由三分之二I：／I-的参加验收评审的成员同意；b) 评审不通过：同意通过验收评审的成员数未达到a) 的要求。5．6．6验收报告验收组织在完成验收评审后，填写验收报告( 验收报告的格式见附录A的表A．3) 。验收报告的内容应包括验收依据、验收内容、验收过程、验收准则、验收测试结论、验收审查结论、表决情况等。根据表决情况，由评审负责人在验收报告上签署验收评审结论。参加验收评审的成员应在验收报告上签字。验收报告应提交给需方和供方。5．7软件系统的最终处置需方依据验收报告作出是否接收该被验收软件系统的决定。必要时，对验收评审未通过的软件系统，按相关程序重新进行验收。6对本标准的剪裁6．1一般考虑本标准为需方验收软件系统提供了基本要求，需方可以根据被验收软件系统的完整性级别对本标准进行适当的剪裁。不同的软件系统在应用本标准时允许有所倜重，可以根据软件系统的完整性级别和其他要求对测试内容等进行剪裁，制定适合实际情况的具体验收细则。6．2高完整性级别软件高完整性级别( A、B级) 的软件系统的验收应严格按照本标准的规定进行，并可增加一些特殊要求。

　A．1软件系统验收申请报告格式附录A( 资料性附录)软件系统验收文档格式软件系统验收申请表格式见表A．1。表A．1软件系统验收申请报告格式G B／T 28035--20 1 1软件系统名称：合同号或验收依据文档标识：需方：开发方：软件系统研制任务来源软件系统用途及组成主要功能与性能软件系统研制情况研制阶段评审情况软件系统测试情况配置管理情况满足主要技术指标情况开发方申请意见：负责人签名——年月日( 单位公章)联系人：电话：通信地址：邮政编码：需方意见：负责人签名——年月日( 单位公章)联系人：电话：通信地址：邮政编码：

　G B／T 28035--20 11A．2软件系统验收审查报告格式软件系统验收审查报告格式见表A．2。表A．2软件系统验收审查报告格式软件系统名称：合同号或验收依据文档标识：需方：开发方：审查的目的和范围审查对象审查依据审查准则审查活动总结审查结果列表审查结论验收组负责人签名——年月日验收组名单及签名姓名职务或职称工作单位签字8

　A．3软件系统验收报告格式软件系统验收报告格式见表A．3。表A．3软件系统验收报告格式G B／T 28035--20 1 1软件系统名称：合同号或验收依据文档标识：需方：开发方：验收依据验收内容验收过程验收准则验收测试结论验收审查结论验收评审结论验收组负责人签名——年月日总人数同意不同意弃权表头情况人人人人验收评审成员名单及签名姓名职务或职称工作单位签字

篇二：软件项目验收标准和验收方法

项目验收实施办法 目前， 国内软件的验收没有可参照的强制性标准， 就软件测试和评价来说， 参照的标准是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）

　原代码或安装盘；

　（16）

　专家组要求的其他材料 4、 其他 在有条件的情况下， 还应该进行安装测试、 压力测试和数据恢复测试。

　若进行子系统验收或部分验收， 可参照以上方法和资料， 双方共同协商确定。

　参考文献：

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

　{日期}

　§ 1

　项目基本情况. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

　§ 2

　项目进度审核. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

　2. 1

　项目实施进度情况

　2. 2

　项目变更情况

　2. 3

　项目投资结算情况

　§ 3

　项目验收计划. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

　3. 1

　项目验收原则

　3. 2

　项目验收方式

　3. 3

　项目验收内容

　§ 4

　项目验收情况汇总. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

　4. 1

　项目验收情况汇总表

　4. 2

　项目验收附件明细

　4. 3 专家组验收意见

　§ 5

　项目验收结论. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

　5. 1 开发单位结论

　5. 2 建设单位结论

　§ 6

　附件. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

　6. 1

　附件一：

　软件平台验收单

　6. 2

　附件二：

　功能模块验收单

　6. 3

　附件三：

　项目文档验收单

　6. 4

　附件四：

　硬件设备验收单

　§ 1

　项目基本情况

　§ 2

　项目进度审核

　2.1

　 项目实施进度情况

　 2.2

　项目变更情况 2. 2. 1

　项目合同变更情况

　{记录合同变更情况}

　 2. 2. 2

　项目需求变更情况

　{记录需求变更情况}

　2.3

　项目投资结算情况

　§ 3

　项目验收计划

　3.1

　 项目验收原则

　 1、 审查提供验收的各类文档的正确性、 完整性和统一性， 审查文档是否齐全、 合理；

　2、 审查项目功能是否达到了合同规定的要求；

　3、 审查项目有关服务指标是否达到了合同的要求；

　4、 审查项目投资以及实施进度的情况；

　5、 对项目的技术水平做出评价， 并得出项目的验收结论。

　3.2

　项目验收方式

　{记录项目验收的组织方式和参与验收工作的人员情况}

　3.3

　项目验收内容

　1、 硬件设备验收；

　2、 软件平台验收；

　3、 应用系统验收；

　4、 项目文档验收；

　5、 项目服务响应（如售后服务、 问题相应等方面）

　验收。

　§ 4

　项目验收情况汇总

　 4.1

　 项目验收情况汇总表

　4.2

　项目验收附件明细

　 1、 软件平台验收单（见附件一）

　。

　2、 功能模块验收单（见附件二）

　。

　3、 项目文档验收单（见附件三）

　。

　4、 硬件设备验收单（见附件四）

　。

　4.3 专家组验收意见

　§ 5

　项目验收结论 5.1

　开发单位结论

　5.2 建设单位结论

　§ 6

　附件 6.1

　 附件一：

　软件平台验收单

　6.2

　附件二：

　功能模块验收单

　6.3

　附件三：

　项目文档验收单

　 6.4

　附件四：

　硬件设备验收单

篇三：软件项目验收标准和验收方法

庄东方热电股份有限公司协同办公系统

　验收报告

　2010 年 10 月 20 日

　 2 目

　录

　§1

　项目基本情况 .....................................................................................................

　§2

　项目进度审核 .....................................................................................................

　2.1

　项目实施进度情况......................................................................................

　2.2

　项目变更情况 .............................................................................................

　2.3

　项目投资结算情况......................................................................................

　§3

　项目验收计划 .....................................................................................................

　3.1

　项目验收原则 .............................................................................................

　3.2

　项目验收方式 .............................................................................................

　3.3

　项目验收内容 .............................................................................................

　§4

　项目验收情况汇总 .............................................................................................

　4.1

　项目验收情况汇总表 ..................................................................................

　4.2

　项目验收附件明细......................................................................................

　4.3 专家组验收意见 ...........................................................................................

　§5

　项目验收结论 .....................................................................................................

　5.1 开发单位结论 ...............................................................................................

　5.2 建设单位结论 ...............................................................................................

　§6

　附件 ....................................................................................................................

　6.1

　附件一软件平台验收单 ..........................................................................

　6.2

　附件二功能模块验收单 ..........................................................................

　6.3

　附件三项目文档验收单 ..........................................................................

　6.4

　附件四硬件设备验收单 ..........................................................................

　 3

　§1

　项目基本情况 项目名称 项目合同甲方 项目合同乙方 项目合同编号 项目开工时间 项目竣工时间 项目验收日期

　石家庄东方热电股份有限公司协同办公系统 石家庄东方热电股份有限公司 太原市精茂科技有限公司

　 §2

　项目进度审核 2.1

　项目实施进度情况 序号 1 2 3 4 5 6

　阶段名称 起止时间 交付物列表 备注

　 4 2.2

　项目变更情况 2.2.1

　项目合同变更情况 {记录合同变更情况}

　 2.2.2

　项目需求变更情况 {记录需求变更情况}

　2.3

　项目投资结算情况 序号 1 2 3 合

　计

　款

　项 金

　额 万元 4.4 6.05 0.55

　备注 预付项目建设费 验收合格 质保金费用

　2 个月进行项目验收 自验收合格之日一年后支付

　§3

　项目验收计划 3.1

　项目验收原则 1、审查提供验收的各类文档的正确性、完整性和统一性审查文档是否齐全、合理 2、审查项目功能是否达到了合同规定的要求 3、审查项目有关服务指标是否达到了合同的要求 4、审查项目投资以及实施进度的情况

　 5 5、对项目的技术水平做出评价并得出项目的验收结论。

　3.2

　项目验收方式

　验收人员 王文彬 所属单位 所属角色 总经理 相关职责 太原市精茂科技有限公司 太原市精茂科技有限公 张强 司

　 技术人员

　 3.3

　项目验收内容 1、硬件设备验收 2、软件平台验收 3、应用系统验收 4、项目文档验收 5、项目服务响应如售后服务、问题相应等方面验收。

　 6 §4

　项目验收情况汇总 4.1

　项目验收情况汇总表 验收项 验收意见 备注 通过 不通过

　 总体意见

　 项目验收组长签字 未通过理由

　 项目验收组长签字

　4.2

　项目验收附件明细 1、软件平台验收单见附件一 。

　2、功能模块验收单见附件二 。

　3、项目文档验收单见附件三 。

　 7 4、硬件设备验收单见附件四 。

　4.3 专家组验收意见

　专家组长签字

　 8 §5

　项目验收结论 5.1 开发单位结论

　开发单位签章

　 9 5.2 建设单位结论

　建设单位签章

　 10 §6

　附件 6.1

　附件一软件平台验收单 验收人 验收时间 序号 1 2 3

　软件类型 软件名称 验收结果 备注 机器的IP地址等

　6.2

　附件二功能模块验收单 验收人 验收时间 序号 1 2 3 4 5 6 7

　功能模块 验收内容 合同要求 验收结果

　 6.3

　附件三项目文档验收单 验收人 验收时间 序号 文档名称 用

　途 验收结果 备注

　 11 1 2 3 4 5 6

　6.4

　附件四硬件设备验收单 验收人 验收时间 序硬件名称 号 1 2 基本用途 型号 配置情况 验收结果 备注 机器的IP地址等

篇四：软件项目验收标准和验收方法

修订记录

　版本号 *变化 状态 简要说明 日期 变更人 批准日期 批准人 V1、0 C 初始版本

　 *变化状态：C = 创立，A = 增加，M = 修改，D = 删除 *正式发布时文档版本号从 1、0 开始。对文档进行小改动时，版本号以 0、1 进阶；大改动时版本号以1、0 进阶。

　矚慫润厲钐瘗睞枥庑赖。

　文档审批记录

　序号 审批人 角色 审批日期 签字 备注

　 目录 1、前言 3 聞創沟燴鐺險爱氇谴净。

　1、1、目得 3 残骛楼諍锩瀨濟溆塹籟。

　1、2、范围 3 酽锕极額閉镇桧猪訣锥。

　1、3、术语定义 3 彈贸摄尔霁毙攬砖卤庑。

　1、4、预期读者与阅读建议 3 謀荞抟箧飆鐸怼类蒋薔。

　1、5、参考 3 厦礴恳蹒骈時盡继價骚。

　2、工程概述 4 茕桢广鳓鯡选块网羈泪。

　3、验收原则 4 鹅娅尽損鹌惨歷茏鴛賴。

　4、总体验收标准 4 籟丛妈羥为贍偾蛏练淨。

　4、1、标准定义 4 預頌圣鉉儐歲龈讶骅籴。

　4、2、验收标准得详细说明 4 渗釤呛俨匀谔鱉调硯錦。

　4、2、1、软件错误得严重性等级 5 铙誅卧泻噦圣骋贶頂廡。

　4、2、2、错误与严重性等级对应 5 擁締凤袜备訊顎轮烂蔷。

　4、2、2、1、一级错误得描述 5 贓熱俣阃歲匱阊邺镓騷。

　4、2、2、2、二级错误得描述 5 坛摶乡囂忏蒌鍥铃氈淚。

　4、2、2、3、三级错误得描述 6 蜡變黲癟報伥铉锚鈰赘。

　4、2、2、4、四级错误得描述 6 買鲷鴯譖昙膚遙闫撷凄。

　4、2、2、5、五级错误得描述 6 綾镝鯛駕櫬鹕踪韦辚糴。

　5、工程验收标准 6 驅踬髏彦浃绥譎饴憂锦。

　5、1、功能测试 6 猫虿驢绘燈鮒诛髅貺庑。

　5、1、1、功能项测试 6 锹籁饗迳琐筆襖鸥娅薔。

　5、1、1、1、功能一 6 構氽頑黉碩饨荠龈话骛。

　5、1、1、2、功能二 7 輒峄陽檉簖疖網儂號泶。

　5、1、2、业务流程测试 7 尧侧閆繭絳闕绚勵蜆贅。

　5、1、2、1、业务流程一 7 识饒鎂錕缢灩筧嚌俨淒。

　5、1、2、2、业务流程二 7 凍鈹鋨劳臘锴痫婦胫籴。

　5、2、非功能测试 7 恥諤銪灭萦欢煬鞏鹜錦。

　5、2、1、容错测试 7 鯊腎鑰诎褳鉀沩懼統庫。

　5、2、2、安全性测试 8 硕癘鄴颃诌攆檸攜驤蔹。

　5、2、3、性能测试 8 阌擻輳嬪諫迁择楨秘騖。

　5、2、4、压力测试 8 氬嚕躑竄贸恳彈瀘颔澩。

　5、2、5、易用性测试 8 釷鹆資贏車贖孙滅獅赘。

　5、2、6、适应性测试 8 怂阐譜鯪迳導嘯畫長凉。

　5、3、安装测试 9 谚辞調担鈧谄动禪泻類。

　5、3、1、数据恢复测试 9 嘰觐詿缧铴嗫偽純铪锩。

　5、3、2、数据接入 9 熒绐譏钲鏌觶鷹緇機库。

　5、3、3、数据服务 9 鶼渍螻偉阅劍鲰腎邏蘞。

　5、4、文档测试 9 纣忧蔣氳頑莶驅藥悯骛。

　5、5、用户有特别要求得测试 9 颖刍莖蛺饽亿顿裊赔泷。

　6、验收资料 9 濫驂膽閉驟羥闈詔寢賻。

　7、附录：GB/T 16260 软件质量评价特性 10 銚銻縵哜鳗鸿锓謎諏涼。

　7、1、功能性 10 挤貼綬电麥结鈺贖哓类。

　7、1、1、适合性 10 赔荊紳谘侖驟辽輩袜錈。

　7、1、2、准确性 10 塤礙籟馐决穩賽釙冊庫。

　7、1、3、互操作性、互用性 10 裊樣祕廬廂颤谚鍘羋蔺。

　7、1、4、依从性 10 仓嫗盤紲嘱珑詁鍬齊驁。

　7、1、5、安全性 11 绽萬璉轆娛閬蛏鬮绾瀧。

　7、2、可靠性 11 骁顾燁鶚巯瀆蕪領鲡赙。

　7、2、1、成熟性 11 瑣钋濺暧惲锟缟馭篩凉。

　7、2、2、容错性 11 鎦诗涇艳损楼紲鯗餳類。

　7、2、3、易恢复性 11 栉缏歐锄棗鈕种鵑瑶锬。

　7、3、易用性 11 辔烨棟剛殓攬瑤丽阄应。

　7、3、1、易理解性 11 峴扬斕滾澗辐滠兴渙藺。

　7、3、2、易学性 11 詩叁撻訥烬忧毀厉鋨骜。

　7、3、3、易操作性 12 则鯤愜韋瘓賈晖园栋泷。

　7、4、效率 12 胀鏝彈奥秘孫戶孪钇賻。

　7、4、1、时间特性 12 鳃躋峽祷紉诵帮废掃減。

　7、4、2、资源特性 12 稟虛嬪赈维哜妝扩踴粜。

　7、5、维护性 12 陽簍埡鲑罷規呜旧岿錟。

　7、5、1、易分析性 12 沩氣嘮戇苌鑿鑿槠谔應。

　7、5、2、易改变性 12 钡嵐縣緱虜荣产涛團蔺。

　7、5、3、稳定性 12 懨俠劑鈍触乐鹇烬觶騮。

　7、5、4、易测试性 12 謾饱兗争詣繚鮐癞别瀘。

　7、6、可移植性 13 呙铉們欤谦鸪饺竞荡赚。

　7、6、1、适应性 13 莹谐龌蕲賞组靄绉嚴减。

　7、6、2、易安装性 13 麸肃鹏镟轿騍镣缚縟糶。

　7、6、3、遵循性 13 納畴鳗吶鄖禎銣腻鰲锬。

　7、6、4、易替换性 13 風撵鲔貓铁频钙蓟纠庙。

　1. 前言

　1.1. 目得

　〔如下描述:〕 在参考了大量得实践案例与文献得基础上，结合工程特征、客户需求及当前业务实际制定本验收标准，确立工程质量目标，规范本软件得验收。

　灭嗳骇諗鋅猎輛觏馊藹。

　1.2. 范围

　〔如下描述:〕 适用于公司所有类型工程（包括产品研发类、合同开发类、工程实施类以及系统集成类）得验收标准确定。

　本标准应在软件合同签订时制定，并作为软件得质量标准指导软件生产。

　1.3. 术语定义

　{提供所有为正确解释本软件开发计划所必需得术语与缩略语得定义。术语很多时，用列表作为本文档得附件。} 1.4. 预期读者与阅读建议

　{描述本文档得主要读者，以及这些读者在阅读时得阅读重点与建议。可用列表得方式列出。如：} 预期读者 阅读建议 业务经理

　工程分管领导

　工程组成员

　关联工程组

　客户代表

　1.5. 参考

　〔列出描述参考得所有文档。〕 《GB/T 16260-1996 信息技术/软件产品评价/质量特性及其使用指南》 《GB/T17544-1998 软件包质量要求与测试》 《GB/T 15532-2008 计算机软件测试规范》

　2. 工程概述

　3. 验收原则

　验收参与部门：客户代表、***公司、最终用户单位、专家小组或第三方验收人员。

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

　铹鸝饷飾镡閌赀诨癱骝。

　4. 总体验收标准

　总体验收标准就是***公司结合国家标准、软件行业惯例所提出得对于软件系统质量得最低要求，所有交付得软件必须满足本标准得约定。

　攙閿频嵘陣澇諗谴隴泸。

　4.1. 标准 定义

　{以下内容根据工程实际情况调整：} 1) 测试用例不通过数得比例&lt; 1、5 %； 2) 不存在错误等级为1得错误； 3) 不存在错误等级为2 得错误； 4) 错误等级为3 得错误数量≤5； 5) 所有提交得错误都已得到更正； 4.2. 验收标准得详细说明

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

　趕輾雏纨颗锊讨跃满賺。

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

　夹覡闾辁駁档驀迁锬減。

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

　视絀镘鸸鲚鐘脑钧欖粝。

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

　偽澀锟攢鴛擋緬铹鈞錠。

　4.2.1. 软件错误得严重性等级 软件错误得严重等级由重到轻，如下：

　1) 不能执行正常功能或重要功能, 或者危及人身安全； 2) 严重地影响系统要求或基本功能得实现, 且没有办法解决； 3) 严重地影响系统要求或基本功能得实现, 但存在合理得解决办法； 4) 使操作者不方便或遇到麻烦, 但不影响执行正常功能或重要功能； 5) 其它错误； 4.2.2. 错误与严重性等级对应 4.2.2.1. 一 一 级错误得描述 这一级别得错误一般包括以下内容: 没有实现或错误地实现重要得功能；业务流程存在重大隐患；软件在操作过程中由于软件自身得原因自动退出系统或出现死机得情况；软件在操作过程中由于软件自身得原因对系统或数据造成破坏；在现有得软、硬建设环境下不能实现应有得功能；特殊软件在操作过程中可能危及系统与人身安全等。

　緦徑铫膾龋轿级镗挢廟。

　4.2.2.2. 二 二 级错误得描述 这一级别得错误一般包括: 没有实现基本功能，并且不存在替代办法；没有实现重要功

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

　騅憑钶銘侥张礫阵轸蔼。

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

　疠骐錾农剎貯狱颢幗騮。

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

　镞锊过润启婭澗骆讕瀘。

　4.2.2.5. 五 五 级错误得描述 通常为文档方面得错误，如安装手册、操作手册、维护手册中得描述错误。

　5. 工程验收标准

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

　榿贰轲誊壟该槛鲻垲赛。

　5.1. 功能测试

　5.1.1. 功能项测试 {对软件需求规格说明书中得所有功能项进行测试；} 5.1.1.1. 功能一 一 1) 功能名称

　2) 功能描述 3) 目标结果 5.1.1.2. 功能二 1) 功能名称 2) 功能描述 3) 目标结果 5.1.2. 业务流程测试 {对软件工程得典型业务流程进行测试；} 5.1.2.1. 业务流程一 1) 业务流程名称 2) 流程图及说明 3) 目标结果 5.1.2.2. 业务流程二 1) 业务流程名称 2) 流程图及说明 3) 目标结果 5.2. 非功能测试

　5.2.1. 容错测试 {容错测试得检查内容包括: 1) 软件对用户常见得误操作就是否能进行提示； 2) 软件对用户得得操作错误与软件错误，就是否有准确、清晰得提示； 3) 软件对重要数据得删除就是否有警告与确认提示； 4) 软件就是否能判断数据得有效性，屏蔽用户得错误输入，识别非法值，并有相应得

　错误提示。} 5.2.2. 安全性测试 {安全性测试得检查内容包括: 1) 软件中得密钥就是否以密文方式存储； 2) 软件就是否有留痕功能, 即就是否保存有用户得操作日志； 3) 软件中各种用户得权限分配就是否合理；} 5.2.3. 性能测试 {对软件需求规格说明书中明确得软件性能进行测试。测试得准则就是要满足规格说明书中得各项性能指标。} 5.2.4. 压力测试 5.2.5. 易用性测试 {易用性测试得内容包括: 1) 软件得用户界面就是否友好，就是否出现中英文混杂得界面； 2) 软件中得提示信息就是否清楚、易理解，就是否存在原始得英文提示； 3) 软件中各个模块得界面风格就是否一致； 4) 软件中得查询结果得输出方式就是否比较直观、合理。} 5.2.6. 适应性测试 {参照用户得软、硬件使用环境与需求规格说明书中得规定，列出开发得软件需要满足得软、硬件环境。对每个环境进行测试。} 邁茑赚陉宾呗擷鹪讼凑。

　5.3. 安装测试

　5.3.1. 数据恢复测试 5.3.2. 数据接入 5.3.3. 数据服务 5.4. 文档测试

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

　6. 验收资料

　1) 解决方案 2) 合同 3) 需求规格说明书； 4) 概要设计说明书； 5) 数据及数据库设计要求说明书； 6) 详细设计说明书； 7) 操作手册； 8) 用户手册； 9) 工程用户评价过程意见；

　10) 软件接口规范； 11) 安装盘； 7. 附录：0 GB/T 16260 软件质量评价特性

　7.1. 功能性

　与一组功能及其指定得性质有关得一组属性，这里得功能就是指满足明确或隐含得需求得那些功能。这组属性以软件为满足需求做些什么来描述，而其她属性则以何时做与如何做来描述 嵝硖贪塒廩袞悯倉華糲。

　7.1.1. 适合性 与规定任务能否提供一组功能以及这组功能得适合程度有关得软件属性，适合程度得例子就是面向任务系统中由子功能构成功能就是否合适表容量就是否合适等 该栎谖碼戆沖巋鳧薩锭。

　7.1.2. 准确性 与能否得到正确或相符得结果或效果有关得软件属性，例如此属性包括计算值所需得准确程度 7.1.3. 互操作性 、 互用性 ...

篇五：软件项目验收标准和验收方法

项目验收流程各步骤内容

　项目验收过程

　 验收作为项目执行过程中的一个重要的里程碑，对公司和客户具有重要的意义。

　 一、验收申请 二、验收准备 2．1 开发商资料收集

　 根据软件项目的特点，在验收时应收集以下文档：

　 除上述文档外，还应单独收集、保存各应用软件源程序代码及开发商所用第三方资源信息。开发商所使用的第三方控件，除已经得到审计署的许可之外，必须提供控件的源代码，并拥有授权使用的证明或保证（由开发商提供无版权争议承诺书）；对于原始程序代码，要求能够在本地不经过任何特殊设置，即可编译并正常运行。源程序清单中列举的项目应该和源程序一一对应。

　 2．2 最终用户资料收集

　 依据软件开发需求说明书和概要设计说明书，编写相关软件的用户满意度调查表，该调查表应该涵盖软件在需求说明书中列举的所有模块，包含软件在不同操作系统下的运行情况等。最终用户或甲方项目组按照实际情况填写该调查表。

　 三、验收测试 验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动，它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，

　因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方面检测。

　软件验收测试分为三部分：文档代码一致性审核、软件配置审核和可执行程序测试，其顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序、平台 API测试、集成测试、验收测试等。文档代码一致性审核、软件配置审核是软件部署和实施全面验收测试的基础，由各应用软件验收责任人检查它们的完整性；由于工程开发的各软件运行环境均基于审计管理系统、审计实施系统平台，最终的集成测试、验收测试由德华工贸员工、验收专家所有参与验收工作的人员一起完成。

　 3．1 文档审核

　 文档审核的主要要求是确定软件开发的所有过程都在提交文档的控制下，对文档的具体要求如下：

　 (1）文档完备性：是否按照合同及其附件要求提交了全部文档；

　 (2）内容针对性：指文档是否是甲方要求的文档；文档的内容应该按照功能模块的重要性在论）上达到不同的详细程度；

　 (3）内容充分性：指该文档全面、详细的程度； (4）文档的价值：文档应该能够反映软件开发的整个过程，即需求中提到的功能在概要设计中体现，在详细设计中实现，在测试计划中检验；

　 (5）图表翔实性：是否包含了足够的图形和表格；

　 (6）符合甲方规范程度：是否很好地符合甲方要求的规范、标准； (7）内容一致性：是否存在前后矛盾；是否存在需求说明中提到的功能在概要设计、详细设计中没有涉及的情况； (8）文字明确性：不使用“可能”、

　“也许”、“待定”等语义含糊不清的语句； (9）易读性：能够在一篇文档中说明清楚的内容，尽量不要拆分成若干文档，不要循环引用，文档目录一目了然，结构清晰。

　 3．2 源代码审核 源代码审核的主要要求是确保开发商将全部源程序交付甲方，并确保交付的代码没有版权问题（由开发商提供无版权争议承诺书）对源代码审核的具体要求如下：

　 3．2．1 版权明晰

　 （1）提交的代码中注释版权的地方均应去掉版权声明，或声明版权为审计署所有。

　（2）得到甲方允许，可以使用的控件，由开发商提供无版权争议承诺书。使用其他的具有源代码的控件，均需要当作提交代码的一部分，直接置于编译环境的工程文件中，在编译发布时无需额外设置。

　3．2．2 代码完整

　 （1）开发商必须把所有实现用户需求的代码交付甲方。

　 （2）除非已经得到甲方的允许，使用的控件也必须有源代码，并得到授权使用证明；由开发商提供无版权争议承诺书。

　 （3）包含开发工具的程序文件；要求能够在甲方计算机中正常编译、运行；除非得到甲方允许，在甲方计算机中编译的时候无需额外安装开发工具的插件或控件。

　 3．2．3 可读性强 注释是软件可读性的具体体现。程序注释量不少于程序编码量的 30%。程序注释不能用抽象的语言（如“处理”、“循环”等），要精确表达出程序的处理说明。为避免每行程序都使用注释，可以在一段程序的前面加一段注释，有明确的处理逻辑。

　3．3 配置文件审核

　对于 B/S 程序，部署维护是软件生存周期中最长的一个过程，配置文件的审核显得尤为重要。对配置文件的审核要求与源代码的审核要求完全一致。

　 3．4 测试用例编写及测试程序、脚本审核

　 这个过程是在文档审核和配置脚本审核后，为了检验通过源代码编译后的程序是否满足设计需求。检验方式主要是 API 测试、集成测试、验收测试；这一阶段应该完成设计及其有关测试所包括的特性，还需要完成测试所需的测试用例和测试规程，并规定特性的通过准则。

　 （1）测试用例说明：列出用于输入的具体值以及预期的输出结果，并规定在使用具体测试用例时，对测试规程的各种限制。要求将测试用例与测试设计分开，可以使它们用于多个设计并能在其它情形下重复使用。

　 （2）测试规程说明：规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。

　 测试方案

　 （1）针对性测试方案：从满意度调查表中筛选出可能不符合需求设计的功能模块，编写针对具体模块设计的测试方案。这种方案的实现耗时短，根据实际使用情况调查软件的具体实现，适合在软件得到较大面积试用后采取的验收测试。

　 （2）抽样测试方案：在设计文档中随机选取，根据抽样的样本大小不同，最后得到的结论可能会出现差异。这种方案的实现耗时可长可短，适合软件未得到大面积适用前验收时采用。

　 3．5 平台 API 测试 常见的白盒测试是单元测试。单元测试是测试中

　最小单位的测试。简而言之，就是拿一个函数出来，加上驱动模块，让它能够运行起来，然后设计一些用例测试其内部的控制点（如：条件判断点、循环点、选择分支点等）。驱动模块是模拟调用被测函数的函数。

　根据设计文档选取关键函数和所有开放的 API，设计测试用例。

　 3．6 集成测试/压力测试 常见的黑盒测试包括：集成测试，系统测试。集成测试是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。通过一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作，在协同工作时是否能够达到功能要求。

　 3．7 验收测试

　 目的是检验待验收软件是否对平台和其它软件保持良好的兼容性。

　 四、验收结论(成绩评定标准)

　 验收结束时，根据以上文档，填写验收结论，对软件的质量做出评价 1．优秀

　 1)材料完整

　 2)软件可正常运行

　 3)实现项目软件需求说明书要求的各项功能需求

　 4)软件界面友好，易于交互

　 5)软件功能新颖，有较强创新

　 2．合格

　1)本标准第 2.1 条要求的材料完整

　 2)可正常运行实现功能达到软件需求说明书要求的三分之二以上

　 3．不合格

　 1)标准第 2.1 条要求的材料不完整

　 2)软件不能运行

　 3) 软件需求说明书要求的主要功能 。

篇六：软件项目验收标准和验收方法

验收标准

　第 1 页 共 6 页

　软件系统验收标准 1. 前言.......................................................................................................................... 2 1.1. 目的............................................................................................................ 2 1.2. 范围............................................................................................................ 2 1.3. 参考............................................................................................................ 2 2. 交付物 ...................................................................................................................... 2 2.1. 软件系统的运行程序及源代码 ..................................................................... 2 2.2. 文档............................................................................................................ 2 3. 验收项目................................................................................................................... 3 3.1. 用户验收测试�UAT� ................................................................................ 3 3.2. 性能测试..................................................................................................... 3 3.3. 文档测试..................................................................................................... 3 3.4. 安全测试..................................................................................................... 4 4. 错误等级................................................................................................................... 4 5. 验收报告................................................................................................................... 5

　系统验收标准

　第 2 页 共 6 页

　 1. 前言 1.1. 目的 为了使软件系统验收更具可操作性和标准化�特制定此验收标准。

　1.2. 范围 适用于公司所有类型软件项目�包括产品研发类、合同开发类、项目实施类以及系统集成类�的验收标准确定。

　本标准应在软件合同签订时制定�并作为软件的质量标准指导软件生产。

　1.3. 参考 《GB/T 16260-2006 软件工程产品质量》 《GB/T 15532-2008 计算机软件测试规范》 2. 交付物 2.1. 软件系统的运行程序及源代码 2.2. 文档 编号 名称 备注 1 项目开发计划

　2 需求分析说明书

　3 系统设计说明书

　4 总体设计说明书

　5 数据库设计说明书

　6 源代码

　7 功能、性能测试方案

　8 功能、性能测试报告

　9 项目实施报告

　10 系统配置参数

　11 系统管理维护说明书

　12 用户操作手册

　13 系统使用到的第三方产品的技术说明、维护文档

　系统验收标准

　第 3 页 共 6 页

　14 培训计划

　15 项目开发工作总结

　 3. 验收项目 3.1. 用户验收测试�UAT� 1) 测试用例不通过数的比例< 1.5 %� 2) 不存在错误等级为1 的错误� 3) 不存在错误等级为2 的错误� 4) 错误等级为3 的错误数量≤ 5� 5) 所有提交的错误都已得到更正� �错误等级详见第四章错误等级� 3.2. 性能测试 1) 提供性能测试报告� 2) 相关重要指标达到以下要求� 系统分类 响应时间 并发量 外部互联网类系统 <1S >1500 内部平台类系统 <1S >800 内部业务操作类系统 <2S >500 内部办公类系统 <3S >200

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

　系统验收标准

　第 4 页 共 6 页

　5) 用户文档是否有详细的目录表和索引表� 3.4. 安全测试 1) 软件中的密钥是否以密文方式存储� 2) 软件是否有留痕功能�即是否保存有用户的操作日志� 3) 软件中各种用户的权限分配是否合理� 4) 安全扫描是否未扫描出任何安全漏洞及隐患� 4. 错误等级 严重级别 描述 详细说明 1-严重 导致系统崩溃、异常死机、服务停止、数据库混乱及系统不能正常运行�不能进行安装等。

　1. 功能引起系统崩溃� 2. 由于程序所引起的死机,非法退出� 3. 死循环� 4. 数据库设计未达到第三方的要求或需求规格说明的要求� 5. 因错误操作迫使程序中断� 6. 数据丢失�数据严重计算错误� 7. 错误产生的影响波及面广�并且隐蔽性高� 8. 数据库发生死锁。

　2-关键 需求说明书中要求的重要功能没有实现。重要功能未实现、不完整、功能出现问题并导致其它功能及模块出现问题。

　1. 主要功能遗漏� 2. 程序接口错误�数据库的表、业务规则、缺省值未加完整性等约束条件� 3. 规定的功能没有实现或不完整、设计不合理造成性能低下�影响系统的运营� 4. 异常的操作和数据导致系统产生严重的处理错误� 5. 系统功能实现可能出现由于缺乏处理规则导致产生业务脏数据� 6. 严重的数据错误�金额、关键信息等�� 7. 工作流错误� 8. 提交给客户的重要文件�包含但不局限于信函、保单、批单、短信、凭证、通知书等�打印内容、格式错误。

　3-一般 功能存在缺陷�存在数据控制错误�影响单个的功能运行的问题。

　1. 非重要功能缺失� 2. 健壮性不强�如非常规操作会导致在运行期间所执行任务的实际结果与预期的结果有差别�

　系统验收标准

　第 5 页 共 6 页

　严重级别 描述 详细说明 3. 轻微数据错误。

　4-轻微 不影响业务运行的功能问题�对非法数据没有进行有效控制�功能可以进一步改进。

　1. 操作界面错误�包括数据窗口内列名定义、含义是否一致�� 2. 简单的输入限制未放在前台进行控制� 3. 删除操作未给出提示� 4. 数据库表中有过多的空字段� 5. 不影响业务运营的功能/性能问题� 6. 由于不充分的数据引起的不正确或不精确�如数据的有效数字太少不足以做精确的计算� 7. 错别字。

　5-微小 建议性缺陷�满足需求功能,使用不方便、不合理、界面不友好或风格不统一�提示内容错误或不完整。

　1. 界面不规范� 2. 辅助说明描述不清楚� 3. 界面风格不易于操作� 4. 输入输出不规范� 5. 长时间交易处理未给用户提示� 6. 提示窗口文字未采用行业术语� 7. 可输入区域和只读区域没有明显的区分标志。

　5. 验收报告 项目验收报告模板

　文档编号�

　系统验收标准

　第 6 页 共 6 页

　 项目名称

　甲方

　 甲方联系人

　甲方联系电话

　乙方

　乙方联系人

　乙方联系电话

　验收组成员

　 项目概况

　交付文档

　验收结果

　 甲方签章�签字��

　 年

　 月

　 日 乙方签章�签字��

　年

　 月

　日 备

　 注�

推荐访问:软件项目验收标准和验收方法 验收 验收标准 方法