环境信息系统测试与验收规范-软件部分(HJ728-2014).pdf

《环境信息系统测试与验收规范-软件部分(HJ728-2014).pdf》由会员分享，可在线阅读，更多相关《环境信息系统测试与验收规范-软件部分(HJ728-2014).pdf（35页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、I 中华人民共和国国家环境保护标准中华人民共和国国家环境保护标准 HJ 728-2014 环境信息系统测试与验收规范 软件部分 Specification for Test and Acceptance of Environmental Information Systems The software part（发布稿）本电子版为发布稿。请以中国环境科学出版社出版的正式标准文本为准。2014-12-25发布 2015-03-01实施 发 布发 布环境保护部环境保护部II 目 次 前 言.II 1 适用范围.1 2 术语和定义.1 3 测试部分.2 4 验收部分.10 附录 A（资料性附录）测试

2、与验收文档集示例.20 III 前 言 为贯彻中华人民共和国环境保护法，促进环境信息化工作，规范环境信息系统的测试与验收流程，确保环境信息系统的质量与性能，制定本标准。本标准规定了环境信息系统（软件部分）测试与验收的策划、实施、监视和评审、纠正及预防等管理流程，用于指导开发方、用户方及第三方对新开发软件、二次开发软件及商用软件的测试与验收工作。本标准的附录 A 为资料性附录。本标准为首次发布。本标准由环境保护部科技标准司组织制订。本标准主要起草单位：环境保护部信息中心、江苏省环境信息中心。本标准环境保护部 2014 年 12 月 25 日批准。本标准自 2015 年 3 月 1 日起实施。本标

3、准由环境保护部解释。1 环境信息系统测试与验收规范软件部分 1 适用范围 本标准规定了环境信息系统（软件部分）测试与验收的策划、实施、监视和评审、纠正及预防等流程，用于指导开发方、用户方及第三方对新开发软件、二次开发软件及商用软件的测试与验收工作。本标准适用于全国各级环境保护部门开发的各类新开发软件、二次开发软件以及商用软件。2 术语和定义 下列术语和定义适用于本标准。2.1 环境信息系统 Environmental Information System 对环境保护业务数据进行集成、处理或展示的核心管理软件；实现环境保护实际业务需求的辅助决策系统、管理控制系统、办公自动化系统以及数据和业务交换

4、接口的总称。2.2 测试 Test 由一个或多个测试用例组成的集合；或者由一个或多个测试规程组成的集合；或者由一个或多个测试用例或规程组成的集合。2.3 验收 Acceptance 按照一定标准针对以项目方式开发的软件，依据合同、软件需求说明书（SRS）等对成品进行检验，确认项目质量是否达到用户所需的要求。2.4 测试组织 Testing Organization 环境信息系统的用户或者用户委托的第三方测试机构。2.5 测试用例 Test Case 为具体的目标（例如，为练习具体的程序路径或验证对特定需求的遵循性）而开发的一组测试输入、执行条件和预料的结果。对于测试项、规定输入、预料的结果和一

5、组执行条件的文档。2.6 验收组织 Acceptance Organization 用户方或者是用户委托的第三方验收组织（包括用户方委托的专家组等形式）。2.7 项目计划 Project Plan 项目的综合管理计划。2.8 用户文档 User Documentation 以打印或非打印形式得到的文档的完整集合，是产品、定制开发的软件和解决方案的必备部分。23 测试部分 3.1 一般要求 3.1.1 覆盖范围 3.1.1.1 国家级环境信息系统 国家级环境信息系统是由国家级环境保护部门批准建设的环境信息系统。此类系统的测试组织为环境保护部或环境保护部认可的第三方软件评测机构。3.1.1.2 省

6、级环境信息系统 省级环境信息系统是由各省级环境保护部门批准建设的环境信息系统。此类系统的测试组织为省级环境保护行政主管部门或省级环境保护行政主管部门认可的第三方软件评测机构。3.1.1.3 地、市级环境信息系统 地、市级环境信息系统是由各地市级环境保护部门批准建设的环境信息系统。此类系统的测试组织为地、市级环境保护行政主管部门或地、市级环境保护行政主管部门认可的第三方软件评测机构。3.1.1.4 区、县级环境信息系统 区、县级环境信息系统是由各区、县级环境保护部门批准建设的环境信息系统。此类系统的测试组织为区、县级环境保护行政主管部门或区、县级环境保护行政主管部门认可的第三方软件评测机构。3.

