CN1051800A - 专家系统测试器 - Google Patents

专家系统测试器 Download PDF

Info

Publication number
CN1051800A
CN1051800A CN90109171A CN90109171A CN1051800A CN 1051800 A CN1051800 A CN 1051800A CN 90109171 A CN90109171 A CN 90109171A CN 90109171 A CN90109171 A CN 90109171A CN 1051800 A CN1051800 A CN 1051800A
Authority
CN
China
Prior art keywords
test
expert system
exception
plan
value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN90109171A
Other languages
English (en)
Inventor
罗伯特·L·奥斯本
喀尔·E·哈泊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CBS Corp
Original Assignee
Westinghouse Electric Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Westinghouse Electric Corp filed Critical Westinghouse Electric Corp
Publication of CN1051800A publication Critical patent/CN1051800A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/28Error detection; Error correction; Monitoring by checking the correct order of processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Testing Or Calibration Of Command Recording Devices (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Feedback Control In General (AREA)
  • Paper (AREA)
  • Investigating Or Analysing Biological Materials (AREA)
  • Debugging And Monitoring (AREA)

Abstract

一种采用专门化数据测试集可对所有数据输入 类型的组合进行实验的专家测试系统。专门化数据 测试集包括一用于一个运行的系统的各级的传感器 值的集合使得可以不用测试每个可能的传感器值及 传感器值的组合便能测试所有级别的诊断。测试集 可以组合以产生各种级别的测试,此测试允许被测试 的传感器和规则之间有复杂的关系。

Description

本发明系针对一种专家系统测试器,此测试器可对专家系统的规则库作广泛的测试而无须其测试程序对被测试的特殊规则库具有任何知识,具体地说,本发明提出了一种在规则库更新之后分析其变化的既省钱又可显著提高规则库品质的回归测试方法。
专家系统规则库通常包括一千条以上的规则,而这样一个系统通常有数以百计的传感器输入。如果采用提供两个输入值之一的数字传感器,因其输入值的可能组合数太多而将其一一予以测试实际上是不可能的。当采用模拟传感器,则因其有无限数目的可能输入值,测试问题更是难以实现。当对一个大规则库制定一些新规则时,有关专家要进行正常的调测型或生产型试验。在此情况下每当专家制定一条新的规则时,他便需要用受试传感器在整个预期值的范围内相应置入的模拟数据,对该系统进行实验,以验证新规则是否如预期地运行,亦即当期望时产生预期的诊断,在此种情况下,除了由该新规则使用的传感器值之外的传感器值都保持在正常值。其结果,生产型测试不能确定其它传感器对新规则的作用或者不能确定新规则与其余诸规则的相互作用。一种第二类测试是使该专家系统与实际的连续置入的数据相联机,并要由专家仔细地试验所作的诊断,以确定该诊断是否与拟想的相符合。显然对大规则库和大数量输入系统的操作验证需要更有效的(测试)技术和工具。
本发明的基本目的是要提供一种能对诊断规则库进行验证的测试系统,它无须利用被测试的规则库内的任何知识去初始化和实验该测试工具。
为此目的,本发明提出了一种用来测试一个专家系统的测试系统,该系统包括:用于存储一个正常测试集和一个专门化的测试集的测试存储装置;和用于利用该正常测试集和专门化测试集测试该专家系统的测试装置。上述系统其特征在于:所述测试装置包括用于将响应于专门化测试集的专家系统的输出与一个例外状况进行比较并报告何时出现符合的例外装置。
在结合附图阅读了下面仅用作为例子的本发明的最佳实施例的描述之后,读者将会更容易理解本发明。在附图中,其中
图1示出了本发明的组成部件,输入和输出;
图2示出了本发明的一级测试的操作流程图;
图3示出了一级测试如何能被修改以产生二级测试;
图4示出了本发明用于推荐的专家系统时的数据流;及
图5示出了推荐的专家系统和本发明的执行顺序。
回归测试是一种用来分析在作了修改之后的规则库变化的方法。有两类可能的变化:(1)拟想的变化,及(2)回归规则库的其它无关方面的未考虑到的变化。回归测试是重要的,因为上述变化和误差校正可能会引入比在最初编制规则库模式时产生的误差还大。
一个完整的回归测试要通过对所有的输入数据和诊断情景的可能组合,对规则库作穷尽的实验。从实用的观点看这是不可能的,因为由此要花费太多的时间。一个比较实际的回归测试方法是对所有可能的数据输入类型的组合进行实验,并根据代表每一种类型(一个穷尽测试的子集)专门化的测试案例作完善的诊断。
本发明的测试系统和回归分析考虑到了上述实际测试要求。本发明作为其输入接受一个生产品质规则库,一个传感器数据集和一个测试计划。对于每一个数据组合,一个正常的诊断是用不会引起任何表明一个诸如报警这样的异常现象的诊断的“正常”数据进行的。继该正常诊断之后再迭代以扰动数据。正常的和扰动的测试周期继续到所有组合被测试完之后。系统产生一个运行记录文件及一张根据测试计划定义的可能的不协调的独立的例外清单。分析程序可以通过人机对话方式作一些简单测试,或可以用成批方式通宵地作广泛的测试。运行记录和例外可以在规则变化之间进行比较以确定是否出现了回归。
如图1,所示的本发明的回归测试器10与包括一个生产规则库14和一个专家系统推理机16的专家系统12相配合。专家系统推理机则最好采用西屋电器公司生产的并在美国专利4,644,479和4,649,515中介绍过的处理器诊断系统(PDS)。可从1987年发行的由西屋电气公司的Kemper和Harper所写的PDS说明书的改写版本的5、1节中关于诊断试验部分的文字中见到对该推荐的专家系统工作原理的描述,该文在此被收作为参考。此回归分析器包括一个下面要予以详述的用一个测试计划语言编制的测试计划18,测试系统20用该计划访问加到推理机16的正常测试数据集22。推理机16用规则库14中的生产规则进行分析(即诊断),其生产输出由测试系统存在运行记录文件24中,生产输出还与期望的结果相比较以产生一个例外报告26。该系统还能将生产输出显示在阴极射线管屏幕28上。我们建议在一个运行一个VMS操作系统的数字设备VAX8000系列计算机上实施本发明。同时也建议使用那种适合于后面要讨论的结构设计的语言诸如“C”语言来实施本发明。
如以后将要更详述讨论的,本发明能够实现1至6级专门化的专家系统测试。熟悉本领域的人们可以认识到,随着处理器速度的提高,实际上还可以做到更高级别的测试。图2示出了在一级测试时的本发明的总的操作流程。本发明在步40启动,在步42时开始读测试计划18。测试计划是用下面将要详述的专门化测试计划语言编写的。该测试计划语言编制了一个回归测试计划18,并将该计划18存入到文本文件并在步42时读入到测试系统20。接着,生产规则库14在44步时被装入,然后在步46时装入测试数据。接着在48步时将指针指向其值要改变的传感器。然后在50步将所有传感器置于正常值并进行更新。更新操作使得专家系统的推理机16确认新的传感值是可用的。用这种方法,在步50时所有的规则为点火(firing)作好标志。
接着,在装入了新的(更新后的)传感器值的专家系统中的规则被点火,并继续点火直到无进一步的变化(点火)发生时为止。如果这是测试的第一循环54,则正常的传感器数据专家系统诊断的结果被当作基线保存56起来。然后,其中一个传感器被置在一个测试值上并予以更新58,接着,点火60所支持的规则。然后专家系统(经错误修正,并最好具有肯定可信度)的输出被写入62到运行记录文件24中。该输出再与测试计划例外进行比较64,并且如果匹配的话,便写出66例外报告。然后更新68指针,并测试70指针以确定是否已到达最后一传感器。如果不是,则重复循环,否则,系统停止。如图2所示,系统周期地送入正常测试数据和专门化测试数据,并迭代地在两个循环间加入专门化测试数据。
图3示出了进行二级测试时的本发明的总的操作。此时需要加上一个新的指针80,以便使两个传感器值能从一个正常值变化到一个扰动值。为确定是否这是测试的第一循环必须保存56结果之前对两个指针进行测试。因为两个传感器值现正在变化,所以它们均需在规则被点火之前(60步时)进行更新84。因为还包括一个附加的指针,所以系统必须在步86时更新这个指针,并对其进行测试以确定它是否已到达最末一个传感器。比较一下图2和图3可知,为了提供附加的测试级能力,本发明只需要提供附加的传感器指针,适当的传感器更新步骤和指针增量和测试循环。附录Ⅳ阐述了为何这样便能以一个结构设计方法提供一个第六级测试能力。
最好以标准的PDS形式,将传感器数据或数据集22输入到回归分析器或本发明的系统20。第六级测试能力需要7个数据集,或者用PDS术语来说,需要7个时间集。这些时间集可用PDS来产生。这些传感器值根据需要可以是逻辑或数字值。
第一时间集应是一个正常的读数集。该集应在PDS系统中产生一些在零与负一之间的可信度因子。这些数据被用作为与所有其它状况进行比较的基准或基线。
接着的6个时间集代表了由异常的部件操作产生的数据。通常,所述异常时间集或数据集应是一些在表示专家系统的不同的条件级别的边界之上及其两侧取得的值。也就是说,测试集应该为要测试的系统的每个诊断级别提供一个测试值,例如,在发电厂中,这些级别是预报,诊断,告警,关机和传感器失效。就一个发电厂而言,可以从发电厂的各告警级别中获得这些数值。尽管我们这里描述的例子是针对一个发电厂的,但是其它类型的数据集,例如经济数据也是可以使用的。
当各传感器在范围以下或以低值失效时,第二个时间集有一些预期的读数。这些读数应至少给每个失效的传感器产生一个传感器诊断,而在PDS系统中的传感器规则的可信度因子应该是正值而其它均为负值。当每个传感器超过范围或以一个高值失效时,第三时间集有一预期的读数,且这些读数应给每个失效的传感器产生至少一个传感器诊断,同时,在PDS系统中的一个可信度因子条件为正值,而其它均为负值。第四时间集用来定义具有一个在规则库设计中预定值的读数。即,预测级别传感器值对那些会在这种条件下预测出连续操作的可能的结果的规则进行点火。这个类别拟用来在一个诊断告警发生以前的级别上提供测试数据。第五个时间集有一个触发诊断PDS告警的读数,这些读数应该在至少一个故障诊断中产生低级别的正可信度。第六时间集有一些触发保护IPDS告警的读数,这些读数应在至少一个故障诊断中产生中等级别的正可信度。第七时间集有一些触发保护ⅡPDS告警的读数,这些读数应在至少一个故障诊断中产生高级别的正可信度。
在本发明中的回归测试计划18在一个文本文件中被定义并读入到测试系统20。该计划包括那些用1,2,3或至直6个随每个周期变化的传感器值的组合试验规则库时所进行的测试。例如,如前面所述,一个一级测试循环要先用一组正常读数对规则库进行测试,然后用同一组其中一个传感器值则变到一个行程读数的正常读数进行测试。整个一级测试对每个传感器重复执行正常/扰动测试,计划定义也可包括对每个测试的例外报告说明书。所谓例外是一个记录一个条件的任何例证的请求。例如,一个在上述一级测试中要包括的有用的例外是要报告是否在其中一个测试循环中没有产生可信度大于0.5的故障。应该用存在例外报告发出回归测试失效信号的方式来设计例外。
测试计划文件的第一行最好包含对规则库文件在何处的目录说明书。接着的各行最好或者有一个测试定义或者有一个例外定义。依循某个测试定义的例外只应用于该测试。
单个回归测试最好用一组加括号的传感器类别表示。例如,行程数据的一级测试(跟随其后的是警告和行程数据的二级测试)表示为:
(行程)(Trip)
(警告行程)(Warn  Trip)
采用这种测试顺序的计划指定将给每个传感器行程值执行规则库的一级测试,而运行记录文件则将记录所有更新的故障和过程结果。接着通过为每个行程值执行规则库来做二级测试,与此同时,每个传感器依次置于警告值。因没有被定义的例外,因此在例外报告26中未作登记。
例外分成为三类,由此提供了三种基本的筛选程序:1.更新例外;2.级别例外;及3.变化例外。更新例外检验查看是否有适当的故障和过程被一个诊断循环作了更新。例如,报告任何更新的故障的例外为:
Exception:Malf  uptated(例外:更新的故障)
级别例外将产生的故障或过程参量与一个固定值进行比较。例如,报告何时一个故障可信度大于0.5的例外为:
Exception:Malf  CF>0.5(例外:故障可信度>0.5)
变化例外将诊断的百分率变化与一常值进行比较。百分率变化用一传统的公式进行计算:(新值-旧值)/旧值。旧值是在图2中步56时保存的正常诊断的故障或过程参数。新值是由循环的第二诊断(58和60)中得到的同一的参数。其效果是:正变化离开零,而负变化是趋向零。例如,报告在过程可信度中至少一个+10%变化的例外为:
Exception:%Proc>10.0(例外:%过程变化>10.0)
有三种提供对三类基本筛选程序的三种变体的例外:1.简单例外;2.集合系例外;及3.充足例外。简单例外如同上所述的类别例外,此种例外包括一个参量,一个操作符,及一个常值。每当一个简单例外测定为真实时,就将测试定义,扰动传感器,故障或触发例外和参量值的过程在步66时记录在报告中。集合例外是前面有限定词ALL(所有)SOME(某些)或NO(不)的简单例外。在这种情况下,如果组成集合的例外参量与例外定义匹配便产生一个报告。如果这个例外测试对整个测试是真空的,则测试定义和扰动传感器在例外报告中被报告66。采用SOME集合限定词,在系中的元素数目也写入66到例外报告。例如,报告何时在回归测试中的某些故障可信度大于零的例外为:例外:某些故障可信度>0.0。充足例外是前面有限定词LTN(少于)或GTN(大于)的简单例外。在这种情形时,如果例外匹配数目小于(大于)回归测试的级别,则产生一个报告。如果例外测试对全体测试是真实的,则在步66时将测试定义,扰动传感器及匹配数目写入报告。例如,报告何时在一个行程回归测试中“少于一个故障严重性”是大于3.0的例外是:
(Trip)(行程)
Exception:LNT  Malf  Severity>3.0
(例外:少于故障严重性>3.0)
每个例外的形式为:
Exception:<guwlifier><paraneter>
<uperatcr><constwnt>
(例外:<限定词><参量><算符><常值>)
参量规定要试验的诊断结果是什么。用:
<object><attribute>(<目标><属性>)来定义一个参量。有效的目标为故障或过程。省略参量的目标部份表示故障和过程均应校核。当使用推荐的专家系统时,被所有除了更新例外的类别的使用的属性有可信度(CF),严重性(SEV),重要性(IMP),或优先权(PR)。
用于例外的算符为:
Updatecl,!Updatecl,==,!=,>,>=,<,<=
前两个算符只用于更新例外和指示有无由更新值支持的规则被点火。其余的算符定义一个在参量与浮点常数之间的比较,其中第三和第四算符对相等和不相等作比较。
测试计划的要求可用在附录Ⅰ中定义的测试计划语言实施。熟悉本领域的普通人们能够用此语言定义编制一个由适用的YACC和LEX  unix第三代语言开发工具产生的语法分析程序,此开发工具将接纳测试计划文本文件和输出此计划的适当的内部表达。一个测试计划的例子给出如下:
Rulebase  directvry:PS:〔harpei·Pds  code.regress.Vbl〕
TEST  1(Normal)
Exception  1:! Updated
TEST  2(trip)
Exception  1:CF>0.800000
Exception  2:LTN  CF>0.800000
两个结果文件最好用本发明的回归分析器产生。如果分析器以成批方式运行,则也有一个来自对话期间的输出文件。输出文件表示该测试的进程。运行记录文件24通常甚为冗长,因为它要列出所有的传感器,它们的描述,和测试数据,所有的故障和过程及它们的描述,测试计划,以及各个测试结果列表。例外结果或报告文件20是较易管理的,它们列出了所有的来自测试的例外报告。
根据本发明,屏幕输出28最好显示在运行PDS期间产生的信息及错误消息。每个测试是顺着所运行的诊断周期被认定和加以时间标记。该输出是类似于由PDS诊断版本产生的文件,在附录Ⅱ中可以见到屏幕输出的例子。
运行记录文件24是一个整个的测试记录。该记录可编档保存在一个常规的源码程序文库中和以后用来将完整的测试结果与用变化后新规则库运行的完整的测试结果进行比较。一个在完整的运行记录文件之间的常规的区别比较将精确地显示在所运行的各次测试间的变化。用这种方式,可以实行在规则库变化之间的回归分析。此外,运行记录明白地定义对规则库的输入和输出是什么,而这些以后可用作为其它类型的专家系统的训练例子,例如,用作为一个神经网络专家系统的实施。如同附录Ⅱ所示,在运行记录文件中最好包含三节。第一节详述测试参量;传感器和传感器数据,故障和过程,及所有它们的描述。第二节是一个测试计划的列表。第三节包含测试案列。对每个更新的故障和过程的案例连同其可信度,严重性,重要性和优先权用字顺序列出。
例外文件26是一个关于每个与在测试计划中的定义的例外相匹配的例证的报告。例外文件实质上是一个筛选后的运行记录文件,其中筛选程序的特性由用户规定的例外定义的。如在附录Ⅱ所述,每个报告具有如下形式:
(<timeset>/<sensor>……)<object><message>
(<时间集>/<传感器>……)<目标><消息>
如前所述,时间集是传感器数据类别,例如行程(trip)或警告(Waring)。所谓传感器是那些被指定的值而不是本诊断周期的正常值的传感器的名字。目标既可为故障也可为过程的名字。消息识别例外报告的类型。
本发明最好用如下讨论的一种结构设计法来实施:
结构设计:计算机程序设训练基础,yourdon和constantine著,yourdon出版社,1979年出版;结构分析与系统说明,Demarco著,yourdon出版社,1979年出版;软件工程:专业人员入门指南,Pressman著,Mccrraw  rlill图书公司1982年出版;和软件设计技术指南,第4版,Freemen,和Wasserman著,1982年IEEE计算机协会出版社。更具体地说,本发明最好用诸如下面列举的系统开发工具来实现:CASE  Analyst/RT  Users  Manual  for  VMS  station/VMS  Hosts  VO·O·4.1,由Mentor  Graphics  1988年出版,该书实施了在由De  Maro著,yowrdon出版社1979年出版的结构分析与系统说明中介绍的操作法。上述方法或工具使得设计者可以编制并维护运用可由标准的“C”程序和普通的“C”程序快而有效地实现的控制流及数据流图。图4和5示出了使用上述工具的方法学的本发明的数据流程和控制流程图。在附录Ⅲ中给出了用这种方法学实施本发明时所用的数据定义。本领域的普通技术人员可根据前述的图表信息以及附录来实施本发明。图4示出了出入测试系统20的除了在前述图1中的信息以外的数据流。图4说明了生产环境100,亦即置入信息必须包括在该系统内。
如图4和5所示,本发明的第一步是用户读取200用测试计划语言编写的测试输入,分析测试计划输入和生成内部测试计划表示18。下一步是初始化202所有的全局变量。该步是PDS专家系统推理机16的操作的一部份,该步生成和初始化真的、假的,和其它上下文,以及生成和初始化那些管理传感器时间步的PDS变量。然后系统被恢复204,204也是PDS推理机16的一部份。此例行程序接受文本文件知识库定义并把相应的模式装入存储器14。下一步也是PDS推理机16操作的一部份,它读取206部件信息文本文件。该文件也是PDS生产环境100的一部份,该环境100将知识库与具体客户的应用相联系,并作为副作用,本发明在所有输出文件首标使用该部件名。接着,系统读取208传感器值,这一步也是PDS推理机16的一部份,该步该出标准格式的传感器数据文本文件并将传感器值和时标装入内部读数列表。然后PDS推理机16恢复210该历史。为执行这一步,推理机读取一个历史文本文件并将文本历史列表和事件记录装入到相应的模式中。历史文本文件是PDS生产环境100的一部份,它保存着在推理机再启动间的、基于时间的分析结果。然后测试系统20初始化212数据时间集。该步只利用在208步读取传感器时生成的读数列表,用来用每个传感器的正常的、失效低、失效高、预求的、诊断的、警告的及行程值填写一个七列时间陈列。使用一个陈列而不是一个文本列表可以提高测试系统的速度。下一步,此也是本发明的一部份,是产生214回归运行记录。该步通过在运行记录中记下以下各项总结和记录了整个分析说明:对该测试计划时间和客户应用,对所有传感器和它们的7个数据值的每一个值的描述,及对所有可能故障的描述。通过把该测试计划的时间和客户应用写入到文件26,步214打开和初始化例外报告和运行记录文件。下一步216也是测试系统20的一部份,它写出由读计划步200将测试计划读入到运行记录文件中的测试计划。它将该测试计划副本附加到运行记录文件中。最后一步218是执行步,它重复地调用PDS推理机16去执行由测试计划规定的诊断。在附录IV中详述了用于该步的详细算法。
如前所讨论,本发明提供了一种有效的标准测试工具,它可以在开发期间和在高用时作了修改和改进之后均可验证诊断规则库。本发明可允许可编程例外,提供了一种描述例外的语言和一个运行记录文件,此运行记录文件可用于训练和测试所有类型的包括神经网络的专家系统,以及提供了用其自己的语言编制的一种可编程测试的待办事件。
由上述详述的说明书中读者已明白了本发明的许多特点和优点,因此我们拟用所附的权利要求去覆盖属于本发明的精神实质和范围内的所有的这些特征。此外,那些熟悉本领域的人们还可对本发明作一些显而易见的修正和改变,但这并不要把本发明限制在完全如所阐述的结构和操作上,因而所有可能诉诸适当的修改和等价物仍然属于本发明的范围内。例如,某些专家系统可具有无点火规则(Wnfiring  rules)的能力而PDS是这样一种系统。并且,不是在步50和52时用正常值点火所有的规则以有效地把系统复位到基线上,而是不点火所有被点火的规则也是可能的。
附图图号说明
含义  参考数字  图号
规则库  14  1
生产知识库  14  4
知识库  14  5
专家系统推理机  16  1
测试计划  18  1
″  18  4
″  18  5
测试系统  20  1
处理器诊断系统  20  4
正常和测试集  22  1
测试数据  22  4
运行记录文件  24  1
″  24  4
″  24  5
例外报告  26  1
″  26  4
″  26  5
屏幕输出  28  1
″  28  4
起动  40  2
读计划  42  2
装入规则库  44  2
含义  参考数字  图号
装入数据  46  2
N=1  48  2
N=1  48  3
设置所有传感器至正常  50  2
和更新
″  50  3
点火所支持的规则  52  2
″  52  3
N=1  54  2
保留结果  56  2
″  56  3
设置所有传感器至测试  58  2
和更新
点火所支持的结果  60  2
″  60  3
写运行记录文件  62  2
″  62  3
输出与测试计划例外进  64  2
行比较
″  64  3
写例外报告  66  2
″  66  3
含义  参数数字  图号
N=N+1  68  2
N=N+1  68  3
N=最末一个传感器  70  2
″  70  3
停止  72  2
″  72  3
M=1  80  3
N=1  82  3
M=1
置第N个和第M个传感器  84  3
至测试值和更新值
M=M+1  86  3
M=最末一个传感器  88  3
生产环境  100  4
读计划  200  5
初始化全局变量  202  5
恢复系统  204  5
初始化部件信息文本文件  206  5
读传感器  208  5
初始化数据时间集  212  5
生成回归运行记录  214  5
含义  参考数字  图号
写计划  216  5
执行  218  5
重复经历  218  5
Figure 901091715_IMG3
Figure 901091715_IMG6
Figure 901091715_IMG7
Figure 901091715_IMG8
Figure 901091715_IMG13
Figure 901091715_IMG14
Figure 901091715_IMG15
Figure 901091715_IMG16
Figure 901091715_IMG18
Figure 901091715_IMG20
Figure 901091715_IMG21

Claims (7)

1、一种用于测试一个专家系统的测试系统包括:
用于存储一正常测试集和专门化测试集的测试存储装置(22);及
用于利用该正常测试集和专门化测试集测试专家系统的测试装置(20),其特征在于:
所述测试装置包括用于将响应于专门化测试集的专家系统的输出与一个例外条件进行比较并报告何时存在符合的例外装置(64)。
2、根据权利要求1所述的系统,其特征在于所述测试装置(20)适用于产生一个包括测试参量的运行记录(24),一个测试计划和一个测试案例,及适用于响应一个指定一个测试级别,测试类型及例外的测试计划(18)实行测试,及在于提供一个测试语言装置(附录Ⅰ)用来将测试计划输入语句转换成测试计划(18)。
3、权利要求1或2所述的系统,其特征在于所述测试装置适用于将正常的测试集,即正常的测试集值循环地运用到专家系统并实行一个n级测试,其中n为整数。
4、如权利要求1,2或3所述的系统,其特征在于用于包括在规则改变前后存储结果的结果存储装置(24),及用于在规则改变前后比较结果并指出差别的比较装置(20)。
5、用于测试一个发电厂的专家系统的测试系统,其特征在于包括:
用于存储一陈列测试集的测试存储装置(22),该测试集包括一个正常传感器值集及包括传感器失效,预求和诊断值的专门化传感器值集;
测试装置(20),它用于用正常的传感器值和专门化值循环地测试专家系统,同时迭代地运用上该专门化值,所述测试装置包括:
读装置(200),它用来读取测试计划语言写的测试输入并把该测试输入转换成一个测试计划,而测试计划规定测试级及待测的例外;
例外装置(64),它把专家系统的输出与例外进行比较并报告何时出现匹配;
运行记录装置(24),它用于记录下被测试的传感器,传感器数据,指示的故障,故障描述,测试计划,及包含专门化传感器集的测试案例;及包括:
比较装置,用来将改变成专家系统前后的运行记录进行比较,所述系统包括一种用于一个测试的测试计划语言,该专家系统包括:
一个允许用户定义测试计划的语言定义,该测试计划包括该测试的级,要使用的测试集,要使用的专家系统规则及测试例外诸项;及包括
一个用于将用户输入转换成为测试系统能使用的测试计划的例行程序(200)。
6、测试一个专家系统的方法,包括如下步骤:
(1)把一个正常测试集加到所有输入值被置于正常值的专家系统上;
(2)把一个专门化的测试集加到一个专家系统上;其中输入值中的一个被置于测试值上;并点火该专家系统的规则,及
(3)在步骤(2)时记录产生的例外,而其中专家系统的输出则与例外进行比较,同时当匹配发生时产生例外,并且步骤(1)-(3)被重复,与此同时迭代地选择在步骤(2)中的不同的各个输入值并将其置于测试值。
7、如权利要求6所述的方法,其特征在于:读出进一步的测试要求和用户的输入,并产生一个测试计划,其中在步骤(2)时,将一对输入值置于一对测试值上,而步骤(1-3)则在专家系统中随着规则库的变化而进行;以及将在规则库变化前后的测试输出予以比较。
CN90109171A 1989-11-17 1990-11-15 专家系统测试器 Pending CN1051800A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US43795189A 1989-11-17 1989-11-17
US07/437,951 1989-11-17

Publications (1)

Publication Number Publication Date
CN1051800A true CN1051800A (zh) 1991-05-29

Family

ID=23738604

Family Applications (1)

Application Number Title Priority Date Filing Date
CN90109171A Pending CN1051800A (zh) 1989-11-17 1990-11-15 专家系统测试器

Country Status (6)

Country Link
JP (1) JPH03172940A (zh)
KR (1) KR100190267B1 (zh)
CN (1) CN1051800A (zh)
CA (1) CA2029495A1 (zh)
ES (1) ES2024939A6 (zh)
IT (1) IT1243879B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104185840A (zh) * 2012-04-30 2014-12-03 惠普发展公司,有限责任合伙企业 持续部署流水线测试的优先化

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0566105A2 (en) * 1992-04-16 1993-10-20 Hughes Aircraft Company Knowledge acquisition system and method
CN113377746B (zh) * 2021-07-02 2023-08-18 贵州电网有限责任公司 一种试验报告数据库构建和智能诊断分析系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104185840A (zh) * 2012-04-30 2014-12-03 惠普发展公司,有限责任合伙企业 持续部署流水线测试的优先化
CN104185840B (zh) * 2012-04-30 2018-01-16 慧与发展有限责任合伙企业 在持续部署流水线中用来优先化多个测试的方法、系统和装置

Also Published As

Publication number Publication date
CA2029495A1 (en) 1991-05-18
KR100190267B1 (ko) 1999-06-01
IT9021931A0 (it) 1990-10-30
ES2024939A6 (es) 1992-03-01
JPH03172940A (ja) 1991-07-26
IT1243879B (it) 1994-06-28
KR910010311A (ko) 1991-06-29
IT9021931A1 (it) 1992-04-30

Similar Documents

Publication Publication Date Title
Hooimeijer et al. Modeling bug report quality
Mariani et al. Compatibility and regression testing of COTS-component-based software
Yang et al. A survey of coverage based testing tools
Engström et al. Empirical evaluations of regression test selection techniques: a systematic review
Soltani et al. Search-based crash reproduction and its impact on debugging
CN1825278A (zh) 源代码静态分析模拟器的自定义api建模
US8078427B2 (en) Calibration curve fit method and apparatus
US20030177417A1 (en) System and method for remote performance analysis and optimization of computer systems
Wen et al. Blimp tracer: Integrating build impact analysis with code review
Zhang et al. Large-scale empirical study of important features indicative of discovered vulnerabilities to assess application security
Kiran et al. A comprehensive investigation of modern test suite optimization trends, tools and techniques
CN105389262A (zh) 一种针对界面测试生成测试建议的方法和装置
Eisty et al. A survey of software metric use in research software development
Yamashita Assessing the capability of code smells to support software maintainability assessments: Empirical inquiry and methodological approach
CN105183658A (zh) 测试软件代码的方法及装置
Madeiral et al. Towards an automated approach for bug fix pattern detection
CN1811626A (zh) 工序管理装置及其控制方法、工序管理程序及记录介质
Jetley et al. Static analysis of medical device software using CodeSonar
US20030177414A1 (en) Model for performance tuning applications
CN1051800A (zh) 专家系统测试器
Michael et al. Metrics for measuring the effectiveness of software-testing tools
Hall et al. Effectively incorporating expert knowledge in automated software remodularisation
JP2006059276A (ja) ソースコード評価システム
Chu et al. FAST: a framework for automating statistics-based testing
Opdebeeck et al. Infrastructure-as-Code Ecosystems

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
AD01 Patent right deemed abandoned
C20 Patent right or utility model deemed to be abandoned or is abandoned