金审工程应用软件验收指南

根据国家有关软件验收标准，结合金审工程(一期)应用系统建设实际情况，制订本验收办法。                                  第1章  验收准备     充分的验收准备为验收测试结果的准确性提供了保证。开发商提交的验收文档应保证软件开发涉及的所有过程已经全部置于文档控制之下，文档应包括软件开发中使用的辅助设计软件的工程文件，例如数据库设计软件PowerDesigner，流程设计软件Rose等等。在验收准备期间广泛听取最终用户的使用意见，可以为有针对性的检查软件的缺陷提供帮助。验收准备阶段的工作包括收集开发商编制的源码、文档、安装程序、控件等，还包括向最终用户（甲方）项目组征集满意度调查表；期间应确定开发商和最终用户的固定联系方式。     1．1  开发商资料收集     根据金审工程软件项目的特点，在验收时应向开发商收集以下文档：     （1）可行性研究报告；     （2）项目立项报告；     （3）软件需求规格说明书；     （4）项目实施计划；     （5）数据库设计说明书；     （6）软件设计说明书。对一些规模较大或复杂性较高的项目，应该把本文档分成概要设计说明书与详细设计说明书两个文档；     （7）软件测试计划说明书；     （8）软件测试结果分析说明书；     （9）用户手册，包括使用手册与管理员维护手册；     (10)源程序清单；     (11)项目开发总结。     除上述文档外，还应单独收集、保存各应用软件源程序代码及开发商所用第三方资源信息。开发商所使用的第三方控件，除已经得到审计署的许可之外，必须提供控件的源代码，并拥有授权使用的证明或保证（由开发商提供无版权争议承诺书）；对于原始程序代码，要求能够在本地不经过任何特殊设置，即可编译并正常运行。源程序清单中列举的项目应该和源程序一一对应。     1．2  最终用户资料收集     依据软件开发需求说明书和概要设计说明书，编写相关软件的用户满意度调查表，该调查表应该涵盖软件在需求说明书中列举的所有模块，包含软件在不同操作系统下的运行情况等。最终用户或甲方项目组按照实际情况填写该调查表。                                        第2章  验收测试     验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动，它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方面检测。     金审工程软件验收测试分为三部分：文档代码一致性审核、软件配置审核和可执行程序测试，其顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序、平台API测试、集成测试、验收测试等。文档代码一致性审核、软件配置审核是软件部署和实施全面验收测试的基础，由各应用软件验收责任人检查它们的完整性；由于金审工程开发的各软件运行环境均基于审计管理系统、审计实施系统平台，最终的集成测试、验收测试由计算机技术中心所有参与验收工作的人员一起完成。     2．1  文档审核     文档审核的主要要求是确定软件开发的所有过程都在提交文档的控制下，对文档的具体要求如下：     (1）文档完备性：是否按照合同及其附件要求提交了全部文档； 　　(2） 内容针对性：指文档是否是甲方要求的文档；文档的内容应该按照功能模块的重要性在论）上达到不同的详细程度； 　　(3）内容充分性：指该文档全面、详细的程度； 　　(4）文档的价值：文档应该能够反映软件开发的整个过程，即需求中提到的功能在概要设计中体现，在详细设计中实现，在测试计划中检验； 　　(5）图表翔实性：是否包含了足够的图形和表格； 　　(6）符合甲方规范程度：是否很好地符合甲方要求的规范、标准； 　　(7）内容一致性：是否存在前后矛盾；是否存在需求说明中提到的功能在概要设计、详细设计中没有涉及的情况； 　　(8）文字明确性：不使用“可能”、“也许”、“待定”等语义含糊不清的语句； 　　(9）易读性：能够在一篇文档中说明清楚的内容，尽量不要拆分成若干文档，不要循环引用，文档目录一目了然，结构清晰。 　　2．2  源代码审核 源代码审核的主要要求是确保开发商将全部源程序交付甲方，并确保交付的代码没有版权问题（由开发商提供无版权争议承诺书）对源代码审核的具体要求如下： 　　2．2．1  版权明晰 　　（1）提交的代码中注释版权的地方均应去掉版权声明，或声明版权为审计署所有。 　　（2）得到甲方允许，可以使用的控件，由开发商提供无版权争议承诺书。使用其他的具有源代码的控件，均需要当作提交代码的一部分，直接置于编译环境的工程文件中，在编译发布时无需额外设置。 　　2．2．2  代码完整 　　（1）开发商必须把所有实现用户需求的代码交付甲方。 　　（2）除非已经得到甲方的允许，使用的控件也必须有源代码，并得到授权使用证明；由开发商提供无版权争议承诺书。 　　（3）包含开发工具的工程文件；要求能够在甲方计算机中正常编译、运行；除非得到甲方允许，在甲方计算机中编译的时候无需额外安装开发工具的插件或控件。 　　2．2．3  可读性强 　　（1）注释是软件可读性的具体体现。程序注释量不少于程序编码量的30%。程序注释不能用抽象的语言（如“处理”、“循环”等），要精确表达出程序的处理说明。为避免每行程序都使用注释，可以在一段程序的前面加一段注释，有明确的处理逻辑。 　　（2）对于Java要求开发商能够提供程序生成的JavaDoc。 　　2．3  配置文件审核 　　对于B/S程序，部署维护是软件生存周期中最长的一个过程，配置文件的审核显得尤为重要。对配置文件的审核要求与源代码的审核要求完全一致。 　　2．4  测试用例编写及测试程序、脚本审核 　　这个过程是在文档审核和配置脚本审核后，为了检验通过源代码编译后的程序是否满足设计需求。检验方式主要是API测试、集成测试、验收测试；这一阶段应该完成设计及其有关测试所包括的特性，还需要完成测试所需的测试用例和测试规程，并规定特性的通过准则。 　　（1）测试用例说明：列出用于输入的具体值以及预期的输出结果，并规定在使用具体测试用例时，对测试规程的各种限制。要求将测试用例与测试设计分开，可以使它们用于多个设计并能在其它情形下重复使用。 　　（2）测试规程说明：规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。     测试方案 　　（1）针对性测试方案：从满意度调查表中筛选出可能不符合需求设计的功能模块，编写针对具体模块设计的测试方案。这种方案的实现耗时短，根据实际使用情况调查软件的具体实现，适合在软件得到较大面积试用后采取的验收测试。 　　（2）抽样测试方案：在设计文档中随机选取，根据抽样的样本大小不同，最后得到的结论可能会出现差异。这种方案的实现耗时可长可短，适合软件未得到大面积适用前验收时采用。 　　2．5  平台API测试 常见的白盒测试是单元测试。单元测试是测试中最小单位的测试。简而言之，就是拿一个函数出来，加上驱动模块，让它能够运行起来，然后设计一些用例测试其内部的控制点（如：条件判断点、循环点、选择分支点等）。驱动模块是模拟调用被测函数的函数。 　　根据设计文档选取关键函数和所有开放的API，设计测试用例。 　　2．6  集成测试/压力测试 常见的黑盒测试包括：集成测试，系统测试。集成测试是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。通过一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作，在协同工作时是否能够达到功能要求。 　　对于B/S程序来说压力测试主要是用户数测试（需要使用专业测试软件，如LoadRunner等），C/S程序主要是软件承载数据量大小测试。 　　甲方需要根据操作手册，将所有功能在发布后的软件上设计并测试测试用例；能够完整运行需求列举的所有功能即完成集成测试；压力测试就是在高负载的情况下完整运行所有功能。 　　2．7  验收测试 　　目的是检验待验收软件集成在AO/OA平台上是否对平台和其它软件保持良好的兼容性；这需要甲方所有人员将所测试软件统一安装到集成测试环境后一同实现。 　　2．8  验收结论 　　验收结束时，根据以上文档，填写验收结论，对软件的质量做出评价。