回归测试范文
时间：2023-02-23 12:56:53
回归测试范文第1篇
关键词：软件测试；回归测试
中图分类号：TP311.52文献标识码：A文章编号：1007-9599 (2011) 03-0000-01
Regression Testing of Software Testing
Fan Xuedong
(Xi'an Foreign Affairs University,Xi'an710077,China)
Abstract:Regression testing despite the tedious,repetitive,but it must do the test,whether to take automated testing tools,or other test method is the problem discussed in this article.In this paper,the nature of regression testing,discusses the key,importance and testing methods,have their academic and practical significance.
Keywords:Software testing;Regression testing
一、概述
所谓回归测试就是当软件发生改变时，重新测试已经通过测试的测试区域，以验证修改的正确性及其影响。在软件开发生命周期中，软件发生改变，就会带来问题。改变可能是源于发现了错误并做了修改，也有可能是因为集成或维护阶段加入了新模块。错误跟踪与管理系统不完善；对错误的理解不透彻，只修正了错误的外在表现，从而造成修改失败；修改还有可能产生副作用，从而导致软件未被修改的部分产生新的问题；新加入代码还有可能对原有代码带来影响。因此，我们就必须重新测试，以便确定修改是否达到了预期的目的。同时，为了验证修改的正确性及其影响就需要进行回归测试。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
二、测试的大部分工作是做回归测试，软件一旦作了修改就必须进行
项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。回归测试需要时间、经费和人力来计划、实施和管理。在给定的预算和进度下，需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。
（一）首先必须有个管理良好的测试用例库，用例库中的所有用例必须有效，达到足够的覆盖率。这需要有良好的测试管理工具，并有相应的资源（时间与人力）去维护这个测试用例库，使其中没有过时，冗余的测试用例。如何管理组织好测试用例库是一个值得深入研究的课题，要做好回归测试，组织管理良好的测试用例库是前提。测试用例库的维护为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或新版本软件会添加新的功能或者变化。同时，被修改的或新增添的软件功能，仅靠重新运行以前的测试用例不行，必须追加新的测试用例来测试。
测试用例库维护是一个连续的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括：（1）删除过时的测试用例。因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。（2）改进不受控制的测试用例。随着软件项目进展，库中的用例会不断增加，会出现对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，影响测试效率。（3）删除冗余的测试用例。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库，并将冗余的用例删除掉。（4）增添新的测试用例。程序段、构件或关键的接口在现有的测试中没有被测试，就应该开发新测试用例。不仅改善了测试用例的可用性，而且也提高了测试库的可信性，同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。
（二）回归测试的实质在于它是一个能够检测到回归错误的受控实验。回归测试包的选择在软件生命周期中，即使一个得到良好维护的测试用例库，也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。当测试组选择缩减的回归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，如果采用了代码相依性分析等安全缩减技术，就可决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：（1）再测试全部用例。选择基线测试用例库中的全部测试用例组成回归测试包，这是比较安全的方法，它具有最低遗漏和风险，但测试成本最高。往往超出我们的预算和进度。（2）基于风险选择测试。可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，其严重性也仅有三级或四级。（3）基于操作剖面选择测试。若基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可由测试预算确定，优先选择针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别风险，有助于尽早发现那些对可靠性有最大影响的故障。（4）再测试修改的部分。当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。
再测试全部用例的策略是最安全的策略，但过时回归测试不太可能揭示新的错误，而且由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可选择适当的策略进行缩减的回归测试。
（三）实际工作中，回归测试需要反复进行，回归测试的基本过程有了测试用例库的维护方法和回归测试包的选择策略。回归测试可遵循下述基本过程进行：（1）识别软件中被修改的部分；（2）从原基线测试用例库中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T。（3）依据一定的策略从T中选择测试用例测试被修改的软件。（4）若必要可生成新的测试用例集T1，用于测试T无法充分测试的软件部分。（5）用T1修改后的软件。第b和第c步测试验证修改是否破坏了现有的功能，第d和第e步测试验证修改工作本身。
三、结论
（一）无论采取何种策略，回归测试是必须的一种测试。回归测试时我们必须采取一些较为有效的方法。例如安排新的测试者完成手工回归测试，让更有经验的测试者开发新的测试用例，做一些探索性的测试。但最重要的就是基于实际可行的引进自动化测试，因为机器不会累。实际中，回归测试的重复将非常令人厌烦，因此，需要通过自动测试来实现重复的和一致的回归测试，提高回归测试效率。
（二）在测试软件时，应用多种测试技术是常见的。测试时，测试者希望采用多于一种回归测试策略来增加修改软件的信心。如果回归测试包不能达到所需的覆盖要求，必须补充新的测试用例。回归测试是重复性较多的活动，容易使测试者感到疲劳和厌倦，降低测试效率，在实际中可以采用一些策略减轻这些问题。可以在不影响测试目标的情况下，鼓励测试者创造性地执行测试用例，变化输入、按键和配置能够有助于激励测试者又能揭示新的错误。
（三）回归测试需要根据项目、测试资源等实际情况采取有效计划和组织。其中需要注意的是必须重视回归测试，在测试计划中有很好的进度安排及选择相应的回归，重视测试用例的维护，借助于自动化工具。在组织测试时需注意：首先是各测试阶段的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。其次，测试期间应对软件版本冻结，将测试发现的问题集中修改，集中回归。建议将回归测试与兼容性测试结合起来。在新的配置条件下运行旧的测试可以发现兼容性问题，同时也可以揭示编码在回归方面的错误。
参考文献：
[1]贺平.软件测试教程.电子工业出版社,2010,1
回归测试范文第2篇
［关键词］ 软件架构（SA）； 可靠性系统； 回归测试； 分析
doi : 10 . 3969 / j . issn . 1673 - 0194 . 2012 . 13. 031
［中图分类号］ TP311.5 ［文献标识码］ A ［文章编号］ 1673 - 0194（2012）13- 0055- 02
1 回归测试背景
首先由于软件总在时刻变化着，软件的不断演化，例如软件的开发、维护、升级都需要修改一些软件的结构和代码，而人类对软件的要求也从未停止过。软件的每次改变都会引入潜在的风险，这是软件演化的缺陷。其次，人类对软件变化有了一些新的要求，关心软件修改后的功能是否达到预期以及原有的功能是否被损害［1－3］。
针对以上要求，选择使用回归测试来解决。回归测试是一种验证已变更系统的完整性与正确性的测试技术。
2 回归测试的定义及意义
回归测试是对之前已测试过、经过修改的程序进行重新测试，以保证该修改没有引入新的错误或者由于更改而发现之前没有发现的错误。
回归测试的意义是：（1） 保证软件维护时未更改的代码功能不会受到影响。（2） 保证软件模块区域和持续维护过程与回归测试的协作关系，使得回归测试成为一个每月、每周、每日的常规活动。（3） 实现软件整个生命周期的测试。
3 回归测试
首先简单介绍传统的基于代码的回归测试选择方法的作用，以便了解软件架构回归测试选择方法的基础。关注于选择性的回归测试方法，然后再重新采用相同的逻辑步骤来提出一种基于软件架构的回归测试方法（在第四部分提出）。
回归测试的目的在于验证修改的软件并确定不会在先前测试的代码中出现新的错误。传统的方法是把它分解为两个阶段。（1） 测试软件P相对于一种指定的测试集T。（2） 当推行了一种新版本P′时，对已修改的版本P′的回归测试提出P′相对于测试组T′是正确的可靠性。
在最简单的回归测试方法中，有一种叫做复制所有的测试。T′中包含T中的所有在T中的测试用例，并且P′ 运行在T′上。在回归测试选择方法上，T′被选出作为一种跟T相关的子集，假设有t∈T，t包含于T′，如果它有可能在P′中生成的结果与在P中不同。对不同回归测试选择方法的实证研究和分析在文献［4］中提出，加上对不同行为的识别需求。
本文着重研究如何为P′选择一种相关的测试用例子集，又叫做回归测试选择问题，描述一种回归测试选择方法，它是在软件架构层面上而不是在代码层面上。换句话说，用选择架构化的层面测试用例代替选择代码层面的测试用例。
4 基于软件架构的回归测试
基于软件架构的回归测试包含以下两个阶段：（1） 基于软件架构的测试。特别地，应用一种基于软件架构的一致性测试方法。（2） 基于软件架构的回归测试选择。这个阶段被分解以满足目的1和目的2。
图1总结了基于软件架构一致性和回归测试所需要的行为。本文主要研究基于软件架构的回归测试。
4．1 基于软件架构的一致性测试
这项工作是基于软件架构一致性测试的一般框架的，目的是测试已给出的软件架构实施的一致性。
这个框架分为5个步骤，如图1中间的部分所示。
第0步：它开始于软件架构规范的拓扑学和行为学，这里的行为通过一种基于机器的形式体系状态来模仿。下面，利用标签的过渡（LTS）来模仿组件的行为。
第1步：提出了一个通过观测得到的方法为了实现一种测试标准，这种标准来源于与测试目的相关视角在软件架构中，而是把无关的行为从这个视角中隐藏起来。标签的过渡（LTS）模型被提取出来，就产生了一种抽象标签的过渡（ALTS），用来说明只有这样高层的行为／组件是需要测试的。
第2步：一种基于架构层面的测试用例（ATC）以架构事件的有序序列被定义了，这种事件是当一个确定的初始事件执行的时候期望发生的架构事件。此定义分解为两个关键词：行为序列，它代表了所期望的行为和初始事件，它是允许发生的结构化输入。获得一个ATCs充分集合需要得到一个合适的包含了ALTS完整路径的集合［5］。
第3步：自然地，这样的ATCs与可执行的代码层面测试用例截然不同，因为在软件架构和代码之间的差距。处理这个问题通过一种“绘图”方法，它能够将软件层面函数的测试转化为代码层面测试用例。
第4步：最后，代码运行在可识别的测试用例上。通过分析执行的踪迹来决定系统在所选择的结构测试中实施得是否正确，采用结构化的模型作为一种测试数据库来识别代码用例成功或失败。
这样的方法已经得到公认，但是重复的测试行为对于系统的发展而言无疑花销太大了，因此需要以更少花销开发一种基于软件架构的测试方法。本文提出一种方法来处理系统的发展，重复使用原始的测试结果来重新测试已修改的结构并以更少的花销来完成。
4．2 目的1：测试对于初始软件架构P′的一致性
让假设基于软件架构一致性的测试已经提出P符合已给出的软件架构的一致性。当P进化到P′之后，如何来测试P′对于相同架构的一致性。采用的方法是将基于软件架构测试方法和现存的基于代码的回归测试方法相融合的。通过一种行为图表，代码层面的回归测试能够与基于软件层面的一致性测试相融合来选择一个新的测试套组T′：
A： 产生图表P，大多数普通的用于代码回归测试的方法是为了通过图表来结构化地表达P。在修改之后，P′也被描述成一张图表。在软件架构中，图表也通过组合成分行为的LTS模型来获得，同时在结构中结构化那些成分组织。
B：把GP和GP′相比较，在基于回归测试的传统代码中，通过比较P和P′的代码图表，识别代码的改变怎样影响到图表中。在软件架构中，这种改变根据在LTS中节点和边来识别。
C：记录覆盖范围，通过测试用例的执行测试历史记录被构建出来。通过测试用例在P上执行代码的过程，记录一连串的节点／电弧。
D：测试用例选择P′。从测试历史和图表比较中积累的信息被应用于识别将要在P′中再次运行的T中的测试用例。如果在t∈T中P的执行包含了在P′中修改的节点，那么t需要在P′中重新运行。
一旦T′被选择了，t′∈T′就在P′中运行并把结果收集起来，然后和一种数据库相比较来确定测试是失败还是成功。与基于传统代码方法的一种主要的区别是，在基于软件架构回归测试的数据库是软件结构自己本身。事实上，当t′在P′中运行的时候，如果它的执行不允许所期望的情况再次出现，那么测试会失败。更多情况，代码层面的测试用例总是被形式化的函数和结构化的需求驱动得很好。
期望从这个方法中得到的好处有两层：（1） 作为传统的回归测试，为P′减少了测试套组的规模，剪掉了所有在P′中不需要被再次应用的那些测试。（2） 当发现了一致性错误的时候，能够搜集关于如何来适应初始架构的信息。
4．3 目的2：测试进化得到的架构的一致性
让再次假设基于软件架构一致性测试已经声明了P的实施应符合已给出的软件架构。采用的方法是根据比较两者的架构的规范来识别软件结构改变／未改变的位置。结构和行为的改变都被考虑在内。特别的，对于S和S″的LTSs被比较之后的区别通过两张图表（利用一种“diff”算法）来识别。在一次与基于回归测试传统代码相似的改革中，无论什么时候一个ATC在S″中被修改的LTS软件架构中遍历一次的时候，它需要在S″中重新测试。图1（最左边）总结了目的2如何通过不同的行为被意识到。
a： 新的软件架构规则。演变的系统S″被结构化的规则提出。
b： 测试标准。测试标准（之前应用在S中）被用在S″上。
c： 比较。架构的规则与识别出的拓扑改变相比较（也就是增加的／删除的组件或修改的配置）和行为的改变（也就是经过改变的部件）
d：为S″选择结构化的测试用例。那些来自于软件架构的被结构的改变影响的ATCs被选择在P″上重新测试，为了S″的实施。注意到任何在这步丢弃的ATC都可以代表很多被消除的代码层面的测试用例，因此很大程度上减少了重复测试的花销。
e： 识别代码层面测试用例。一旦已经识别了需要用在S″中的回归测试ATCs，为了S″需要把架构的测试用例转化到代码层面的测试用例，以便为了P″选择T″。这一步类似于在第三步中基于软件架构的测试。
回归测试范文第3篇
关键词:回归测试风险管理修改影响分析
1、引言
在软件测试过程中,由于需要对软件进行修改,修改后的程序必须重新测试,以确保程序的修改是否达到了目的和是否引入了新的错误,这种测试就是回归测试。软件的变化可能是源于发现了错误并做了修改,也有可能是因为在集成或维护阶段加入了新的模块。当软件中所包含的错误被发现时,如果对错误的跟踪管理系统不够完善,可能会遗漏对这些错误的修改;而开发人员对错误理解的不够透彻,也可能导致所做的修改只修正了错误的外在表现,没有修改错误本身,甚至可能产生副作用,从而导致软件未被修改的部分又产生新的问题,使本来正常的功能产生错误。同样,在有新代码加入软件的时候,除了新加入的代码中有可能含有错误外,新代码还有可能对原有的代码带来影响。因此,每当软件发生变化时,我们就必须重新测试现有的功能,以便确定修改是否达到了预期的目的,检查修改是否损害了原有的正常功能。因此需要进行回归测试。
回归测试是一种代价较高,比较耗时的测试方法,然而又是必不可少的。大型软件通常规模大,系统结构复杂,构成要素多、层次多,在渐进和快速迭代开发中,新版本的连续使回归测试的实施更加频繁。因此,通过选择正确的回归测试策略来改进回归测试的效率和效果,减小回归测试代价是非常有意义的。
2、大型软件回归测试面临的问题
大型软件回归测试面临两个重大难题:一是系统变更引起的回归测试范围无法准确界定;二是参数组合引起的测试用例急剧膨胀,无法在较短时间内以合理成本完成最低覆盖率要求的回归测试。而且大型软件回归测试往往受到测试时间和测试环境条件的约束,而测试的工程性质又决定了它不可能达到理论上的完整。
在有限的时间和资源条件下,为了更合理的规划和安排测试工作,在测试计划的制定阶段需要一个决策机制能够在资源约束,如时间、人力、成本的前提下基于风险管理和测试成本预算进行决策。
随着软件生命周期的推进,软件的开发与回归测试反复迭代,规则的表达逐渐完善,测试用例库越来越丰富,回归测试的实施效率将越来越高。
3、大型软件回归测试方法
通过构建回归测试决策支持平台可以为大型软件的回归测试提供可行的解决方案。
3.1业务规则
业务规则是定义和约束业务结构与业务行为的规定或规范,是业务运作和管理决策所依赖的重要资源。建立大型软件业务规则模型正是要继承资深测试专家所积累的业务知识,使事实上得到使用的规则有一种显式的表达。在此基础上,结合测试理论和规则的整合以及用例优化算法,建立自动化用例生成系统。
业务规则的来源一般包括:
1.业务需求导出的规则;
2.测试理论原则导出的规则;
3.软件业传统导出的规则;
4.业内常识导出的规则。
业务规则模型的基础是手工测试中积累的一系列用例设计规则、行业规范和源于业务的特殊约束。业务规则模型用于表达这些手工时代的规则,并建立一种可加载规则的引擎结构,在通过该引擎加载规则后,可以通过决策支持系统生成面向某个具体过程的用例模板的基础用例集。
所谓规则的加载,是将某条规则加入规则库中,重点是适用条件的表达和优化算法的指定。
对于一个目标系统,一次穷尽所有可能的规则是不可能的,只能渐进地逼进,所以应该允许手工追加规则,这一过程是业务规则模型的学习过程。
3.2修改影响分析
对于软件回归测试来说,确定修改影响的范围是至关重要的,修改的影响范围也是回归测试的目标范围。如果无法确定修改的范围,则理论上说就得把整个系统重测一遍,对于大型软件,这种代价也是巨大的。
3.3成本风险评估
如何在有限的时间和资源预算下,更合理的规划和安排测试工作。回归测试在实践中往往受到测试时间、测试成本、人工投入和测试对象业务关键性等约束,因此需要制定一个科学的测试计划,以保证在满足各种条件约束的前提下能够确保测试质量。
Boehm 用公式RE=P(UO)*L(UO)对风险进行定义,其中RE表示风险或者风险所造成的影响,P(UO)表示令人不满意的结果所发生的可能性,L(UO)表示糟糕的结果会产生的破坏性程度。
因此,被测试对象f中存在的风险值 Re(f)的大小可以用出错的概率与出错的代价的乘积来表达:
Re(f) = p(f)*l(f)
确定待测试对象风险因素发生的可能性及其造成的损失的过程是风险估计阶段。将风险发生的概率与风险发生造成的损失相乘,可以得到每个测试对象的风险值。
为了方便对风险进行定量的估计,采用等级评定的方法对出错代价和出错概率进行表达。其中风险概率由模块成熟度和开发人员的出错预期共同计算。确定开发方的出错预期的依据是过往的缺陷率记录,在没有缺陷记录时,所有的开发人员度成熟度都默认为高,此后,个人成熟度分值随着个人缺陷率对平均缺陷率的相对值和个人缺陷率趋势而变化。
根据风险值的估算,可以确定待测试对象的最低测试深度。在测试深度的要求下,首先选择适当强度的测试用例简约算法进行试算,可以得出完成该对象测试需要的用例数。
由于回归测试中大量用例可以复用,计算实施成本是需要对自动生成的测试用例和手工完成的测试用例区分对待,以不同的权重进行计算,最终得出整个测试过程的实施成本。实施成本可以表示为测试投入的人时数。根据实施成本与项目预期成本投入和时间进行比较,判断待测试对象的成本是否在可以接受的范围里,如果可以接受,就可以根据相应简约算法生成最终需要的测试用例库。如果实施成本无法接受,可以重新调整用例简约算法,降低或者提高测试强度,重新计算实施成本,直到满足预算要求。
4、结论
回归测试研究有着广阔的空间,尤其对于系统结构复杂,构成要素多的大型系统软件回归测试,本文提出的自动化回归测试方法,对于降低回归测试代价,提高回归测试质量和效率具有及其重要的作用。
参考文献:
[1]孟微,罗省贤.面向行业应用的回归测试方法研究.应用技术与研究
[2]Boehm B.Software Risk Management:Principles and Practices[J].IEEE Software,1991,01.
[3]雷海虹,缪力,张大方.面向对象程序的两种修改影响分析方法.计算机工程与科学.2005.5.
[4]胡顺仁,蒋西明,周登义.面向对象系统的回归测试研究.重庆工学院学报.2005.5.
回归测试范文第4篇
关键词：交互 测试用例 优化 故障检测率
中图分类号：TP311 文献标识码：A 文章编号：1007-9416(2012)05-0201-03
1、引言
在软件开发和维护过程中，随着软件模块化水平的提高，软件的回归测试显得越加重要。然而，大规模、高频率的修改软件也使得回归测试的成本不断增加。因此，解决这一矛盾的重要方案就在于优化测试用例[1]。优化测试用例是指在保持一个较高的、稳定的故障检测率的基础上减少一组测试用例中案例的数量。回归测试中传统优化用例的方法将源码分成两个部分，一部分用于实际测试，而另外一部分则用于软件模块之间的交互。但传统的优化测试用例的方法正面临着新的挑战。例如，现有商业组件COTS的源码通常很难获取得到。另外，对大型软件的源码覆盖率进行分析不仅难度大，而且成本太高。这些问题都限制了现有优化用例方法的使用。因此有必要提出一个无需访问源码的测试用例优化方法。
本文提出了一种基于回归测试的测试用例优化方法。该方法包含一组接口函数，在软件执行过程中，通过使用该方法，可以分析出模块之间的交互过程。该方法不需要对函数源代码访问，也不需要监控模块交互过程，更加不需要对其他模块进行源代码分析，从而显著地增加了该方法的适用范围。
2、优化算法的描述
为了解决现有测试优化方法的不足之处，本文提出了一个新的测试用例优化算法。该算法是一种基于两个软件模块间交互过程的回归测试方法。该方法是对一个测试用例间模块交互“行为”的模拟，不需要访问或监控源代码。
2.1 两个模块之间的互动模式
为了模拟模块间的交互行为，新的优化算法定义了一组模块的接口函数，使其在软件测试阶段被调用执行，且新算法在使用接口函数的时候将考虑函数的传递和参数的传递。
假设有两个模块，模块A和模块B，两个模块之间的交互，通过模块B的接口完成。因此，定义：
(1)接口函数：构成一部分模块接口的函数。
(2)测试用例t的交互记录：模块B的一组接口函数，在测试案例t的执行过程中由模块A调用。假设，这些函数的名字和在调用过程中传递给它们的参数值，或者依照调用次序发生的值，体现了函数的功能。
(3)长度为k的接口函数序列：一个长度为k的连续序列表示一条交互记录。
(4)接口函数的序列集合，相当于案例t 中模块A和模块B之间的交互集合——一组包含所有可能性的长度为K的序列集合，代表了案例t中A和B之间所有的交互记录。本文使用“滑动窗口”技术[5]（窗口的大小等于K）构建这组长度为K的序列的集合。
在这些定义的基础上，本文定义了案例t中A模块和B模块之间的交互模型，该模型表示上文所说的序列集合。
2.2 交互模型的等价关系
对于上面定义的模块之间的交互模型，本文可以定义一个等价关系。文献[6]给出了定义两个交互行为模型之间的关系为等价关系的公式：
这里M1，M2表示被比较的模型；S1，S2表示长度为K的序列；FK1，FK2表示带有参数m的函数，其中前n个参数是文本，其它参数是数值；name（FK）表示函数FK的名称;δ（name（Fi），name（Fj））表示函数fi和fj之间的等价关系；xi,yi,i=1…n表示函数Fk1和Fk2的文本参数的值；δ（x，y）表示文本参数x和y的等价关系；xi,yi,i=N +1……m表示函数Fk1和Fk2数值参数的值；interval（x）表示数值参数x所属区间的序号；δ（interval（x），interval（y））表示数值参数x和y之间的等价关系。
文献[6]中给出了这个等价关系的详细解释。在这里，可以总结为：两个给定模型的序列集相等时，即认为它们是相等的，否则不等。当两个函数接口序列调用的元素相匹配时，两个序列被认为是相等的。因此，以下3个条件都成立时，即认为函数f1和f2是相等的：(1)函数具有相同的名称，(2)文本参数的值是相同，和(3)数值参数的值属于相同的区间。
2.3 算法描述
该优化测试用例的算法由以下几点组成。首先，该测试启动相同的接口函数序列，在测试模块交互时也使用这组序列；其次，该测试不启动任何模块间的交互；再次，该方法是基于假设和过滤掉的个体测试，它既不产生新的接口函数序列，也不调用接口函数。因此，按照假设，可以使用传统思路去测试交互性。
通过在上一节建立的模块交互模型，提出了以下算法：
MS’=;S’=;
while (S not empty)
{s=get_next_test_from(S);
Ms=build_interaction_model(s);
if (Ms is empty)then continue;
if (Ms MS’)then
{MS’=MS’∪{Ms};
S’=S’∪{s};
}
}
S-原始测试用例;
S’-优化后的测试用例，S''S;
S-原测试用例中的下一个测试案例;
Ms-测试用例s的交互状况模型;
MS’-优化后测试用例S’的交互状况模型集合。
(1)首先，从原测试用例中读取下一个测试案例并执行;
(2)在程序执行的过程中，建立了测试用例s的模块交互模型Ms，如果Ms为空，程序返回到第一步;
(3)然后，判断Ms是否属于交互模型集合MS’;
(4)如果Ms不属于MS’，那么Ms加入到MS’，案例s加入到优化用例S’;
(5)当测试用例S耗尽时，程序停止，S''表示该算法工作的结果，即优化后的测试用例。
判断模型Ms是否属于交互模型集合MS’，我们将使用等价关系。这点非常重要，尽管本文讨论的是带参函数的情况，但是这个等价关系当适用于所有能定义等价关系的函数（带参或者不带参）。
2.4 收集交互记录
为了实现该方法，需要一种技术来收集软件组件之间的交互作用记录。许多平台和编程环境提供这样一个机制，可用于收集函数调用记录，而无需访问源代码。这些机制只需要有关的函数特征的信息。例如：在Linux操作系统下，一个由连接器ld提供的拦截函数调用的机制[6];在Windows操作系统下的Detour tool[7];.NET和Java平台自身都内置了这样一种机制，可以允许拦截函数调用，而无需对二进制程序或对象代码实行监控。
在本文的实验中，实验测试了用C语言编写的主应用程序并且在Linux操作系统下运行，测试是通过连接器ld提供的一种机制完成的。这种机制仅需要接口函数的特征信息、一个主程序目标代码入口、主调函数、模块（上例中的模块B）以及那些不需要消耗资源的模块或者模块源码的说明。
3、实验以及结论
本文中的优化测试用例方法主要有两个特点：
(1)测试用例优化的百分比。这一特点体现了一个优化法优化测试用例的能力。
(2)故障检测率。这一特点显示了一个测试用例的故障检测能力。优化后测试用例的故障检测率和原测试用例保持一致或者几乎一致是非常重要的。
以前的实验的实验结果表明：本文的方法可以在不降低故障检测率的基础上提高测试用例的优化率。但这些结果仍然不能说明在集成回归测试中使用优化后的测试集比使用原测试集更能节省资源。在这个实验中，除了提高测试用例优化率和故障检测率，还测量了运行回归测试所需的时间资源。为了做到这一点，本文提出了一个附加的特征，表示了回归测试中优化后测试用例和原测试用例的增益。
3.1 实验环境设置
在这个实验中，本文选用了一系列的测试用例，这些用例是在Linux Standard Base（LSB）规范下，由linux候选作业系统LSB Application Battery v.3.1[8]产生的。本次实验的实验环境采用的是SuSE Linux v10.2。调用接口函数的次数为6次，Xlib库[9]V.11版本和标准C库用作模块整合。
LSB Application Battery v.3.1测试用例本质其实是符合LSB规范的应用程序的集合，这些应用程序由LSB工程提供并用于测试候选作业系统是否满足LSB规范要求。LSB Application Battery的具体任务之一就是测试LSB所有的库函数。基于这个原因，LSB Application Battery所选择的所有的函数库都受到LSB标准的严格约束。Xlib库是c语言函数库的一个子函数库，实现了一个与X Window系统协议相连的接低级别的C语言接口。Xlib库是LSB规范v.3.1必备的函数库之一，并作为网络传输系统x windows系统的一部分。
本文采用一个标准库函数的子集来实现Xlib的库和标准C库之间的相互作用进行测试。该子集定义在stdio.h头文件中，主要负责输入/输出功能。本文还采用X Window X11R6.9.0版的Xlib库、标准c语言库的glibc库作为具体实现。
3.2 实验指标与实验步骤
在实验前，本文收寻了17个分布在Xlib库源代码的不同地方的人为集成错误，由于Xlib库源码主要负责通过输入/输出程序与标准C语言库进行交互,人为错误与文献中提到的变异集成分析相似，创建了错误的样例，这些样例又将错误引入函数的输入/输出参数，并得到错误的函数返回值。并且这些参数被错误的加入到参数列表中，继而影响模块之间的交互。本文使用以下指标：(1)优化后测试用例的大小;(2)优化测试用例的百分比;(3)检测到的故障数量;(4)故障检测率（％）;(5)回归测试的时间;(6)回归测试优化后时间减少的百分比。
实验的第一步：收集模块交互的记录和建立模块交互的模型。要做到这一点，需要重新编译Xlib库函数对glibc库的接口函数调用的拦截；第二步：实验执行对LSB Application Battery v.3.1测试用例的测试，并建立交互模型；第三步：实验使用本文的测试用例优化算法，建立优化后的测试用例，并且开始分析和对比两种测试用例的指标。包括：优化后测试用例与原测试用例的大小、优化后测试用例与原测试用例测试的百分比、优化后测试用例与原测试用例测试的故障检测率以及优化后测试用例与原测试用例发现的错误数量。
3.3 实验结果
实验结果列于表1：
表1 两种测试用例指标对比
结果表明，新的算法减少了原测试用例的88.9％（即9分之一），从而导致测试时间减少了88％，而测试用例的故障检测能力保持在原测试用例相同的水平，优化后的测试用例检测到的错误数量与原测试用例相同。
4、结语
在本文中，给出了一个新的基于回归集成测试的测试用例优化的算法。除了测试用例优化这个主要特性之外（例如测试用例优化百分比和故障检测率），新的算法在计算机资源的消耗上也获得了改进。结果表明，基于回归集成测试的优化测试用例方法具有良好的可行性。
参考文献
[1]林木,戴月明.回归测试中测试用例集优化方法的研究.计算机工程与应用,2011,47(11):54-56，163.
[2]高静,兰雨晴,金茂忠.一种基于运行时交互约束的COTS构件集成测试用例生成方法.计算机科学,2009,36(3):261-265.
[3]杨建军,陈卫东,叶澄清等.面向组件的接口变异测试方法.浙江大学学报(工学版),2003,37(2):129-133.
[4]Rountev A，Kagan S，Sawin J. Coverage Criteria for Testing of Object Interactions in Sequence Diagrams. Lecture Notes in Computer Science，2005，3442：289-304.
[5]Steven A Hofmeyr，Stephanie Forrest，Anil Somayaji. Intrusion Detection using Sequences of System Calls. Journal of Computer Security，1998，6：151-180.
[6]Dmitry Kichigin. Test Suite Reduction for Regression Testing of Simple Interactions between Two Software Modules. Proceedings of Spring Young Researchers Colloquium on Software Engineering,2007,vol.2:31-37.
[7]Hunt G，Brubacher D. Detours: binary interception of Win32 functions. Proceedings of the 3rd USENIX Windows NT Symposium，1999,7：135-143.
[8]Linux Standard Base Application Battery pages.
www.省略/appbat/.
[9]徐浩刚,何星,张文渊.多线程环境下X-Window程序设计.计算机工程,2000,26(1):56-60.
作者简介
欧阳陈华(1978-)，男，湖南衡阳人，研究生，主要研究方向：软件测试和平行计算。
*基金项目
回归测试范文第5篇
关键词： 回归测试； 测试用例； 神经网络； BP网络
中图分类号： TN711?34 文献标识码： A 文章编号： 1004?373X（2015）19?0114?03
Abstract： Regression testing means after modifying the source code， re?testing to confirm whether the discovered defect is repaired， and whether detection and modification have brought in a new bug or caused the errors in other codes which possesses a large proportion of the workload during testing procedure. The fundamental principle of neural network is analyzed， and the thought of BP algorithm is introduced into the case set selection of regression testing. The algorithm to select regression testing case package is presented. The functions which may be influenced by code modification are screened out by samples training， and the higher priority use case can be screened out. A set of regression testing strategy with high efficient and easy operation was summed up through the accumulation of testing practice.
Keywords： regression testing； testing case； neural network； BP network
0 引 言
软件分析，设计过程中难免有各种各样的错误，需要通过测试查找错误，以保证软件的质量。软件测试是由人工或计算机来执行或评价软件的过程，验证软件是否满足规定的需求或识别期望的结果和实际结果之间有无差别。大量统计资料表明，软件测试工作量往往占软件开发总量的40%以上。而回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续使回归测试变得更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，研究回归测试方法，尽可能地将软件存在的问题找出来，对保证软件质量和提升测试工作效率都是非常有意义的。
1 相关工作
1.1 回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试时，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包实现回归测试。
在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例，时间和成本约束可能阻碍运行这样一个测试，有时测试工作不得不选择一个缩减的回归测试包来完成回归测试。
1.2 相关技术的研究
测试用例的优化技术旨在以小的运行代价尽可能多地发现系统Bug。假设测试用例是能发现缺陷的；测试用例的运行效率是一样的。测试用例的集合的选取不仅是减少用例的数目，降低用例的执行代价，也需要考虑测试覆盖能力，即缺陷发现能力。在测试用例选择优化的问题上，已有很多文献对此进行了研究，如配对测试法[1]、关系树模型[2]、蚁群模拟退火算法[3]及一些其他新的理论和方法[4?7]。
2 回归测试用例集生成方法
2.1 基本原理
神经网络是通过对人脑的基本单元――神经元的建模和联接，探索模拟人脑神经系统功能的模型，并研制一种具有学习、联想、记忆和模式识别等智能信息处理功能的人工系统。
神经网络的一个重要特性是它能够从环境中学习，并把学习的结果分布存储于网络的突触连接中。神经网络的学习是一个过程，在其所处环境的激励下，相继给网络输入一些样本模式，并按照一定的规则（学习算法）调整网络各层的权值矩阵，待网络各层权值都收敛到一定值，学习过程结束，从而以新的方式响应环境。
2.2 BP神经网络
Back?Propagation Network，由于其权值的调整采用反向传播（Back Propagation）的学习算法，因此被称为BP网络。网络中心思想是梯度下降法，通过梯度搜索技术，使网络实际输出值与期望输出值的误差均方值最小。网络的学习过程是一种误差边向后传播边修正权系数的过程。一般分三层：输入层（Input Layer），隐层（Hide Layer），输出层（Out Layer），也可以有2层或更多个隐层。层与层之间采用全互联方式，同一层单元之间不存在相互连接，如图1所示。
由于神经网络具有自学习、自组织和并行处理等特征，并具有很强的容错能力和联想能力，因此，神经网络具有模式识别能力。在神经网络识别中，根据标准的输入输出模式对，采用神经网络学习算法，以标准的模式作为学习样本进行训练，通过学习调整神经网络的连接权值。当训练满足要求后，得到知识库，如图2所示。
BP算法的具体步骤如下：
（1） 用小的随机数对每一层的权值[W]初始化，以保证网络不被大的加权输入饱和；
（2） 计算网络各层输出矢量以及网络误差[E；]
（3） 计算各层反传的误差变化并计算各层权值的修正值以及新权值；
（4） 再次计算权值修正后误差的平方和；
（5） 检查误差是否小于给定误差，若是，训练结束；否则继续。
输入信号[Xi]通过中间节点（隐藏层节点）作用于输出节点，经过非线性变换，产生输出信号[Yk，]网络训练的每个样本包括输入向量[X]和期望输出量[t]（类别），网络输出值[Y]和期望输出值（真值）[t]之间的偏差，通过调整输入节点与隐藏层节点的连接强度取值和隐藏层节点与输出节点之间的连接强度以及阈值，使误差沿梯度的方向下降，经过反复学习训练，确定与最小误差项对应的网络参数（权值和阈值），训练即告停止。学习样本的数量和质量影响学习效果和学习速度。
为了训练一个BP网络，需要计算网络加权输入矢量以及网络输出和误差矢量，然后求得误差平方和。当所训练矢量的误差平方和小于误差目标，训练则停止；否则在输出层计算误差变化，且采用反向传播学习规则调整权值，并重复此过程。当网络完成训练后，对网络输入一个不是训练集合中的矢量，网络将给出输出结果。
2.3 回归测试用例包选取
基于全量的测试用例库，回归测试包的选择策略可遵循下述基本算法进行：
（1） 识别出软件中被修改的部分。
（2） 从原基线测试用例库[T]中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库[T0。]
（3） 依据一定的策略从[T0]中选择测试用例测试被修改的软件。
（4） 如果必要，生成新的测试用例集[T1，]用于测试[T0]无法充分测试的软件部分。
（5） 用[T1]执行修改后的软件。
在上述步骤中，第（2）和第（3）步测试验证修改是否破坏了现有的功能，第（4）和第（5）步测试验证修改工作本身。第（3）步中，将神经网络知识结合到测试领域，通过对样本的学习，确认修改没有引入新的错误或导致其他代码产生错误。
其主要思想为：对于[q]个输入学习样本：[P1，P2，…，Pq，]已知与其对应的输出样本为：[T1，T2，…，Tq。]通过网络的实际输出[A1，A2，…，Aq]与目标矢量[T1，T2，…，Tq]之间的误差来修改其权值，使[Al （l=1，2，…，q）]与期望的[Tl]尽可能地接近，使网络输出层的误差平方和达到最小。
3 回归测试实践的优化
在项目测试过程中，不仅需要应用高新的测试技术，也要从宏观上制定可行的测试策略，解决在有限的时间中使测试覆盖率最优化。本文从项目实践角度出发，提出以下的回归测试策略：
（1） 对所有已修复Bug进行验证；
（2） 对新增功能进行全量重点测试；
（3） 对原有功能，按优先级进行测试。基于一定的风险标准从基线测试用例库中选择回归测试包。首先运行最重要、关键和可疑的测试，而跳过那些非关键、优先级别低或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也较低，不影响系统的功能。一般而言，测试从主要特征到次要特征。
（4） 对修复的Bug可能会引入新的Bug的功能模块重点测试，可采用本文介绍的神经网络进行样本训练和用例筛选。将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。
（5） 如果情况允许，测试全部用例的策略是最安全的策略。但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。
4 结 语
将神经网络知识引入到测试领域是一个比较新的研究，本文就此方向进行了研究，并给出了实例说明。然而，BP神经网络需要大量的样本数据用来训练和测试，当样本数量不够时，预测的误偏差可能会较大，回归测试开始时，由于数据样本不足，可能会存在预测的偏差，所以下一步的研究方向将是如何克服这一问题。
参考文献
[1] 廖剑锋，蔡贤涛.组合测试中用例集的选择策略[J].计算机工程与应用，2012，48（11）：65?70.
[2] 钮鑫涛，聂长海，CHAN Alvin.组合测试故障定位的关系树模型[J].计算机学报，2014，37（12）：2505?2518.
[3] 聂长海，徐宝文，史亮.一种基于组合测试的软件故障诊断方法[J].东南大学学报：自然科学版，2003，33（6）：681?684.
[4] 徐宝文，聂长海，史亮，等.一种基于组合测试的软件故障调试方法[J].计算机学报，2006，29（1）：132?138.
[5] YILMAZ C. Covering arrays for efficient fault characterization in complex configuration space [J]. IEEE Transaction on Software Engineering， 2006， 32（1）： 20?34.
[6] 郑燕妮，李志蜀，李奇.蚁群模拟退火算法在测试用例约简中的应用[J].计算机工程，2009，35（2）：197?199.
回归测试范文第6篇
【关键词】系统测试；信息系统；监理；要点
中图分类号：P208 文献标识码：A 文章编号：
前言
随着我国信息化工程的加速推进，在项目的信息化过程中引入了第三方监理。其主要职能是对软件信息系统进行监理工作。主要负责测试系统，达到项目验收的目的，在监理测试信息系统的过程中，系统测试工作的规范化，标准化，科学化，有利于信息系统测试结果的准确性的提高。本文针对信息系统测试中监理的要点进行分析，指出了监理工作的重点及重要性。
二、信息系统测试的流程和关注点
1.信息系统项目测试的流程
从信息系统监理的角度，信息系统项目中测试的流程基本分两步进行，第一步，承建单位进行的测试;第二步，项目小组(建设单位、监理单位、承建单位)进行的测试。
图1 信息系统项目测试的流程
2.系统测试的关注点
(一) 信息系统的类型
信息系统，从项目建设的角度可以分为纯开发系统和二次开发配置系统。纯开发系统是指根据用户需求，采用某种编程语言(如Java、JSP)和某种开发工具(如eclipse)，从零基础开始编写代码实现的系统。二次开发配置系统是指在成品软件(如Oracle DIM、Oracle BIEE、Oracle CRM、Oracle EBS、Oracle iLearning等)的基础上，根据用户需求，进行配置开发实现的系统。
(二)纯开发系统
纯开发系统的质量与开发人员的技术水平、开发风格、对系统需求目标的理解等因素有很密切的关系，导致纯开发系统的测试工作任务繁重，其关注点也很多、很细。从监理的角度，假定系统基本包含用户需求的所有功能点，纯开发系统测试时的关注点，可以概括为：(1)系统界面布局的合理性、美观性;(2)系统每个组件、控件的有效性、合理性;(3)系统流程逻辑的合理性;(4)具体功能的实现方式的最优性;(5)开发代码的可阅读性等。
(三)二次开发配置系统
二次开发配置系统的质量部分取决于所基于的软件产品的质量。进行二次开发配置系统测试时的关注点，可以概括为：(1)系统组件、控件的有效性;(2)系统流程逻辑的合理性等。
与纯开发系统的区别，主要体现在(1)系统界面的整体布局基于成品软件产品，细节部分可以二次干预;(2)系统组件、控件的合理性也基于成品软件产品，不建议二次干预(系统升级后，一切恢复为成品软件原始状态);(3)编写开发代码的工作量比纯开发系统的工作量少。
系统测试中监理要点分析
1.信息系统测试中监理的工作
(一)审核承建单位的单元测试报告、集成测试报告、自测报告(总集成测试报告)及回归测试报告；
(二)审核承建单位提交的系统测试计划、系统测试方案(包含测试用例)；
(三)根据测试计划和测试方案，制定系统测试记录表，包括功能测试记录表、性能测试记录表、回归测试记录表，三方讨论确认后执行；
(四)协助业主方、确定性能测试指标，三方签字确认后执行；
(五)根据测试记录表，出具测试结果分析报告(功能测试结果分析报告、性能测试结果分析报告、回归测试结果分析报告)，其中，功能测试结果分析报告和性能测试结果分析报告作为回归测试的依据；
(六)汇总测试结果分析报告，出具初验系统测试报告。
2.平台的系统测试
平台经过需求调研分析、概要设计、详细设计、二次开发配置、差异化分析及修正、自测等阶段之后进入项目初验阶段，承建方提交初验申请，批准后，业主方、监理方、承建方组成平台初验的系统测试小组对平台进行系统测试，包括功能测试、性能测试及回归测试。
(一) 功能测试阶段
平台的系统测试的功能测试部分的流程，可以概括为：
(1)监理方根据承建方提交的测试方案，制定《功能测试记录表》包含需求分析说明书中的所有功能点和项目合同文件中的所有功能模块；
(2)按照测试方案(含测试用例)，采用手动测试的方式，一边测试一边记录测试情况；
(3)监理方对功能测试记录表进行分析，形成《功能测试结果分析报告》，包含通过测试的功能点及模块、未通过测试的功能点及模块、计划完成功能点及模块数与实际完成功能点及模块数的比较、存在的问题及建议；
(4)承建方根据功能测试结果分析报告，制定《回归测试记录》确定初验阶段回归测试的内容及终验时需跟进的内容，三方讨论通过后执行。
(二)性能测试阶段
平台的系统测试的性能测试部分分别采用人工方式和工具测试两种方式进行。该阶段的流程，可以概括为：
(1)测试小组讨论确定《性能测试指标》，包括对CPU利用率(＜=80％)、在CPU利用率允许范围内的最大并发用户数、吞吐量、疲劳强度(12小时)、响应时间、内存页交换率等指标的要求规定；
(2)监理方根据承建方提交的测试方案，制定《性能测试记录表》包含功能性、可靠性、易用性、效率、可维护性、可移植性六个方面；
(3)在功能测试完成时采用人工方式，进行以上六个方面的性能测试，填写性能测试记录表；
(4)监理方汇总性能测试记录表，形成《性能测试结果报告》；
(5)根据性能测试指标，采用工具测试的方式，对平台进行负载压力测试，生成测试报表；
(6)承建方对测试报表进行分析，形成《性能测试分析报告》，提交监理方审核，审核通过后性能测试结束。
(三)回归测试阶段
平台的系统测试的回归测试主要是指对功能测试的回归测试，该阶段的流程，可以概括为：
(1)按照测试方案和《回归测试记录》中确定的内容对平台进行回归测试，并将结果记录在回归测试记录中；
(2)监理方对回归测试记录结果进行分析，形成《回归测试结果分析报告》，包括本次通过测试的内容、还需改进在终验时跟进的内容、在用户培训时需重点跟踪的内容、平台上线后需进行深化的内容；
(3)将回归测试结果分析报告和回归测试记录中约定的需在后期跟进的内容汇总整理形成《工程备忘录》，作为对项目初验的补充。
(四)系统测试报告
平台的系统测试u引经历功能测试、性能测试及回归测试之后基本结束，监理方汇总整个测试过程中产生的文档，形成《系统测试报告》及附件，附件包括《功能测试结果分析报告》、《性能测试指标》、《性能测试结果报告》、《性能测试分析报告》及测试报表、《回归测试结果分析报告》、《工程备忘录》。
四.系统试运行中监理的工作要点
系统试运行是为了检查系统的稳定性、适用性等。一般情况下监理方在这个阶段的主要工作有：
1.审核竣工文档资料的完整性、可读性及一致性；
2.审核软件环境配置与设计方案的符合性；
3.检测验证系统功能性能与合同的符合性；
4.检查人员培训计划落实情况；
5.出具阶段性验收报告；
6.帮助用户制定系统运行管理规章制度；
7.在保修期内定期或不定期对项目进行质量检查、督促承建方按合同要求进行维护。
本阶段，软件开发的工作告一段落，重点在于解决试运行工作中暴露出来的各种问题，和系统交付用户前的各项准备工作。一般情况下， 目前业内第三方软件功能、性能测试均在本阶段进行。
五、结束语
信息系统监测监理工作是一份技术含量高，智力高等优质素质的工作，他是多种科学领域综合交叉的产业，软件工程监理是一门技术含量高，智力、知识密集型的产业，信息系统监测是多种科学技术领域的综合交叉的产业，涉及到国民经济的各个领域，因此，本文着重分析系统监测监理的工作要点，有助于监理们更清晰的把握工作职责，让系统检测工作得到有的放矢的开展。
参考文献：
[1] 宋丽华，张建成，任强等.软件需求评审监理要点分析[J].信息技术与信息化.2011年第4期：71-73.
回归测试范文第7篇
关键词：可靠测试；优化；数据分析
高质量且高可靠性的企业应用程序系统是数字化时代非常重要的元素[1]。测试团队在确保企业应用程序系统满足既定标准或需求时会发挥非常重要的作用。随着系统的规模和复杂性升级，其可靠性和质量要求必然成倍增长，这意味着测试团队需要开发更有效的测试方法。一个完整的测试过程包括数据记录、数据维护、数据验证等多个方面。测试数据管理策略对于测试数据的记录必须是全面的，这也为后期的数据分析挖掘提供了支撑。
陈翔等人在文献[2]中重点阐述了回归测试中用例优先排序（test case prioritization，简称TCP）问题。从源代码、需求和模型三个角度对TCP问题进行分类，重点分析了回归测试中测试资源缺乏时的TCP问题。另外，潘伟丰等人在文献[3]中提出了基于错误传播网络的测试用例排序方法。该方法在类粒度将软件抽象成加权类依赖网络（weighted class dependency network， 简称WCDN）模型，并基于WCDN分析错误在网络上的传播行为，构造错误传播网络（bug propagation network，BPN）。实例研究表明，基于错误传播网络的测试用例排序方法在错误检出率上相比于其他经典方法有一定的提高，并且具有较好的稳定性。一个全面的用例排序方法，能准确地将当前的软件质量反映到执行用例的优先级上[4-5]。通过使用正确的TCP策略测试团队能够提供及早发现缺陷，在整个产品开发过程中，为提供更简单的方法去解决系统缺陷提供支撑。因此，拥有正确的TCP策略对测试团队乃至公司都至关重要，能加快系统周期并大幅削减成本。然而在现有的研究工作中，TCP策略问题主要集中在回归测试阶段，但是回归测试处于整个测试过程的末端[6]。由于回归测试时对于本系统缺陷分布情况有非常清晰的概念，但是由于处于末端，对于测试团队的优化毕竟有限。同时测试团队与研发团队往往是单线交流，即研发团队待测系统，测试团队极少参与提高研发团队的开发质量。
因此，可以从测试用例执行策略和测试结果反向优化开发策略两个方面展开研究，并提高系统可靠性。测试用例执行顺序问题是测试执行策略中非常重要的部分，在测试项目中持续优化测试用例执行顺序可以提早发现潜在的缺陷。同时由于测试团队对于项目整体的理解更为透彻，对缺陷的总体分析可以帮助研发团队在类似问题上处理地更为妥善。测试团队在需求分析阶段的有效介入，将从源头上提高系统的质量和可靠性。
1 测试执行策略优化
测试中的关键问题是第一时间发现被测系统不符合规范要求的内容。测试经理在测试规划时是通过大量的测试用例保证测试的覆盖率。持续优化测试用例执行顺序是在保障测试覆盖率的同时，合理地安排测试用例地执行顺序，即TCP问题。文章提出将项目测试分为三个阶段，在项目测试的初期、中期、后期三方面分别进行优化TCP，最终优化整个测试执行策略。
如图1 所示，项目测试初期，分析测试用例的历史数据得到测试用例的执行潜在价值，优先执行潜在价值高的测试用例。比如在其它项目中执行某些用例时，发现了系统不符合规范要求的部分，并提交了缺陷。在新的测试用例执行时，应首先执行这类测试用例以便快速发现系统缺陷。项目测试中期，分析本项目当前缺陷情况得到各个系统功能模块的缺陷发生概率。优先执行缺陷分布较多的功能模块相关的测试用例。项目测试后期，即回归测试阶段，需结合各个系统功能模块在本项目和历史项目中的缺陷发生概率，在保证一定回归比率的情况下，综合考虑本项目和历史项目的分析，优先回归测试缺陷发生概率较高的模块。
2 需求分析优化
项目测试工作通常被安排在项目研发工作之后，测试团队的主要工作也仅仅是将测试结果中发现的缺陷情况报告给研发团队，并没有对缺陷情况进行分析，可能使得类似的缺陷在不同的项目中反复出现。因此测试团队在提供测试报告的同时，对各个功能模块中所发现的缺陷进行分析，并在新项目立项初期给出系统模块开发时的缺陷概率，帮助研发团队在需求分析阶段重点考虑高缺陷概率的模块开发和模块间的协作，从源头上降低缺陷发生的概率。测试团队与研发团队的双向反馈将优化产品设计的需求分析阶段，提高系统的可靠性，如图2所示。
图2 测试团队和研发团队双向通道
3 结束语
文章从优化测试用例执行顺序和测试结果优化需求分析两个方面，阐述了现在系统开发中提高系统可靠性的重要方法。测试数据的管理是一座金矿，对测试数据的深入分析可以让整个测试过程不再是静止的，而是可以动态调节以应对更复杂的情况，同时深入分析测试结果也可以建立测试研发的双向通道，形成良性循环。最终可以超预期地提交高质量的系统，节约运营成本，完成市场抢占。
参考文献
[1]K.Krishna Murthy， Janardhana S Channagiri， "test data management： Enabling reliable testing through realistic test data"Building Tomorrow's Enterprise， Oct 2009.
[2]陈翔，陈继红，鞠小林，等.“回归测试中的测试用例优先排序技术述评”[J].系统软件与软件工程，2013（8）.
[3]潘伟丰，李兵，周晓燕，等.“基于错误传播网络的回归测试用例排序方法”[J].计算机研究与发展，2016（3）.
[4]朱海燕，范辉，谢青松，等.“测试用例排序的研究”[J].计算机工程与科学，2008（1）.
[5]潘伟丰，李兵，马于涛，等.“基于复杂软件网络的回归测试用例优先级排序”[J].电子学报，2012（12）
回归测试范文第8篇
关键词:FPGA;硬件驱动层;嵌入式软件测试;样卡;回归测试
Function Testing of Hardware Driver Layer in Contactless IC Card
ZUO Jie
(Shanghai Huahong Integrated Circuit Co.,Ltd. )
Abstract:With wide use of contactless IC card application, new challenges to the effectiveness and practicability of embedded software function testing arise. A function testing of hardware driver layer in contactless IC card was proposed in this paper. Online testing on the FPGA platform and regression testing method of sample cards were included. Based on the theory of embedded software testing methods, we chose feasible functional testing methods for testing of hardware driver layer. Test cases were designed and then sample card regression testing methods were determined. Finally according to test environments and actual project situations an appropriate test platform was selected.
Key words:FPGA; Hardware Driver; Embedded Software Test; Sample Card; Regression Test
1引言
随着非接触式IC卡使用越来越广泛,特别是金融类卡、身份认证类卡的使用,高层次的安全保护已成为非接触式IC卡广泛使用所必须考虑的重要因素。一种常用的安全保护手段是在用户COS(Chip Operating System,片上操作系统软件)与硬件层之间添加硬件驱动层(Hardware Driver,Hwd),从而完全屏蔽上层应用COS对于硬件资源的直接操作,也就从软件上隔离了对于硬件资源的攻击风险。
本文探讨了非接触式IC卡硬件驱动层的功能测试方法,包括在FPGA平台上进行在线测试以及样卡的回归测试方法。本文作者以嵌入式软件测试方法理论为基础,确定在进行硬件驱动层测试时可使用到的功能测试方法,并依此设计测试用例;然后,确定样卡的回归测试方法;最后,根据测试环境以及实际项目情况,选择一种合适的测试架构。
本文研究中所基于的非接触式IC卡使用的CPU为ARM公司的SC100。该CPU基于32位的ARM7架构设计,并采用RISC指令,内置ROM、RAM作为程序和数据的存储,并且采用EEPROM作为数据或程序的断电存储。另外,该芯片集成了定时器和看门狗、时钟生成、随机数生成、中断控制器、DES算法、RSA算法、ECC算法、安全控制、RF接口等模块。用户COS将通过Hwd层来实现对这些功能的使用。
2硬件驱动层(Hwd)简介
Hwd层(如图1所示)位于硬件和用户COS之间,它与用户COS一样拥有单独的ROM和RAM空间,不同的是,Hwd层运行在ARM处理器的特权模式,而用户COS运行在ARM处理器的用户模式[1]。用户COS通过CPU的软中断机制来调用Hwd提供的功能函数,从而实现对硬件资源的访问。
Hwd为固化在非接触式IC卡芯片只读存储器(ROM)中的二进制Bin文件,由两个子系统组成:
(1) 硬件驱动接口子系统:包含有异常向量表、内存布局初始化代码、初始化用户程序的执行环境程序和特权模式变更用户模式代码。
(2) 硬件驱动功能子系统:包含有功能入口句柄列表、功能模块主体(包含功能调用参数检查)和特权模式变更用户模式代码。如图2所示。
3功能测试用例的设计
不论是嵌入式软件测试还是普通的软件测试,它们的中心任务都是验证和确认其设计实现是否符合需求要求,在验证过程中发现系统的缺陷[2]。与一般的软件测试一样,嵌入式软件测试方法也可分为两类,即静态测试和动态测试。动态测试又可分为黑盒测试和白盒测试。黑盒测试又叫做功能测试或数据驱动测试。
采用黑盒技术设计测试用例的方法有:等价类划分方法、边界值分析方法、错误推测方法、因果图方法、判定表驱动分析方法等。
3.1 测试用例设计方法
在对Hwd的测试中我们选择使用等价类划分方法、边界值分析方法以及错误推测方法来设计测试用例:
(1) 等价类划分方法:等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试,因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类[3]。
(2) 边界值分析方法:是对输入或输出的边界值进行测试的方法[3]。
(3) 错误推测方法:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性地设计测试用例的方法[4]。
例如:函数参数的正确取值范围为0～100,如图3所示,可划分为两个无效等价类以及一个有效等价类,边界值除了需要考虑到0和100以外,还需要考虑到0与100分别减1和加1后的数值:-1、1、99以及101。错误推测方法则取决于经验与直觉,假设在其他类似项目中出现过取值为99.0001这样的小数时程序出现错误的情况,则本次测试设计中也可以添加类似的测试用例。
3.2 测试数据来源
Hwd提供了DES算法、RSA算法、ECC算法以及大数运算(例如:2048位数据的乘法运算、1024位数据的模乘运算)的功能函数,对于这些函数的测试首先要保证所设计的输入输出测试数据的正确性。本文采用的是OpenSSL软件包作为测试数据的来源。
OpenSSL由加拿大的Eric Yang等发起编写,是一个开源的软件包,采用C语言作为开发语言,实现了SSL(Secure Socket Layer,安全套接层协议)及相关加密技术。OpenSSL的最新版本为openssl-0.9.8k.tar.gz。以大数运算为例,该软件包的crypto/bn目录下的文件实现了各种大数运算,我们可以编写一个图形用户界面的测试数据生成工具,该工具通过调用OpenSSL文件中相应的功能函数来完成测试数据的生成。
4样卡的回归测试方法
将每个测试用例都写成一个main.c文件,并分别与测试工程编译成可执行文件,即一个测试用例就是一个可执行文件。在FPGA平台上在线测试时,编译成的可执行文件为ELF格式的映像文件,该文件通过ARM调试仿真器下载到ROM中来执行,而在样卡回归测试时,则需要编译成可下载到EEPROM或RAM中的二进制Bin文件。
在研究中,为了向用户演示芯片的基本功能,我们开发了一个DemoCos用于演示,样卡的回归测试就要用到这个DemoCos的指令。一共会使用到3条指令,分别为:写EEPROM指令、写RAM指令以及跳转指令。由于写指令支持的是16进制的数据,故首先要将二进制Bin文件数据从二进制转换成16进制,以下为样卡回归测试的两种方法:
(1) 首先,使用写EEPROM指令将测试程序下载到一块空闲的可供用户使用的EEPROM空间。例如:如图4所示,从地址0x91000开始写,写完后,使用跳转指令跳转到该地址,开始执行测试程序,执行完成后便可在上位机程序中看到测试结果。复位卡片或非接触式读卡机,重复以上操作,完成下一个测试用例的测试。
(2) 与下载到EEPROM空间的方法类似,可使用写RAM指令将测试程序下载到一块空闲的可供用户使用的RAM空间来完成测试。例如:如图4所示,将测试程序写到地址0xB0000。特别需要注意的是,由于RAM空间有限,DemoCos以及固化在芯片中的发卡程序都需要使用到RAM空间,故余下的空闲空间很小,所以,要求测试程序的大小加上变量使用的空间大小要小于RAM空闲空间的大小。
从以上对于样卡两种回归测试方法的描述,对比可知,使用将测试程序下载到EEPROM的方式更加恰当,即下载到RAM空间的方式可作为备份方式,当芯片的EEPROM损坏时使用。
5测试方案
5.1 测试结果验证
所有的测试用例均需要对结果进行验证,验证的思路有两种:
(1) 对所测函数的输出数据进行验证,例如:算法类的函数,可设计输入以及输出的测试数据来对函数进行测试;
(2) 对无法通过输出数据来验证结果的函数,可通过读取函数执行后所修改的寄存器位值来验证,例如:
该函数操作的对象为随机数控制寄存器的[2]:参数close取1,则往随机数控制寄存器的[2]写入1 ;参数close取0,则往随机数控制寄存器的[2]写入0。由于Hwd需要掩膜到芯片中,所以在进行前期设计时会尽可能减少代码量,以避免过多占用芯片资源,故只要参数close取值为0或1,则程序将值进行写入操作后便直接返回SUCCESS,不会进行校验,所以在测试中不仅要验证该函数的返回值是否正确,还需要验证对于相应寄存器位的写入值是否正确。
在FPGA平台上进行在线测试时,要达到上述目的并不困难,因为,在ADS1.2包含的仿真调试器AXD中便可对寄存器值进行查看或修改,但这样的操作为非代码实现,需要人工干预,这大大降低了测试的自动化程度;而在样卡的回归测试中,则无法对寄存器进行这样的操作。为解决这个问题,需要在Hwd中增加测试用函数,该函数的功能为可对所有寄存器进行读写操作,特别需要注意的是,测试用函数必须在Hwd通过研发阶段FPGA平台上的在线测试以及样卡回归测试后、提交大规模流片前删除。
5.2 测试方案
每一个Hwd的功能函数均有一个独立的软中断号,用户COS是通过软中断指令(SWI)发起Hwd函数调用,从而间接对硬件进行操作,完成需要的功能。故在进行Hwd的功能测试时,测试程序就是在模拟用户COS对Hwd功能函数的调用,验证相应的硬件操作是否成功。
在设计测试架构时,样卡的回归测试是重点考虑的方面。在FPGA平台上进行在线测试时,可在仿真调试器AXD中调试测试程序,查看被测Hwd函数的返回值以及寄存器、RAM等芯片资源的情况,而在样卡的回归测试中则无法跟踪查看到此些情况,故设计思路如下:
(1) 首先,定义一个数组,然后,将测试结果保存在数组中,最后,通过Hwd中RF模块的收发数据函数将该数组的所有元素值发送到上位机程序,从而获得测试结果。以上文中的RFreshSeed函数为例:
int ret, i;
unsigned char key = 0;
unsigned int close = 1;
unsigned chartest_result[10];
unsigned charresult _fail = 0xFF;
//赋初值
for(i=1; i
{ test_result t[i] = i; }
//运行被测函数RFreshSeed,并对返回值进行验证
ret = RFreshSeed (close);
if( ret != 0)
{ test_result [1] = result _fail;}
//计算数组元素值为0xFF的个数,并赋值给test_result[0]
for(i=1; i
{
if(test_result [i] == 0xFF)
{ key = key + 0x01;}
}
test_result[0] = key;
最后,调用Hwd中RF模块的收发数据函数将该数组的所有元素值发送到上位机程序:
若测试通过,则上位机程序收到的数据应为:00010203040506070809
若测试未通过,则上位机程序收到的数据为:01FF0203040506070809
(2) 考虑到样卡回归测试时,需要将测试程序下载到芯片中执行,所以测试程序的大小以及变量对于RAM空间的使用都要尽可能的小。将每个测试用例写成一个main.c文件,然后与测试工程编译成可执行文件,即一个测试用例就是一个可执行文件,就解决了这个问题。
5.3 测试环境
对于Hwd的功能测试将在两种测试环境中进行,本文中使用的操作系统平台为Windows XP Professional:
(1) Hwd的研发阶段:需要在FPAG平台上采用在线方式进行测试,在FPGA平台上连上ARM调试仿真器,通过仿真器将测试程序下载到ROM中,然后可对SC100上运行的测试程序进行实时检测、观察以及设置断点进行调试,并可实时更改寄存器、RAM以及EEPROM等数据。测试环境如下:
硬件:
测试用PC机一台
FPGA仿真平台 一套
非接触式读卡机一台
ARM调试仿真器:Smart-ICE 一台
软件:均运行在PC机上
ADS1.2集成开发环境
ARM Multi-ICE V2.2
上位机程序
(2) 样卡的回归测试阶段:此时,Hwd已掩膜到样卡的ROM中,需要将测试程序写入到EEPROM或RAM中执行,方可完成相应的测试工作。测试环境如下:
硬件:
测试用PC机一台
非接触式读卡机一台
软件:运行在PC机上
上位机程序
其中,非接触式读卡器以及上位机程序一般为公司自行研发的产品,这样便于根据项目的实际情况,在研发与测试中调整与修改这两项产品,以使其更适合具体项目的使用。
6结论
本文探讨了非接触式IC卡硬件驱动层的功能测试方法,包括在FPGA平台上进行在线测试以及样卡的回归测试方法。本文作者以嵌入式软件测试方法理论为基础,确定在进行硬件驱动层测试时可使用到的功能测试方法,并依此设计测试用例;然后,确定样卡的回归测试方法;最后,根据测试环境以及实际项目情况,选择一种合适的测试架构。通过在实际工作中的使用情况表明,所设计的功能测试方法行之有效。
下一步的工作将在已有基础上,对非接触式IC卡硬件驱动层进行自动化或半自动化功能测试,以及开发自动化测试工具方面进行研究。
参考文献
[1] 王宇行, “ARM程序分析与设计”, 北京航空航天大学出版社, 2008年3月.
[2] 康一梅, 张永革, 李志军, 胡江, 吴伟.“嵌入式软件测试”. 机械工业出版社, 2008年7月.
[3] 文斯测试技术研究中心.“测试用例设计白皮书”. www.省略/
[4] 飞思科技产品研发中心, “实用软件测试方法与应用”, 电子工业出版社, 2003年8月.
作者简介
回归测试范文第9篇
关键词：计算机；软件测试
中图分类号：TP311 文献标识码：A 文章编号：1007-9599 （2012） 18-0000-02
1 计算机软件测试的概念
所谓软件测试，主要是以发现程序错误为目的而执行程序的过程，是结合软件开发过程中每一个阶段的规格及软件内部的结构进行认真设计的测试用例。因此，我们可以说，软件测试就是在精心搭建的环境下对程序进行执行，以更好的发现软件中的错误，对其可靠性给出鉴定。
2 软件测试的流程
2.1 设计测试方案。设计测试方案是在软件测试初始阶段进行的，在这个工作中，首先要调研所需要应对的系统框架和业务模型，对测试需求进行收集。其次，根据测试需求制订一个合理的测试计划。具体来说，我们的测试团队要对被测试项目有着提前的了解，而且开发部门也要配合测试部门的工作，提供各种系统规格书、系统总体介绍、网络拓扑结构图、用户使用手册、系统配置说明、应用部署与配置以及关键服务器及等文档。经过与业务部门协商之后，就可以确定下来这次测试的目标，然后对这一目标进行细化，制定出各个阶段的目标，并制定相应的指标要求。
2.2 开发测试场景。这主要是指开发测试脚本，是针对被测系统业务进行模拟、录制、编程、参数化、脚本定制以及调试测的工作，通过测试场景的开发，可以使测试脚本实现对现实场景的真是模拟，而且我们还可以通过改变参数来控制并发数以及思考时间等属性。
2.3 执行测试。这主要是按照预先制订的测试方案，在完成测试环境以及测试场景之后进行的工作。
2.4 测试报告及分析。这一工作主要是在执行完测试之后进行的，主要的任务是对测试过程中所暴露的问题进行收集及分析。而测试报告则主要是对测试过程中监控报告以及报表的汇总，然后对其进行一定整理之后所得到的结论性文档。
2.5 回归测试。开发部门在分析了测试报告之后，会对软件的缺陷进行了修复或者优化，使其具有更高的性能，而对于这种修复之后软件的测试就是回归测试。
3 计算机软件测试的基本方法
3.1 按照阶段进行划分。如果按照阶段对计算机软件测试方法进行划分的话，则可以分为单元测试、集成测试、系统测试、验收测试、回归测试、Alpha测试以及Beta测试。
（1）单元测试。这主要是指对软件的基本组成单位进行测试，比如一个模块。单元测试是动态测试中最基本，也是最重要的部分，它主要的目的是对软件基本单元的正确性进行验证。在单元测试中，由于需要我们了解程序的设计及编码的细节，所以这一工作主要是由程序员进行。另外，单元测试还需要开发测试驱动模块以及桩模块进行辅助。在单元测试中，主要的方法包括控制流测试、排错测试、数据流测试以及分域测试等。
（2）集成测试。集成测试主要进行于软件系统集成过程中，它的作用是对单位之间接口的正确性进行检查。一般来说，根据计划，我们将在模块集成为较大系统的过程中运行该系统，查看各个组成部分是否合拍。在这个过程中，使用的策略有自底向上以及自顶向下这两种。
（3）系统测试。这主要是针对已经集成好的系统进行测试，进而对系统的性能及正确性进行检查。由于这一测试的整体难度比较大，我们要制定合理的计划，并严格按照计划执行测试工作。在系统测试工作中，主要的方法有随机测试、性能测试以及功能测试。
（4）验收测试。这种测试的目的是主要是对软件的购买者展示软件的性能，确保其符合购买者的需求。在这个过程中，测试数据主要来自于系统测试中使用的数据。这是软件在应用之前最后的测试。
（5）回归测试。上文中已经对其概念进行了简要的分析，这里将进一步对其进行分析。回归测试的主要目的是检测所进行的修改是否合理。在这个问题上，修改有着以下内涵：首先是修改达到了预期的目的，其次是修改不能够对软件其他功能的正确性产生影响。
（6）Alpha测试。这是在软件开发即将完成的时候所进行的测试，在测试之后，一般仍然会有一些设计上的变更，在这一测试工作中，测试人员主要是最终用户而不是程序员或者测试员。
（7）Beta测试。这是指在开发及测试在根本完成之后进行的测试，这种测试的工作一般由其他人员或者最终用户来完成，不可以由测试员完成。
3.2 按照按测试方法进行划分。按照测试方法进行划分则可以分为白盒测试以及黑盒测试这两种。
（1）白盒测试。这也被我们称之为逻辑驱动测试或者结构测试，是基于覆盖所有代码、路径、分支以及条件的测试。在白盒测试中，我们是清楚程序内部工作过程的，主要的目的是检测其内部动作是否符合规格说明书的要求，至于软件的功能是否符合要求则不属于这一测试的范畴。常见的白盒测试方法有逻辑驱动以及基路测试等。
在使用白盒测试方法的时候，测试者必须对程序的内部结构进行检查，并通过对其逻辑的检查得到测试数据。在这种测试方法中，存在着以下不足：首先，对于程序是否符合设计规范，或者说程序本身就是错误程序的情况，我们是没有办法检查的。其次，对于程序中因路径遗漏而导致的错误，我们无法检查。最后，某些和数据相关的错误我们没有办法检查。在这一具体的工作中，常使用的工具有Junit Framework，Jtest等。
（2）黑盒测试。顾名思义，黑盒测试和白盒测试是相反的。在黑盒测试中，我们的测试目的不是为了检查内部设计及代码是否正确，而是检查程序能否符合功能性方面的需求，因此，这种测试也被我们称之为数据驱动测试或者功能测试。
在测试的过程中，我们将完全不考虑其内部特性，只是将程序作为一个黑盒子看待，然后在其接口进行测试，具体的工作就是检查程序在接收到输入数据之后能否产生正确的数据输出信息。在黑盒测试方法中，常见的方法等价类划分、因—果图、边值分析以及错误推测等。
由于黑盒测试方法属于穷举输入测试，我们只有将所有的输入都当成测试情况使用之后才能够检查出程序中所有的错误，而实际的测试情况有无穷多个，因此，我们除了要有合法的输入之外，还要有不合法却可能的输入。一般常用的工具有WinRunner，Rational Robot，QuickTestPro等。
4 结语
由上文我们可以看出，软件测试中的环节比较多，而且方法也有很大的差别。因此，做好计算机软件测试工作并不是一件很轻松的事情，需要我们对各种软件测试方法了如指掌。所以，我们还要不断的学习，并加强探索，以一个严谨科学的态度去面对软件测试工作，只有这样才能真正的使软件发挥其应有的作用，进而提升企业的竞争力。
参考文献：
[1]何强.通信软件自动化测试系统的研究与实现[D].中南大学，2009.
[2]易涛.基于通讯的考务信息系统的设计与实现[D].华中科技大学，2009.
回归测试范文第10篇
Abstract: As an important phrase in software lifecycle,software testing is effective to ensure software quality. This paper analyses the basic ideas of present component testing techniques and discussed the research contents and problems. In addition, other aspects of component testingwere summarized.
关键词: 软件测试;构件测试;软件质量
Key words: software testing;component testing;software quality
中图分类号:TP311文献标识码:A文章编号:1006-4311(2010)16-0170-01
0引言
软件测试是软件生命周期的一个重要组成部分,它已不仅仅局限于软件开发中的一个阶段,它已贯穿整个软件开发过程。软件测试是信息技术的重要方面,是保证软件达到高质量和高可靠性的关键元素,在国内外受到广泛重视并已进行了多年的研究。
构件测试是软件测试的重要组成部分,是保证软件质量和可靠性的重要手段之一。在软件的开发过程中,不管在设计阶段采取什么样的质量保证手段,最终得到的系统都要进行测试,以验证是否达到了预期的设计目标。如文献[1]所述,在英国约克大学为英国海军开发的SHOLS项目中,尽管采用形式化方法描述和证明软件规约,并且采用程序正确性证明方法排除了软件开发前期的许多缺陷,单元测试仍然发现了整个软件开发过程15.75%的缺陷。
1构件测试
软构件技术把构架从系统逻辑中清晰地隔离出来,可以实现不同开发语言和平台的协作,组织大规模的开发,而且使得系统的开发周期更短、造价更低。基于构件的软件工程(CBSE)已成为软件工程领域的研究热点[2-3]。
构件的测试问题应该从构件的开发者与构件的使用者两个角度来看,主要是因为使用环境的不同、拥有资源的不同和测试目的不同。构件的开发者需要测试构件的所有功能,构件的使用者只关心与他有关的构件功能。目前的研究主要体现在以下方面:
1.1 研究构件测试策略新思想的提出文献[4]中蔡开元等人将软件构件测试问题转换为控制问题,将受控Markov链方法应用于软件构件,以实现在给定测试资源(测试时间、测试费用)内发现最多的构件失效;也有研究人员利用行为观测理论(behavior observation theory)实施构件的集成测试,并提出用于并发系统的观测模式公理;由于用UML建模表示的信息可给测试提供便利,文献[5]中研究人员从协作/序列图和状态图中提取构件间控制依赖和数据依赖信息,进而实施构件软件的集成测试。
1.2 构件测试体系结构的研究文献[6]中为了对构件进行有效的测试,提出一种形式化的构件模型框架,利用偏序事件多集来表示构件的行为模式;在文献[7]中作者描述了一种使用“validation agents”的方法,自动测试部署的构件,验证功能与非功能的需求是否满足。“validation agents”使用“component aspects”描述受影响的构件的功能和非功能横切面。
1.3 对构件软件的回归测试的深入探讨回归测试首先是回归测试范围的确定,通过对构件之间交互行为的图形建模表示,可以计算出变更构件所影响到的构件和接互。文献[8]中使用模块推理确定需要重新测试的构件集合。文献[5]中基于构件元内容(meta-content)的回归测试技术运用描述构件信息的元数据和用以计算或检索这些信息的元方法指导用例选择;文献[9]给出一种基于新的组件测试关联模型的组件系统回归测试方法。
1.4 构件测试其他方面的研究变异测试的研究可以解决构件的源码不可见以及异质性,导致测试构件软件时难以判定测试覆盖的充分性等问题;内省(反射)机制则为信息缺乏难以实施测试的构件提供了便利。此外,基于包装器的测试方法可增加为测试提供信息的方法或是限制使用某些功能以便于实施测试等。
构件测试目前在以下方面有待进一步研究:内建式测试中如何进行交换信息的表达、理解和提取等;将智能Agent技术应用于构件软件(特别是分布式构件系统)的测试;研制和开发自动化或半自动化的测试工具。目前国内对构件可测试性的研究还有很多问题需要解决,如缺少测试的统一标准,如何进一步提高测试性能等。
2总结
随着软件业的发展,人们对软件质量要求的不断提高,无论从工程上还是实验系统阶段,软件测试都会受到越来越多的关注和推广。构件、Web Services、Agent等新技术的应用为软件测试带来新的问题和挑战,也为软件测试的发展带来新的机遇,测试技术自身的不断发展也对软件开发方法学将产生影响。
参考文献:
[1]King S, Hammond J, Chapman R, et al. Is Proof More Cost-Effective Than Testing? IEEE Transactions on Software Engineering,2000,26(8):675-686.
[2]单锦辉,姜瑛,孙萍.软件测试研究进展.北京大学学报(自然科学版),2005,41(1):134-145.
[3]曹方,吴克明,郭福亮.面向构件的测试研究.海军工程大学学报,2002,14(2):96-99.
[4]Cai K Y, Chen T Y, Li Y C, Ning W Y, Yu Y T. Adaptive testing of software components. Proc 20th ACM Symposium on Applied Computing, 2005:1463-1469.
[5]毛澄映,卢炎生.构件软件测试技术研究进展.计算机研究与发展,2006,43(8):1375-1382.
[6]张晓东,柴跃廷,任守榘. 一种形式化的构件模型框架.清华大学学报(自然科学版),2000年,40(3):64-67.
[7]J Grundy,G Ding,J Hosking.Deployed software component testing using dynamic validation agents[J].The Journal of Systems and Software,2005,74(1):5-14.
[8]B W Weide. Modular regression testing: Connections to component-based software[c]. In:Proc of the 4th ICSE Workshop on Component-Based Software Engineering. Los Alamitos, CA: IEEE Computer Society Press. 2001.47-5l.