软件故障的21种模型(DOC)
软件功能性测试的21种故障模型
测试的目标是要发现错误，因此在编写测试用例的时候也要遵循这个目标，尽量在软件的最薄弱环节多编写测试用例。虽然测试时有很多单个输入变量、多个输入变量的组合，但优秀的软件测试人员不会依靠运气，他们有着丰富的经验和直觉，可以从中找到哪些是需要进行测试的，哪些不需要测试，哪些操作可能会引起软件失效。把这些测试人员的经验和直觉尽量归纳和固化，就形成了一些故障模型。故障模型指明了故障是如何以及为什么会在软件执行时引起软件失效。在测试过程中，我们可以按照这些故障模型所提供的缺陷类型和寻找该类缺陷的方法找到尽量多的缺陷。
1 输入非法数据
1．1缺陷产生原因
开发人员通常用以下3种技术来处理非法输入：
? 防止不正确的输入进入被测软件。过滤掉不正确的输入，只允许合法输入通过界面。? 输入了不正确的数据后，软件提示错误信息，拒绝不正确的输入。
? 允许不正确的输入进入系统并进行处理，软件失效时调用异常处理程序，显示一些错误信息。
可见开发人员除了编写主要的功能代码外，还必须编写对非法输入的检查代码，这些代码经常被遗忘，或者编写完这部分代码后，开发人员很少认真检查，导致处理非法输入经常出错。
1．2如何发现这类问题
进行测试时从输入值的属性出发，一般考虑以下三点：
? 输入类型：键入无效的类型常会产生错误信息。
? 输入长度：对于字符型，键入太多的字符常会引出错误信息。边界值：输入边界值或超过边界值的数据。
1．3测试方法小结
? 应用场合：GUI的输入。
? 测试方法：分别从输入数据的类型、长度、边界值等方面进行考虑。
? 测试信息检查：
l 错误信息和错误要一致。
l 错误信息的内容为空，用户不知道为什么出错。
l 显示的错误信息是给开发人员调试使用的，例如“Error 5-unknown data”，开发人员可以通过该信息很容易找到错误类型，但是用户根本不明白，不知道做错了什么。
? 测试知识储备：牢记各基本数据类型的边界值。
2 输入默认值
2．1缺陷产生原因
一旦软件中使用了变量，就必须赋给初始值，如果在赋值之前就使用了这些变量，软件就会失效，正确地使用变量的顺序是：声明变量→给变量赋值→使用变量。通常会由于以下两个原因使变量的默认值不正确：
? 给变量赋值这一步经常会被开发人员不经意地路过。
? 开发人员有时不确定到底要赋什么初始值，就随便给了一个值，但用户并不认可该值，这种情况下，软件并不一定会失效，但对用户的使用会带来很多不便。例如某程序把打印默认输出份数设置为2份，会给用户造成很大麻烦。
2．2如何发现这类问题
确定应用软件中所使用的数据有以下一些基本原则：
? 查找选项按钮、配置面板、安装屏幕等。这种屏幕上显示的数据常常在应用程序的许多地方用到。
? 查阅源代码的数据声明部分（如果可以得到）。
? 确定了要测试的数据，可以通过以下操作来强制使用或不使用默认的值：
l 接受软件显示的默认值。有时软件需要用户输入一个值，如果没有输入任何值，软件就可能失效。这时可以只是简单的单击“确定”按钮来接受默认值，完成这个功能测试。
l 键入空值。删掉默认值，使输入域变成空值。
l 将默认值改为另一个值，这样会使应用程序以不同的值来运行。
l 将输入值改为另一个值，然后再变以空值。
一个好的软件会这样处理以上情况，将输入的不合法内容默认为合法边界内的某个合理值，或者返回错误提示信息。
2．3测试方法小结
? 应用场合：需要有默认值的地方。
? 测试方法：分别从选项按钮、配置面板、安装配置、开始界面等方面进行考虑，强制使用或不使用默认值等。
? 测试知识储备：全面理解需求规格说明书中对默认值的要求；同时深刻理解被测软件的行业背景。
3 输入特殊字符集
3．1缺陷产生原因
应用程序接受字符串输入，如果程序没有针对特殊输入进行特殊编程，那么就有可能导致程序挂起，主要包括以下3种情况：
? 字符集包括普通字符和特殊字符。例如，ASCII字符集包括普通字符和特殊字符。应用程序有时只能处理普通字符，当输入特殊字符时就会出现错误。
? 实现应用程序的程序设计语言有特定的处理一些字符和字符串的方法。例如，C语言把\n、++和&这样的字符用于特殊目的。如果将这些字符串键入到对话框中，程序必须进行错误处理，否则容易产生错误。
? 应用程序有时也使用设置名称、系统对象和程序的保留字符串集合。只要在程序中使用了这些字符串，就可能导致失效。
3．2如何发现这类问题
? 根据被测软件所处的操作系统、使用的程序设计语言、字符集等信息列出表格，通过测试小组的讨论，标明应用表格中的哪些字符和数据类型作为输入来测试。
? 根据经验，软件很少会因为这种操作而崩溃，通常它会挂起没有响应。
3．3测试方法小结
? 应用场合：需要接受字符输入的地方。
? 测试方法：根据被测软件的具体情况输入非法字符。
? 测试知识储备：尽可能多地了多地了解字符集、程序设计语言和操作系统中的保留字符串及其特定含义，可以使我们更好地分辨这类缺陷。
4 输入使缓冲区溢出的数据
4．1缺陷产生原因
开发人员没有考虑传送给内存缓冲区的字符串的大小。如果缓冲区只能保留固定长度的字符串，输入更长的字符串就会改写其他的内存存储单元，引起操作系统强制性地终止应用程序。
4．2如何发现这类问题
当应用程序允许输入字母、数字时，通过GUI控件（如文本框），或者通过API 调用的参数来进行这种测试。
? 首先弄清楚要测试的输入域的长度，输入最大字符串测试。
? 输入一个比最大字符串长的字符串，应用程序可能出现错误提示信息，提示不允许输入；或者输入了更长的字符串使应用程序崩溃。
4．3测试方法小结
? 应用场合：需要接受字符输入的地方。
? 测试方法：根据被测软件的具体情况输入最大字符串或输入一个比最大字符串更长的字符串。
? 测试知识储备：尽可能多地和开发人员讨论，以了解和确定输入域的合理长度。
5 输入产生错误的合法数据组合
5．1缺陷产生原因
测试多个输入值的组合，每个输入值已被单独测试过，但是这些值的组合可能会互相影响而引起软件失效。
5．2如何发现这类问题
首先要确定测试哪些输入组合，并弄清楚它们之间的“关系”。如果具备以下任一特性，就可以认为这些变量是有“关系”的。
? 描述的是有关单个内部数据结构的属性和内容。例如，输入面板需要用户输入列表的“行”和“列”，这时测试人员要输入单个内部数据结构“列表”的属性“行和列”。
? 一起用在了一个计算中，也就是将多个输入用做一个内部计算的操作数，因此这些输入变量具有了相互“关系”。
5．3测试方法小结
? 应用场合：输入值之间存在依赖关系。
? 测试方法：输入可能是存在问题的组合值。
? 测试知识储备：尽可能多的内部数据结构的属性和内容，并与开发人员探讨，以确定输入的数据值。
6 产生同一个输入的各种可能输出
6．1缺陷产生原因
单个输入产生多种输出的情况与先前的输入和被测系统的状态都有关系。例如，在文字处理程序中单击“关闭”按钮，如果文件被编辑且未被保存，程序将提示是否保存文件。如果文件已被保存过，则文件直接关闭。
6．2如何发现这类问题
测试人员必须具有关于被测系统软件的业务方面的知识，具备各种程序文档，明确一个输入可以产生何种输出。我们可以据此列出关于程序输入与输出的一个列表，然后进行测试。
6．3测试方法小结
? 应用场合：同一输入对应多个输出的情况。
? 测试方法：测试输入对应的每一个输出。
? 测试知识储备：全面理解需求规格说明书中的内容，找出输入与输出之间的关系。
7 输出不符合业务规则的无效输出
7．1缺陷产生原因
有时开发人员也可能对业务了解不深刻，对有些问题也是一知半解，因此编写出的软件就会产生不符合业务逻辑的问题。另外在绝大多数情况下开发人员会忽略处理没有遵循一般规则的输入，如果不对这些特殊情况进行编程处理，软件就会产生错误的结果。
7．2如何发现这类问题
? 测试人员应该尽可能地学习的涉及问题的领域。
? 有时在列举出无效输出后，也很难知道哪些输入组合能强制这些输出产生。这时测试人员必须先要确定哪些输入与输出有关，然后用产生意外结果的输入组合进行测试，测试过程中要注意输入执行顺序，用不同的顺序执行可能得到不同的结果。如果不能强制无效的输出产生，就说明软件没有这方面的缺陷。
7．3测试方法小结
? 应用场合：强制产生不符合业务背景的知识。
? 测试方法：列举出所有的无效输出，然后逐一测试。
? 测试知识储备：全面理解需求规格说明书中的内容，熟悉行业背景知识。
8 输出属性修改后的结果
8．1缺陷产生原因
输出常常具有可修改的属性，如颜色、形状、维数及大小等，用户可以修改这些属性。
在这种情况下，开发人员必须编码、设立初始或默认属性值，然后编码允许用户编辑
这些属性。当用户改变了这些属性后，内部的相应变量值也随着变化，再次进行处理时，这些值没有被重新恢复为默认值，输出的属性就被强制改变了。
8．2如何发现这类问题
该测试方法可以使用在那些输出具有可编辑性、可修改性的功能中。测试人员首先要
仔细了解能够产生的输出，特别要注意具有可编辑属性的输出。测试人员的任务就是
强制每个输出产生，并编辑其属性，然后再次强制输出产生。
8．3测试方法小结
? 应用场合：输出的结果，可以由用户修改属性得出。
? 测试方法：强制每个输出产生，并编辑其属性，然后再次强制产生输出。
? 测试知识储备：全面理解需求规格说明书中的内容，了解能够产生的输出。
9 屏幕刷新显示
9．1缺陷产生原因
通常GUI软件会产生刷新问题，因为GUI在对窗口进行覆盖、移动和调整大小时，必须刷新屏幕才能使对象重新显示。但是如果经常刷新，容易减慢应用程序的运行速度；
如果不刷新，又会影响用户对程序的使用，使用户必须停止工作，去寻找刷新的方法
才可以继续工作。所以开发人员有时候不能很好地确定什么时候需要刷新，需要刷新
多大范围的区域，这就发生了令人烦恼的刷新问题。
9．2如何发现这类问题
测试刷新问题的方法是增加、删除称移动屏幕上的对象，这样会使某些对象重新显示。
如果不能正确、及时地进行重新显示，就产生了软件缺陷。我们可以通过以下几个方法
来检查刷新：
? 从起始位置移动对象。先移动一点，然后增加移动幅度；先移动一次或两次，
然后多次移动，确保覆盖了所有区域。
? 从覆盖对象的边界开始一点点覆盖，使其中一个对象遮住别一个对象。
? 使用不同类型的对象。如果应用程序支持多种类型的对象，如文本对象、图形
对象等，就把这些不同对象混在一起使用。
9．3测试方法小结
? 应用场合：一个对象包含在另一个对象中，拖动被包含对象时，可能出现刷新问题。? 测试方法：增加、删除和移动屏幕上的对象。
? 测试知识储备：全面理解需求规格说明书中的内容，了解程序中对象之间的关系。----------------------------------------------------------------------------------------------------------------------
10 数据结构溢出
10．1缺陷产生原因
所有数据结构的大小都有上限。一些数据结构会逐步增加长度以充满机器内存容量或
磁盘空间，而其它数据结构具有固定的上限。开发人员经常对有关数据结构的内容
进行编码，忘记结构本身的物理局限。
10．2如何发现这类问题
? 确定数据结构的界限，尝试将过多的值输入数据结构。应该特别注意界限为
数据类型的边界256、1024、32768等上溢的测试。
? 对于下溢的测试，可以尝试多删除一个数据，例如当结构为空时，尝试再删除，
或者添加一个数据，尝试删除两个数据时的情况。
10．3测试方法小结
? 应用场合：程序中存在数组。
? 测试方法：尝试将过多的值输入数据结构，测试上溢；对于下溢的测试，
可以尝试多删除一个数据。
? 测试知识准备：全面理解需求规格说明书中的内容，确定数据结构的界限。
11 数据结构不符合约束
11．1缺陷产生原因
在编程过程中对内部数据结构都有所约束，包括大小、维数、类型、形状、屏幕
上的位置等。我们测试的重点就是用户能够设置的属性，这些属性使用了一组参数
来约束。在建立数据项和随后对数据项进行修改的任何时刻都要对数据属性的约束
进行检查。初始化代码中修改后的代码有错误，在修改错误的时候只修改了初始化
部分，而忽略了对其他部分的修改，使得其修改不完全，不彻底。
11．2如何发现这类问题
? 确认候选数据，并列出其可修改的属性。对每个属性列出有效值的允许范围、约
束的条件等。
? 确定所有可修改属性的功能位置。
? 对数据进行初始化，改变每个属性以确定是否正确进行了约束。
如果数据约束遭到破坏，可能导致系统崩溃，或者表现为响应时间延迟，错误信息
不正确以及使用错误数据产生的无效输出。
11．3测试方法小结
? 应用场合：应用程序内部的数据结构存在约束。
? 测试方法：破坏内部数据结构的约束。
? 测试知识储备：全面理解需求规格说明书中的内容，确定内部数据结构的所有约束。
12 操作数与操作符不符
12．1缺陷产生原因
几乎每个运算符都有它无效的操作数，对于具体的操作符，开发人员在使用它们时，
必须编写错误检查代码。例如：除以零的问题。
12．2如何发现这类问题
找到程序中包含的数据或输入（即操作数）的计算（即操作符）、数学表达式（即操
作符和操作数的组合）及对图形的操作。另外，对多个操作数进行组合也更容易发生
错误。例如，字符和数字都可以使用“+”操作符。对字符通过“+”把它们连成一串；
对数字通过“+”来进行加法运算。如果系统尝试把字符和数字相加，即进行相互矛盾
的操作，就会引起软件失效。
12．3测试方法小结
? 应用场合：需要进行数值计算的程序或图形操作的程序。
? 测试方法：对于数值计算考虑操作数和操作符之间的限定关系，对于图形计算还
要考虑各种输入数据之间的组合关系。
? 测试知识储备：全面掌握被测软件中操作符对操作数的要求。掌握不同的操作符
和操作数具有的不同的有效和无效的取值范围。
13 递归调用自身
13．1缺陷产生原因
函数有时会递归调用自身，如果不限制执行次数，递归就会出现问题，它不断地调用自身，很快地占用机器资源，最终产生溢出，使程序崩溃或挂起。产生这类问题的主要原
因是开发人员没有编码来保证循环和递归调用的终止，通常是在循环的开始或结束时缺
少检查条件。
13．2如何发现问题
在软件中寻找可以使用递归调用的功能。这时可以制作一个列表，标明软件中可能嵌入
递归的功能的列表，然后自己引用自己来检查程序是否能正确处理。
13．3测试方法小结
? 应用场合：需要和其它对象进行交互的地方。
? 测试方法：考虑对象的自我交互或复制。
? 测试知识储备：全面掌握被测软件的需求。
14 计算结果溢出
14．1缺陷产生原因
当所有的输入和数据都有效时，计算的最终结果也可以是无效的。所有变量都有值域范围，有时开发人员在执行计算时会忘记检查这些上限。
14．2如何发现这类问题
一次又一次地执行计算或使用很大或很小的输入和数据进行计算，重点测试数据类型的
初始值或边界值附近的值。
14．3测试方法小结
? 应用场合：应用程序执行能够导出待产生结果并进行内部存储的计算。
? 测试方法：强制数据产生上溢或下溢。
? 测试知识储备：全面掌握被测软件的需求，了解计算变量的上下限。
15 数据共享或关联功能计算错误
15．1缺陷产生原因
通常对孤立的功能进行测试时不会发生很多缺陷，而当把单独的功能和同一软件中的其它功能结合时，就可能出现很多软件缺陷。这种缺陷的产生往往是在两个或更多的功能使用了共享数据集，而每个功能允许使用的数据范围不同引起的。例如，一个功能可能会将某数据项设置为特定大小，然而另一个功能却允许该数据项的大小可以超过第一个功能的处理能力。开发人员根本没考虑到该数据项在其它功能处也可以修改，他们只是编码保证在该功能中数据的合法性，而当使用该数据时，没有再编码来检查可以使用的范围；而此时，另一个功能修改了共享数据，当再使用这些数据时就产生了缺陷。
15．2如何发现这类问题
当应用程序在同一时间完成一个以上的功能或当一个以上的功能在同一时间处于运行状态时，就可以使用该方法进行测试。利用一个功能影响输入、输入数据或另一个功能的计算。在测试前要确定哪些功能是相互依赖或共享数据的：
? 能应用同样输入的每个功能。如果这些功能有相互重叠的输入域，就可能存在交互问题。
? 有类似的输出产生功能。如果某些功能结合起来产生单个输出，就说明这些部件之间存在关系，应该被一起测试。
? 一个功能被包含在另一个功能的计算中。例如要测试鼠标选取对象的功能，不仅要测度鼠标选取屏幕上的文本的功能，还可以把包含超链接文本、粗体、斜体、符号及图形元素放在一起，测试鼠标选取这些元素的功能。
15．3测试方法小结
? 应用场合：一个以上的功能在同一时间处于运行状态。
? 测试方法：以点代面，重点测试某一功能，对可能与这个功能相连的其它功能附带测试。
? 测试知识储备：全面掌握被测软件的需求，在测试之前对被测功能之间的依赖关联有所掌握，另外还需要对共享数据有所掌握。
16 文件系统超载
16．1缺陷产生原因
开发人员可能会忘记编写代码处理满状态的文件系统，忽略了诸如CreateFile，WriteFile等操作系统API的错误检查代码，没有这样的代码，当显示满状态的文件系统时，API调用就会失败，软件就会在没有任何警告的情况下崩溃。
16．2如何发现这类问题
创建满容量或近乎满容量的文件系统，然后强制执行各种通过输入或输出访问文件系统的操作；或者打开足够多的文件，打开文件时会强制备份创建的副本，从而占用双倍的存储空间，这种操作达到一定程度时，会达到该系统的容量，于是就能测试应用程序处理超载状态的文件系统的能力。（通常通过磁盘配额实现）
16．3测试方法小结
? 应用场合：系统较大，运行时需要较大的空间。
? 测试方法：强制磁盘系统满容量或容量小于等于被测软件运行时所需容量后，运行被测软件或利用测试工具模拟磁盘状况。
? 测试知识储备：全面掌握被测软件的需求，了解被测软件处理超载状态的文件系统的能力。
17 介质忙或不可用
17．1缺陷产生原因
当多个应用程序同时访问硬盘（或其它存储器），操作系统为提供多请求服务会慢下来，并且必须对应用程序进行编程以处理这些延迟，当延迟变得很长时，没有对这些错误进行响应的应用程序就会出现错误。
17．2如何发现这类问题
通过启动大量应用程序，强制它们都打开并保存文件使文件系统处理繁忙状态；或者同时下载大量文件也可以使后台拥挤；检查被测软件能否正确处理这种情况，应用程序应该给出错误信息或等待批示，提示用户正在处理。
17．3测试方法小结
? 应用场合：应用程序的运行需要消耗大量内存或运行时需要其它相关软件同时运行。? 测试方法：启动大量程序或利用测试工具模拟磁盘状况。
? 测试知识储备：全面掌握被测软件的需求，了解被测软件运行时对系统的要求。
18 介质损坏
18．1缺陷产生原因
? 损坏的介质可能会使操作系统传回错误代码，这些错误代码没有在应用程序中编程处理。
? 操作系统不能检测出所有这样的错误，操作系统自己也有错误或者损坏的介质损坏了部分操作系统。
18．2如何发现这类问题
使用损坏了的介质，例如，刮伤、灰尘、磁干扰等。检查应用程序对错误的处理能力，应用程序可以对错误进行处理或者将问题告诉用户，并要确保用户数据文件不丢失、为损坏。
18．3测试方法小结
? 应用场合：应用程序对安全的要求较高，对灾难恢复的要求较高。
? 测试方法：用实际损坏介质的方法测试应用程序。
? 测试知识储备：全面掌握被测软件的需求，了解被测软件运行时对系统的要求。
19 文件名不合法
19．1缺陷产生原因
操作系统本身具有自己的文件命名规范，例如，Dos的8.3格式。在Windows中，文件名不能超过255个字符，并且文件名不可以含有/ \ : < > ? * |这8个字符，以及AUX、COM1、COM2、COM3、COM4、CON、LPT1、LPT2、LPT3、LPT4、NUL及PRN这些操作系统保留字。
开发人员在应用程序中使用不相同的规则管理文件名，当应用程序和操作系统使用的文件名
命名规则不一致的时候，就会发生问题。
19．2如何发现这类问题
? 保存文件为操作系统不允许的文件名，例如，文件名中含有/ \ : < > ? * |这8个字符，测试应用程序是否不允许输入包含这些字符的文件名。
? 输入一些应用程序不允许使用的文件名，例如，使用过长的、含有特殊字符的、可能相互作用的字符作为文件名，检查应用程序能否识别该文件。
19．3测试方法小结
? 应用场合：几乎所有涉及需要输入文件名功能的应用程序。
? 测试方法：输入操作系统不允许的文件名和应用程序不允许使用的文件名。
? 测试知识储备：全面掌握被测软件的需求，了解操作系统和应用程序对文件名的要求。
20 更改文件访问权限
20．1缺陷产生原因
在操作系统中，可以设置不同用户对不同的文件具有不同的访问权限（如读写、只读等）。程序员必须在访问文件的函数中考虑文件的访问权限，例如在每个文件写入之前检查文件的访问权限。如果没有进行检查，就会导致程序出错。另外，如果文件访问失败，程序员必须要有正确的错误的代码，以保证程序可以正确捕获所产生的错误。
20．2如何发现这类问题
? 打开两个应用程序，关闭同一个文件。例如，把同一个应用程序的不同版本安装在同一机器上，在不同版本的应用程序中打开和关闭同一文件，或试着在某个应用程序中打开在另一个程序中已打开的文件，这可能导致文件访问权限的冲突。
? 打开一个文件，在操作系统中修改文件的访问权限。有些操作系统允许权限高的用户控制一般用户已经打开的文件。
20．3测试方法小结
? 应用场合：需要对文件进行读写操作的应用程序。
? 测试方法：修改文件访问权限或使用低权限的用户访问文件。
? 测试知识储备：全面掌握被测软件的需求，了解读写文件所需的权限。
21 文件内容受损
21．1缺陷产生原因
开发人员编写代码来读取和写入文件，他们也编写代码来调用系统API得到文件指针，并打开和关闭文件。由于某些原因，这些系统API会失败或传回异常返回值。如果开发人员没有编写代码来验证传回的预期返回值，则应用程序会由于无法处理异常而失败。
21．2如何发现这类问题
? 手工损坏文件。从应用程序已创建的某个完整文件开始对其进行编辑，改变文件格式和内容。
? 使用测试工具。模拟CRC（循环冗余校验）错误，或强制文件API返回无效的返回码。
21．3测试方法小结
? 应用场合：需要对文件格式和内容进行校验的应用程序。
? 测试方法：手工损坏文件或利用测试工具模拟CRC错误。
? 测试知识储备：全面掌握被测软件的需求，了解文件读写需要的权限。
基于模型的测试综述报告
基于模型的测试综述 2016年1月
摘要 面向对象软件开发应用越来越广泛，自动化测试也随之被程序员认可和接受，随之而来的就是基于UML的软件开发技术的大范围普及和基于模型的软件测试技术的普遍应用。基于模型的测试是软件编码阶段的主要测试方法之一，具有测试效率高、排除逻辑复杂故障测试效果好等特点。本文描述了基于模型的测试的模型以及建模标准，并介绍基于模型的测试的基本过程以及支持工具，同时通过七个维度对基于模型的测试方法进行描述。最后分析基于模型的测试的优缺点并列举了应用案例。 关键词：软件测试，基于模型的测试，软件模型，测试工具
目录 摘要................................................ I 1 引言 (2) 2 基于模型的测试、模型以及建模标准 (2) 2.1基于模型的测试 (2) 2.2基于模型的测试的模型 (3) 2.3建模标准 (4) 3 基于模型的测试的基本过程及支持工具 (5) 3.1基于模型的测试的基本过程 (5) 3.2支持工具 (6) 4 分类 (7) 4.1 模型主体 (7) 4.2 模型冗余程度 (7) 4.3 模型特征 (7) 4.4 模型表示法 (7) 4.5 测试用例选择标准 (8) 4.6 测试用例生成技术 (8) 4.7 联机、脱机测试用例生成 (9) 5 基于模型的测试的工具Spec Explorer (9) 5.1 Spec Explorer (9) 5.2 连接测试用例和待测系统 (9) 5.3 静态模型和实例模型 (11) 6 基于模型的测试的优缺点 (11) 参考文献 (13)
基于MFM的故障诊断模型的研究
基于MFM的故障诊断模型的研究 发表时间：2016-08-25T16:02:40.417Z 来源：《电力设备》2016年第12期作者： 1罗成 2牟春晓 3孙睿 4许潇 5曹东亮 6李雪 [导读] 多级流模型是一种基于目标的层次化、图形化的建模方法，它将真实的物理系统以物质流、能量流、信息流的形式进行抽象。 1罗成 2牟春晓 3孙睿 4许潇 5曹东亮 6李雪艳 （1、2、4、5、6国网山东省电力公司检修公司 264000 ; 国网山东省电力公司东营供电公司 257000） 摘要：多级流模型将复杂系统分解为不同的功能层，相互之间通过完成关系、实现关系和条件关系相连接。本文通过研究MFM中流的基本属性、功能节点分组及MFM的建模方法，建立变电站的MFM模型。 关键字：MFM 故障诊断模型 1. MFM模型 基于多级流模型（Multilevel Flow Models, MFM）的故障诊断方法，是把整个生产过程抽象成广义的“流”，根据生产系统物质流、能量流以及信息流等变化推断故障源[1]。目前，MFM已经成功应用于复杂系统的故障诊断。 2.MFM建模的理论基础 多级流模型是一种基于目标的层次化、图形化的建模方法，它将真实的物理系统以物质流、能量流、信息流的形式进行抽象，然后使用一些特定的图形符号来描述系统过程的目标、功能以及设备单元，从而对系统的生产、运行过程进行建模。 MFM对系统主要进行三个层次的描述：目标、功能、设备元件 [2]。在电力系统中，应用较多的功能节点有：源、目标、传输、存储、平衡、汇、连接节点、观测者、决策者、管理者及操作者等，如图1所示。 图1 常用功能节点 每个功能模型通过流网络以特定的连接关系与一个或多个目标模型连在一起，以完成系统的目标。同样，目标模型也能通过特定的条件关系与一个或多个功能模型连接起来，表明此目标为该功能实现的前提。目标、功能和设备元件之间是多对多的关系，概括起来说，主要有：达成关系、条件关系、实现关系等。 多级流模型的建模思想是把生产过程抽象成广义的“流”，以系统目标与实现目标的功能为模型主体，建立复杂流程工业系统的抽象层次模型。以 “流”作为建模的主线，它主要可分为：能量流、物质流、信息流[3]。 因为多级流建模是一种基于目标与功能的建模方法，子目标的实现是总目标实现的前提条件，所以，可以把大系统分解成若干个子系统。子系统的目标即为子目标，子目标的实现要靠多种功能共同完成。 3.简单电力系统MFM简化模型分析 下面以一个简单电力系统的简化MFM模型为例，说明MFM建模的机理，对MFM的建模过程进行验证。简单电力系统的示意图如图2所示。 图2 简单电力系统示意图 电力系统的供电过程是：发电机发出电能，通过母线输送到线路，然后再通过母线输送到负载。 系统主要由发电机C1、母线C2和C5、线路C4、负载C6和保护C3组成。本文主要以其两个目标进行举例说明：G1是系统的主目标——维持负载正常供电；G2是系统的子目标——为线路提供保护。 电力系统的目标、功能节点及设备元件间的关系如上文分析的是多对多的关系。它们之间的关系主要有：设备元件C1-C6和功能节点Fl-F10间的实现关系，目标G1与功能节点F1-F7间的达成关系，子目标G2与功能节点F4的条件关系以及功能节点间的连接关系。 考虑到实际电力系统的复杂性，可以将电力系统分模块建模，主要的模块有发电机、线路、母线、保护和负载。各个模块的模型如图3所示，这些模块之间可以相互连接，其中母线模块可以根据母线上具体的出现调整出线的多少，保护可以具体到保护的类型。
软件故障的21种模型(DOC)
软件功能性测试的21种故障模型 测试的目标是要发现错误，因此在编写测试用例的时候也要遵循这个目标，尽量在软件的最薄弱环节多编写测试用例。虽然测试时有很多单个输入变量、多个输入变量的组合，但优秀的软件测试人员不会依靠运气，他们有着丰富的经验和直觉，可以从中找到哪些是需要进行测试的，哪些不需要测试，哪些操作可能会引起软件失效。把这些测试人员的经验和直觉尽量归纳和固化，就形成了一些故障模型。故障模型指明了故障是如何以及为什么会在软件执行时引起软件失效。在测试过程中，我们可以按照这些故障模型所提供的缺陷类型和寻找该类缺陷的方法找到尽量多的缺陷。 1 输入非法数据 1．1缺陷产生原因 开发人员通常用以下3种技术来处理非法输入： ? 防止不正确的输入进入被测软件。过滤掉不正确的输入，只允许合法输入通过界面。? 输入了不正确的数据后，软件提示错误信息，拒绝不正确的输入。 ? 允许不正确的输入进入系统并进行处理，软件失效时调用异常处理程序，显示一些错误信息。 可见开发人员除了编写主要的功能代码外，还必须编写对非法输入的检查代码，这些代码经常被遗忘，或者编写完这部分代码后，开发人员很少认真检查，导致处理非法输入经常出错。 1．2如何发现这类问题 进行测试时从输入值的属性出发，一般考虑以下三点： ? 输入类型：键入无效的类型常会产生错误信息。 ? 输入长度：对于字符型，键入太多的字符常会引出错误信息。边界值：输入边界值或超过边界值的数据。 1．3测试方法小结 ? 应用场合：GUI的输入。 ? 测试方法：分别从输入数据的类型、长度、边界值等方面进行考虑。 ? 测试信息检查： l 错误信息和错误要一致。 l 错误信息的内容为空，用户不知道为什么出错。 l 显示的错误信息是给开发人员调试使用的，例如“Error 5-unknown data”，开发人员可以通过该信息很容易找到错误类型，但是用户根本不明白，不知道做错了什么。 ? 测试知识储备：牢记各基本数据类型的边界值。
预测模型与案例
预测模型 最近几年，在全国大学生数学建模竞赛常常出现预测模型或是与预测有关的题目，例如疾病的传播，雨量的预报等。什么是预测模型？如何预测？有那些方法？对此下面作些介绍。 预测作为一种探索未来的活动早在古代已经出现，但作为一门科学的预测学，是在科学技术高度发达的当今才产生的。“预测”是来自古希腊的术语。我国也有两句古语：“凡事预则立，不预则废” ，“人无远虑，必有近忧” 。卜卦、算命都是一种预测。中国古代著名著作“易经”就是一种专门研究预测的书，现在研究易经的人也不少。古代的预测主要靠预言家，即先知们的直观判断，或是借助于某些先兆，缺乏科学根据。预测技术的发展源于社会的需求和实践。20 世纪初期风行一时的巴布生图表就是早期的市场预测资料，哈佛大学的每月指数图表为商品市场、证券市场和货币市场预测提供了依据。然而这些预测都未能揭示1929－1930 年经济危期的突然暴发，使工商界深感失望。尔后，经济学家们从挫折中吸取了教训，采用趋势和循环技术对商业进行分析和预测，科学预测也因此开始萌生。20 世纪30 年代凯思斯提出政府干预和市场机制相结合的经济模型，1937 年诺依曼又提出了扩展经济模型，对近代经济模型产生重要的影响，科学的经济和商业预测也就步入发展阶段。 技术预测开始于二次世界大战后的20 世纪40 年代，直到20 世纪50 年代未才广泛应用于工农业和军事部门。由于社会、科学技术和经济的大量需求， 预测技求才成为一门真正的科学，预测未来是当 代科学的重要任务 20 世纪以来，预测技术所以得以长足进步，一方面，与社会需求有很大关
系，另一方面通过社会实践和长期历史验证，表明事物的发展是可以预测的。而且借助可靠的数据和科学的方法，以及预测技术人员的努力，预测结果的可靠性和准确性可以达到很高的程度，这也是预测技术迅速发展的另一个重要原因。 科学技术、经济和社会预测的应验率也是很高的。维聂尔曾预言20 世纪是电子时代，法国思想家迈希尔18 世纪末到19 世纪初对巴黎未来几百年的发展进行了预测。从1950 年的实际情况分析，他的预测中有36％得到证实，28％接近实现，只有36％是错误的。法国哲学家和数学家冠道塞在法国大革命时期曾采用外推法进行了一系列社会预测，其中75％得到证实。沙杰尔莱特1901 年在《二十世纪的发明》一书中的一些预测，其中64％得到证实。凯木弗尔特在1910 年和1915年公布的25项预测中，到1941年只有3 项未被证实，3 项是错误的。我国明朝开国功臣刘基就预测将来是天上铁鸟飞，地上铁马跑，那时还没有火车、飞机。 预测的目的在于认识自然和社会发展规律，以及在不同历史条件下各种规律的相互作用，揭示事物发展的方向和趋势，分析事物发展的途径和条件，使人们尽早地预知未来的状况和将要发生的事情，并能动地控制其发展，使其为人类和社会进步服务。因而预测是决策的重要的前期工作。决策是指导未来的，未来既是决策的依据，又是决策的对象，研究未来和预测未来是实现决策科学化的重要前提。预测和决策是过程的两个方面，预测为决策提供依据，而预测的目的是为决策服务，所以不能把预测模型和决策模型截然分开，有时也把预测模型称为决策模型。
软件测试过程模型
软件测试过程模型 发布时间: 2010-7-27 11:02 作者: 未知来源: 51Testing软件测试网采编 字体: 小中大| 上一篇下一篇| 打印| 我要投稿| 每周一问，答贴有奖 目前主流的开发模型主要有：瀑布模型、原型模型、螺旋模型、增量模型、渐进模型、快速软件开发(RAD)以及Rational统一过程(RUP)等，这些模型对于软件开发过程具有很好的指导作用，但是，非常遗憾的是，在这些过程方法中，并没有充分强调测试的价值，也没有给测试以足够的重视，利用这些模型无法更好地指导测试实践。软件测试是与软件开发紧密相关的一系列有计划的系统性的活动，显然软件测试也需要测试模型去指导实践。下面对主要的模型做一些简单的介绍。 V模型 V模型是最具有代表意义的测试模型。在传统的开发模型中，比如瀑布模型，人们通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成后的一个阶段，尽管有时测试工作会占用整个项目周期的一半的时间，但是有人仍然认为测试只是一个收尾工作，而不是主要过程。V模型的推出就是对此种认识的改进。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，如模型图中所示，图中的箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。 V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。 V模型指出，单元和集成测试是验证程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满
故障诊断与容错基于模型和基于信号的方法
故障诊断与容错技术概述——第一部分：基于模型和信号的故障诊断技术 引言：随着工业系统复杂性和费用的不断增加，不能容忍性能下降、生产率降低和安全隐患这些必须尽早的检测和识别出异常和故障的存在，并采取实时的故障容错操作尽量降低性能的下降避免危险情况出现。在过去40年里，关于故障诊断和容错技术的丰硕的研究成果被报道出来并应用到各种工程系统中。这三部分的调查目的在于给出实时故障诊断和容错技术的全面的回顾，对过去十年的成果进行重点关注。在本文中，全面回顾关于基于模型和信号处理的故障诊断方法和应用。 关键词：冗余分析；故障容错；基于模型的的故障诊断；实时监测；基于信号的故障诊断； Part I介绍 众所周知，许多工程系统，例如航空发动机、车辆动力学、化学工艺、制造系统、电力网络、电气设备、风力发电转换系统以及工业电子设备是安全关键系统。工业系统对潜在过程异常和部件故障的安全和可靠性的要求不断提升。因此，尽早的检测和识别出任何类型的故障和潜在异常并采取容错操作以降低性能下降避免危险情况的出现十分重要。 故障被定义为系统的至少一个特征属性或参数从可接受的/平常的/标准的状态出现一个不受约束（原文：unpermitted）的偏差。类似的故障例如，执行器阻塞、传感器失效或者一个系统失去连接。因此通常故障常被分为执行器故障、传感器故障以及设备故障（或者称为组件故障或参数故障），这些故障会打断系统的控制器对系统部件的控制行为或者产生大量的测量误差或者直接改变系统的动态输入输出属性，从而导致系统的性能下降甚至使整个系统崩溃或损坏。为了提升所关心系统的可靠性，故障诊断通常通过使用冗余的概念用于监控、定位，并辨识故障，冗余通常可分为硬件冗余和软件冗余(或称为解析冗余)两种。硬件冗余的基本思想是使用相同的输入信号分量，从而使得复制的输出信号可以进行
软件测试综合题目(附答案)-上
一、选择题： 1.模块的耦合度描述了___D___。 A．模块内各种元素结合的程度B．模块内多个功能之间的接口 C．模块之间公共数据的数量D．模块之间相互关联的程度 2.内聚是一种指标，表示一个模块_B_____。 A．代码优化的程度B．代码功能的集中程度 C．完成任务时及时程度D．为了与其他模块连接所要完成的工作量3.在UNIX操作系统中，把输入/输出设备看作是__D____。 A．普通文件B．目录文件C．索引文件D．特殊文件4.“
基于模型的分时段软件测试工具TPT
基于模型的分时段软件测试工具TPT TPT是针对嵌入式系统的基于模型的测试工具，特别是针对控制系统的软件功能测试。TPT支持所有的测试过程：包括测试建模、测试执行、测试评估以及测试报告的生成。 TPT软件由于首创地使用分时段测试（Time Partition Testing），使得控制系统的软件测试技术得以极大提升；同时由于TPT软件支持众多业内主流的工具平台和测试环境，能够更好地利用客户已有的投资，实现各种异构环境下的自动化测试；针对MATLAB/Simulink/Stateflow以及TargetLink，TPT提供了全方位的支持进行模型测试。 PikeTec公司是全球知名的基于模型的嵌入式系统测试工具TPT的软件供应商，总部位于德国柏林，其创始人均在戴姆勒公司拥有十多年的嵌入式软件开发经验。TPT产品曾被评为2005年戴姆勒最佳创新软件，并在戴姆勒、大众、奥迪、保时捷、通用等汽车整车厂及多家零部件企业（如博世、大陆、海拉）中得到广泛应用，如戴姆勒的多个车型的混合动力车的动力总成、电池管理控制器的测试，博世的汽油机和柴油机控制系统测试等。（请登录PikeTec的TPT产品了解更多产品详情。） 北汇信息作为PikeTec的中国合作伙伴，将帮助中国客户借助TPT提升嵌入式控制系统的开发效率。 分时段测试方法 分时段测试（Time Partition Testing）是一种采用分时段对软件进行测试和验证的测试方法，主要被用于嵌入式系统中基于模型的模块测试、集成测试、系统测试和回归测试。 通常软件测试的一种分类是静态测试和动态测试。静态测试是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。例如QAC C/C++、Logiscope等软件都属于静态测试工具。
串并联可靠性模型的应用及举例
上海电力学院 选修课大型作业 课程名称：机电系统可靠性与安全性设计报告名称：串并联可靠性模型的应用及举例院系：能源与机械工程学院 专业年级：动力机械140101 学生姓名：潘广德 学号：14101055 任课教师：张建平教授 2015年4月28日
浅谈串并联可靠性模型的应用并举例 摘要 详细阐述了机械可靠性工程中串并联可靠性模型的应用，并详细的举例说明。系统可靠性与组成单元的数量、单元可靠性以及单元之间的相互联接关系有关。以便于可靠性检测，首先讨论了各单元在系统中的相互关系。在可靠性工程中，常用可靠性系统逻辑图表示系统各单元之间的功能可靠性关系。在可靠性预测中串并联的应用及其广泛。必须指出，这里所说的组件相互关系主要是指功能关系，而不是组件之间的结构装配关系。 关键词：机械可靠性串联并联混联应用举例 0前言 学技术的发展，产品质量的含义也在不断的扩充。以前产品的质量主要是指产品的性能，即产品出厂时的性能质量，而现在产品的质量已不仅仅局限于产品的性能这一指标。目前，产品质量的定义是：满足使用要求所具备的特性，即适用性。这表明产品的质量首先是指产品的某种特性，这种特性反应这用户的某种需求。概括起来，产品质量特性包括：性能、可靠性、经济性和安全性四个方面。性能是产品的技术指标，是出厂时产品应具有的质量属性，显然能出厂的产品就赢具备性能指标；可靠性是产品出厂后所表现出来的一种质量特性，是产品性能的延伸和扩展；经济性是在确定的性能和可靠性水平下的总成本，包括购置成本和使用成本两部分；安全性则是产品在流通和使用过程中保证安全的程度。在上述产品特性所包含的四个方面中，可靠性占主导地位。性能差，产品实际上是废品；性能好，也并不能保证产品可靠性水平高。反之，可靠性水平高的产品在使用中不但能保证其性能实现，而且故障发生的次数少，维修费用及因故障造成的损失也少，安全性也随之提高。由此可见，产品的可靠性是产品质量的核心，是生产厂家和广大用户所努力追求的目标。 1串联系统可靠性模型的工作原理 如果一个系统中的单元中只要有一个失效该系统就失效，则这种系统成为串联系统。或者说，只有当所有单元都正常工作时，系统才能正常工作的系统称为串联系统。 设系统正常工作时间（寿命）这一随机变量为t，则在串联系统中，要使系统能正常工作运行，就必须要求每一个单元都能正常工作，且要求每一单元的正常工作时间都大于系统正常工作时间t。假设各个单元的失效时间是相互独立的，按照概率的乘法定理和可靠性定
故障检测与诊断的模型
故障检测与诊断的模型 发表时间：2017-08-01T11:15:27.483Z 来源：《电力设备》2017年第9期作者：陈明庆 [导读] 摘要：快速、准确的故障检测与诊断离不开有效的系统模型。针对故障检测与诊断的特点，文章简要介绍了机理建模（南京理工大学江苏南京 210094） 摘要：快速、准确的故障检测与诊断离不开有效的系统模型。针对故障检测与诊断的特点，文章简要介绍了机理建模、知识建模和数据驱动建模三类传统建模方法，并从不同维度对以上几种建模方法作了比较阐述，同时基于上述各模型的特点，给出了几种混合建模的思路。 关键词：机理；知识；数据驱动；混合模型 0 引言 故障检测与诊断是一门相对独立的技术。我国在1979 年才初步接触故障检测与诊断技术，经过30多年的发展，故障检测与诊断技术已在自动驾驶、人造卫星、航天飞机、汽轮发电机组、大型电网系统等重要核心领域得到广泛应用。 目前，故障检测与诊断的模型大致有基于机理的模型、基于知识工程的模型、基于数据驱动的模型，文章将结合各模型的特点重点探讨故障检测与诊断中混合建模的思路。 1 机理模型 基于机理模型的方法首先需要被诊断系统精确的机理模型，然后利用构造出来的观测器预估系统的输出值，再将估计值与实际值做差产生残差。当系统运行正常时，残差应为零或近似于零；当系统出现故障时，残差量会明显超出允许范围。基于机理模型的方法根据残差产生的原因可细分为参数估计法、状态估计法、等价空间法等。参数估计法根据观测数据来辨识系统的动态参数，依据系统参数与模型参数的差值来判断系统是否出现故障。状态估计法通过对系统的状态进行重构，通过与可测变量做差生成残差序列，并采用统计检验法从残差序列中把故障检测出来，前提是系统可观测或者部分可观测，一般用各种状态观测器或滤波器进行状态估计。等价空间法是通过系统的输入输出真实值来检验系统机理的等价性，通过确定系统的输入输出间的冗余，实现检测和分离故障的效果。 基于解析模型的故障诊断方法充分体现了过程的内部机理，外延性好。但当系统过于复杂时无法获取其内部机理的全部信息，具有一定的局限性。 2知识工程模型 基于知识的方法主要是通过相关的经验建立系统的定性模型来解决复杂的故障诊断问题。基于神经网络、模糊逻辑方法是常用的方法。其中，神经网络因其具有处理非线性和自学习以及并行计算能力的特点，有利于非线性系统的故障诊断。模糊逻辑由于其概念易于理解，表达上更接近人的思维，适用于复杂的故障诊断中。 基于知识的方法不需要精确的定量机理模型，其适用于有相关经验和知识的对象，且诊断的结果易于理解。但是，其最大的缺点是通用性差，必须通过大量的经验知识才能够建立“知识库”；当系统比较复杂时，很容易出现一种未知故障会导致误报和漏报的情况。此时，基于知识的方法将不再适用。 3数据驱动模型 基于数据驱动的方法是通过采集系统的输入输出数据，然后分析数据的各种统计特征，建立过程的数据特征模型。目前，常用的方法有小波分析、神经网络、主成分分析等。小波分析方法是对所采集的信号进行相关处理，处理后的信号中除去由于输入变化引起的奇异点，剩下的奇异点即为系统可能出现的故障点。神经网络能够实现自组织、自学习，同时还具有处理非线性、并行、信息分布存储等能力，这大大提高了故障诊断的效率。主成分分析方法的主要是通过坐标变换将数据从高维空间映射到低维空间，建立正常情况下的主成分模型，当实测信号偏离所建模型时即可判断系统出现异常。 基于数据驱动的方法不必像基于机理模型那样需要过程的模型或先验知识只需对过程数据进行处理与分析，简单方便，实时性好，实用性强。但是数据模型的内插性及外延性较差，无法获取大量的各种状态下的过程数据。 4 混合模型 基于机理与基于数据驱动模型相结合的混合建模技术既能保证模型有明确的物理意义，又能保证模型具有较高的精度[6]。
基于模型的执行器故障诊断
第41卷第10期2007年10月 浙 江 大 学 学 报(工学版) Journal o f Zhejiang U niv ersity (Engineer ing Science) Vol.41No.10Oct.2007 收稿日期:2007-07-30. 浙江大学学报(工学版)网址:w w w.journals.z https://www.360docs.net/doc/1b1025719.html,/eng 基金项目:国家自然科学基金资助项目(60774031). 作者简介:尚群立(1964-),男,陕西武功人,教授,从事智能仪表,鲁棒控制理论及应用等工作.E mail:qlshang@sin https://www.360docs.net/doc/1b1025719.html, 基于模型的执行器故障诊断 尚群立,孙 黎,吴海燕 (杭州电子科技大学自动化学院,浙江杭州310018) 摘 要:为依据执行器的动态特性分析,实现执行器设备故障的在线诊断与分离,在机理分析的基础上建立起执行器完整的非线性动态数学模型,由执行器工作过程中的实测信号和模型计算获得残差实现故障的在线诊断,通过残差的变化及其组合情况分析完成故障分离.实验结果表明,利用动态机理模型计算得到的阀位、薄膜气室压力的理论计算值和实测值进行残差分析,可以准确及时地诊断与分离出如阀体阻塞、填料函磨擦力增大、薄膜或气路接头破损、气源压力下降、弹簧老化等执行器主要的内在故障.关键词:数学模型;故障残差;执行器 中图分类号:T P277 文献标识码:A 文章编号:1008-973X(2007)10-1660-04 Model based actuator fault diagnosis SHAN G Q un li,SU N Li,WU Hai yan (School of A utomation,H angz hou D ianz i Univ er sity ,H angz hou 310018,China) Abstract:Online actuator fault diag no sis and separation w ere r ealized based o n dynam ic characteristics analysis and com plete no nlinear dynamic models for actuato rs w ere co nstructed based on mechanical analy sis.The o nline fault diag no sis w as r ealized by using the fault residuals obtained from the measured actua to r signals and the mo del calculation v alues,then the fault separatio n w as perfo rmed through analyzing the varieties of the residuals and its combination.The ex perimental results sho w that through analy zing the re siduals of valve stem displacement and pressure value m ain faults can be accurately and tim ely diagnosed and separated,such as valve blo ckage,fr ictio n enlarg e,diaphragm leakag e,supply pressure dro p and spring aging. Key words:mathem atical model;fault residual;actuator 检测仪表、DCS 控制系统、执行器三类工业自动化仪表的技术水平已成为流程工业发展的决定性因素之一,并深刻地影响着生产的质量、效率、安全和环保等.以控制阀和执行机构为主体、以阀门定位器为核心控制部件的执行器,通过调节介质流量来控制工艺参数,是整个自动化系统中必备且重要的终端执行仪表,其对控制系统调节品质的优劣、安全平稳运行具有很大的影响. 执行器安装在生产现场,由于高温、高压/高压差、振动、腐蚀性或在有悬浮颗粒或纤维介质的环境 下工作,执行器各部件会出现故障,这可能会导致出现有毒介质泄漏等严重安全事故、或不动作导致停产等生产事故,所以执行器设备故障在线诊断对整个自动化控制系统的可靠性非常重要.而故障诊断 由于不能安装在线检测传感器,主要依据执行器的动态特性分析. 本文研究了基于流体力学和热力学原理建立的描述执行器气动定位系统动态特性的数学模型,并通过模型计算以及实测获得故障残差,实现故障检测,进一步通过对残差的分析,进行故障分离.
常用的收缩徐变预测模型
1.1 国内外常用的收缩徐变预测模型 1.1.1 ACI 模型 1982年，美国混凝土协会在ACI-209R-82规范中推荐的收缩徐变模型采用了双曲线函数，考虑了混凝土的各种因素，且不区分弹性变形和塑性变形错误!未找到 引用源。 。 徐变系数为： ()()() ()0.6 0.6 ,10t t t τ?τ?τ-=∞ +- (0.1) ()1 234562.35K K K K K K ?∞= (0.2) 式中： τ——加载龄期，要求7≥天，否则该公式不适用； t ——计算龄期； 1K ——混凝土的加载龄期影响系数，10.118 01.25K t -=； 2K ——为环境相对湿度H 的影响系数，2 1.270.0067K H =-（当H ＞ 40%）； 3K ——为混凝土构件平均厚度的影响系数； 4K ——为混凝土稠度的影响系数，40.820.00264K S =+，S 为新鲜混 凝土的坍塌度，以mm 计； 5K ——为细骨料含量影响系数，50.880.0024K f =+，f 为细骨料 ()4.8mm <占总骨料分率； 6K ——为空气含量影响系数，60.460.091c K A =+≥ c A ——为新鲜混凝土中空气含量的体积，以%计算。 收缩系数表达式为： ()max ( )()35sh sh t t t εε=+ (0.3) 1.1.2 CEB-FIP （1978）模型 (1)徐变错误!未找到引用源。 对于单轴受力的混凝土构件，在时刻τ受到大小为0σ的常应力的作用，在t
时刻的徐变应变(),c t ετ表达式为： ()() ()0 ,,28c c t t E σετφτ= (0.4) ()()()(),,d d f f t t t αφτφβτβββτ??=+-?? (0.5) 式中，(,)d d t φβτ为可恢复的滞后弹性变形，[()()]f f t αβββτ-是不可恢复的流变变形，()f t αββ瞬时流变，()f αββτ是后继流变。各项取值如下： 0.4d φ=，()()()0.81/c c f f αβττ=-∞????，()()0.01,0.7310.27t d t e τβτ--??=-+?? ()()0.73 0.73/ 5.27c c f f τττ∞=+，12f f f φφφ=+ f1φ取决于相对湿度(%)λ： ()3210.1110.00020.043 2.57 2.2f φλλλ=-+- (0.6) 2f φ取决于名义厚度0()h mm ： 0.580 0.0442 1.12[1]h f e φ-=+，02c A h u γ = (0.7) 式中：c A 为构件横截面面积（mm 2）；u 为构件截面暴露在空气中的周长（mm ）。 0.11.00.00049e 98 30 98 λλγλ?+≤=?≤? (0.8) γ为湿度系数，当050mm 1600mm h ≤≤时 ()13 f t t t α α ββ??= ?+?? ，0 0.003h 0.80.55e α-=+，00.0043h 770210e β=+ (0.9) (2)收缩错误!未找到引用源。 在时间间隔内发生的混凝土平均收缩应变为： ()()()000,sh sh sh sh t t t t εεββ=-????，sh0sh1sh2εεε= (0.10) 式中：
软件可靠性模型综述(完整资料).doc
【最新整理，下载后即可编辑】 软件可靠性模型综述 可靠性是衡量所有软件系统最重要的特征之一。不可靠的软件会让用户付出更多的时间和金钱, 也会使开发人员名誉扫地。IEEE 把软件可靠性定义为在规定条件下, 在规定时间内, 软件不发生失效的概率。该概率是软件输入和系统输出的函数, 也是软件中存在故障的函数, 输入将确定是否会遇到所存在的故障。 软件可靠性模型，对于软件可靠性的评估起着核心作用，从而对软件质量的保证有着重要的意义。一般说来，一个好的软件可靠性模型可以增加关于开发项目的效率，并对了解软件开发过程提供了一个共同的工作基础，同时也增加了管理的透明度。因此，对于如今发展迅速的软件产业，在开发项目中应用一个好的软件可靠性模型作出必要的预测，花费极少的项目资源产生好的效益，对于企业的发展有一定的意义。 1软件失效过程 1.1软件失效的定义及机理 当软件发生失效时，说明该软件不可靠，发生的失效数越多，发生失效的时间间隔越短，则该软件越不可靠。软件失效的机理如下图所示：
1）软件错误（Software error）：指在开发人员在软件开发过程中出现的失误，疏忽和错误，包括启动错、输入范围错、算法错和边界错等。 2）软件缺陷（Software defect）：指代码中存在能引起软件故障的编码，软件缺陷是静态存在的，只要不修改程序就一直留在程序当中。如不正确的功能需求，遗漏的性能需求等。 3）软件故障（Software fault）：指软件在运行期间发生的一种不可接受的内部状态，是软件缺陷被激活后的动态表现形式。 4）软件失效（Software failure）：指程序的运行偏离了需求，软件执行遇到软件中缺陷可能导致软件的失效。如死机、错误的输出结果、没有在规定的时间内响应等。 从软件可靠性的定义可以知道，软件可靠性是用概率度量的，那么软件失效的发生是一个随机的过程。在使用一个程序时，在其他条件保持一致的前提下，有时候相同的输入数据会得到不同的输出结果。因此，在实际运行软件时，何时遇到程序中的缺陷导致软件失效呈现出随机性和不稳定性。 所有的软件失效都是由于软件中的故障引起的，而软件故障是一种人为的错误，是软件缺陷在不断的测试和使用后才表现出来的，如果这些故障不能得到及时有效的处理，便不可避免的会
软件测试流程方案
软件测试流程方案 Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT
软件测试流程实施方案1.流程的意义 从一个软件企业的长远发展来看，如果要提高产品的质量首先应当从流程抓起，规范软件产品的开发过程。这是一个软件企业从小作坊的生产方式向集成化规范化的大公司迈进的必经之路，也是从根本上解决质量问题，提高工作效率的一个关键手段。 软件产品的开发同其它产品（如汽车）的生产有着共同特性，即需要按一定的过程来进行生产。在工业界，流水线生产方式被证明是一种高效的，且能够比较稳定的保证产品质量的一种方式。通过这种方式，不同的人员被安排在流程的不同位置，最终为着一个目标共同努力，这样可以防止人员工作间的内耗，极大的提供工作效率。并且由于其过程来源于成功的实例，因此其最终的产品质量能够满足过程所设定的范围。软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中，这就形成了软件工程过程，简单的说就是开发流程。 不管我们做哪件事情，都有一个循序渐进的过程，从计划到策略到实现。软件流程就是按照这种思维来定义我们的开发过程，它根据不同的产品特点和以往的成功经验，定义了从需求到最终产品交付的一整套流程。流程告诉我们该怎么一步一步去实现产品，可能会有那些风险，如何去避免风险等等。由于流程来源于成功的经验，因此，按照流程进行开发可以使得我们少走弯路，并有效的提高产品质量，提高用户的满意度。 目前流行的流程方法有很多种，如瀑布模型、螺旋模型、RUP模型、IPD流程等，不同的过程模型适合于不同类型的项目。 2.测试工作流程图 测试工作总体流程图
航天器推进系统基于定性模型的故障诊断方法研究
目录 摘要 (i) Abstract (iii) 第一章绪 论 (1) 1.1 研究背景与内涵 (1) 1.2 航天器推进系统动力学建模与仿真研究进展 (3) 1.2.1 推进系统静动态过程的数值模拟方法 (3) 1.2.2 推进系统模块化建模与仿真 (5) 1.3 航天器推进系统故障诊断方法研究进展 (7) 1.3.1 故障可诊断性分析 (8) 1.3.2 故障诊断方法 (9) 1.3.3 故障诊断方法在航天领域的适用性分析 (20) 1.4 航天器推进系统故障诊断系统的应用研究进展 (21) 1.5 论文的研究内容和结构安排 (24) 第二章航天器推进系统故障模式与可诊断性分析 (26) 2.1 引 言 (26) 2.2 典型推进系统的构成及工作过程 (26) 2.2.1 DFH卫星推进系统构成及工作过程 (26) 2.2.2 SZ推进系统构成及工作过程 (28) 2.3 推进系统故障模式与效应分析 (32) 2.4 推进系统故障可诊断性分析 (36) 2.4.1 故障可诊断性评价方法 (37) 2.4.2 故障可诊断性的度量指标 (39) 2.4.3 推进系统可诊断性实例分析 (40) 2.5 小 结 (46) 第三章航天器推进系统动力学建模与仿真 (47) 3.1 引 言 (47) 3.2 推进系统模块化建模方法 (48) 3.2.1 推进系统的模块化分解 (49) 3.2.2 模块的动力学建模 (51) 3.2.3 系统仿真模型的构建 (52)
3.3 推进系统的模块化建模 (53) 3.3.1 气路子系统模块 (54) 3.3.2液路子系统模块 (58) 3.4 推进系统动力学仿真分析 (62) 3.4.1 推进系统动力学仿真模型及其验证 (62) 3.4.2 推进系统主供应管路的动态特性分析 (64) 3.4.3 推进系统姿控管网的动态特性分析 (67) 3.4.4 推进系统水击的抑制方法 (70) 3.5 推进系统故障仿真分析 (74) 3.5.1 推进系统稳态故障效应分析 (74) 3.5.2 推进系统故障过渡特性分析 (82) 3.6 小 结 (84) 第四章航天器推进系统基于符号有向图的诊断方法研究 (86) 4.1 引 言 (86) 4.2 推进系统的SDG建模 (87) 4.2.1 SDG模型及建模方法 (87) 4.2.2 推进系统的SDG模型 (92) 4.3 航天器推进系统基于SDG模型的诊断实例 (95) 4.3.1 基于SDG模型的诊断策略 (95) 4.3.2 DFH卫星推进系统的诊断结果与分析 (96) 4.3.3 SZ推进系统的诊断结果与分析 (98) 4.4 基于SDG模型的推进系统传感器配置 (101) 4.4.1 基于可检测性的传感器配置 (101) 4.4.2 基于可隔离性的传感器配置 (103) 4.4.3 传感器配置实例与分析 (104) 4.5 小 结 (107) 第五章航天器推进系统定性定量集成的故障诊断方法研究 (109) 5.1 引 言 (109) 5.2 推进系统基于SDG模型的动态故障诊断方法 (109) 5.2.1 系统的SDG动态模型描述 (109) 5.2.2 基于SDG模型的动态诊断算法 (110) 5.2.3 SZ推进系统诊断实例分析 (111) 5.3 集成定量信息的SDG模型动态故障诊断方法 (113) 5.3.1 推进系统定量信息的分析 (113)
功能测试中故障模型的建立
功能测试中故障模型的建立 1. 概述 故障模型是软件测试的基础，也是一个判断测试方法是否成熟的重要标志。在测试的过程中，要确保每一个目标状态都被测试，那么测试必须是系统的;为了最终定位软件缺陷，所以测试必须是集中的;测试需要使用大量的测试用例和重复性测试，因此测试必须是自动的。若要满足上述三个测试条件，我们必须建立故障模型。 故障模型是将测试人员的经验和直觉尽量归纳和固化，使得可以重复使用。领测国际通过理解软件在做什么，来猜测可能出错的地方，并应用故障模型有目的地使它暴露缺陷。它具有一定的形式和足够的信息对错误进行预测，因此对测试人员来说，构造一个准确的故障模型，是选择测试策略、设计测试用例和测试执行的基础。在建立故障模型时，希望故障模型在框架上是通用的，但是建立具体的故障模型时一定要针对具体的软件类型、应用环境、甚至开发工具才有意义。一个成熟的故障模型必须具备下列条件： 1)该模型是符合实际的：大多数系统中存在的故障都可以用该模型来表示; 2)模型下的故障个数是可容忍的：模型下的故障个数一般和系统的规模是成线性关系; 3)模型下的故障是可以测试的：存在一个算法，利用该算法可以检测模型中的每一个故障。 本文将从软件的功能和技术特点出发，如软件的输入、输出、数据以及处理等，分析在软件功能测试过程中，我们通常应建立的故障模型及按照故障模型所提供的缺陷类型寻找尽量多的缺陷。
2. 输入型故障模型 主要是对用户的各种输入进行建模，因为用户的输入是无法预期的，可能的组合状态也是千变万化。软件功能除了能让正确的输入得到正确的输出之外，还必须对非法和不合逻辑的输入进行处理，防止因数据异常造成不可挽回的错误。典型的建模方法有： 1)使用非法数据：从输入数据的类型、长度、边界值等方面考虑，测试软件是否允许不正确的输入进入系统并进行处理，是否有错误处理代码，代码是否正确。 2)使用默认值输入：检测软件中所使用的变量是否初始化，是否将非法数据默认为合法边界内的某个合理值。 3)使用特殊字：检测软件是否正确处理了特殊字符和数据类型。 4)使用使缓冲区溢出的合法输入：输入超过允许的最大长度的数据，检测软件是否检查字符串/缓冲区的边界。 5)使用可能产生错误的合法输入组合：测试多个输入值的组合，确认这些值的组合是否会互相影响而引起软件失效。 6)重复输入相同的合法输入序列：检测软件是否考虑了循环处理的边界。 3. 输出型故障模型 软件的输出通常是最直观也是用户最关注的，输出型故障模型就是从软件输出角度出发，分析造成故障的可能原因。例如通过一个正确的输入在不同情况下产生不同输出的情况可以对输入和输出的关系进行进一步验证;可采用列举等方法，强制软件产生不符合业务背景知识的无效的输出，从而进行处理，规避不必要的错误;强制修改输出的属性、