7、1.2 系统规模 根据系统所对应的信息安全等级保护级别将系统规模分为 I 至 V 级，分别对应信息安全等保制度中的第一级到第五级，如表1所示。表表1 系统规模划分系统规模划分 系统规模系统规模 对象对象 对应等保级别对应等保级别 I 第一级 II 一般系统 第二级 III 第三级 IV 重要系统 第四级 V 极端重要系统 第五级 3.1.3 系统类型 a)新建系统：指在合同执行前并不存在，需要承建单位进行开发的系统；3b)二次开发系统：此类系统包括三类，即部分开发的系统、订购方提供的系统和可重用的系统。部分开发的系统，通常是指在合同执行前业已存在或部分存在，但在交付前还需进行修改的系统；订购方

8、提供的系统，通常是指可以得到其源代码，但需要承建单位评价、开发或修改部分代码方可投入使用的系统；可重用系统，通常是指承建单位拥有源代码，能够开发或修改文档，通过调用代码就可以实现相关功能的系统；c)商用系统：即产品系统，此类系统一般只有目标码和用户手册，获取系统的源代码很困难，用户或承建单位无法自由对系统进行修改。3.1.4 测试级别 a)单元测试：是指系统开发过程中要进行的最低级别的测试活动。在单元测试活动中，系统的独立单元将与程序的其他部分在相隔离的情况下进行测试；b)集成测试：是指在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成的测试活动；c)系统测试：是指将已经

9、确认的系统、计算机硬件、外设、网络等元素结合起来，进行组装测试和确认测试的活动。目的是验证系统是否满足了需求规格的定义，找出不合格之处；d)回归测试：是指修改了代码后，重新进行的测试活动。目的是确认修改没有引入新的错误或导致其他代码产生错误。3.1.5 系统规模、测试级别与系统类型的对应关系 系统规模、测试级别与系统类型的对应关系如表2所示。表表2 系统规模、测试级别与系统类型对应关系表系统规模、测试级别与系统类型对应关系表 测试级别测试级别 系统系统 规模规模 新建系统 二次开发系统二次开发系统 商用系统商用系统 I 集成测试、系统测试（主要功能）、回归测试 集成测试、系统测试(主要功能)、

10、回归测试 系统测试(主要功能)、回归测试 II 单元测试、集成测试、系统测试(主要功能)、回归测试 单元测试（对修改的部分）、集成测试、系统测试(主要功能)、回归测试 系统测试(主要功能)、回归测试 III 单元测试、集成测试、系统测试(全功能)、回归测试 单元测试（对修改的部分）、集成测试、系统测试(全功能)、回归测试 系统测试(全功能)、回归测试 IV 单元测试、集成测试、系统测试(全功能)、回归测试 单元测试、集成测试、系统测试(全功能)、回归测试 系统测试(全功能)、回归测试 4V 单元测试、集成测试、2次以上系统测试(全功能)、回归测试 单元测试（对修改的部分）、集成测试、2次以上系

11、统测试(全功能)、回归测试 2次以上系统测试(全功能)、回归测试 3.1.6 相关角色和职责 3.1.6.1 按照环境信息系统测试与验收要求，环境信息系统测试与验收规范相关角色分为以下四类：a)环境保护部门：负责环境信息系统测试策划和流程管理；b)监理机构：负责监督和控制环境信息系统的测试流程；c)系统承建单位：负责环境信息系统的实施；d)第三方软件评测机构（或外聘厂家、专家）：负责环境信息系统开发全流程的测试管理。3.1.6.2 系统规模与第三方软件评测机构及资质要求对应关系如表 3 所示。表表3 系统规模与第三方软件评测机构及资质要求对应表系统规模与第三方软件评测机构及资质要求对应表 系统

12、规模系统规模 第三方软件测评机构第三方软件测评机构 资质要求资质要求 I II 符合 ISO17025 体系要求的第三方软件评测机构。III 省级以上软件评测机构。IV 通过国家认可委评定，具有 CNAS 资质的软件评测机构。V 通过国家认可委评定，具有 CNAS 资质的软件评测机构。注：表示必须选取，表示可以选取 3.2 测试管理流程 3.2.1 测试管理流程图 测试管理流程主要由策划、实施、监视和评审、纠正与预防、记录测试管理流程5个部分组成，其流程图如图1所示。5 图图1 测试管理流程测试管理流程 3.2.2 测试策划 3.2.2.1 内容和要求 测试策划主要是进行测试需求分析，确定需要

13、测试的内容或质量特性；确定测试的充分性要求；提出测试的基本方法；确定测试的资源和技术需求；进行风险分析与评估；制定测试计划（含资源计划和进度计划）。如果计划测试由第三方软件评测机构实施，则必须是满足系统规模与第三方软件评测机构及资质要求的第三方软件评测机构。3.2.2.2 测试计划 3.2.2.2.1 在实施测试前，测试组织应根据环境信息系统的合同（或项目计划）、被测环境信息系统的开发合同或系统/子系统的设计文档来策划测试过程，制定测试计划。监理机构应协助测试组织制定测试计划，并督促项目承建单位按照计划的要求开展工作。3.2.2.2.2 测试计划的主要内容 a)确定测试充分性要求。确定测试应覆

