李绍栋
(北京广利核系统工程有限公司,北京 100094)
近年来,许多计算机软件应用于关键领域,从医疗电子设备、空中交通管制系统到核电站。尽可能杜绝软件系统一切可能存在的缺陷,是保护人类生命和财产安全的重要保障。然而,由于软件中存在无法预知的错误,通常通过人为的方式判断出可能存在错误的地方,并对此处进行相应修改。但是在软件测试结束后,仍不能确保软件系统中已不再存在错误。尽管如此,软件测试还是能够准确地估算出软件出错的可能性及其可能导致事故后果的严重程度,并将其控制在可接受的范围内。由此可见,软件测试绝不是一个简单轻松的过程,除了要占用大量的资源,还需要投入大量的人力、消耗大量的时间。对于核电DCS 应用软件测试更是如此,人力资源约占整个测试阶段的30%~40%,测试时间会占到整个软件开发周期的20%~30%,由此可见软件测试工作的繁重,同时由于种种原因,人因失误难以避免。因此,如何实现核电DCS 应用软件测试的自动化以提高软件测试效率、减少人工重复性工作,是一个亟待解决的问题。
1983 年,IEEE 提出软件工程的标准术语,将软件测试定义为:“使用人工或自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别”[1]。该定义中明确地提出软件测试的目标是检验被测软件是否满足需求。
核电DCS 应用软件测试的目的是证明软件设计到软件实现的一致性,逻辑测试的对象是配置管理的工程组态。根据程序执行的方式,可以将软件测试方法分为人工测试和自动化测试两类。根据测试过程中程序的执行状态,可以将软件测试分为静态测试和动态测试[2]。根据测试过程对系统内部结构和具体实现算法细节的关心情况,软件测试方法可分为黑盒测试和白盒测试。核电应用软件逻辑传统测试方法按照分类来说,属于人工的、静态或动态的白盒测试。
核电站安全级DCS 应用软件逻辑测试是为了验证工程软件组态与功能图的输入变量和输出变量名称、类型及逻辑组态的一致性。其主要检查安全级DCS 组态文件是否正确实现了工程设计图纸要求的控制功能,测试过程中需确认点名、逻辑功能块选择、跳转页面的名称、逻辑功能块的输入输出信息和逻辑组态实现的功能及信号流向与FD功能图一致性。
测试人员通过在维护工具上强制的方法来产生信号,信号经过相应的算法块会产生相应的操作结果,将通过算法块的运算结果与算法块的功能加以比较,就能得出该算法块的功能是否正确,信号流向是否正常等一系列结果,通过验证的使用记号笔进行涂抹标记。具体测试方法流程如图1 所示。
由于核能的特殊性,一个小误差经过累计可能导致一次核事故。因此,核电软件对每个数据的精度要求都比较高。核电站一旦爆发事故,便会引起不堪设想的严重后果。因而在核电软件的测试过程中需要特别关注如何检测和更正发生的软件故障,同时又能保证其按预定的成本、进度、质量顺利地执行并完成,显得尤为重要。
图1 人工逻辑测试流程图Fig.1 Flow chart of manual logic test
基于以上几点,上述测试方式在实践过程中,往往存在以下问题:
1)测试周期长、通用性差
涂抹测试方法在A 项目安全级DCS 应用软件逻辑测试一个版本5100 余张大约需要投入10 人大约需要2 个月工期,占用了20%的测试周期40%的人力资源,且后续多个版次及后续项目应用软件逻辑测试仍需大量人力和时间,所以现有测试方法周期长、效率低。
2)自动化程度低,人因失误
人工测试过程中,测试人员往往采用手动加载工程、手动使用工程师站软件强制信号、人工读取工程师站软件反馈信号的方式进行测试。这种主要依靠手工测试方式效率较低,一个DCS 项目1 个版次就将近5100 多张功能图,按10 人10 张/天的工作量计算,测试时间往往长达2 个月。测试人员采用手动加载工程、手动使用工程师站软件强制信号、人工读取工程师站软件反馈信号,在功能图上进行涂抹确认的方式进行测试,由于测试人员知识、状态差异,难免会由于人因出现错误或遗漏。
3)测试结果的可追溯性差
测试人员采用在功能图上进行涂抹确认的方式形成测试记录,当发生错测、漏测时,仅仅依靠涂抹不足以分析错测、漏测的原因。如果测试人员的能力达不到规定的要求,软件测试的过程失去控制,从而导致软件测试结果的重现性差,不同的测试人员对同一个软件的测试结果经常是不同的,导致测试结果的可追溯性差。
软件逻辑测试的目标是尽可能多地发现软件中存在的问题,软件测试是软件质量保证的关键步骤。针对人工比对涂抹的测试方法存在测试周期长、测试效率低、人因失误无法避免等问题。为了提升应用软件逻辑测试的自动化率水平,减少测试人力投入,缩短测试工期,减少和避免人工测试引入的人因失误,引入了一种通过因果图分析法,将输入文件转化因果图进而转化为真值表测试用例,然后提出需要,开发相应的自动化测试工具。最终,通过自动化测试工具,使得测试用例能够自动读取、自动执行、自动生成测试记录。还可以将大量的测试用例收集到测试用例库中,经过合理分类,供测试人员复用,有利于提高后续项目的测试效率。
影响软件逻辑测试的因素很多,例如软件本身的复杂程度,组态人员(包括分析、设计、测试人员)的素质,测试方法和技术的运用等。测试用例是测试工作的指导,可以把人为的因素减少到最小,而且会随着测试的进行日趋完善,是软件测试质量稳定的根本保障。测试用例是为特定目标开发的测试输入、执行条件和预期结果的集合[3]。测试用例属于软件测试工作的指导性文件,测试用例的优劣直接影响软件测试的质量。
软件测试中的逻辑测试是从用户的角度出发,以功能图和算法块手册为依据来设计测试用例,执行测试活动的。为了尽可能多地发现系统中的缺陷,验证系统实现与需求之间一致性,逻辑测试用例需要设计的非常具体、详细,包括每一操作步骤的执行动作、输入数据等。仅凭个人的工作经验来设计测试用例,测试质量无法保证,因此有必要寻找一种经济有效的用例设计方法,以期用最少的人力和资源投入,在最短的时间内完成测试,并发现软件的问题,进而保证软件的品质。
在核电DCS 软件测试领域,因果图是一种较好地检测应用软件问题或缺陷的方法。因果图法是一种根据条件组合生成测试用例的系统性方法,它利用图解法分析输入的各种组合情况,从而设计测试用例,适合于检查程序输入条件的各种组合情况。因果图通过将不同条件组合转换为图表的形式来获得需求中额外的情况,以最有效率的方式来验证软件程序。
使用因果图处理逻辑关系的技巧如下(T 代表“Ture”,F 代表“False”,effect 代表“作用”):
如果输入条件是N 个“因”通过“or”组成的逻辑关系,那么就要用到N +1 个测试用例:
①如果输入1T or 2F...or NF ',输出为T;
②如果输入1F or 2T...or NF ',输出为T;
......
图2 因果关系图Fig.2 Causality diagram
N.如果输入1F or 2F...or NT ',输出为T;
N+1.如果输入1F or 2F...or NF ',输出为F;
同理,如果输入条件是N 个“因”通过“and”组成的逻辑关系,那么也要用到N +1 个测试用例:
①如果输入1F and 2T...and NT ',输出为F;
②如果输入1T and 2F...and NT ',输出为F;
......
N.如果输入1T and 2T...and NF ',输出为F;
N+1.如果输入1T and 2T...and NT ',输出为T;
按照此原理,每个“果”所需要的测试用例数量通常是“因”的数量加1。经过实践发现,每个“果”所需要的测试用例必须至少等于这个“果”所对应“因”的数量加1。
基于以上基本理论,某核电项目改进逻辑测试用例,通过真值表模板来制作应用软件逻辑测试用例,具体用例设计方法如下:
1)分析软件规格说明描述中,哪些是原因(即输入条件或输入条件的等价类),哪些是结果(即输出条件),并给每个原因和结果赋予一个标识符。
2)分析软件规格说明描述中的语义。找出原因与结果之间,原因与原因之间对应的关系。根据这些关系,得出因果图,如图2 所示。
3)标记约束或限制条件,由于语法或环境限制,有些原因与原因之间、原因与结果之间的组合情况下不可能出现。为表明这些特殊情况,在因果图上用一些记号表明约束或限制条件。
4)把因果图转换为判定表,用判定表中的每一项生成测试用例。
5)按照逻辑对应关系得出一个单独完整的测试用例,该测试用例覆盖了所有需求,详见表1。
此例不考虑设计因素的情况下仅用了10 步就将“003KS”的需求包含在内,保证了测试用例满足需求。由此可见,因果图能帮助人们按一定步骤,高效率地选择测试用例,并且以最小覆盖的范围来尽可能地找出程序中的缺陷或错误。
表1 测试用例Table 1 Test cases
测试用例设计时,需从以下几个方面考虑测试覆盖率是否满足要求:
1)功能图页中所有输入变量、输出变量需纳入测试覆盖率。
2)以测试用例为单位,统计所有变量类型的数量。
3)统计测试步骤中变量数值变化的数量和名称。
4)按照下面的公式计算覆盖率:覆盖率=执行过程中变化的变量数量/变量总数量。
5)用例第一步执行完成后,记录变量数值作为统计基准值,后续发生变化的认为是变化。
测试用例完成设计之后,为了进一步减少测试人力投入,缩短测试工期,减少和避免人工测试引入的人因失误,提高自动化率。经过对多项目逻辑测试数据的分析,对自动化测试工具提出了具体的需求,以满足软件逻辑自动化测试:
1)独立运行,具备仿真功能,按照测试用例中的步骤,执行强制和取消强制输入变量的操作,读取输出变量的结果。
2)组态文件中每个算法块都有唯一的名称,自动化工具能够支持算法块输入引脚和输出引脚的强制和读取。
3)测试用例中输出变量回读时间与组态中算法块延时时间一致,软件能够根据控制站周期与回读时间计算仿真周期计数,回读结果按照周期计数总数执行。
4)测试用例中能通过“-”表示空白信息,软件加载时遇到“-”不进行校验处理。
5)测试执行完成后,结果为“√”的代表执行通过,结果为“×”的标记执行不通过,通过红色高亮显示。
图3 自动化逻辑测试流程图Fig.3 Flow chart of automated logic test
经定制开发的自动化测试工具能够正常执行自动化仿真测试,并且生成执行结果和测试报告。
逻辑测试用例设计完成之后,通过自动化测试工具,加载工程文件和自动化逻辑测试用例文件后,选择自动执行测试用例,工具读取试验条件变量的在线值,依次判断试验条件是否满足,满足则进行下一步;试验时,工作区显示当前正在进行的逻辑测试用例,并更新执行完成的每一步骤的结果,试验失败则更新为红色显示的实验失败的数据(预期值后加括号显示失败数据)和试验结果(“×”),试验成功则表示预期值与试验数据一致,只更新为绿色显示的实验结果(“√”);自动化逻辑测试试验项结束时对所有变量数值进行记录,最终输出试验结果和形成测试记录。
自动化测试流程如图3 所示。显而易见,自动化逻辑测试是一种高效的、动态的、黑盒自动测试方法。
自动化逻辑测试方法适用于所有核电站项目安全级DCS 项目应用软件逻辑测试。通过相应平台的自动化测试工具,能够大幅提升测试效率。结合在某核电项目DCS 工厂测试应用的效果来看,对于传统的上述测试项目,相比原有的人工确认涂抹测试方式,单项测试的耗时平均缩短80%;测试期间人力投入可减少50%。自动化逻辑测试方法不仅提高了效率,还减少了人因失误,具体效果详见表2。
表2 人工测试与自动化测试效果对照表Table 2 Comparison table of manual test and automated test effect
本文以核电站安全级DCS 自主化开发为研究背景,对比了自动化逻辑测试方法与人工测试方法之间的差异,并结合工程实践,自动化测试方法不仅能提升测试效率与准确率,同时降低了人因失误,及早发现并解决DCS 存在的问题,降低后续工程测试阶段以及现场改造成本。另外需要特别指出的是,人工逻辑测试方法仍然有效,但需要投入大量有经验测试人员去执行测试,测试效率、用例复用性、可追溯性方面不如自动化逻辑测试方法有效。