（计算机应用技术专业论文）航空软件测试用例自动生成方法研究.pdf

m e t h 承诺书 本人郑重声明：所呈交的硕士学位论文，是本人在导师指 导下，独立进行研究工作所取得的成果。尽我所知，除文中已 经注明引用的内容外，本学位论文的研究成果不包含任何他人 享有著作权的内容。对本论文所涉及的研究工作做出贡献的其 他个人和集体，均已在文中以明确方式标明。 本人授权南京航空航天大学可以有权保留送交论文的复 印件，允许论文被查阅和借阅，可以将学位论文的全部或部分 内容编入有关数据库进行检索，可以采用影印、缩印或其他复 制手段保存论文。 ( 保密的学位论文在解密后适用本承诺书) 作者签名：莹蠹 日期： 翌坦：王：2 兰 南京航空航天人学硕士学位论文 摘要 软件测试在软件的整个开发过程中t 与有非常重要的地位，是保证软件质量的关键步骤。航 空软件具有实时性、嵌入性、高可靠性等特点，对其进行严格的软件测试至关重要。测试用例 生成是软件测试的核心问题，研究适用于航空软件的测试用例自动生成方法，对提高航空软件 的可靠性有着重要的理论意义和实用价值。 本文以在某研究所参与的航空软件一一卫星导航系统测试项目为研究背景，首先，在对国 内外已有的测试用例自动生成研究成果深入分析的基础上，研究了基于模型检奄的测试用例自 动生成方法。结合航空软件灰盒测试过程，提出了一个基丁需求、运川模型检布技术的测试用 例自动生成流科，该流程涉及软件需求抽象、软件需求的形式化系统建模、基丁测试准则的时 序逻辑变换、软件需求形式化模型与时序逻辑的一致性验证以及测试用例的提炼和整理等内容。 其次，依据航空软件测试标准d o 一1 7 8 b 的要求，本文提出一个布尔运算符替换算法来构造时序 逻辑，该时序逻辑经过模型检查后得剑的用例能够满足m c d c 覆盖准则。 最后，本文针对测试用例自动生成流程，设计开发了一个基r 模型检奄测试j j 例自动生成 工具。根据卫犀导航系统的软什测试过程，通过将该工具作为设计测试用例的辅助 具，并设 计测试驱动模板，以及进行结构覆盖分析，对提出的测试用例自动生成方法实刚性进行了验证。 关键词：模型检查，测试用例自动生成，灰盒测试，m c d c ，d o 1 7 8 b 航空软件测试用例臼动生成方法研究 a b s t r a c t s o f h a r et e s t i n go c c u p i e sv e 巧i m p o r t a n tp o s i t i o ni nt h ed e v e l o p m e n tp r o c e s so fs o f 研a r e i ti sa c r i t i c a ls t 印t oe n s u r es o 行w a r eq u a l i t y b e c a u s eo fa v i a t i o ns o f t w a r ew i t ht 1 1 ec h a r a c t e r i s t i c so f r e a m e ，e m b e d d e da j l dh i 曲r e l i a b i l n ye t a l ，t oc a 吖o u t g o r o u ss o r w a r et e s t i n gi se s s e n t i a l t e s t c a s eg e n e r a t i o ni sm ec o r ei s s u ei ns o f t w a r et e s t i n g t h er e s e a r c ho fa u t o m a t i cg e n e r a t i o nm e t h o d0 f t e s tc a s ef o ra v i a t i o ns o f t w a r eh a si m p o r t a n tt h e o r e t i c a ls i g n i 6 c a n c ea n dp r a c t i c a lv a l u et oi m p r o v e t h er e l i a b i l i t yo fa v i a t i o ns o 胁a r e i nt h i sp a p e r t a k i n ga v i a t i o ns o r w a r e 一一s a t e l l i t en a v i g a t i o ns y s t e m sa st h ep r i o j e c tb a c k g r o u n d ， f i r s t ，m a k eai n d e p t ha n a l y s i so fa l lk i n d so fm e t h o d sa n dr e s e a r c hr e s u l t so fa u t o m a t i cg e n e m t i o no f t e s tc a s e sa th o m ea n da b r o a d o nt h eb a s i so fa _ b o v em e n t i o n e ds t u d y ，r e s e a r c hab a s e do nm o d e l c h e c k i n gm e t h o do fa l l t o m a t i cg e n e r a t i o no ft e s tc a s e s c o m b i n e dw i t hg m y b o xt e s tp r o c e s sw h i c h 印p l i e df o ra v i a t i o ns o r w a r e ，p u tf o n a r dat e s tp r o c e s so fa u t o m a t i c a l l yg e n e r a t i n gt e s tc a s e sw h i c h b a s e do ns o f t w a r er e q u i 肌e ma n dt a k i n gu s eo fm o d e lc h e c k i n g t h ep r o c e s si n v o l v e st l l ea _ b s 订a c t i o n o fs o f t w a r er e q u i r e n l e n t s ，e s t a b l i s h i n gf o m 诅ls y s t e mr n o d e la c c o r d i n gt os o 胁a r er e q u i r e m e n t s ， s e q u e m i a l l o g i c 缸- 觚s f o i l a t i o nb a s e do nt e s t i n gc r i t e r i a ，c o n s i s t e n c yv e 订6 c a t i o nb e m e e ns o r w a r e r e q u i r e m e n t sf o h l l a lm o d e l sa n dt e m p o m ll o g i ca 1 1 dt 1 1 er e 6 n i n go ft e s tc a s e sa n ds oo n s e c o n d l y ， a c c o r d i n gt o a v i a t i o ns o 脚a r et e s t m gs t a j l d a r dd o 1 7 8 b ，t h i sp 印e rp r e s e n t sab o o l e a l lo p e r a t o r r 印l a c e m e n ta l g o r i t h m t oc o n s 协】c tt h es e q u e n t i a l l o 百c ，t h et e s tc a s e sw h i c hg e n e r a t e db yi 1 1 p u t i n g l e c o n v e r t e dt e m p o r a ll o g i ct om o d e lc h e c k e rc a nm e e tm c d cc o v e r a g ec r i t e r i o n i i lt h ee n dt h ep a p e ra i m e dt om ep r o c e s so fa u t o m a t i c a l l yg e n e r a t i n gt e s tc a s e s ，d e s i g na n d d e v e l o pa na u t o m a t i cg e n e r a t i o no f t e s tc a s e sb a l s e do nt h em o d e lc h e c k i n gt 0 0 1 1 1 1t e m l so fs a t e l l i t e m v i g a t i o ns y s t e ms o r w a r et e s t i n gp r o c e s s ，v “母a v a i l a b i l 时o ft l l ep r 叩o s e dm e t h o do fa u t o m a t i c g e n e r a t i o no ft e s tc a s e sb yi l s i n gt h et o o l 觚a u x i l i a 巧t o o lt od e s i g n t e s tc a s e sa i l dd e s i 伊i n g t e s t - d r i v e nt e m p l a t ea l l dn l a k i n gs 仇l c t l l r a lc o v e m g ea n a l y s i s k e y w o r d s ：m o d e lc h e c k i n g ，a u t o l i l a t i c g e n e r a t i o n 0 ft e s tc a s e ，g r a y - b o xt e s t i n g ，m c d c ， d o 一1 7 8 b 一 南京航空航天大学硕十学位论文 目录 第一章绪论1 1 1 研究背景和意义1 1 2 国内外研究现状2 1 3 主要研究内容3 1 4 论文的组织结构3 第二章软件测试技术5 2 1 软件测试5 2 1 1 软件测试的过程5 2 1 2 软件测试的方法5 2 2 测试川例设计方法7 2 2 1 基于代码的测试用例设计方法8 2 2 2 基于规格说明的测试用例设计方法1 0 2 3 测试用例自动生成方法1 1 2 3 1 面向结构的测试数据自动生成方法1 2 2 3 2 面向对象的测试数据自动生成方法1 3 2 3 3 面向功能的测试数据自动生成方法1 3 2 4 航空软件测试技术1 4 2 4 1 航空领域软件标准d o 1 7 8 b 介绍1 4 2 4 2 灰盒方法在航空软件测试中的应用1 5 2 5 本章小结1 5 第三章运用模型检查自动生成测试用例1 6 3 1 时序模型概述1 6 3 1 1k n p k e 结构1 6 3 1 2 时态逻辑1 6 3 2 符号模型检查2 l 3 2 1 二元决策图介绍2 1 3 2 2 不动点理论基础2 5 3 2 3 符号模型检测算法2 6 航空软件测试用例自动生成方法研究 3 3 运用模型检查自动生成测试用例原理2 7 3 4 运用模型检查自动生成测试用例流程2 7 3 4 1 模型检查过程2 7 3 4 2 运用模型检奄白动生成测试用例过程2 9 3 5 本章小结3 1 第四章测试用例自动生成流程3 2 4 1 根据需求建立系统模型3 2 4 1 1 需求抽象3 2 4 1 2s m v 语法描述系统模型3 3 4 2 构造满足m c d c 准则的时序逻辑3 6 4 2 1m c d c 准则3 6 4 2 2m c d c 准则的形式化定义3 7 4 2 3 布尔运算符替换算法设计3 8 4 2 4 构造满足m c d c 准则的时序逻辑4 3 4 3 利h j 模型检查器进行模曩4 检查4 6 4 3 1 模型检奄器n u s m v 介绍4 6 4 3 2 初始运行结果4 7 4 4 从反例抽取测试用例4 9 4 5 本章小结5 0 第五章测试用例自动生成方法实验验证5 l 5 1 卫星导航系统测试过程5 l 5 2 基丁模型检查测试用例自动生成_ 具设计框架5 4 5 2 1 系统建模模块5 4 5 2 2 时序逻辑模块5 6 5 2 3 抽取测试用例模块5 7 5 3 测试驱动创建5 8 5 4 结构覆盖结果分析6 0 5 5 本章小结6 0 第六章总结与展望6 1 6 1 本文的主要j ：作6 1 6 2 今后的上作6 2 参考文献6 3 南京航空航天人学硕士学位论文 至5 【谢6 7 在学期间的研究成果及发表的学术论文6 8 航空软件测试川例自动生成方法研究 图表清单 图2 1 基于代码的测试用例设计方法8 图2 2 被测程序段流程图8 图2 3 基于规格说明测试州例设计方法。1 0 图3 1l p k e 结构到计算树的转换1 7 图3 2 四种典型的c t l 运算符2 0 图3 3 仁( a & b ) l ( c d ) 对应的b d d 2 2 图3 4 由香农展开式获得的b d d 2 3 图3 5 约简后的o b d d 2 4 图3 6 状态s l 和s 2 的k i p k e 结构2 5 图3 7 模型检查过程2 8 图3 8 结构覆盖准则覆盖强度一3 0 图3 9 运用模型检奄自动生成测试削例过程一3 1 图4 1 需求抽象过程3 3 图4 2 布尔运算符替换算法流程3 9 图4 3 由初始真值表建成的树4 2 图4 4 所有布尔常量被标记后的树4 2 图4 5 最小真值表法与布尔运算符替换算法时间比较一4 4 图4 6n u s m v 运行结果4 7 图5 1 卫星导航系统软1 ；， = 测试过程5 2 图5 2 基于模型检查测试用例自动生成t 具5 3 图5 3 主要功能框架。5 4 图5 4 系统建模录入。5 5 图5 5 查看自动生成的s m v 程序5 5 图5 6 布尔运算符替换算法实现类图一5 6 图5 7c t l 时序逻辑变换5 7 图5 8 生成符合m c d c 准则的测试用例5 8 图5 9 测试用例l 的运行结果5 9 图5 1 0 覆盖测试过程6 0 南京航空航天人学硕+ 学位论文 图5 1 l 覆盖结果报告6 0 表4 1 “aa i l db ”m c d c 真值表3 7 表4 2 “ao rb m c d c 真值表3 7 表4 3 操作符优先关系表。4 0 表4 4 布尔运算符替换规则表4 l 表4 5b 【1 】出队后生成的真值表4 1 表4 6b 5 出队后生成的真值表4 l 表4 7b 【3 】出队后生成初始真值表4 l 表4 8 优化真值表一4 3 表4 9 选取用例及时间对照表4 4 表4 1 0 “a i b & c ”m c d c 真值表4 5 v l l 航空软件测试j h 】例自动生成方法研究 s c d c c c c d c m c c p c m c d c c t l i i j l c t l b d d o b d d f s m u m l v 1 l i 注释表 s t a t e m e n tc o v e r a g e d e c i s i o nc o v e r a g e c o n d i t i o nc o v e r a g e c o n d i t i o nd e c i s i o nc o v e r a g e m u l t i p l ec o n d i t i o nc o v e r a g e p a t hc o v e r a g e m o d i f i e dc o n d i t i o n d e c i s i o nc o v e r a g e c o m p u t a t i o n1 r e el o g i c l i n e a rt e m p o r a ll o g i c c o v e r a g et e m p o r a ll 0 9 i c b i n a r yd e c i s i o nd i a 铲a m o r d e r e db i n a r yd e c i s i o nd i a g r 锄 f i n i t e s t a t em a c h i n e u m f i e dm o d e l i n gl a n g u a g e 语句覆盖 判定覆盖 条件覆盖 条件判定覆盖 条件组合覆盖 路径覆盖 修正条件判定覆盖 计算树逻辑 线性时态逻辑 分支时态逻辑 二元判定图 有序二元判定图 有限状态机 统一建模语言 一 南京航空航天人学硕士学位论文 1 1 研究背景和意义 第一章绪论 随着信息技术的飞速发展，计算机已广泛应用丁国民经济和国防建设中的许多重要领域， 如：航空、航天、工业控制、交通、银行、企业管理和军事指挥白动化系统等。这类应川对软 什提出了很高的质量要求，冈为即使很小的软件错误也可能导致整个系统的崩溃，造成极大的 经济损失及灾难性后果。 影响设计的软件的可靠性的闪素有很多，而提高软什可靠性的途径也有多种。其中一个传 统的不可或缺的方法是：通过提高对软件测试的充分性，尽可能充分地考验软件，以发现尽可 能多的问题，从而提高软件的可靠性。软件测试的工作龌很人，据统计，测试时间会t l i 到总开 发时间的4 0 ，一些可靠性要求非常高的软件，测试时间其至占剑开发周期的6 0 。由丁测试 的许多操作和过程是重复性的，因此在整个软件过程中软件测试t 作可以应j 【 j 自动化。自动化 测试能够提高测试的速度、效率和准确度。而自动化测试技术和测试1 j 具是提高白动化测试水 平和效率的基本手段。 软件自动测试的过程可分为测试用例的自动生成、被测程序驱动程序的生成以及执行结果 的自动比较等几个部分。其中驱动程序模块用来模拟被测模块的运行环境；测试用例自动生成 提供明确的测试数据，执行结果的比较用来比较以测试数据为输入的被测程序输出利预期的输 出是否一致。驱动程序模块以及执行结果的比较自动化较易实现，而测试用例自动生成部分由 于往往要对软件需求进行分析，因此其开发相对较难。 软件测试的核心思想是：对于输入域的特定输入，观察软件的执行结果，验证该结果与期 望结果是否一致，然后作相应的纠错和调整。软件测试领域中的一个关键的同时也是极为凼难 的问题就是如何设计和生成有效的测试用例。目前，软件测试技术的发展还不是很成熟，测试 人员在选择测试用例时通常根据直觉和经验进行。但对状态变量繁多，状态变量之间存在复杂 的耦合情况的系统，通过人1 ：构造测试用例时，往往出现考虑不周，设计不全的问题，从而给 测试带来很人的盲目性，最终导致的后果是使软件后期维护的费用在软件成本中高居不下。 为了从根本上保证软件系统的可靠安全，许多计算机科学家都认为，采用形式化方法对系 统进行形式化验证和分析，是构造可靠安全软件的一个重要途径。形式化方法是基丁数学方法 来描述目标软件系统性质的一i j 技术，用严格的数学符号和数学法则对目标软件的结构与行为 进行有效的综合、分析和推理，它为系统的说明、开发和验证提供了一个框架。形式化方法的 主要表现是形式规格说明。由丁形式规格说明基于严格的数学概念和理论，避免了用臼然语言 描述时可能带来的模糊性和歧义性，因而便，对规格说明的各种性质进行推理或证明，也有利 l 航空软件测试用例自动生成方法研究 于采用软件：i = 具对规格说明进行自动化分析和验证。 模型检查技术就是一种基于状态探测的得到广泛运用的形式化方法。模型检奄器检奄需求 中某个系统特性是否成立时，根据反映需求的形式化模型在内存中构造一个有限状态转换模犁， 探测模型的可达状态空间，以检测被验证的系统特性与模型是否存在冲突，从而验证这个系统 特性对于需求是否成立。当被检验的系统特性与模型存在冲突时，模型检奄器会产生一个反例， 证明冲突是如何发生的。反例以输入输出序列的形式给出，将有限状态转换模型从初始状态引 入到冲突发生的状态。 测试是对选定的输入数据集运行系统，通过比较所产生的输出与预期值来判断系统是否存 在错误。测试是事后性的检测手段。而对丁模型检查，通常意义是在系统建模设计阶段，考察 系统是否满足一些关键的性质，是一种事前保证方式。模型检查不是针对某种特定输入，而是 面向某类性质来检奄系统是否合乎规约。当系统不满足所要求的性质时，模型检查算法会产生 一个反例米说明不满足的原冈。从而，模型检奄算法产生的路径和测试中由一个输入产生一个 输出都是系统的一次执行。由此可以把模型检查与软件测试技术相关联，按模型检查的路径产 生测试用例。 1 2 国内外研究现状 随着需求的形式化描述方法的应用，有关基于形式化规格说明的测试川例自动生成方法， 国内外已经有了许多研究成果。如多人提出了基丁z 规格说明的测试用例生成方法f l 】【2 】【3 1 ， w e ”k e r 提出基丁布尔规格说明的测试数据生成方法【4 j ，t s a i 提出的从用关系代数查询表示的规 格说明中生成测试用例的方法【5 】a j e 脏r s o no 腼t t 给出从s o f l 表示的规格说明产生测试用例 方法【6 】o 虞凡等7 1 提出基于时序逻辑语言x y z 厄软件规范说明的测试用例自动生成方法，多人 研究了基于u m l 模型的测试用例自动生成方法【8 】f 9 1 【1 0 1 等。 模型检测技术冈其完全自动化并且验证速度快的优点在硬件及协议的验证中广泛应用，近 年米在软件测试领域的应用研究也不断涌现【l 。利片j 模型检查器，对需求进行形式建模后，可 根据用户声明的时序逻辑生成测试 j 例。g a r g a l l t i l l i 和h e i 仃n e y d l 2 】描述了一种从s c r 表示的需 求规约中生成测试序列的方法。a m m a i l l l 和b l a c k 【l3 】结合了变异分析和基于模型检查的测试用 例生成方法。郭国林1 4 】，彭晓红等1 5 1 利用模型检查技术，结合特定软件系统生成了测试用例。 范轶平等【1 6 】根据模型检查器自动生成反例的特点，提出了一种实用反例生成策略。g a 唱a i l t i n i 等提出一种从需求规约生成测试用例的方法【1 7 】。黎吾平1 8 1 设计了一个原型系统进行基于源代码 进行模型检查。梁陈良等【1 9 】提出了从类源代码生成测试用例的方法。 这些已有的测试用例生成方法，大部分结合具体的需求，且生成的测试用例未考虑结构覆 盖问题。h e i m d a l l l 和g e o r g e 【驯】对基于不同的覆盖准则生成的测试用例集进行裁减，裁减后的 2 南京航空航天人学硕十学位论文 测试h j 例集仍能满足相应的覆盖准则，但发现错误的能力却人人降低。a m m a 衄川分析了运用 模型检查生成满足不同覆盖准则的测试用例的难度。 1 3 主要研究内容 本文以在某研究所参与的航空软件一一卫星导航系统测试项目为研究背景，从模型检查入 手，针对航空软件测试的高可靠性高安全性的特点，进行了测试用例自动生成方法的研究。主 要研究内容如下： 1 通过研究国内外软件测试用例白动生成方法的研究现状，针对目前软件测试过程中测试 用例设计的特点，结合卫星导航系统的软件需求，利用模型检查能生成反例的特点，提出一种 适用丁航空软件的测试川例自动生成测试方法。 2 根据d o 一1 7 8 b 规范，测试用例需满足m c d c 覆盖准则的要求。本文研究了布尔运算符 替换算法，该算法实现对一个布尔表达式求出满足m c d c 准则的最小测试用例集。结合布尔运 算符替换算法，对与状态变量转换相应的时序逻辑进行变换，以生成适合模型检查器检查的时 序逻辑。 3 实现本文提出的运用模型检查生成测试用例的方法，设计一个基于模型检查测试刚例自 动生成j r 具，结合卫星导航系统的软件测试过程，对提出的测试用例自动生成方法进行验证。 4 为生成的测试用例构建驱动模板，以便结合源代码运行测试用例，自动生成预期值与实 际值的比较结果。 1 4 论文的组织结构 本文的整体结构如下： 第一章绪论主要介绍了本课题研究的背景和意义、国内外的研究现状，给出了本文的主 要研究内容及论文的组织结构。 第二章软件测试技术主要介绍了软件测试的相关概念、分析了现行的测试用例的设计方 法，详细介绍了几种测试用例自动生成技术，并介绍了航空领域软件标准d o 1 7 8 b 及应用于航 空软件测试中的灰盒方法。 第三章运用模型检查自动生成测试片j 例主要介绍了模型检查、符号模型检查的相关概念， 阐述了运用模型检查生成测试用例的原理。根据模型检奄过程，分析了运用模型检查生成满足 m c d c 准则的测试用例的过程。 第四章测试片j 例自动生成流程详细介绍了测试用例的生成流程。介绍了利用s m v 语言 进行系统建模的过程，提出了布尔运算符替换算法，利h j 该算法可实现时序逻辑的变换。结合 卫星导航系统的软件需求对整个流程进行解释。 第五章测试用例自动生成方法实验验证介绍了卫星导航系统软件测试的过程，介绍了测 3 航空软件测试用例臼动生成方法研究 试用例自动生成- 具的框架及各个模块的实现过程。结合卫星导航系统测试过程，检验提出的 方法的正确性，有效性，以及实用价值。 4 第六章总结与展望对论文的研究t 作进行了总结，并对进一步的研究工作做了展望。 南京航空航天人学硕十学位论文 第二章软件测试技术 2 1 软件测试 m v e r s 对软件测试的定义是：“软件测试是为了发现错误而执行程序的过程”。这一定义明 确指出测试的目的是“寻找错误”。从软件质量保证的角度看，软件测试是一种重要的软件质量 保证活动，其动机是通过一些经济、高效的方法，捕捉软件中的错误，从而达到证实软件内在 质量的目的。软件测试通过发现错误使软件增值。这种测试主要针对功能实现的止确性，无法 测试功能设计的正确性。 2 1 1 软件测试的过程 软件测试一般经过以卜步骤：选择合适的测试模型、定义合适的测试覆盖准则、利用该覆 盖准则生成测试用例、测试及测试结果的评估、修改错误、同门测试。选择测试模犁是测试_ t 作的第一步，定义合适的测试覆盖准则是整个测试的基础，而测试t 丰j 例的生成是整个测试活动 的关键，其根本目的在于确定一组最可能发现某类错误的测试数据，它决定了软件测试的效率 及所能达剑的目标。 一个成功的测试必须包括两方面：一是软件在所有的测试数据上的正确性；二是测试数据 的充分性，判断一个测试数据集是否充分称为充分性问题，即软件在测试数据上的表现能够充 分反映软件的总体表现。测试过程中，既要保证软件测试充分性，义要避免过度测试，过度测 试会增加软件的成本。 2 1 2 软件测试的方法 软件测试的发展是一个从实践到理论，又从理论同到实践的不断往复的过程。随着软件技 术的发展、软件系统的不断扩人，测试方法也在不断得到发展。从不同的角度对于软件测试进 行分类，可以将软件测试归纳为以下几种方法： 依据是否需要执行被测软件，可将其分为静态测试和动态测试两大类： 1 静态测试是一种同分析软件开发中的各种产品相关的测试活动。静态测试利用软件的文 本或图形化文档，人们用眼睛或者使用软件来检查文档或代码，不实际运行被测程序，而从分 析程序结构出发审查和验证程序的正确性。静态测试包括由手工进行的代码审查、代码走查、 桌面检查以及主要由软件工具自动进行的静态分析。 代码审查 代码审查的内容包括：检夯代码和设计的一致性；检查代码的规范性、可读性：检查代码 5 航空软件测试用例自动生成方法研究 逻辑表达的正确性；检奄代码结构的合理性：检奄数据及数据结构使用的正确性；检查程序注 释的完整性与准确性。 静态分析 静态分析是对被测试程序进行特性分析的一些方法的总称。静态分析常需使用软件测试上 具进行。一般包括控制流分析、数据流分析、接口分析、表达式分析等。 静态测试技术虽然有其自身的特点，但是也有不足之处。代码审查的结果往往受到审杏组 成员素质的影响。静态分析主要对违反编码规则的错误有效。随着编译系统功能的加强，一些 错误在程序编译时就会发现。静态测试技术对软件的动态特性( 例如：功能、时间性等) 的测 试无能为力。 2 动态测试是通过运行程序来检验程序的动态行为以及运行结果的正确性。动态测试包括 三部分核心内容：生成测试数据，执行程序与验证程序的输出结果。 依据测试时是否需要了解被测软件代码，将软件测试分为白盒测试和黑盒测试。 1 白盒测试是以源程序为基础的测试。测试人员是在己知被测对象的源代码情况下，根据 程序内部的结构特性来设计、选择测试t h j 例，检测程序的每条路径是否都按照预定的要求正确 地执行，而不必考虑它的功能，同时以稃序被执行的程度米判断测试是否充分。 2 黑盒测试是以需求规约和需求描述为基础的测试。通过分析软件的需求描述和需求规约 形成测试用例，并根据覆盖功能和性能要求的程度米判断测试是否得到充分进行。 依据执行测试的主体不同，测试又可以分为手t 测试和自动化测试。 1 手工测试是指在测试过程中，按测试计划一步一步执行程序，得出测试结果并进行分析。 手- t 测试有一定的局限性： 通过手工测试无法做到覆盖所有代码路径。 简单的功能性测试用例在每一轮测试中都不能少，而且具有一定的机械性、重复性， 工作量往往较大。 许多与时序、死锁、资源冲突、多线程等有关的错误，通过手工测试很难捕捉到。 进行系统负载、性能测试时，需要模拟大量数据或大量并发用户等各种应用场合时， 很难通过手工测试来进行。 进行系统可靠性测试时，需要模拟系统运行十年、几十年，以验证系统能否稳定运行， 这也是手工测试无法模拟的。 如果有大量( 几千) 的测试用例，需要在短时间内( 1 天) 完成，手工测试几乎不可能 做到。 2 自动化测试是相对手1 ：测试而存在的，提出自动测试就是希望能够通过自动化测试工具 或其他手段，按照测试上程师的预定计划进行自动的测试，目的是减轻手工测试的劳动量，充 6 南京航空航大大学硕士学位论文 分利用计算机快速、重复计算的能力，提高软件测试的效率，缩短软件的开发周期，从而达到 提高软件质量的目标。自动化测试主要是通过所开发的软件测试工具，脚本等来实现，具有良 好的可操作性、可重复性和高效率等特点。自动化测试的优势有： 可以使某些测试任务比手工测试执行的效率高，并可以运行更多更频繁的测试。 对程序的新版本可以自动运行已有的测试( 同归测试) ，特别是在频繁地修改许多程序 的环境中，一系列同归测试的开销应是最小的。 可以执行一些手1 j 测试凼难或不可能做的测试，例如对于2 0 0 个用户的联机系统，用 手j ：进行并发操作的测试儿乎是不可能的，但自动测试：1 ：具可以模拟来自2 0 0 个用户 的输入。 更好地利用资源。将繁琐的任务自动化，如重复输入相同的测试输入，可以提高准确 性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。 测试具有一致性和可重复性。对于自动重复的测试可以重复多次相同的测试，如不同 的硬件配置、使用不同的操作系统或数据库等，从而获得测试的一致性，这在手一i ：测 试中是很难保证的。 一旦一系列测试已经被自动化，则可以更快地重复执行，从而缩短了测试时间，使软 件更快地推向市场。 增加软件信任度。一日得知软件通过强有力的自动测试后，软件发布时对其的信任度 也高。 2 2 测试用例设计方法 在软件测试的过程中，测试用例是核心，也是测试执行环节的基本依据。所谓测试用例， 就是指测试数据与测试结果的总称。测试用例一般包括名称、目标、测试方法、输入数据、期 望输出、实际输出等。构造测试用例的目的是为了检查被测软件的操作结果是否与预期的需求 相吻合，确定应用程序的某些特性是否正常地下作等。测试用例的质量可以用以下四个特性来 描述： 有效性：是否能够发现缺陷，或者至少可能发现缺陷； 仿效性：可仿效的测试片j 例能够测试多项内容，从而减少测试用例的数量； 经济性：测试用例的执行、分析和调试是否经济； 修改性：软件修改后测试用例的维护成本。 测试方法不同，构造测试用例的方法也不相同。软件测试的最基本方法是白盒测试和黑盒 测试，依据这两种测试方法可分为基于代码的测试用例设计方法和基于规格说明的测试用例设 计方法。 7 航空软件测试用例白动生成方法研究 2 2 1 基于代码的测试用例设计方法 基丁代码的测试用例设计方法，它的测试需求主要从软件程序代码中获得。例如，如果是 分支测试，测试j j 例集就必须能够覆盖程序中的每一个分支。用图形化抽象描述基于代码的测 试如图2 1 所示。软件说明s 是编写的程序p 的基础。根据某些覆盖准则，如分支覆盖、数据 流覆盖等，用p 来产生测试用例集t 。计算机c 在p 上执行t 米产生实际的输出，这些实际输 出必须与期望输出比较，来反映程序的正确与否。而期望输出实际上是从说明中获得。 图2 1 基丁代码的测试用例设计方法 测试者根据程序的内部结构特性和路径相关的数据特性设计测试用例、制定测试的标准和 测试策略。其设计方法有： ( 1 ) 逻辑覆盖 逻辑覆盖是以程序内部的逻辑结构为基础的测试川例设计技术，这一方法要求测试人员对 程序的逻辑结构有清楚的了解。逻辑覆盖可分为：语句覆盖s c 、判定覆盖d c 、条件覆盖c c 、 判定条件覆盖c 仍c 、条什组合覆盖m c c 与路径覆盖p c 等。 8 图2 2 被测程序段流程图 c e 南京航空航天人学硕十学位论文 语句覆盖 语句覆盖的含意是，在测试时，首先设计若干个测试用例，然后运行被测程序，使得每一 条执行语句至少执行一次。如图2 2 所示，根据语句覆盖准则，选取测试用例1 为：x = 3 ，y = 2 ，z = 2 ( 沿路径a b d ) 。从程序中每个可执行语句都得到执行这一点米看，语句覆盖的方法似 乎能够比较全面地检验每一个可执行语句。但它也不是完美无缺的。假如程序段中的两个判断 的逻辑运算有问题，例如，如果把第一个判定表达式中的逻辑运算符“& ”误写成“i ”，或把第 二个判定表达式中的条件“x = 3 ”误写成“x = l ”，这时使用侧试用例1 ，程序仍将按路径a b d 执行。这说明虽然也做到了语句覆盖，却发现不了判断中逻辑运算的错误。 判定覆盖 按判定覆盖准则进行测试是指，设计若干测试用例，运行被测程序，使得程序中每个判断 的取真分支和取假分支至少经历一次，即判断的真假值均曾被满足。对于图2 2 ，根据判定覆盖 准则，选用两组测试用例( x - 3 ，y = 2 ，萨2 ) 、( x - 2 ，) ，= l ，牙o ) ，则可分别执行路径a b d 和a c e ， 从而使两个判断的4 个分支分别得剑覆盖。所以满足判定覆盖的测试片j 例也同时满足语句覆盖。 但设想，在程序段中的第2 个判断条件z 1 如果错写成z = 1 ，则上述两组测试用例仍能按原路 径执行，不影响结果。这个事实说明，只做到判定覆盖仍无法确定判断内部条件的错误。 条件覆盖 条件覆盖是指，设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能 取值至少满足一次。对于图2 2 ，使用2 组测试用例( x - o ，y = 2 ，z = ) 、( x _ 3 ，) ，= 1 ，z = 0 ) 可把 4 个条件的8 种情况均做覆盖。但两组测试用例的执行路径都是a c d ，故它只覆盖了4 个分支中 的两个。这一情况表明，覆盖了条件的测试用例不一定覆盖了分支。 判定条件覆盖 判定条件覆盖要求设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次， 并且每个判断本身的判定结果也至少出现一次。对丁图2 2 ，使用4 组测试用例( x = 0 ，y = 2 ， z = 3 ) 、( x _ 3 ，) ，= l ，捌) 、( x - 3 ，) ，= 2 ，减