14、盖的范围及每一范围所要求的覆盖程度；6b)确定测试终止的要求。指定测试过程正常终止的条件（如测试充分性是否达到要求），并确定导致测试过程异常终止的可能情况；c)确定环境信息系统测试的质量目标；d)确定用于测试的资源要求，包括软件、硬件、人员数量和人员技能等；e)确定需要测试的环境信息系统特性。根据合同或系统/子系统设计文档的描述，确定系统的功能、性能、状态、接口、数据结构、设计约束等内容和要求，并从中确定需测试的环境信息系统特性；f)确定测试需要的技术和方法，如测试数据生成和验证技术、测试数据输入技术、测试结果获取技术、是否使用标准测试集等；g)根据合同或项目计划的要求和环境信息系统的特点，确

15、定测试准出条件；h)确定由资源和被测系统决定的测试活动的进度；i)对测试工作进行风险分析与评估，并制订应对措施。3.2.2.2.3 测试计划评审 测试组织应组织相关方对测试计划进行评审。在测试计划通过评审后，进入下一步工作；否则，需要重新进行策划。测试计划评审要点包括但不限于以下内容：a)测试计划的范围和内容、资源、进度、各方责任等是否明确；b)测试方法是否合理、有效和可行，风险的分析、评估与对策是否准确可行；c)测试文档是否符合规范，测试活动是否独立。3.2.3 测试实施 3.2.3.1 测试设计 3.2.3.1.1 前提 依据测试需求，设计测试大纲，分析并选用已有的测试用例或设计新的测试用

16、例；获取并验证测试数据；根据测试资源、风险等约束条件，确定测试用例执行顺序；获取测试资源，开发测试系统；建立并校准测试环境；进行测试就绪评审。3.2.3.1.2 步骤 测试组织应依据测试计划进行测试设计，测试设计一般包含以下步骤：a)设计测试大纲。依据测试需求，明确测试所需针对的项目，设计测试步骤，建立测试大纲；b)评审测试大纲，发现测试大纲的问题，针对问题修改测试大纲；c)设计测试用例。将需测试的环境信息系统特性分解，针对分解后的每种情况设计测试用例；7d)获取测试数据，包括获取现有的测试数据和生成新的数据，并按照要求验证所有数据；e)确定测试顺序，可从资源约束、风险以及测试用例失效造成的影

17、响或后果几个方面考虑；f)获取测试资源，对于支持测试的系统，有的需要从现有的工具中选定，有的需要开发；g)编写测试程序，包括开发测试支持工具；h)建立和确认测试环境；i)编写测试说明。3.2.3.1.3 测试就绪评审 测试组织应组织用户方委托的专家组或用户委托的第三方测试机构进行测试就绪评审。测试就绪评审主要评审测试大纲、测试计划的合理性；测试用例的正确性、有效性和覆盖充分性；测试组织、环境和设备工具是否齐备并符合要求。在进入下一步工作之前，应通过测试就绪评审。3.2.3.2 测试实施 3.2.3.2.1 测试组织依据测试计划执行测试用例，获取测试结果，分析并判定测试结果。同时，根据不同的判定

18、结果采取相应的措施。3.2.3.2.2 对测试过程的正常或异常终止情况进行核对，并根据核对结果，对未达到测试终止条件的测试用例，决定是停止测试还是需要修改或补充测试用例集，并进一步测试。3.2.3.2.3 测试执行的工作包括以下内容：a)根据每个测试用例的期望测试结果、实际测试结果和评价准则判定该测试用例是否通过，并将结果记录在测试记录中。如果测试用例不通过，测试组织应认真分析情况，并根据以下情况采取相应措施：1）测试说明和测试数据的差错。采取的措施是：改正差错，将改正差错信息详细记录，然后重新运行该测试。2）执行测试步骤时的差错。采取的措施是：重新运行未正确执行的测试步骤。3）测试环境中的差

19、错。采取的措施是：修正测试环境，将环境修正情况详细记录，重新运行该测试；若不能修正环境，记录理由，再核对终止情况。4）环境信息系统的实现差错。采取的措施是：填写问题报告单，可提出系统修改建议，然后继续进行测试；或者把差错与异常终止情况进行比较，核对终止情况。信息系统变更完毕后，应根据情况对其进行回归测试。85）环境信息系统的设计差错。采取的措施是：填写问题报告单，可提出修改建议，然后继续进行测试；或者把差错与异常终止情况进行比较，核对终止情况。信息系统变更完毕后，应根据情况对其进行回归测试或重新组织测试，回归测试中需要相应的修改测试设计和数据。6）环境信息系统的安全差错。采取的措施是：填写问题

