小议软件测试用例的设计的论文

下面是小编为大家带来的小议软件测试用例的设计的论文，本文共9篇，希望大家能够喜欢!本文原稿由网友“BMW325520”提供。

篇1：小议软件测试用例的设计论文

小议软件测试用例的设计论文

白盒测试技术中测试用例的设计方法研究

白盒测试方法的主要作用有：

（1）至少测试一次程序子模块的所有独立执行路径；

（2）针对所有可能的逻辑判定，至少一次取“真”或“假”两种情况；（3）在运行界限内和循环边界处执行循环体；

（4）测试程序内部的数据结构的有效性。在实际的数据测试中，如果程序具有多种循环嵌套的情况，不同的执行路径数目可能是天文数字，例如一个有5条路径的嵌套20次循环的小程序，包含不同执行路径条数为520次方，如果每一条路径测试1ms，全年无休时要测试完所有路径需要约3170年的时间。因此，我们必须采用一些替代办法，典型的方法是有选择的执行程序中某些最有代表性的通路。白盒测试的主要技术有：

1根据程序内部的逻辑结构设计测试用例的技术—逻辑覆盖

（1）语句覆盖，选择足够多的测试数据以使被测程序中每条语句都至少执行一次。语句覆盖不考虑对程序的逻辑覆盖，它主要关心表达式的结果，却对每个条件取不同值的情况不做测试。因此，语句覆盖是比较弱的逻辑覆盖标准。在图论中和语句覆盖对应的是点覆盖。

（2）判定覆盖，又叫分支覆盖，它首先满足语句覆盖的条件，同时对每个判定的每种可能的'结果都至少执行一次，即对每个分支都至少执行一次每个判定，判定覆盖对程序的逻辑覆盖程度也不高。在图论中和判定覆盖相对应的是边覆盖。

（3）条件覆盖，指的是不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果，条件覆盖中可能不包含判定覆盖。

（4）判定/条件覆盖，指选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，每个判定表达式也取到各种可能的结果。

（5）条件组合覆盖，要求选择足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。条件组合覆盖是逻辑覆盖标准中最强的。

（6）路径覆盖，指的是选取足够多的测试数据，使程序的每条可能路径都至少执行一次。测试用例设计举例1：如下图1所示程序段流程，实现语句覆盖需要设计的测试数据有：X=0，Y=3和X=-1，Y=2；实现条件覆盖至少采用的测试数据有：X=0，Y=3和X=3，Y=1；实现判定覆盖至少应用的测试数据有X=0，Y=3，X=1，Y=2和X=-1，Y=2。

2测试程序的控制结构，主要包括条件测试，循环测试和基本路径测试。

其中基本路径测试是由TomMcCabe提出的一种白盒测试技术，这种技术在设计测试用例时需要首先计算程序的环形复杂度，并用该复杂度为指南定义执行路径的基本集合。在实际测试中，仅靠基本路径测试还不能满足要求，还需要结合条件测试技术来检查程序模块中包含的逻辑条件，还有循环测试来专门测试循环结构的有效性。

黑盒测试技术中的测试用例设计方法研究

黑盒测试主要用来测试软件的功能特点，通过黑盒测试可以发现：（1）是否有遗漏了的功能或者不正确的功能；（2）能否有正确的接收输入和正确的输出结果，这主要针对接口而言；（3）是否有外部信息访问错误或数据结构错误，同时，软件运行时能否满足性能上的要求；（4）软件在初始化或者退出时有无错误等；使用黑盒测试同样不可能将所有可能的输入条件和输出条件用于测试，因为测试用例的组合是天文数字。例如一个程序有两个输入量和一个输出量，在32位计算机上运行，若X，Y取整数，按穷举测试时需要232×232=264组，如果一组数据需要1ms，全年无休，需要5亿年的时间。显然，我们必须设计合理的方案来减少测试用例的数量。目前黑盒测试的主要测试用例设计技术有：

1等价类划分

等价类划分是把程序的输入域划分成若干个数据类，据此导出测试用例，因为对于同一类中的数据而言其作用是相同的[3]。等价类划分可以分为有效等价类和无效等价类。有效等价类是指符合程序功能要求的数据类，该类中包含的都是有意义的数据；而无效等价类指不能满足程序正确运行或者预期结果的数据类的集合。我们在设计测试用例时，要同时考虑有效等价类和无效等价类的设计方案。等价类的划分有自己的原则。在具体使用等价类划分设计测试用例时有两个步骤：（1）设计一个新的测试方案以尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤直到所有有效等价类都被覆盖为止；（2）设计一个新的测试方案，使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止。

2边界值分析

使用边界值分析方法来设计测试用例时需要开发者具有一定的经验和创造性，通常根据划分的输入等价类和输出等价类的边界来确定边界值的结果，即选取刚刚等于、刚刚小于和刚刚大于边界值的测试数据，而不是选择等价类内部的数据作为测试用例。

3错误推测法

错误推测法主要依靠直觉和经验，需要有一定开发大型软件工程的经验，其基本思想是通过列举出程序中可能有的错误和容易发生错误的特殊情况，并根据这些情况来选择测试方案。

小结

测试用例的设计方法并不是独立使用的，而是经常会进行一些不同设计方案的组合，如黑盒测试中的等价类划分和边界分析方法可以结合使用，进步设计更加合理的测试用例，找出更多的软件运行错误。

篇2：软件测试用例设计编写技巧

软件测试用例设计编写技巧

一、问题

许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验(或习惯)，希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。

当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：

从此几乎很少被执行

执行用例发现的bug很少

根本没有时间为新的功能需求增补用例

有时间补充，但用例结构越来越乱

特性的用例与通性用例之间联系不明确(以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化)

知道怎样执行这个用例，但它要说明什么呢?(多数用例给我们的感觉是只见树木，不见森林，只对某一功能，无法串起)

通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益 处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。

但没有用例或简略用例的编写我们又会舒服很多么?不言自明，谁也不想倒退发展吧。

二、原因

事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：

1、没有适合的规范

“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义，但它适合我们当前的项目么?

每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好?

在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范?于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往\"的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。

我们有太多经验，但却没有形成适合的规范。

2、功能与业务的分离

我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。

边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。

复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中(点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体)。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。

用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。

3、测试未能跟上变化

想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢?当地区特性，软件版本越来越多的时候，测试是否在积极响应呢?变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。

疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法很快发现。

永远是变化决定我们的下一步工作，这也是混乱的开始。

三、可能解决的办法

