软件综合项目验收作业流程各步骤内容.doc

项目验收过程
验收作为项目实施过程中一个关键里程碑，对企业和用户含相关键意义。
一、验收申请
二、验收准备
2．1开发商资料搜集
依据软件项目标特点，在验收时应搜集以下文档：
编号
名称
形式
介质
1
项目开发计划
文档
电子、纸质
2
软件需求说明书
文档
电子、纸质
3
系统概要设计说明书
文档
电子、纸质
4
总体设计说明书
文档
电子、纸质
5
数据库设计说明书
文档
电子、纸质
6
具体设计文档
文档
电子、纸质
7
为本项目开发软件源代码
文档
电子、纸质
8
FAT&SAT汇报
文档
电子、纸质
9
试运行汇报
文档
电子、纸质
10
性能测试汇报、功效测试汇报
文档
电子、纸质
11
项目实施汇报
文档
电子、纸质
12
培训计划
文档
电子、纸质
13
服务计划
文档
电子、纸质
14
维护手册
文档
电子、纸质
15
用户手册
文档
电子、纸质
16
应用软件清单
文档
电子、纸质
17
系统参数配置说明
文档
电子、纸质
18
所提供第三方产品技术说明和操作、维护资料
文档
电子、纸质
19
系统瓦解及恢复步骤文档
文档
电子、纸质
20
技术服务和技术培训等相关资料
文档
电子、纸质
21
项目总结汇报
文档
电子、纸质
除上述文档外，还应单独搜集、保留各应用软件源程序代码及开发商所用第三方资源信息。开发商所使用第三方控件，除已经得到审计署许可之外，必需提供控件源代码，并拥有授权使用证实或确保（由开发商提供无版权争议承诺书）；对于原始程序代码，要求能够在当地不经过任何特殊设置，即可编译并正常运行。源程序清单中列举项目应该和源程序一一对应。
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) 软件需求说明书要求关键功效 。