20、报告单，可提出修改建议，然后继续进行测试；或者把差错与异常终止情况进行比较，核对终止情况。信息系统变更完毕后，应根据情况对其进行回归测试，回归测试中需要相应的修改测试设计和数据。b)当所有的测试用例都执行完毕，测试组织要根据测试的充分性要求和失效记录，确定测试工作是否充分，是否需要增加新的测试。当测试过程正常终止时，如果发现测试工作不足，应对系统进行补充测试，直到测试达到预期要求，并将附加的内容记录在测试报告中；如果不需要补充测试，则将正常终止情况记录在测试报告中。当测试过程异常终止时，应记录导致终止的条件、未完成的测试和未被修正的差错。c)当所有导致测试异常终止的差错都被修正后，需对测试对象

21、再次进行回归测试以确认修改没有引入新的错误或导致其他代码产生错误。各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段；回归测试期间应对该系统版本冻结，将回归测试发现的问题集中修改，集中回归。监理机构应检查项目承建单位测试过程中的问题记录及其改正的记录，并监督项目承建单位解决测试中发现的问题和不合格项，提出监理意见。3.2.4 监视和评审 3.2.4.1 监视和评审包括规则检查和监督，监视和评审的结果应记录到测试报告中。3.2.4.2 测试组织依据测试计划监控测试实施过程，对实施过程与测试计划产生的偏差进行记录。3.2.4.3 测试组织应根据合同、测试计划、测试说明、

22、测试记录、测试问题报告单等，分析和评价测试工作，一般包括以下几项工作：a)总结测试计划和测试说明的变化情况及其原因，并记录在测试报告中；b)对测试异常终止情况，确定未能被测试活动充分覆盖的范围，并将理由记录在测试报告中；c)确定未能解决的测试问题以及不能解决的理由，并将理由记录在测试报告中；d)总结测试所反映的环境信息系统与合同、需求之间的差异，记录在测试报告中；e)将测试结果连同所发现的差错情况同需求或者合同对照，评价环境信息系统的设计与实现，提出改进建议，记录在测试报告中；f)编写测试报告，该报告应包括：测试结果分析、对环境信息系统的质量评价和建议；9g)根据测试记录和测试问题报告单编写测

23、试问题报告。3.2.4.4 测试组织应组织相关方对测试报告、测试记录和问题报告进行评审。评审包括测试活动的有效性、测试结果的正确性和合理性以及评审是否达到了测试目的、测试文档是否符合要求等。3.2.5 纠正与预防 3.2.5.1 纠正 测试组织应采取措施，以消除造成测试异常或差错的原因，防止测试异常或差错的再发生。纠正措施应与所遇到不合格的影响程度相适应。应编制形成文件的程序，以规定以下方面的要求：a)评审不合格；b)确定不合格的原因；c)评价确保不合格不再发生的措施的需求；d)确定和实施所需的措施；e)记录所采取措施的结果；f)评审所采取的纠正措施的有效性。3.2.5.2 预防 测试组织应确

24、定措施，以消除潜在不合格的原因，防止不合格的发生。预防措施应与潜在问题的影响程度相适应。应编制形成文件的程序，以规定以下方面的要求：a)确定潜在不合格及其原因；b)评价防止不合格发生的措施的需求；c)确定并实施所需的措施；d)记录所采取措施的结果；e)评审所采取的预防措施的有效性。3.2.6 记录测试管理流程 3.2.6.1 依据 测试管理活动应该可以被追溯。测试组织应提供用于测试管理过程记录的实施方法或工具。创建相关记录时，应考虑：a)管理目的可用效益相关信息；b)创建和维护记录的成本和效益；c)法律、法规和业务需要的记录；10d)使用方法，易用、可恢复的记录介质；e)保存期限；f)敏感程度

25、。3.2.6.2 输出的记录 3.2.6.2.1 测试管理流程输出记录 a)测试计划；b)测试说明；c)测试报告；d)测试记录和/或测试日志；e)测试问题报告。3.2.6.2.2 测试文档集的取舍和合并要求 根据系统的规模等级对测试文档集进行合理的选取与合并，其要求如表4所示。表表4 测试文档集的选取与合并要求测试文档集的选取与合并要求 系统规模 文档 I、II III、IV、V 测试计划 测试说明 测试报告 测试记录/测试日志 测试问题报告 注：表示选取，表示可以合并 4 验收部分 4.1 一般要求 4.1.1 验收前提 被验收系统应经过系统测试、具备合同或双方约定的验收依据文档规定的验收条