在这里我希望以探讨的方式提出一些可能的解决办法，因为上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。不用拘泥形式，最适合的就是最好的。

1、测试驱动开发，用例指导结果，数据记录变化

“测试驱动开发”(TDD)是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效(Work)更洁净(Clean)，“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。

首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80%以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。

如何在黑盒测试中做到测试驱动开发?我认为可以从用例级别做起，以业务用例指导过程和结果。

开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很明确的指出应该实现怎样的结果，这使得从业务到功能出现一个“阅读上的障碍”，如果最后程序错误了还需返工，这样耗费的人力物力就非常大了。使用业务用例驱动开发，就是一个比较好的方法，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。

业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。

这就是测试主导变化的另一点“数据记录变化”。

我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段(业务段与程序中以窗体或页面的划分是不一样的)，使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。

再进一步的话“数据库”就开始涉及到程序内部的接口了，这需要开发人员的配合。

为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。

为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。

2、功能用例与业务用例分开组织

将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作(例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理?)。

3、审核用例，结对编写

测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例(前提是你有两个以上的测试人员)，内部审核。

测试用例不是一个人编写一个人执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理，提高组员的参与积极性。

四、发展

上面的这些解决方法只是一种建议，具体怎样实施到项目中还需根据情况而定。可以看到测试的发展方向是很多很广的，传统的黑盒测试并不是毫无新意，测试工作怎样适合我们而发展，将给予我们更多的思考。

篇3：浅析GUI软件的测试用例优化算法的论文

浅析GUI软件的测试用例优化算法的论文

随着计算机产业应用范围的进一步拓展，计算机数据应用技术也进一步实现了深入研究，GUI软件技术是现代网络技术应用的重要技术之一，它的应用实现了计算机数据挖掘与数据图像转换之间的完美融合。为了保障GUI软件技术能够在实际应用中发挥实际作用，积极开展GUI软件技术测试，用例优化算法的探究能够提高GUI软件技术应用程序的功能性完整，提高GUI软件技术在实际应用中的作用，促进我国计算机技术的创新探究。

1 GUI软件技术进行用例优化算法探究的理论构建

GUI软件技术的实施用例优化算法进行系统测试，是对数据结构的实际应用完整度，输入不同数据后，数据结构和数据应用中结构反馈准确性的进一步检验，使GUI软件技术的应用能够准确的反馈出用户的数据运行需求，并且GUI软件技术具有智能数据存储功能，能够依据用户的程序执行习惯，形成执行逻辑，符合用户的用户系统的操作习惯。本文针对GUI软件技术的检测理论分析主要从空间构建理论、计算机域概念与类概念、数据动态处理理论几方面对测试的实施提供理论分析。

1.1 空间构建理论。第一，空间构建理论。GUI软件技术进行优化算法执行过程中，应用的数据结构不是直接从计算机数据库中直接挖掘出来的，而是结合在GUI软件技术测试中进行数据管理应用的进一步划分，为GUI软件技术的检测提供明确的数据应用范围，从而进一步将数据结构进行系统的划分整理，保障GUI软件技术检测的数据应用的准确性。例如：GUI软件技术在进行算法检测前期，需要设定算法检测的最大值和最小值，计算机依据用户输入的数域的范围，智能的进行GUI软件技术的执行空间筛选，为系统测试提供最佳检测环境。计算机程序空间构建理论在GUI软件技术测试中的应用，能够提高检测的应用的准确率，充分发挥GUI软件技术用例优化算法检测的作用。

1.2 域与类。第二，域与类理论。GUI软件实施用例优化算法进行测试中，主要是通过算法中数据变化反馈GUI 软件技术的实际运行情况，为了进一步提高GUI软件算法检测的准确性，增强数据检测的准确性。GUI软件需要应用数据的数字域和数字的类，进行科学划分。域是针对数据系统检测程序的判断应用。通常情况下，域可以作为系统内部划定软件检测数据应用空间性的依据，也可以作为程序执行中内部数据执行步骤管理的主要依据。例如：为了保障GUI软件测试的顺利实施，程序管理人员分别应用域对程序执行中的每一个步骤设定的域值;类进行数据控制的范围是输入数据的形态，检测范围，反映属性的相关信息控制，实现了数据资源应用管理的全方位、精准化分析，为我国计算机产业的进一步完善准确的数据检测反馈。

1.3 动态理论。第三，数据动态处理理论，计算机以理论的应用是从物体运动变化状态的基本理论发展而来的，数据动态判断在GUI软件技术检测中的应用与GUI状态判断结合在一起，对GUI软件技术执行算法后的数据结构进行推断，得出判断结果，从而对GUI 软件的实际执行情况做出判断。例如：GUI软件检测中输入的数据为I={0,1，2,}，其中1为系统背景颜色属性正常，2为画面清晰度正常，0为系统存在故障，执行情况较差。通过GUI软件系统执行算法反馈的数据变化结果，判断GUI软件的运行情况，实现了GUI软件用例优化算法测试的实际意义。

2 GUI 软件技术进行用例优化算法实践探究

GUI 软件技术进行用例优化算法实践表示图为图1，从图中可知，GUI 软件技术的实际执行情况主要分为三部分，同时又每一部分的基础上进行不同层次的精细划分，最终形成划分GUI 软件技术算法测试的划分结构，本文结合图1 中相关换分结构，将这三大部分按照GUI 软件技术的执行顺序进行操作步骤讲解。

2.1 GUI 软件技术构建匀数据运算空间

首先，GUI 软件技术应用数据结构构运算执行空间。GUI 软件技术的检测是在在计算机数据模拟的虚拟空间中实施的，为了将GUI 软件技术广泛的应用在计算机程序监测管理中，应用计算机虚拟模型，确定软件检测的数据应用范围，确定GUI 软件技术的检测空间。例如：某次GUI 软件技术是的主要目的是对计算机数据管理程序进行检测，系统内部应用数据挖掘的程序信息，设定程序运算空间，为GUI 软件技术的'检测划定了明确的检测范围，从而提高了GUI 软件技术的算法运行的准确性。

2.2 输入检测数据

其次，输入检测数据，检测数据通常为一系列的检测系统数据，为了保障GUI 软件技术的系统测试能够顺利进行，计算机对运算数据的划分通常采用初次输入数据划分和二次数据划分两部分，初次数据划分将从计算机大数据库中随意划分的检测检测数据进行初步筛选，对原始数据中结构不完善，数据不够清晰的进行进一步完善;二次数据监测是在初次数据筛选的基础上开展数据层次性排列，从而使程序管理人员可以通过数据值的变化趋向判断GUI 软件技术实际应用作用。

