软件验收流程

软件验收流程软件验收流程软件验收流程资料仅供参考文件编号：2022年4月软件验收流程版本号：A修改号：1页次：1.0审核：批准:发布日期：项目验收

验收作为项目执行过程中的一个重要的里程碑，对公司和客户具有重要的意义。一、验收申请二、验收准备充分的验收准备为验收测试结果的准确性提供了保证。开发商提交的验收文档应保证软件开发涉及的所有过程已经全部置于文档控制之下，文档应包括软件开发中使用的辅助设计软件的工程文件，例如数据库设计软件PowerDesigner，流程设计软件Rose等等。在验收准备期间广泛听取最终用户的使用意见，可以为有针对性的检查软件的缺陷提供帮助。验收准备阶段的工作包括收集开发商编制的源码、文档、安装程序、控件等，还包括向最终用户（甲方）项目组征集满意度调查表；期间应确定开发商和最终用户的固定联系方式。2．1开发商资料收集根据软件项目的特点，在验收时应收集以下文档：编号名称形式介质1项目开发计划文档电子、纸质2软件需求说明书文档电子、纸质3系统概要设计说明书文档电子、纸质4总体设计说明书文档电子、纸质5数据库设计说明书文档电子、纸质6详细设计文档文档电子、纸质7为本项目开发的软件源代码文档电子、纸质8FAT&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集成测试/压力测试常见的黑盒测试包括：集成测试，系统测试。集成测试是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。通过一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作，在协同工作时是否能够达到功能要求。对于B/S程序来说压力测试主要是用户数测试（需要使用专业测试软件，如LoadRunner等），C/S程序主要是软件承载数据量大小测试。甲方需要根据操作手册，将所有功能在发布后的软件上设计并测试测试用例；能够完整运行需求列举的所有功能即完成集成测试；压力测试就是在高负载的情况下完整运行所有功能。3．7验收测试目的是检验待验收软件是否对平台和其它软件保持良好的兼容性。四、验收结论(成绩评定标准)验收结束