26、件。对委托开发系统，实施系统验收还应具备以下条件：a)被验收系统已通过确认测试；b)合同或双方约定的验收依据文档规定的各类文档齐全并通过评审；c)被验收系统已置于配置管理之下并得到有效控制。4.1.2 验收依据 系统验收依据是合同或验收双方约定的验收依据文档中所规定的各项内容。114.1.3 验收组织及人员组成 系统验收方负责指定或成立专门的验收组织。根据验收计划和被验收系统的具体情况，验收方可选取以下验收组织形式：a)第三方软件测评机构 第三方软件测评机构应从环境保护部或各级环境保护行政主管部门认可的软件测评机构中选取。b)专家组 专家组成员应具有被验收系统相关的专业知识，以及一定的系统测试

27、能力和经验。4.1.4 验收组织的任务 验收组织实施系统验收计划，包括下列任务：a)制定验收测试计划、验收审查计划；b)进行验收测试和验收审查；c)进行系统验收评审。4.1.5 验收各方职责 系统验收由验收方负责组织实施，验收方负责审批验收申请、制定验收计划、指定或成立验收组织、做出验收结论。验收方包括验收组织及监理机构，验收组织及监理机构的职责如下：验收组织负责验收测试、验收审查和验收评审。监理机构负责监督和控制环境信息系统的验收流程、出具相应的监理文档。被验收方一般是指系统承建单位，其职责定义如下：系统承建单位提供被验收的系统，包括程序、文档和数据；被验收方应积极支持、配合完成系统验收工作

28、，负责做好验收所需各项保障工作。验收各方应遵守验收双方规定的保密承诺。系统规模与验收参与各方要求如表5所示。表表5 系统规模与验收参与各方要求系统规模与验收参与各方要求 参与各方 系统规模 被验收方 验收方 I II 系统承建单位 验收组织 III IV V 系统承建单位 监理机构、验收组织 12注：注：系统规模III级以上的系统必须有监理机构全程参与系统验收工作。系统规模为I、II级的系统可以邀请监理机构参与系统验收工作。4.1.6 初验和终验 4.1.6.1 初验 初验：是指系统实现主要功能，达到用户方需求的最低功能要求。即将进入试运行阶段前组织的验收工作。初验结果：初验通过，系统进入试运

29、行期；初验不通过，记录导致不通过的原因，纠正错误后重新组织系统初验。4.1.6.2 终验 终验：是指系统完成4.1.5规定的所有需求，全部交付，并经过初验、试运行阶段，在即将进入运行阶段前组织的验收工作。终验结果：终验通过，系统验收工作完成进入运行维护阶段。终验不通过，记录导致不通过的原因，纠正错误后重新组织系统终验。系统规模与初验、终验要求如表6所示。表表6 系统规模与初验、终验要求 验收标准 系统规模 初验 终验 I II III IV V 注：表示必须，表示可以省略 4.1.7 验收程序 系统验收程序从验收方与被验收方进行设计交底开始到验收方完成验收活动终止。系统验收工作程序一般包括：a

30、)验收方与被验收方进行设计交底；b)被验收方向验收方及监理方提交系统验收申请；c)监理方协助验收方审批系统验收申请，出具监理报告；d)被验收方向验收方及监理方提交被验收系统及相关文档；e)监理方审核被验收系统及相关文档是否符合设计要求，是否齐全，出具监理意见；f)验收方制定系统验收计划；13g)验收方指定或成立系统验收组织；h)监理方协助验收组织进行验收测试、验收审查和验收评审，监理方出具监理意见；i)验收方根据验收组织提交的验收报告对被验收系统做出验收结论。如系统规模为I、II级，没有监理方参与，则可将工作程序中监理方职责合并至验收方职责中，对应的系统验收工作程序如下：a)验收方与被验收方进

31、行设计交底；b)被验收方向验收方提交系统验收申请；c)验收方审批系统验收申请；d)被验收方向验收方提交被验收系统及相关文档；e)验收方审核被验收系统及相关文档是否符合设计要求，是否齐全，并制定系统验收计划；f)验收方指定或成立系统验收组织；g)验收组织进行验收测试、验收审查和验收评审；h)验收方根据验收组织提交的验收报告对被验收系统做出验收结论。4.2 验收管理流程 4.2.1 工作程序 制定验收管理流程，首先需明确系统是否符合验收要求，程序是否完整、依据是否充足。如果符合要求，则按如下流程组织验收工作：a)被验收方向验收方提出系统验收申请，依据环境信息系统测试与验收规范所规定的申请程序，由被