2.3 构建数据判断流程

其三，针对GUI 软件技术在网络空间构建的数据应用模型，将不同层次的数据结构进行划分，并实现了管理管理结构和管理形式的进一步完善。GUI 软件中数据输入后，依据层次性数据结构的进一步判断，实现输入数据程序执行情况的判定。例如：UI软件检测中输入的数据为I={0,1，2,}，其中1 为系统背景颜色属性正常，2 为画面清晰度正常，0 为系统存在故障，而本次数据程序运算的输出结果为2，那么，从2 数字下的子系统继续执行程序P={1,2,3}，将画面的清晰程度依旧实现层次性划分，最终将子程序和主程序的数据进行综合判断，得出GUI 软件算法结构判断图。一方面，系统直接将构成的数据判断结构图的结果反馈给程序人员，形成数图结合结构;另一方面将返回检测结果进行GUI 软件技术实际应用效果系统智能存储，进行系统存储，形成电子数据，以便于系统数据的进一步深入管理。

3结论

GUI 软件技术是现代计算机程序执行中的一种新型数据资源管理手段，对GUI 软件技术的用例优化算法检测能够提高GUI软件技术在实际应用中的准确性和检测结构的科学性，实现计算机数据网络应用技术的进一步创新发展，促进我国网络应用体系的创新发展。

篇4：基于SFTA和等价类的软件测试用例设计方法研究与应用

基于SFTA和等价类的软件测试用例设计方法研究与应用

