路径: 主页 > HJ > 第17页 > HJ 728-2014 | 标准编号 | HJ 728-2014 (HJ728-2014) | | 中文名称 | 环境信息系统测试与验收规范--软件部分 | | 英文名称 | Specification for Test and Acceptance of Environmental Information Systems. The software part | | 行业 | 环保行业标准 | | 字数估计 | 35,357 | | 发布日期 | 12/25/2014 | | 实施日期 | 3/1/2015 | | 标准依据 | 环境保护部公告公告2014年第87号 | | 发布机构 | 生态环境部 | | 范围 | 本标准规定了环境信息系统(软件部分)测试与验收的策划、实施、监视和评审、纠正及预防等流程, 用于指导开发方、用户方及第三方对新开发软件、二次开发软件及商用软件的测试与验收工作。本标准适用于全国各级环境保护部门开发的各类新开发软件、二次开发软件以及商用软件。 | HJ 728-2014: 环境信息系统测试与验收规范--软件部分
HJ 728-2014 英文名称: Specification for Test and Acceptance of Environmental Information Systems.The software part
I中华人民共和国国家环境保护标准
环境信息系统测试与验收规范-软件部分
1 适用范围
本标准规定了环境信息系统（软件部分）测试与验收的策划、实施、监视和评审、纠正
及预防等流程，用于指导开发方、用户方及第三方对新开发软件、二次开发软件及商用软
件的测试与验收工作。
本标准适用于全国各级环境保护部门开发的各类新开发软件、二次开发软件以及商用软件。
2 术语和定义
下列术语和定义适用于本标准。
2.1 环境信息系统 Environmental Information System
对环境保护业务数据进行集成、处理或展示的核心管理软件；实现环境保护实际业务需
求的辅助决策系统、管理控制系统、办公自动化系统以及数据和业务交换接口的总称。
2.2 测试 Test
由一个或多个测试用例组成的集合；或者由一个或多个测试规程组成的集合；或者由一
个或多个测试用例或规程组成的集合。
2.3 验收 Acceptance
按照一定标准针对以项目方式开发的软件，依据合同、软件需求说明书（SRS）等对
成品进行检验，确认项目质量是否达到用户所需的要求。
2.4 测试组织 Testing Organization
环境信息系统的用户或者用户委托的第三方测试机构。
2.5 测试用例 Test Case
为具体的目标（例如，为练习具体的程序路径或验证对特定需求的遵循性）而开
发的一组测试输入、执行条件和预料的结果。对于测试项、规定输入、预料的结果和一组执行条件的文档。
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 省级环境信息系统
省级环境信息系统是由各省级环境保护部门批准建设的环境信息系统。此类系统的测试
组织为省级环境保护行政主管部门或省级环境保护行政主管部门认可的第三方软件评测机构。
3.1.1.3 地、市级环境信息系统
地、市级环境信息系统是由各地市级环境保护部门批准建设的环境信息系统。此类系统
的测试组织为地、市级环境保护行政主管部门或地、市级环境保护行政主管部门认可的第三
方软件评测机构。
3.1.1.4 区、县级环境信息系统
区、县级环境信息系统是由各区、县级环境保护部门批准建设的环境信息系统。此类系
统的测试组织为区、县级环境保护行政主管部门或区、县级环境保护行政主管部门认可的第
三方软件评测机构。
3.1.2 系统规模
根据系统所对应的信息安全等级保护级别将系统规模分为 I 至 V 级，分别对应信息
安全等保制度中的第一级到第五级，如表1所示。
3.1.3 系统类型
a) 新建系统：指在合同执行前并不存在，需要承建单位进行开发的系统；
3b) 二次开发系统：此类系统包括三类，即部分开发的系统、订购方提供的系统和可重
用的系统。部分开发的系统，通常是指在合同执行前业已存在或部分存在，但在交付前还需
进行修改的系统；订购方提供的系统，通常是指可以得到其源代码，但需要承建单位评价、
开发或修改部分代码方可投入使用的系统；可重用系统，通常是指承建单位拥有源代码，能
够开发或修改文档，通过调用代码就可以实现相关功能的系统；
c) 商用系统：即产品系统，此类系统一般只有目标码和用户手册，获取系统的源代码
很困难，用户或承建单位无法自由对系统进行修改。
3.1.4 测试级别
a) 单元测试：是指系统开发过程中要进行的最低级别的测试活动。在单元测试活动中，
系统的独立单元将与程序的其他部分在相隔离的情况下进行测试；
b) 集成测试：是指在单元测试的基础上，将所有模块按照设计要求组装成为子系统或
系统，进行集成的测试活动；
c) 系统测试：是指将已经确认的系统、计算机硬件、外设、网络等元素结合起来，进
行组装测试和确认测试的活动。目的是验证系统是否满足了需求规格的定义，找出不合格之处；
d) 回归测试：是指修改了代码后，重新进行的测试活动。目的是确认修改没有引入新
的错误或导致其他代码产生错误。
3.1.5 系统规模、测试级别与系统类型的对应关系
系统规模、测试级别与系统类型的对应关系如表2所示。
3.2 测试管理流程
3.2.1 测试管理流程图
测试管理流程主要由策划、实施、监视和评审、纠正与预防、记录测试管理流程5个部分组成，其流程图如图1所示。
图1 测试管理流程
3.2.2 测试策划
3.2.2.1 内容和要求
测试策划主要是进行测试需求分析，确定需要测试的内容或质量特性；确定测试的充分
性要求；提出测试的基本方法；确定测试的资源和技术需求；进行风险分析与评估；制定测
试计划（含资源计划和进度计划）。
如果计划测试由第三方软件评测机构实施，则必须是满足系统规模与第三方软件评测机
构及资质要求的第三方软件评测机构。
3.2.2.2 测试计划
3.2.2.2.1 在实施测试前，测试组织应根据环境信息系统的合同（或项目计划）、被测环境信
息系统的开发合同或系统/子系统的设计文档来策划测试过程，制定测试计划。监理机构应
协助测试组织制定测试计划，并督促项目承建单位按照计划的要求开展工作。
3.2.2.2.2 测试计划的主要内容
a) 确定测试充分性要求。确定测试应覆盖的范围及每一范围所要求的覆盖程度；
6b) 确定测试终止的要求。指定测试过程正常终止的条件（如测试充分性是否达到要求），
并确定导致测试过程异常终止的可能情况；
c) 确定环境信息系统测试的质量目标；
d) 确定用于测试的资源要求，包括软件、硬件、人员数量和人员技能等；
e) 确定需要测试的环境信息系统特性。根据合同或系统/子系统设计文档的描述，确定
系统的功能、性能、状态、接口、数据结构、设计约束等内容和要求，并从中确定需测试的
环境信息系统特性；
f) 确定测试需要的技术和方法，如测试数据生成和验证技术、测试数据输入技术、测
试结果获取技术、是否使用标准测试集等；
g) 根据合同或项目计划的要求和环境信息系统的特点，确定测试准出条件；
h) 确定由资源和被测系统决定的测试活动的进度；
i) 对测试工作进行风险分析与评估，并制订应对措施。
3.2.2.2.3 测试计划评审
测试组织应组织相关方对测试计划进行评审。在测试计划通过评审后，进入下一步工作；
否则，需要重新进行策划。
测试计划评审要点包括但不限于以下内容：
a) 测试计划的范围和内容、资源、进度、各方责任等是否明确；
b) 测试方法是否合理、有效和可行，风险的分析、评估与对策是否准确可行；
c) 测试文档是否符合规范，测试活动是否独立。
3.2.3 测试实施
3.2.3.1 测试设计
3.2.3.1.1 前提
依据测试需求，设计测试大纲，分析并选用已有的测试用例或设计新的测试用例；获取
并验证测试数据；根据测试资源、风险等约束条件，确定测试用例执行顺序；获取测试资源，
开发测试系统；建立并校准测试环境；进行测试就绪评审。
3.2.3.1.2 步骤
测试组织应依据测试计划进行测试设计，测试设计一般包含以下步骤：
a) 设计测试大纲。依据测试需求，明确测试所需针对的项目，设计测试步骤，建立测试大纲；
b) 评审测试大纲，发现测试大纲的问题，针对问题修改测试大纲；
c) 设计测试用例。将需测试的环境信息系统特性分解，针对分解后的每种情况设计测
试用例；
7d) 获取测试数据，包括获取现有的测试数据和生成新的数据，并按照要求验证所有数据；
e) 确定测试顺序，可从资源约束、风险以及测试用例失效造成的影响或后果几个方面考虑；
f) 获取测试资源，对于支持测试的系统，有的需要从现有的工具中选定，有的需要开发；
g) 编写测试程序，包括开发测试支持工具；
h) 建立和确认测试环境；
i) 编写测试说明。
3.2.3.1.3 测试就绪评审
测试组织应组织用户方委托的专家组或用户委托的第三方测试机构进行测试就绪评审。
测试就绪评审主要评审测试大纲、测试计划的合理性；测试用例的正确性、有效性和覆盖充
分性；测试组织、环境和设备工具是否齐备并符合要求。
在进入下一步工作之前，应通过测试就绪评审。
3.2.3.2 测试实施
3.2.3.2.1 测试组织依据测试计划执行测试用例，获取测试结果，分析并判定测试结果。同时，
根据不同的判定结果采取相应的措施。
3.2.3.2.2 对测试过程的正常或异常终止情况进行核对，并根据核对结果，对未达到测试终止
条件的测试用例，决定是停止测试还是需要修改或补充测试用例集，并进一步测试。
3.2.3.2.3 测试执行的工作包括以下内容：
a) 根据每个测试用例的期望测试结果、实际测试结果和评价准则判定该测试用例是否
通过，并将结果记录在测试记录中。如果测试用例不通过，测试组织应认真分析情况，并根
据以下情况采取相应措施：
1）测试说明和测试数据的差错。采取的措施是：改正差错，将改正差错信息详细记录，
然后重新运行该测试。
2）执行测试步骤时的差错。采取的措施是：重新运行未正确执行的测试步骤。
3）测试环境中的差错。采取的措施是：修正测试环境，将环境修正情况详细记录，重
新运行该测试；若不能修正环境，记录理由，再核对终止情况。
4）环境信息系统的实现差错。采取的措施是：填写问题报告单，可提出系统修改建议，
然后继续进行测试；或者把差错与异常终止情况进行比较，核对终止情况。信息系统变更完
毕后，应根据情况对其进行回归测试。
85）环境信息系统的设计差错。采取的措施是：填写问题报告单，可提出修改建议，然
后继续进行测试；或者把差错与异常终止情况进行比较，核对终止情况。信息系统变更完毕
后，应根据情况对其进行回归测试或重新组织测试，回归测试中需要相应的修改测试设计和数据。
6）环境信息系统的安全差错。采取的措施是：填写问题报告单，可提出修改建议，然
后继续进行测试；或者把差错与异常终止情况进行比较，核对终止情况。信息系统变更完毕
后，应根据情况对其进行回归测试，回归测试中需要相应的修改测试设计和数据。
b) 当所有的测试用例都执行完毕，测试组织要根据测试的充分性要求和失效记录，确
定测试工作是否充分，是否需要增加新的测试。当测试过程正常终止时，如果发现测试工作
不足，应对系统进行补充测试，直到测试达到预期要求，并将附加的内容记录在测试报告中；
如果不需要补充测试，则将正常终止情况记录在测试报告中。当测试过程异常终止时，应记
录导致终止的条件、未完成的测试和未被修正的差错。
c) 当所有导致测试异常终止的差错都被修正后，需对测试对象再次进行回归测试以确
认修改没有引入新的错误或导致其他代码产生错误。各测试阶段发生的修改一定要在本
测试阶段内完成回归，以免将错误遗留到下一测试阶段；回归测试期间应对该系统版
本冻结，将回归测试发现的问题集中修改，集中回归。
监理机构应检查项目承建单位测试过程中的问题记录及其改正的记录，并监督项目承建
单位解决测试中发现的问题和不合格项，提出监理意见。
3.2.4 监视和评审
3.2.4.1 监视和评审包括规则检查和监督，监视和评审的结果应记录到测试报告中。
3.2.4.2 测试组织依据测试计划监控测试实施过程，对实施过程与测试计划产生的偏差进行记录。
3.2.4.3 测试组织应根据合同、测试计划、测试说明、测试记录、测试问题报告单等，分析
和评价测试工作，一般包括以下几项工作：
a) 总结测试计划和测试说明的变化情况及其原因，并记录在测试报告中；
b) 对测试异常终止情况，确定未能被测试活动充分覆盖的范围，并将理由记录在测试报告中；
c) 确定未能解决的测试问题以及不能解决的理由，并将理由记录在测试报告中；
d) 总结测试所反映的环境信息系统与合同、需求之间的差异，记录在测试报告中；
e) 将测试结果连同所发现的差错情况同需求或者合同对照，评价环境信息系统的设计
与实现，提出改进建议，记录在测试报告中；
f) 编写测试报告，该报告应包括：测试结果分析、对环境信息系统的质量评价和建议；
9g) 根据测试记录和测试问题报告单编写测试问题报告。
3.2.4.4 测试组织应组织相关方对测试报告、测试记录和问题报告进行评审。评审包括测试
活动的有效性、测试结果的正确性和合理性以及评审是否达到了测试目的、测试文档是否符合要求等。
3.2.5 纠正与预防
3.2.5.1 纠正测试组织应采取措施，以消除造成测试异常或差错的原因，防止测试异常或差错的再发
生。纠正措施应与所遇......
|