32、验收方提交相关资料和文档；b)验收组织提出相关的验收策划要求，并依据项目合同或双方约定制定验收策划方案；c)验收组织依据验收计划执行验收，记录验收结果，分析并判定验收结果。根据不同的判定结果采取相应的措施，并需对系统验收过程进行审查；d)验收组织依据验收计划监控验收实施过程，对实施过程与验收计划产生的偏差进行记录，并根据合同、验收计划、验收记录等，分析和评价验收工作；e)在完成验收测试、验收审查后按规范要求进行验收评审，给出评审结论，验收组织在完成验收评审后,根据表决情况，由评审负责人在验收报告上签署验收评审结论；f)对发生问题/不合格，或评审组织质疑的项目，需按本标准要求制定纠正和预防措施，

33、防治问题或不合格项目再次发生，并记录验收管理流程。验收管理流程如图2所示。14 图2 验收管理流程 4.2.2 验收申请 4.2.2.1 申请程序 被验收方向验收方提交系统验收申请报告，概要说明申请验收的系统满足4.1.1的要求。系统验收申请报告应由被验收方的负责人签字。对于委托开发系统，验收申请报告（格式参见附录A1.6）主要内容应包括：系统名称、系统研制任务来源、系统用途及组成、主要功能与性能、系统研制情况、研制阶段评审情况、系统测试情况、配置管理情况及满足主要业务技术指标情况等。对于商用系统及其他系统，验收申请报告主要内容应包括：系统名称、系统用途及组成、主要功能与性能以及文档清单。验收

34、方在收到系统验收申请报告后，应当及时了解被验收系统的功能、性能及文档等方面的内容，由监理机构协助检查其是否与4.1.1规定的要求相一致，并对被验收方提出的系统通过不通过通过不通过不通过 通过 不通过 不通过 验收申请 资料提交 验收策划验收计划 验收审查 修改错误 资料审核 记录原因、纠正错误、重新进行审查 验收测试 验收实施 计划评审 通过 通过 验收评审 记录原因、纠正错误、重新进行验收评审 形成验收报告 15验收申请报告进行审查，对符合验收条件的应予以批准，并通知被验收方；对不符合验收条件的应退回被验收方，并说明原因。4.2.2.2 被验收方应提交的资料 对于委托开发的系统，被验收方在提

35、交系统验收申请报告时，应提供被验收系统的确认测试报告及其评审结论以及4.1.5所规定的文档清单和软件产品清单。对于商用系统及其他系统，被验收方在提交系统验收申请报告时，应提供被验收系统的产品规格说明以及4.1.5所规定的文档清单和软件产品清单。4.2.2.3 被验收系统及相关文档的提交 被验收方在接到系统验收申请的批准通知后，应及时向验收方提交4.1.5所规定应交付的软件产品及其相关文档。4.2.3 验收策划 4.2.3.1 策划要求 4.2.3.1.1 策划内容 验收策划主要是进行验收需求分析，确定需要验收的内容或质量特性；确定验收的充分性要求；提出验收的基本方法；确定验收的资源和技术需求；

36、进行风险分析与评估；制定验收计划。4.2.3.1.2 验收计划 在实施验收前，监理机构协助验收组织根据合同、需求制定验收计划，验收计划应根据4.1.5中的约定，确定是否由各级环保部门认可的第三方软件测评机构进行验收测试、验收审查和验收评审。验收计划一般包括以下内容：a)明确验收的范围；b)明确验收的时间；c)明确验收的地点；d)明确验收的环境；e)明确验收的资源；f)明确验收的方法；g)明确质量目标；h)对验收工作进行风险分析与评估，并制订应对措施；i)确定验收终止的要求，指定验收过程正常终止的条件，并确定导致验收过程异常终止的可能情况；j)根据合同或项目计划的要求和环境信息系统的特点，确定验

37、收准出条件；k)应对验收过程中的验收记录工作提出要求。164.2.3.1.3 验收计划的评审 验收组织应组织监理方、用户方委托的第三方验收机构或专家组对验收计划进行评审。评审要点包括但不限于以下内容：a)验收计划的范围和内容、资源、进度、各方责任等是否明确；b)验收方法是否合理、有效和可行，风险的分析、评估与对策是否准确可行；c)验收文档是否符合规范，验收活动是否独立。验收计划在得到验收方和被验收方的协商认可后实施。在验收计划通过评审后，进入下一步工作；否则，需要重新进行策划。4.2.4 验收实施 4.2.4.1 验收测试的步骤 验收测试应符合本标准3.2 测试管理流程的规定。4.2.4.2

38、验收审查的步骤 a)制定验收审查计划，应包括：审查目的、审查范围、审查对象、审查内容、审查准则、审查方法、人员分工、进度安排等；b)进行验收审查，建立完整的验收审查记录；c)编写验收审查报告（格式参见附录A1.7）。4.2.4.3 验收审查的内容 验收审查包括功能验收审查、物理验收审查和安全性验收审查。功能验收审查验证被验收系统功能和接口与4.1.5中要求的一致性。物理验收审查检查文档的完整性、程序和文档的一致性、文档和文档的一致性、交付的产品与4.1.5要求的一致性等情况。安全性验收审查应验证安全性测试文档、测试结果是否符合4.1.5规定的安全需求。当验收执行完毕，验收组织要根据验收的充分性