摘 要： 为了解决软件测试时高可靠性安全性要求，测试用例设计的充分性和有效性不足的问题，软件故障树分析结合等价类原则解决了测试用例设计的充分性和有效性问题。通过对软件的故障模式进行分析，在建立软件故障树的基础上获得了软件故障树的最小割集。以最小割集为模型，结合等价类划分方法实现了测试用例设计，并根据该方法开发了测试用例自动生成工具。通过测试项目实际应用表明，采用该方法进行测试用例设计可以满足测试的充分性和有效性要求。 关键词： 软件测试； 测试用例； 故障树； 等价类 中图分类号： TN06?34； TP311.5 文献标识码： A 文章编号： 1004?373X21?0128?04 0 引 言 随着计算机科学技术的不断发展，软件在各个行业中发挥着越来越重要的作用，在许多领域中软件实现的功能已达到整个系统功能的80%。因此，软件系统的质量往往决定着系统的质量，有时由软件缺陷引发的故障造成的后果会非常严重。例如文献[1]中20世纪80年代美国发生的放射治疗机软件错误，导致五名患者受到超计量辐射死亡的严重事故。随着软件应用的深入和广泛，特别是，应用于高铁、银行、医疗、军事和航天航空领域的软件，其软件的质量更加需要关注，如果这些系统中发生由软件缺陷引发的事故，其后果将是无法预料的。 目前，软件测试仍是保证软件质量的重要手段之一，而软件测试最关键的环节之一就是测试用例设计，测试用例设计的充分性决定着测试的有效性。采用何种测试用例设计方法满足测试的有效性和充分性要求是软件测试领域不断深入探索研究的课题。 软件故障树分析[2]（SFTA）是一种自顶向下的软件可靠性和安全性分析方法，即从软件系统不希望发生的事件（顶事件），特别是对人员和设备的安全产生重大影响的事件开始，向下逐步追查导致顶事件发生的原因，直至基本事件（底事件）。利用SFTA分析的结果可以确定软件测试的重点和内容。 等价类划分方法是一种黑盒测试方法[3]，它将软件的输入划分为若干个数据类，从中得到测试用例的输入。等价类划分的测试用例设计是基于对输入条件的等价类进行评估，是软件黑盒测试中最常采用的方法之一。 本文将SFTA和等价类划分方法相结合提出了一种有效的测试用例设计方法，并实现了测试用例的自动生成。 1 软件故障树及最小割集 SFTA技术是应用较为广泛的软件安全性分析方法，将此方法用于软件测试时，主要应用于软件黑盒测试的测试用例设计。对于那些高可靠安全要求的软件应在进行安全性分析的基础上，进行测试用例的设计以便实现测试用例的有效覆盖。 1.1 建立软件故障树 软件故障树的建立是软件故障树分析中最基本同时也是最关键的一项工作。软件故障树简单地说是由一些逻辑和事件符号构建而成的。由于软件故障树的准确性直接影响到对软件的分析，因此，在建立软件故障树时需要开展必要的准备工作。软件故障树的建立通常包括：收集并分析有关技术资料，选择要分析的顶事件和构建故障树。 1.1.1 收集并分析有关技术资料 软件故障树建立的完善程度直接影响基于最小割集的测试用例集合的有效性，因而需要软件故障树的建立者广泛地掌握并使用有关方面的知识和经验。这些知识和经验获取主要依靠对相关资料的学习和对软件的熟悉，需要掌握的内容主要应包括：软件系统的体系结构设计、软件的功能、系统的范围、软件之间的接口关系和运行环境等；识别人为因素对软件系统的影响；识别软件在不同的运行模式下的状态，以及不同模式之间的相互转换关系。 另外，在建立故障树时应征求有经验的设计人员、用户等的意见，以便保证软件故障树的.正确性。 对于软件关键等级较高的软件，一般情况下，软件研制人员已完成了软件安全性分析。测试人员可以在此基础上开展进一步的分析。 1.1.2 选择要分析的顶事件 利用故障树进行软件分析常遇到的问题就是构建的故障树过于复杂，很难利用其进行有效的测试用例设计。为了避免这一难题，在构建故障树时可以将软件故障树分层构建，先按照软件单个功能项为单位进行构建，在逐渐延伸至顶事件。 这种顶事件确定方法也符合确认测试对所有功能进行测试的实际要求。顶事件的确定可以与确认测试的测试项的确定一起完成。当一个测试项有多个子测试项时，可以将子测试项做为顶事件。 采用这种方法不仅避免了软件故障树过于复杂的问题，也更符合测试工作的需要与流程。将软件故障树分析与测试项的分解、测试用例的设计紧密结合，更有利于测试用例的自动生成。 1.1.3 构建故障树 软件故障树中使用的符号包括事件符号和逻辑门符号两类。事件符号用以表示故障事件，逻辑门符号用以表示故障事件之间的逻辑关系。 建立软件故障树通常采用演绎法。所谓演绎法是指首先选择要分析的顶事件（即不希望发生的故障事件）作为故障树的“根”。然后分析导致顶事件发生的直接原因（包括所有事件或条件），并用适当的逻辑门与顶事件相连，作为故障树的“节”（中间事件）。按照这个方法逐步深入，一直追溯到导致顶事件发生的全部原因（底层的基本事件）为止。这些底层的基本事件称为底事件，构成故障树的“叶”。 在故障树最底层的底事件是导致顶事件发生的根本原因。有些底事件可以独立地引发顶事件，有些底事件按照一定的逻辑关系共同引发顶事件。在分析故障发生原因过程中，要充分发挥分析者、软件开发组以及软件测试机构的经验。 1.2 故障树的数学描述 有[n]个底事件构成的故障树，故障树的顶事件为[T，][xi]是底事件的状态变量，[xi]的值为1或0，[Φ]表示顶事件的状态，则有如下定义： [xi=1，底事件i发生0，底事件i不发生] [Φ=1，顶事件发生0，顶事件不发生] 由于[Φ]由底事件的状态确定，即[Φ=Φ（X），]其中[X={x1，x2，…，xi}。]因此，[Φ=Φ（X）]就是故障树数学表述的结构函数[4]。 对于顶事件和底事件之间全部为逻辑与门结构的故障树，结构函数可以表述为： [Φx=i=1nxii=1，2，…，n] 对于顶事件和底事件之间全部为逻辑或门结构的故障树，结构函数可以表述为： [Φx=i=1nxii=1，2，…，n] 根据上述定义就可以表示出任意一棵故障树的结构函数。图1所示的软件故障树的结构函数就可以表示为： [Φ=x1x2x3x1x3x4] 1.3 最小割集的数学描述 割集为能引起顶事件发生的底事件集合。最小割集为不包含任何冗余因素的割集。如果去掉最小割集中的任何事件，它就不再成为割集。 根据上述的定义，在软件故障树中，由于最小割集发生时，顶事件必然发生，因此，一棵故障树的全部最小割集的完整集合代表了顶事件发生的所有可能性。因此，若软件故障树有[m]个最小割集[C=（C1，C2，…，Cm），]任意一个最小割集中的全部底事件发生时，故障树的顶事件必定发生，最小割集可以表示为： [Cj=i=1xi] 在[m]个最小割集集合中只要有一个最小割集发生，顶事件就发生，所以软件故障树可以表示为： [Φ=j=1mi=1nxi] 根据故障树最小割集的定义，利用Fuseell?Vesely算法，可以获得图1的最小割集为：[x1，][x2，x3，x4，]其软件故障树也可表示为： [Φ=x1x2x3x4] 根据上述表达式，图1的等价软件故障树如图2所示。 2 生成测试用例集 利用软件故障树最小割集建立了进行测试用例设计模型，每个底事件就是测试用例的输入，而每个输入的取值应根据等价类划分的原则设置典型值。 2.1 确定输入条件的等价类 在进行输入的典型值选取时，应根据等价类划分的方法进行确定。等价类的确定应遵循如下原则[3]： （1）若输入条件指定一个范围，则可以定义一个有效等价类和两个无效等价类； （2）若输入条件需要特定的值，则可以定义一个有效等价类和两个无效等价类； （3）若输入条件指定集合的某个元素，则可以定义一个有效等价类和一个无效等价类； （4）若输入条件为布尔值，则可以定义一个有效等价类和一个无效等价类。 以最小割集[{x2，x3，x4}]为例，其典型取值分别为下[x2：a1，a2，a3；x3：b1，b2，b3；x4：c1，c2。] 2.2 生成测试用例集 在进行测试用例设计时，以每一个最小割集为一组测试用例。以最小割集[{x2，x3，x4}]为例，根据在2.1节中确定的[x2，x3，x4]各自的等价类取值，可得到测试用例为：[{a1，b1，c1}，][{a1，b1，c2}，][{a1，b2，c1}，][{a1，b2，c2}，][{a1，b3，c1}，][{a1，b3，c2}，][{a2，b1，c1}，][{a2，b1，c2}，][{a2，b2，c1}，][{a2，b2，c2}，][{a2，b3，c1}，][{a2，b3，c2}，][{a3，b1，c1}，][{a3，b1，c2}，][{a3，b2，c1}，][{a3，b2，c2}，][{a3，b3，c1}，][{a3，b3，c2}。]这样就得到[C13×C13×C12=3×3×2=18]个测试用例。 软件的算法流程图如图3所示。 3 应用实例 （1）获取软件故障树 在实际应用中获得了如图4所示的软件故障树，其中中间事件“游机未关机”的发生是由Ggjx1，Ggjx2，Ggjx3中的任意两个以上发生时导致的。根据这种情况，可将图4改造为如图5所示的等效故障树。 （2）求出割集 {T2fc1，T2fc2，T2fc3}，{Ggjx1，Ggjx2}，{Ggjx1，Ggjx3}，{Ggjx2，Ggjx3}，{Luwo}，{Ggjx1，Ggjx2，Ggjx3}，{Luwo，T2fc1 }，{Luwo，T2fc2}，{Luwo，T2fc3}。 （3）求出最小割集 {Ggjx1，Ggjx2}，{Ggjx1，Ggjx3}，{Ggjx2，Ggjx3}，{Luwo}，{T2fc1，T2fc2，T2fc3}。 （4）设置典型值 根据输入条件的等价类原则设置的典型值见表1。 （5）生成测试用例 基于割集生成的测试用例有63个，而基于最小割集生成的测试用例只有25个。基于最小割集{T2fc1，T2fc2，T2fc3}生成的一个测试用例集合如图6所示。 4 结 语 本文利用故障树的原理和方法，将故障树的最小割集作为生成测试用例的模型，测试用例的输入采用等价类划分的方法选取，提出了基于故障树最小割集和等价类划分的测试用例生成方法，并开发了测试用例自动生成工具。该方法在逃逸软件测试项目中得到了应用，实际结果表明它有效地提高了测试测试用例设计的充分性和高可靠软件测试的自动化程度。 参考文献 [1] 黄锡滋.软件可靠性、安全性与质量保证[M].北京：电子工业出版社，. [2] 陆廷孝，郑鹏洲，何国伟，等.可靠性设计与分析[M].北京：国防工业出版社，1995. [3] PRESSMAN R S. Software engineering： a practitioner′s approach [M]. 7th ed. [S.l.]. McGraw?Hill Companies，Inc， . [4] 孙志安，裴晓黎，宋昕，等.软件可靠性工程[M].北京：北京航空航天大学出版社，2009. [5] 练峰海，石启亮，陈方涛.基于GUI方法的故障树运算软件实现[J].现代电子技术，，35（18）：83?85. [6] 姜兴杰，杨峰辉.软件可靠性分析与设计[J].现代电子技术，，34（7）：135?137.

