2. 中国兰州 730000 甘肃省地震局;
3. 中国广东 518003 深圳防灾减灾技术研究院
2. Earthquake Administration of Gansu Province, Lanzhou 730000, China;
3. Shenzhen Academy of Disaster Prevention and Reduction, Guangdong Province 518003, China
地震速报是对已发生地震的时间、地点、震级等的快速测报。随着测震台网数字化和网络化的实现,以及测震台站密度的增加、计算机处理能力的提高和地震数据处理方法的改进,人工地震速报用时大幅度缩短。目前,人工速报地震平均用时:国内地震约10 min,国外地震约20 min。自动地震速报也已于2013年实现向各省地震局和社会提供地震速报信息的服务。在我国,可在2 min左右给出国内东部地区3.0级及以上、3 min左右给出国内西部地区4.0级及以上地震较合理的地震速报结果(杨陈等, 2010, 2012, 2014;吴永权等,2011)。目前我国地震速报过程执行自动地震速报、省级地震台网中心人工初报、国家地震台网中心人工正式报的三级协同(或三阶段)工作的速报产出体系①。地震速报时间的缩短,为政府和社会有效应对地震灾害提供了强有力的信息支持。
①中国地震局. 地震速报技术管理规定(2015年修订版)(中震测发〔2018〕51号).2015.
测震台网建设完成后,其地震速报结果的时效性、合理性和稳定性主要取决于地震速报软件,可以说,地震速报软件质量的好坏,直接影响了地震速报结果。而地震速报软件的质量,不仅取决于软件开发者,也取决于软件的全面测试。我国对地震速报软件测试工作开展的研究不多,可供使用的工具和平台较少。“十五”期间,曾在仪器质检中心建设测震专业软件测试与评估平台(肖武军等,2011),其提供的测试数据是以真实地震为基础,存在一定不足之处,加之其他原因等,该平台的实际使用有限。目前,地震速报软件测试主要指开发人员进行的单元测试、集成测试和系统测试,软件质量评定往往由开发人员的保证确定,而由专业测试人员和用户/客户进行的系统测试与验收测试则相对简单且不规范。
笔者曾负责或参与多个地震业务软件验收测试工作,认为地震业务软件测试尚存在不足之处②:①缺乏行业软件的管理体系,难以保证专用软件测试的规范性;②测试投入时间较短,一般仅2—3天,且需保留足够时间编写软件测试报告,软件验收测试内容往往不完备,测试用例也以用户提供数据为主,难以进行较全面的功能和性能的详细测试;③缺少必要的支持工具或平台,主要是以现有数据运行被测软件,难以进行各种典型应用场景的模拟测试;④缺少相应的测试指标体系或评估打分标准,难以与类似软件进行比较测试。基于此,地震速报软件测试的相关研究和工作亟待加强和规范,借以促进地震速报软件质量的提高,为地震速报数据处理提供高质量软件支撑。
②何少林. 一种地震自动速报软件测试平台研制. 2020.
1 软件测试相关问题 1.1 软件测试的定义软件测试的定义有多种,比较权威的定义由IEEE于1983年提出:“软件测试是使用人工或自动化手段运行或测定某个系统的过程,其目的在于检验它是否满足规定的某个需求或是发现预期结果与实际结果之间的差别”。即软件测试是为了发现错误而执行程序的过程,也可以说,软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例,并用它们去执行程序,以发现程序错误的过程。软件测试是在软件投入使用前,对软件的需求分析、设计规格说明和系统编码的最终复审。
测试的关键在于“发现错误”而不是“证明程序正确”,即使用最少的测试用例,尽可能多地发现错误。《计算机软件测试规范》(GB/T 15532—2008)指出,软件测试的目的是:①验证软件是否满足软件开发合同或项目开发计划、系统/子系统设计文档、软件需求规格说明、软件设计说明和软件产品说明等规定的软件质量要求;②通过测试,发现软件缺陷;③为软件产品的质量测量和评价提供依据。
1.2 软件测试的重要性据悉,美国每年因软件Bug面临近600亿美元的经济损失。历史上典型的、具有毁灭性软件Bug的例子较多,如:1987年华盛顿因程式交易引起股票系统崩盘,1天就损失5 000亿美元;1991年海湾战争,由于软件的舍入错误,美国爱国者导弹系统未能及时发现和拦截飞入伊拉克境内的飞毛腿导弹,造成28名士兵死亡;1999年因千年虫Bug,损失5 000亿美元;2000年因爱虫病毒,损失87.5亿美元③。基于如此严重的教训,在软件业较发达的国家,软件测试不仅成为软件开发的一个有机组成部分,而且在软件开发的系统工程中占据着相当大的比重。以美国的软件开发和生产的平均资金投入为例,通常是“需求分析”约占3%、“规划确定”约占3%,“设计”约占5%,“编程”占约7%,“测试”约占15%,投产和维护占60%—70%,可见测试在软件开发中的地位。仅就“编程”和“测试”过程看,“测试”的平均资金投入约为“编程”的2倍。更广泛的统计表明,软件测试工作量一般占软件开发总工作量的40%以上,测试经费占软件开发总经费的30%—50%,测试人员和开发人员的比例约为1.5—2.5(陈春玲等,2002)。例如,在Windows 2000研发团队中,测试人员约1 800人,开发人员约900人、测试人员与开发人员比例为2.0:1.0。
③截至2014年全球最具毁灭性的20个软件Bug. http://www.idcps.com/news/20141017/78642.html.
一个软件的好坏和质量的优劣不仅取决于软件开发者,还取决于软件测试。软件测试是提高软件质量的重要环节,贯穿于软件项目的整个生命过程。
2 地震速报软件相关问题 2.1 测震业务软件的分类按照《软件产品分类》(GB/T 36475—2018)规定,测震软件分类号为C.2.13,其中“C”标识“应用软件”,“2”标识“行业应用软件”,“13”标识“其他行业应用软件”。根据测震软件在应用中的重要性、使用范围、结果的影响等因素,可将测震软件分为关键性软件(暂定分类号为C.2.13.1,简称“Ⅰ”类)、一般性软件(暂定分类号为C.2.13.2,简称“Ⅱ”类)。Ⅰ类软件是指大范围使用的,或产出结果影响范围较大,或产出结果作为其他地震科学研究基础资料的软件或软件系统。Ⅱ类软件指其产出结果不会造成重大的,或广泛的政府、社会和行业影响,或其结果不会对行业发展造成影响,或不会造成后续处理错误的软件或软件系统。
在具体划分时,符合以下条件之一的测震软件可认为是Ⅰ类软件:①在5个或以上省地震局测震台网正式使用的软件;②在20个或以上地震台站正式使用的软件;③省地震局测震台网/中国地震台网中心在线运行的地震速报(含自动和人机交互)、地震编目、地震烈度速报、地震预警等软件;④在地震行业内提供观测数据存贮、交换、服务的软件;⑤对外提供信息公共服务的软件,如地震应急产品产出软件、地震信息发布软件、地震信息公开展示软件等。
2.2 地震速报软件的管理从测震业务软件分类看,地震速报软件属于Ⅰ类软件。对于Ⅰ类软件,至少应建立软件产品的供方(含开发方、维护方)、业务管理方和用户方(含质量保证管理者、操作方)构成的管理组织,明确各自的责任要求。各方的责任至少包括但不限于以下内容。
(1)供方。供方应提供软件开发过程形成的有关材料,包括系统需求分析、软件需求分析、软件体系结构设计、软件详细设计、源程序、可执行程序、软件安装说明、软件使用说明、软件更新(升级)与维护说明、软件单元测试文档、软件集成测试文档、软件配置项测试文档、合同授权的系统测试的文档、软件迁移文档等(GB/T 8566—2007)。相关测试文档的内容应符合《计算机软件测试规范》(GB/T 15532)要求。
(2)业务管理方。需方管理部门管理软件的系统测试、Ⅱ类软件的验收测试、软件试运行、软件使用培训、软件运行;行业业务管理部门管理与Ⅰ类软件有关的验收测试组织、认证、在线运行许可、软件退役。
(3)用户方。用户方负责软件安装、试运行、正式运行,提供软件的运行文档,包括软件改进建议。Ⅰ类软件应有3个及以上用户试运行文档。
2.3 地震速报软件文档地震速报软件供方应提供文档作为验收测试时文档评价的材料。文档应包括表 1中所列信息,但不限于所列信息。表 1中标“*”为应有内容。
软件测试包含多方面内容,文中重点从文档和软件功能、性能和易用性方面探讨自动地震速报软件的测试问题。
3.1 文档检查软件文档是软件使用和维护过程中的必备资料。文档能提高软件开发效率,保证软件质量,而且在软件使用过程中具有指导、帮助、解惑的作用,尤其在维护工作中,是不可或缺的资料。
文档检查主要是检查文档的正确性、完备性和可理解性。正确性是指不要将软件功能和操作写错,也不允许文档内容前后矛盾。完备性是指文档不可以“虎头蛇尾”,更不许漏掉关键内容。文档中诸多内容对开发者可能是“显然”的,但对用户而言不见得都是“显然”的。软件的可理解性是理解计算机程序、规程、相关文档和数据的难易程度。可参照表 1所列内容进行文档检查。
3.2 功能测试功能测试又称正确性测试,就是对产品的各功能进行验证,检查软件的功能是否符合规格说明,是否按照项目任务书的要求,完成任务书要求实现的功能。由于正确性是软件最重要的质量因素,所以其测试也最重要。
功能测试可根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。功能测试也叫黑盒测试或数据驱动测试,只需考虑需要测试的各个功能,不需要考虑整个软件的内部结构及代码。一般从软件产品的界面、架构出发,按照需求编写测试用例,输入数据在预期结果和实际结果之间进行评测,进而提出使产品达到用户使用的要求。
在功能测试中要考虑软件的容错性。容错性主要检查系统的容错能力,检查软件自身在异常条件下是否具有防护性措施或者某种灾难性恢复手段,是检查软件在异常条件下的行为。容错性好的软件能确保系统不发生无法意料的事故。容错性测试通常构造一些不合理的输入来诱发软件出错,例如:①输入错误的数据类型;②输入定义域之外的数值等。
可按照表 2所列指标对软件进行功能测试。功能测试的产出有:①功能完成情况:全部完成、部分完成比例、偏离情况;②总体评价:根据功能整体完成情况、主要功能完成情况给出总体评价。
功能评价主要检查是否具有以及其适应范围。自动地震速报系统的功能包括多个方面,这些功能根据工作的重要性可分为基本功能和扩展功能。基本功能是自动地震速报软件必须具备的功能,见表 2中一级功能的第1—5项。扩展功能是可选择的功能,见表 2中一级功能的第6—20项。
3.3 性能测试性能测试是为了验证系统是否达到用户提出的性能指标,同时发现系统中存在的性能瓶颈,起到优化系统的目的。通常验证软件的性能在正常环境和系统条件下重复使用是否仍能满足性能指标。系统性能主要体现在处理响应时间的长短上,执行同样任务时新版本不比旧版本慢。性能测试一般还检查系统记忆容量在运行程序时会不会出现内存泄露。
测试要点:①软件性能测试是在功能测试完成后进行的;②软件性能测试的计划、方案,一般与测试用例统一在一个文档里;③测试环境应尽量与用户环境保持一致;④软件性能测试一般使用测试工具,由测试人员编制测试脚本来完成,软件性能测试的环境应单独运行,尽量避免与其他软件同时使用;⑤软件性能测试的重点在于前期数据设计与后期数据分析;⑥软件性能测试用例主要涉及整个系统架构的问题,所以测试用例一旦生成,改动一般不大,但是如果某个功能有较大修改,软件性能测试也应重新进行测试;⑦软件性能测试指标的来源:测试依据是产品需求规格说明书;如果用户未提出性能指标,则根据用户需求、测试设计人员的经验来设计各项测试指标。
自动地震速报系统软件的性能测试主要是对自动地震速报涉及的2个主要环节(震相自动识别、自动定位),以及产出结果的时效性、稳定性、合理性等进行评价。
通过性能测试,综合分析给出软件的适用场景。不是简单的好与不好,应是同一方法,在不同条件下的好与不好;不同方法,在相同条件下的好与不好。
根据自动地震速报软件系统的特点,结合功能要求,提出如下性能评价指标,见表 3,其中自动地震速报得分100分,可参照表 4打分。
关于软件的易用性问题,可按照一级指标、二级指标进行分级测试,对软件安装、维护、升级和迁移进行评价,具体测试内容见表 5所示。
针对地震速报专用软件测试的现状,讨论了测震业务软件进一步细分类的参考依据,提出了构建地震速报软件管理组织的建议,给出了地震速报软件的内容信息表。以自动地震速报软件测试为例,从文档检查、功能测试、性能测试、易用性测试等提出了测试的内容,并给出了自动地震速报结果评分表。
文中针对地震速报专用软件测试提出的建议和内容具有一定操作性,可在实际工作中参考使用。鉴于地震行业软件测试相关研究和规范性工作的不足之处,文中提出的内容尚需在今后实践中不断补充和修改,以达到软件测试促进软件质量提高的最终目的。
陈春玲, 李频, 陈丹伟. 软件工程与数据库概论[M]. 陕西: 西安电子科技大学出版社, 2002: 125.
|
吴永权, 黄文辉, 康英, 等. 国家地震速报备份系统的部署与运行[J]. 国际地震动态, 2011(12): 21-28. |
肖武军, 赵建和, 韩磊, 等. 中国数字测震台网专业软件评测[J]. 地震地磁观测与研究, 2011, 32(4): 122-126. |
杨陈, 黄志斌, 翟璐媛. 全国自动地震速报系统综合评估[J]. 地震地磁观测与研究, 2012, 33(5/6): 316-321. |