39、要求和失效记录，确定验收工作是否充分，是否需要增加新的验收。当验收过程异常终止时应记录导致终止的条件、未完成的验收和未被修正的差错。4.2.5 监视和评审 4.2.5.1 监视和评审的内容 监视和评审包括规则检查和监督，这些检查和监督可以是已经存在的或者是定期不定期的。监视和评审的结果应记录到验收报告中。验收组织依据验收计划监控验收实施过程，对实施过程与验收计划产生的偏差进行记录。验收组织应根据合同、验收计划、验收记录等，分析和评价验收工作，一般包括下面几项工作：17a)总结验收计划的变化情况及其原因，并记录在验收报告中；b)对验收异常终止情况，确定未能被验收活动充分覆盖的范围，并将理由记录在

40、验收报告中；c)确定未能解决的问题以及不能解决的理由，并将理由记录在验收报告中；d)总结验收所反映的环境信息系统与合同、需求之间的差异，记录在验收报告中；e)将验收结果连同所发现的差错情况同需求或者合同对照，评价环境信息系统的设计与实现，提出改进建议，记录在验收报告中；f)编写验收报告，该报告应包括：验收结果分析、对环境信息系统的评价和建议。验收组织应组织相关方对验收报告进行评审。评审验收执行活动的有效性、验收结果的正确性和合理性。评审是否达到了验收目的、验收文档是否符合要求。4.2.5.2 评审的时机 验收评审应在完成验收测试、验收审查后进行。4.2.5.3 评审的形式 验收评审一般应采用会

41、议评审形式，根据被验收系统的完整性级别等具体情况验收评审，还可以采取现场评审或验收双方认可的其他形式。4.2.5.4 评审的通过准则 a)被验收系统通过验收测试；b)被验收系统通过验收审查；c)被验收系统满足双方约定的其他验收准则。4.2.5.5 评审的程序 a)验收组织审查验收测试报告、验收审查报告；b)根据评审通过准则验收组织就被验收系统是否通过验收进行表决；c)根据表决情况，做出评审结论。4.2.5.6 评审结论 依据评审通过准则，验收组织对被验收系统进行综合评价，最后由参加验收评审的成员进行表决，做出被验收系统是否通过验收的结论。4.2.5.7 验收报告 验收组织在完成验收评审后，填写

42、验收报告（格式参见附录A1.8）。验收报告的内容应包括验收依据、验收内容、验收过程、验收准则、验收测试结论、验收审查结论、表决情况等。根据表决情况，由评审负责人在验收报告上签署验收评审结论。参加验收评审的成员应在验收报告上签字。验收结论分为两种：18a)同意通过验收：系统规模为III、IV、V级的系统验收需由参加验收评审的成员一致同意；系统规模为I、II级的系统验收需由参加验收评审成员的三分之二以上同意；b)不同意通过验收：同意验收通过的参加验收评审的成员数达不到通过的要求。4.2.6 纠正与预防 4.2.6.1 纠正 验收组织应采取措施，以消除不合格的原因，防止不合格的再发生。纠正措施应与所

43、遇到不合格的影响程度相适应。应编制形成文件的程序，以规定以下方面的要求：a)评审不通过；b)确定不合格的原因；c)评价确保不合格不再发生的措施的需求；d)确定和实施所需的措施；e)记录所采取措施的结果；f)评审所采取的纠正措施的有效性。4.2.6.2 预防 验收组织应确定措施，以消除潜在不合格的原因，防止不合格的发生。预防措施应与潜在问题的影响程度相适应。应编制形成文件的程序，以规定以下方面的要求：a)确定潜在不合格及其原因；b)评价防止不合格发生的措施的需求；c)确定并实施所需的措施；d)记录所采取措施的结果；e)评审所采取的预防措施的有效性。4.2.7 记录验收管理流程 4.2.7.1 记

44、录的创建依据 验收管理活动应该可以被追溯。验收组织应提供用于验收管理过程记录的实施方法或工具。创建相关记录时，应考虑：a)管理目的、可用效益相关信息；b)创建和维护记录的成本和效益；c)法律、法规和业务需要的记录；d)使用方法，易用、可恢复的记录介质；e)保存期限；19f)敏感程度。4.2.7.2 记录的输出 验收管理流程输出的记录：a)验收计划；b)验收报告；c)验收问题记录；d)验收问题报告。验收方根据验收组织提交的验收管理流程输出记录，正式做出被验收系统是否通过验收的结论，并通知被验收方。20 附录 A（资料性附录）测试与验收文档集示例 A.1 环境信息系统测试计划 1 概述概述 1.1