篇5：基于分词搜索的测试用例复用研究论文

摘 要随着软件行业快速发展，软件功能的复杂程度随之提高，软件质量逐渐受到重视。在软件的整个生命周期中，软件测试是一个非常重要的环节。软件质量在很大程度上由软件测试的完整程度所决定。然而，随着软件复杂度的提高，软件测试的工作成本在不断增加。为了减少测试中的冗余现象，提高软件测试的效率，测试用例复用技术被应用于各个软件测试环节。本文建立了一套测试用例管理系统，通过统一存储并管理测试用例，提出将分词技术应用于测试用例复用查询，提高测试用例查询结果的有效性和可复用性。

关键词软件测试，测试用例，复用，分词

0 引言

软件测试是在规定的条件下对程序进行操作，以发现程序错误，由此来衡量软件质量，并对其是否能满足设计要求进行评估的过程。作为软件生命周期中的重要环节，其成败直接决定着软件的最终质量。软件测试工作不仅保证了软件质量，而且降低了日后维护成本。随着我国软件产业的蓬勃发展以及对软件质量的重视，软件测试也逐渐受到软件企业的关注，正逐步成为一个新兴的产业。测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于测试某个程序路径或核实是否满足某个特定需求。

随着软件规模越来越庞大，软件测试的工作量也与日俱增。软件测试过程中，测试用例的设计是软件测试过程的核心，直接影响了软件测试的效率。测试设计的好快直接决定着测试结果及其成效，测试用例是最有可能发现软件错误的测试数据和流程的集合。测试用例复用是将已执行过的测试用例重复使用或改进使用于不同的软件或软件测试阶段中，以此来降低测试用例设计环节的工作成本。为了提高软件测试的效率，测试用例复用技术被广泛地应用于各类软件测试的设计和回归测试阶段，用于减少测试设计阶段的成本，以缩短测试周期，提高测试效率。本文通过对可复用测试用例的收集以及分析，提出了一种以行业领域和基于分词搜索策略的测试用例复用思路，以提高测试用例的复用率。但是当测试用例管理系统中的测试用例数量过于庞大时，则不利于测试用例的筛选，因此有必要设计了推荐算法来按照一定规则对可能被复用的测试用例进行排序推荐。

篇6：基于分词搜索的测试用例复用研究论文

1.1 测试用例复用的概念

测试用例复用是指测试工程师在执行一项新的测试工作时，通过直接调用或修改现有的、合适的测试用例，并将其应用在测试执行中的过程。如果搜索后得到的测试用例与需求完全一致，则直接复用现有测试用例，但是一般情况下，直接复用测试用例的情况很少；如果搜索到的测试用例与需求近似，则对其进行修改，得到新的测试用例之后再复用。在一定程度上，测试用例复用可以节省重新设计测试用例的时间，减少测试工程师的工作量，提高软件测试的效率。

然而，并非所有的测试用例都适合复用，有些测试用例定制化程度较高，只适合某些特定的测试场景，这样的测试用例可复用程度不高。由此可知，测试用例要能进行复用，须具备一定的可复用特性。

1.2 可复用测试用例特性

经过对大量可复用测试用例的收集以及分析，本文认为可复用测试用例需满足以下5个特性：标准化、通用性、有效性、独立性、小粒度1]。

1) 标准化。测试用例通常用自然语言进行描述，但由于自然语言的非结构化特性，无统一结构的测试用例不利于测试用例复用。因此，测试用例的设计必须使用统一的格式或结构，以消除由于自然语言的表述的差异带来的问题。标准化不仅强调测试用例的可复用能力，更偏向于测试用例管理。采用明确无歧义的语言描述测试用例并用统一结构进行存储，如表1测试用例描述案例所示2]。其中，加粗字体表示测试用例的字段，中括号 ]里的内容表示测试用例的具体内容或相关属性。

2) 有效性：测试用例的目标是发现软件中的问题或者验证功能是否正确，因此测试用例必须是针对它的测试目的而设计，并且经审核后必须是正确、完整、适用于被测对象并且是可执行的。

3) 通用性：测试用例不局限于具体的应用，不过分依赖于被测软件的需求、设计、环境、其他功能以及其他业务流程，可复用测试用例可多次适用于不同版本的软件测试或广泛应用于某同类软件或类似功能模块的测试。

4) 独立性：测试用例不过分受制于测试环境、相关业务流程以及前置测试用例。理论上，测试用例与其他因素的耦合度越小，则独立性也就越高，其测试用例的可复用程度相对较高。

5) 小粒度：通常指一个被测模块的末梢功能，测试用例的粒度设计追求功能的不可分割性。粒度越小并且相对独立的功能，针对其功能设计的用例，可复用性也就越高。

以登录功能举例，该功能相对于整个应用系统来说粒度最小，并且与其他功能相对独立，同时，针对登录功能设计的测试用例具有较强的通用性，所以通常情况下，登录功能的测试用例具有较高的可复用性。

1.3 测试用例复用场景

然而，并非所有的软件测试过程都适合进行测试用例复用。测试用例复用是为了避免测试用例的重复设计，提供现有的测试用例给测试工程师直接使用。因此，只有在需要重复执行的测试用例时，测试用例的复用才能真正发挥作用。通常情况下，测试用例复用主要由三类测试场景3]：

1) 软件升级：包括版本升级、缺陷修复等升级行为。例如：一家公司的业务管理系统的升级，或某个功能的改进。通常不会引起非常大的业务流程变动或界面改动，因此前一个版本的测试用例可被大量复用。

2) 产品测试：此类场景多存在于软件研发公司，多从事于某个领域的软件研发工作，通常此类公司有着自己的测试用例库。比如：从事ERP（企业资源计划）软件开发的公司。虽然不同行业的业务流程都不完全一致，但也有存类似的可复用业务流程，例如员工管理模块等。

3) 第三方测评4]：第三方测评机构适用于此类测试用例复用场景。由于第三方测试机构会对大量的软件进行测评，其中不乏相同领域的软件产品。如果对每个测试软件重新设计测试用例，必然增加工作成本。因此，对于第三方测评机构测试用例复用是十分有必要的。测试用例复用在不同领域和场景中有着广泛应用，对于大量测试用例的复用需要建立在大量测试用例基础上，需要将以往设计的测试用例加以存储和管理，因此设计一套测试用例管理系统是测试用例复用成为可能的先决必要条件。

2 测试用例复用库模型设计与实现

测试用例复用就是对已经执行的测试用例进行重复使用或修改使用。要实现测试用例复用，则需要对以往设计的测试用例进行有效的存储以及分类管理以供后续使用。对测试用例的管理就需要创建一个测试用例复用库来存储测试用例，在测试用例复用库中使用统一的规范数据格式对测试用例进行管理。当测试工程师要设计测试用例时，可先在测试用例库中进行搜索，查找合适的测试用例进行复用。但是，随着时间的增长以及测试项目的增加，测试用例库也随之扩充，测试用例数目与日俱增，这就增加了搜索的工作量。为了提高搜索的效率，根据测试用例适用的行业领域，对测试用例进行划分存储，并打上行业领域的标记。其原因在于，相同行业领域的软件其测试用例的通用性更高，可复用性也更高。

为了提高在测试用例库中的搜索效率和准确度，将分词技术应用于测试用例搜索功能中，对用户的搜索输入进行分词、筛选，得出有效的搜索关键字，根据关键字在测试用例复用库中进行搜索，减少了非关键字的干扰，提高了查询速度，并且搜索结果更准确。

通常情况下，测试用例复用分为直接使用以及修改使用，但无论何种情况，都需要对新测试用例进行审核，确定其有效性和唯一性方能进入测试用例复用库，测试用例复用模型如图1所示。

3 测试用例复用搜索设计与实现

3.1 分词词库

测试工程师进行测试用例复用时，需要对查询输入进行处理，常用方法是使用分词技术提取其中的关键字进行查询。分词技术中，英文单词之间以空格作为自然分界符，而中文是以字为基本的书写单位，词与词之间没有明显的区分标记，因此，对中文信息处理相对比较复杂。语义分析是中文信息处理的基础与关键，常见的.分词算法有两种：

算法1：建立词库，对待分析字符串逐词匹配，分离关键字；

算法2：建立词库，对目标串构造全文索引，然后将结果集与词库进行笛卡尔积匹配，获取匹配结果。

以上算法如果用于较大规模词库时，存在如下效率问题：

1) 当词库较大时，逐词匹配耗时较长；

2) 采用全文索引方式消耗多余内容，同时不适用于测试用例复用查询功能，因为用户输入的查询信息较短，而全文索引多适用于长文本字符串搜索功能。

在测试用例复用查询功能中，用户查询输入相对简单，但需要进行精确分词，因此针对此类特点，本文对文献5]中提出的索引方法加以改进，采用二级索引对中文词条进行分词（这里只讨论中文分词，英文分词可使用Lucene工具进行分词），以确保能快速并精确地进行分词。由于长度为2的中文词条占整个汉字词条约70%5]以上，同时假设汉字词长度2、3、4的词条个数比例为7：2：1，因此，大约90%的情况下，执行两次检索便能定位一个汉字词条，以保证较高的分词效率。同时为减少磁盘I/O，在系统启动时，将词库载入至内存，使所有计算可在内存中进行，进一步提高分词效率。根据《中国大百科全书》目前收录约6 000万个词条为例，整个中文词库大约适用300MB～400MB内存，因此，常见的主机可满足其硬件需求。

3.2 搜索算法

随着软件测试项目的日益增加，测试用例复用库不断扩充，这势必会影响到搜索的效率。本文中，当接收到用户的查询输入，程序首先将其与分词词库进行匹配，对查询输入进行分词，然后根据被测软件的行业领域，查询对应领域的测试用例数据，并且根据排序算法对查询结果进行排序。由于该分词算法仅用于测试用例查询，因此对于中文分词算法中歧义词的处理可以忽略不计，其伪代码如下所示：

由于词库在初建之时，未必能覆盖所有中文词条，并且随着各个行业的高速发展，每天都可能会有新词条出现，因此必然存在无法匹配的词条。当出现新词时，分词算法将自动定位到下一个可匹配词条，然后继续进行拆分，而新词则被单独作为一个分词加载至分词结果中。同时存储该用户输入，待管理员进行审核，人工加入到词库中。采用人工添加新词而非程序自动添加新词的原因在于，程序还不够智能，也无意义做到足够智能，同时对于新词的理解或判断的正确率远低于人判断的正确率。

3.3 结果排序

针对测试工程师进行测试用例的复用查询，其查询结果可能是几条，也可能是几十条，甚至是几万条数据，然而并非所有查询到的测试用例都是查询者所需要的，当查询结果数量庞大时，逐条查看筛选所消耗的时间可能早已超过了重新设计一个测试用例所需的时间，必然导致时间成本上的浪费，这与测试用例复用的初衷相违背。由此可见，根据查询到的测试用例与用户所需测试用例的相关性，为用户推荐一个“好”的测试用例是十分必要的。

可复用测试用例的查询结果的排序可以为用户提供选择测试用例的依据，针对查询主要针对教育期刊网

关键词 的搜索，因此对查询结果中的测试用例按照一个三元组方式排序，其中K表示搜索的教育期刊网

关键词 集合，ki是该教育期刊网

关键词 集合中的某个教育期刊网

关键词 ，则排序三元组表示如下：

C(ki)表示当前查询结果中是否有与ki匹配的教育期刊网

关键词 ，如有，则C(ki)记为1，如没有，则C(ki)记为0。

C(ki)是K中每个教育期刊网

关键词 在本次查询中是否匹配的计数之和，始终大于0，因为查询结果中显示的是至少有一个查询关键字匹配的搜索结果。S(ki)表示当前查询结果中教育期刊网

关键词 ki出现的频次。S(ki)是K中每个教育期刊网

关键词 在本次查询中出现频次之和。Creuse则表示查询结果中该条测试用例被复用的次数。

通过上述三元组对测试用例的查询结果进行排序。首先按照C(ki)列进行降序排序，若该列数值相同，则按S(ki)列进行降序排序，若此列数值相同，则按Creuse列进行降序排列。由此可以发现，查询关键字匹配越完全，其满足查询需求的程度就越高，同时，复用次数越多的测试用例，越具有通用性。

4 总结