45、 目的 描述系统测试的目的以及测试与测试目的的相关性。1.2 背景 对被测试系统的软件特性、被测试特性等进行概述，同时描述测试范围以及与其他测试阶段的关系。1.3 使用的文档 列出所有被测试文档、支持软件测试的文档以及相关的标准。2 资源资源 2.1 人员要求 描述进行系统测试的工作人员所需的技能与专业知识以及其职责和权限，规定完成测试工作所需的人员数量，并对系统开发人员和测试人员之间的独立性程度要求进行描述。2.2 测试环境、工具和方法 对所选择的测试环境、测试工具和测试方法包括与其相关的合格性判定、标识和控制进行描述。2.3 设施/硬件 列出用于系统测试的设施、计算机硬件和接口硬件的规格要

46、求、数量及使用时间。这些设施的位置和硬件情况可能发生变化，视具体情况写出调整计划。2.4 接口/支持软件 列出系统测试所需的接口和支持软件（例如预处理程序、测试驱动程序、测试数据生成程序、后处理程序和其他计算机程序）。3 测试管理测试管理 3.1 测试组织和职责 描述在实施和协调系统测试活动中软件测试组织的构成、职责、权限以及构成人员之间的相互关系。3.2 被测试系统的控制 21 描述被测试系统在整个测试过程活动中的控制规程。3.3 测试控制 描述测试方控制系统测试活动的规程。3.4 评价和重复测试的准则 定义、分析、评价系统测试结果的管理规程。每个测试的评价准则（成功的测试准则或接受/拒收限

47、制）是确定系统测试成功和失败的依据。同时必须指明重复系统测试的准则。3.5 测试数据环境 指明生成和确认在测试中使用的系统数据库的活动，并提供：a)标定或校准测试数据；b)强度测试数据（包括有干扰或其他不完整的数据）。3.6 测试报告 指明制定系统测试报告的要求和规程，确定系统测试报告的发放和控制方法。4 测试结构设计测试结构设计 4.1 测试层次 指明并描述每个被测试系统的层次（按功能的扩充分层，例如任务、子功能、功能）。4.2 测试方法 描述系统测试的方法、步骤和顺序。并描述强化软件系统的概念和方法（如用有干扰的或不完全的输入数据或峰值加载）。4.3 测试输入 指明每一层被测试的系统实体如

48、何获取必要的测试数据。4.4 测试用例/测试分类 对测试用例和测试分类进行描述。4.5 测试标识 标识和描述系统测试的过程与活动。内容描述如下：a)测试标识；b)目的；c)测试要素；d)输入数据；e)输出数据；f)测试过程；g)评价方法/接受准则。225 进度进度 描述测试的进度安排与计划网络图。6 测试开始、完成标志与判断准则测试开始、完成标志与判断准则 6.1 测试活动的开始 描述系统测试的进入条件及开始准则。6.2 测试活动的完成 定义系统测试的结束判断准则与结束标志。7 有关事项说明有关事项说明 对有关事项如安全性、保密性等进行说明。同时，有关事项说明中还包括测试过程中发现问题的处理规

49、程，包括暂停准则和继续进行的要求等。附件 23A.2 环境信息系统测试用例 系统名称：合同号或测试依据文档标识：用例名称 用例标识 测试追踪 用例说明 硬件配置 系统配置 测试配置 用例的初始化 参数设置 操作过程 序号 输入及操作说明 期望的测试结果 评价标准 备注 前提和约束 过程终止条件 结果评价标准 设计人员 设计日期 24A.3 环境信息系统测试记录 系统名称：合同号或测试依据文档标识：用例名称 用例标识 用例说明 硬件配置 系统配置 测试配置 用例的初始化 参数设置 操作过程 序号 输入及操作说明 期望的测试结果 评价标准 实测结果 是否发生重启动 重启动是否成功 是否发生失效 是

50、否发生故障 测试结论 测试人员 测试日期 25A.4 环境信息系统测试报告 测试报告样例测试报告样例 1 简介简介 1.1 编写目的编写目的 实例：本测试报告为 XXX 系统的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到 XXX 功能目标）。预期参考人员包括用户、测试人员、开发人员、系统管理者、其他质量管理人员和需要阅读本报告的其他管理人员。1.2 项目背景项目背景 对项目目标和目的进行简要说明。必要时包括简史。1.3 系统简介系统简介 注意必要的框架图和网络拓扑图。1.4 术语和缩写词术语和缩写词 列出设计本系统/项目的专用术语和缩写语约定。对于技术相关