测试用例复用的核心思想是将以往的测试用例加以收集积累，通过建立测试用例管理系统来统一管理测试用例库。本文提出了将分词技术和软件行业领域应用于测试用例复用来提高测试用例复用程度。按领域划分测试用例可使得查询结果更具有可复用性，同时设计了一套采用二级索引结构的中文分词词库使分词效率更高效。因此，系统为测试用例设计人员推荐更“好”的可复用测试用例，对查询结果顺序稍加改进便于筛选，便能极大的减少测试用例设计阶段的工作量。

篇7：软件测试经典用例设计面试笔试题

软件测试经典用例设计面试笔试题

1.测试项目：电梯

需求测试:查看电梯使用说明书、安全说明书等

界面测试:查看电梯外观

功能测试：测试电梯能否实现正常的上升和下降功能.电梯的按钮是否都可以用;

电梯门的打开，关闭是否正常;报警装置是否可用，报警电话是否可用;

通风状况如何.突然停电时的情况;是否有手机信号;

比如说上升途中的响应，电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来;

电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停;

可靠性：门关上的一刹那出现障碍物，同时按关门和开门按钮，点击当前楼层号码，多次点击同一楼层的号码等等;同时按上键和下键会怎样;

易用性：电梯的按钮的设计符合一般人使用的习惯吗.

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

压力测试：看电梯的最大限度的承受重量.在负载过重时报警装置是否有提醒.在一定时间内不断的.让电梯上升，下降.最大负载下平稳运行的最长时间，

2.测试项目：杯子

需求测试: 查看杯子使用说明书

界面测试: 查看杯子外观

功能度：用水杯装水看漏不漏;水能不能被喝到

安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水(案例一)放24 小时检查泄漏时间和情况;盛上汽油(案例二)放24 小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

跌落测试: 杯子加包装( 有填充物), 在多高的情况摔下不破损

篇8：无线式播种机监测软件系统的设计论文

无线式播种机监测软件系统的设计论文

1系统硬件设计

1．1下位机系统的设计

1．1．1温湿度测试系统

采用温湿度传感器SHT10测量播种的温湿度情况，采用CMOSenstechnology微过程技术，可靠性较强且能保持较高稳定性。由能隙式测温元件和电容式聚合体测湿元件组成，并与A/D转换器以及数字接口2－wire单芯片结合。

1．1．2种子粒数的测量原理

选用光电开关测量播种粒数。利用被检测物体对红外束的遮光或反射，由同步回路选通而检测物体的有无，其检测特体不限于金属，对非金属所有物体均可检测。产品具有体积小、精度高、检测距离远、防水、防腐蚀、抗光和电磁干扰等特点。其外围接线图如图3所示。

1．1．3播种深度的测量

选择超声波测距模块HC－SRO4测量播种深度，其可提供2～400cm的非接触式距离感测，测量精度可达3mm。模块包括超声波发射器、接收器与控制电。

1．1．4拖拉机和播种机转速的测量

拖拉机和播种机转速由霍尔元件测量。霍尔传路。感器是对磁敏感的传感元件，从外形看为3端器件，具有与三极管相似的外形。工作时只需接电源和地，采用OC门输出，具有较宽的工作电压，使用非常方便。

1．2上位机系统设计

1．2．1无线模块的选择

传感器节点采用Zigbee射频收发芯片CC2530，它是一款单芯片，也就是把负责解调无线通讯信号与51单片机内核集成在一起的芯片。CC2530是个真正的用于IEEE802．15．4，ZigBee和RF4CE应用的片上系统(SoC)解决方案，集成了RF收发器、8051MCU、系统可编程Flash存储器、8－KBRAM和许多其它强大功能，能够以非常低的总材料成本建立强大的网络节点。

1．2．2单片机选型与电路

本系统选择PIC16F877A单片机作为数据处理器件，它是美国Microchip公司生产的8位单片机产品。在上位机中，单片机与CC2530无线模块进行数据通信，并对播种的温湿度状况、播种深度、播种粒数、拖拉机和播种机的转速等数据进行处理，由液晶模块进行适时显示。其主电路接线图如图7所示。无线模块接收下位机中的'播种机相关参数信息，输入单片机进行处理后，由液晶显示模块适时显示。

1．3液晶显示模块及其接线图

本文选择CH240128B液晶显示模块，其系列点阵绘图型液晶显示模块(LCM)采用240×128点阵液晶显示屏(LCD)与低功耗LED背光组成。

2系统软件设计

软件设计要完成的内容包括:检测记录播种管通过的种子粒数;检测播种机的播种深度;记录播种时间，并计算播种速度;控制程序运行;显示检测的数据;计算播种机转速和滑移率，建立通信网络。

2．1无线数据传输流程图

系统上电以后，由协调器设备建立网络，播种参数传感器设备加入网络后，周期性地向协调设备发送传感器测得数据，网络启动后，CC2530模块需要在网络允许加入后才可接收数据。

2．2传感器节点流程图

在扫描过程中发现协调器以后，允许其加入网络，进行绑定，读取由温湿度传感器、光电开关、超声波传感器及霍尔元件测得的数据，并且进行上位机与下位机C2530模块的通信;然后数据进入单片机PIC16F877A进行处理，由CH240128进行适时显示。

3结论

1)采用PIC16F877A单片机和无线模块CC2530为核心控制单元，设计了播种质量检测系统的无线数据传输系统，可适时采集播种数据并能够进行传输与显示。

2)硬件包括单片机控制单元、电源、传感器和显示器等。其中，温湿度传感器监测播种大气环境，红外光电传感器检测种子下落情况，霍尔检测播种机前进速度，超声波测距模块检测播种深度。系统可以检测整个播种机的实际播种状况，并进行无线通讯。

3)软件方面，采用结构化程序设计方法，运用C语言进行编程。主程序通过调用子函数完成各种功能，从而实现网络的建立、数据的发送、接收和显示。

篇9：药品真空冷冻干燥过程测温软件的开发设计论文

药品真空冷冻干燥过程测温软件的开发设计论文

引言

真空冷冻干燥简称冻干，是将湿物料或溶液在较低的温度(-10℃～-50℃)下冻结成固态，然后在真空(1.3～13帕)下使其中的水分不经液态直接升华成气态，最终使物料脱水的干燥技术。我国是原料药生产大国，因此该技术应用前景十分广阔。

真空冷冻干燥是一种使物料在低温低压下脱水的干燥工艺。现代生物药品大多具有热敏性，在对热敏性生物药品进行干燥时，为防止由于温度过高而使药品变性，影响其质量，目前广泛采用真空冷冻干燥技术[1]。生物药品冻干过程中必须考虑：①如何保证冻干过程顺利进行;②如何减少冻干过程对生物药品品质的影响;③如何降低生物药品冻干过程中的能耗。在保证生物药品冻干品质条件下，真空冷冻干燥过程中应尽量提高样品温度，因为样品温度每升高1℃，升华干燥时间将缩短13%以上[2]。但是样品温度过高会对冻干产品质量造成破坏，出现熔融、塌陷和皱缩等问题。因此，需要对冻干过程中的药品温度进行准确测量与控制。升华界面是指在冻干药品溶液一次干燥过程中，位于干燥层和冻结层之间的移动界面，随一次干燥进行，升华界面由冻干药品顶部逐渐移动至底部，直接反映一次干燥进程，可由此来判断一次干燥终点。

与其它干燥方法一样，要维持升华干燥的不断进行，必须满足两个基本条件，即热量的不断供给和生成蒸汽的不断排除。在开始阶段，如果物料温度相对较高，升华所需要的潜热可取自物料本身的显热。但随着升华的进行，物料温度很快就降到与干燥室蒸汽分压相平衡的温度，此时，若没有外界供热，升华干燥便停止进行。在外界供热的情况下，升华所生成的蒸汽如果不及时排除，蒸汽分压就会升高，物料温度也随之升高，当达到物料的冻结点时，物料中的冰晶就会融化，冷冻干燥也就无法进行了。

目前，国内外冻干机大多采用传统的接触式测温方法，将热电偶或热敏电阻插入冻干样品中对冻干过程进行监测。传统测温方法有一定局限性[1]，即无法测得移动的升华界面温度，热电偶或热敏电阻本身会对冻干样品传热产生影响，导致被监测的样品比未监测样品干燥更快，无法准确判断整个批次样品冻干状况，且对冻干过程无菌化造成不利影响。因此，开发非接触式测温软件对于药品冻干品质保证和节能有着重要意义。

动压测温技术是一种非接触测温技术，在冷冻干燥过程中通过关闭中隔阀进行压力升测试，获得干燥室内压力升数据，并采用动态参数估值法(DynamicParametersEstimation，DPE)计算得到升华界面温度。本文对DPE数本文由论文联盟wWw.LWlM.com收集整理学模型和求解方法进行分析，并采用MATLAB编程开发DPE动压测温软件。

1.冻干过程动压测温技术

1.1动压测温技术

动压测温是根据平衡状态下的冰晶温度与其饱和蒸汽压为单值函数，在升华干燥过程中，突然中断从冻干室流向冷阱的水蒸汽流，通过测量冻干室内压力回升情况，运用数据回归方法推算升华界面温度，可较准确反映升华界面温度[3]。压力升测试(PressureRiseTest，PRT)是在样品冻干过程中，中隔阀突然关闭，冻干室压力因为冰的持续升华而上升，直至冻干室压力与升华界面冰的饱和水蒸气压相等为止，从而可得出冻干室压力随时间变化曲线。基于PRT动压测量技术，有气压温度测量法(BarometricTemperatureMeasurement，BTM)[4，5]、压力温度测量法(ManometricTemperatureMeasurement，MTM)[68]、动态压力升法(DynamicPressureRise，DPR)[9]、压力升分析法(PressureRiseAnalysis，PRA)[10]等方法。

在前人研究基础上，Velardi等提出了“DynamicParametersEstimationMethod(DPE)”测温新方法[11]，该方法可以看作是MTM法的改进，其建立了冻干室中热质传递的一维非稳态模型，通过DPE法可得到药品冻结层温度分布、升华界面位置、药品瓶底与搁板传热系数、药品干燥层有效扩散系数，以及在压力升测试过程中冻结层温度上升状态。利用DPE方法模拟测得的`参数可靠性更高[12]。Barresi等[13，14]根据DPE法建立了一种适用于冻干过程的测量和控制策略，可对冻干过程进行在线优化监控，在保证药品冻干质量的前提下缩短冻干时间。

1.2DPE理论模型和求解方法

1.2.1模型建立假设[11]

在冻干过程中，动压测量实施时间较短，一个测量单元可在3～20s内完成。为简化计算，对动压测量法实施作如下假设：

①冻干过程热量和质量传递是一维，且传递方向垂直于物料表面;

②升华过程仅发生在物料升华界面上，不考虑干燥层中的解析干燥;

③冻干过程中，较短时间内，温度、压力和升华界面位置等物理量变化很小，在中隔阀关闭之初，冻结层按准稳态处理;

④假设冻干室内为水蒸气，不考虑非凝性气体;

⑤由于压力很低，冻干室内的气体视为理想气体;

⑥只考虑热传导，不考虑箱体对物料的辐射作用。

2.DPE动压测温软件开发

软件开发原理

MATLAB是一种高效的工程计算语言，在数值计算、数据处理、自动控制等方面有着广泛应用，可实现大量数据的分析、处理及显示，而且具有图形用户界面(GraphicalUserInterface，GUI)设计功能[15]，界面设计友好、方便用户操作。

本文将DPE冻干传热模型在时间和空间上进行区域离散化(见图3)，建立节点离散方程[16]，使用MATLABR2011a软件对离散方程进行编程，并利用软件自身GUI设计功能对界面进行设计。

3结语

真空冷冻干过程中，对冻干产品温度进行准确测量与控制，关键是确保冻干样品质量和提高干燥效率。本文对动态参数估值法(DPE)法数学模型及求解方法进行分析，并基于DPE模型的非接触测温算法进行数值计算，运用MATLAB软件编程，开发动压测温软件对药品冻干过程进行监测，通过计算得到样品冻干过程参数;分别用不同样品在不同型号的冻干机上进行冻干实验，将测得PRT数据运用所开发软件进行模拟计算，实验测试值与模拟计算结果一致，可应用于冻干进程判断。本文所开发的软件能通过动压测量计算出冻干样品状态参数，但需要进一步完善。后续研究将建立冻干过程优化控制策略，通过控制冻干过程主要变量(冻干室压力、隔板温度)达到冻干过程最优化，目标是实现在不同型号冻干机上对不同样品冻干过程进行优化控制，缩短冻干时间。

软件配置管理表单审批系统设计论文

开发组件软件的论文

有效朗读课例论文

CATIA 软件在轮胎三维设计中的应用分析论文

测土配方施肥关键技术工学论文

小议软件测试用例的设计的论文.doc

将本文的Word文档下载到电脑，方便收藏和打印

推荐度：

点击下载文档