软件测试中回归测试

软件测试中回归测试（共10篇）

软件测试中回归测试 篇1

摘要：应用偏最小二乘回归方法, 考虑影响应力腐蚀敏感性指数的各种因素, 建立了应力腐蚀敏感性指数预测的模型, 通过计算, 预测结果较好, 对于探索316L不锈钢的应力腐蚀敏感性指数具有重要意义。

关键词：应力腐蚀敏感性指数,偏最小二乘回归模型,信息挖掘

316L奥氏体不锈钢与碳素钢相比, 具有较高的抗拉强度、较低的屈服点、极好的塑性和韧性, 而且焊接性能和冷弯成型工艺性能也很好, 所以被广泛用于制造各种储槽、塔器、反应釜等压力容器。作为不锈钢, 316L能耐多种介质的均匀腐蚀, 但在某些环境中 (特别是含Cl-介质) 的应力腐蚀开裂现象非常严重, 已成为不锈钢领域中急待解决的工程实际问题。影响316L不锈钢应力腐蚀开裂的介质因素具有特定性, 在酸性环境中主要因素有:Cl-浓度、H2S浓度、温度和p H值等。对其影响因素的关系, 已进行了广泛研究, 取得了许多研究成果[1,2,3,4,5,6]。文献[7]采用慢应变速率拉伸腐蚀试验方法, 研究Cl-浓度、H2S浓度、温度和p H值等参数单独和交互作用对316L钢应力腐蚀敏感性的影响, 并进一步对应力腐蚀敏感性指数进行统计回归分析。

偏最小二乘回归于1983年由S。Wold和C。Albano等人首次提出, 它集多元线性回归、典型相关分析和主成分分析的基本功能为一体, 将建模预测类型的数据分析方法与非模型式的数据认识方法有机地结合起来, 因此, 偏最小二乘回归较传统的回归分析、主成分分析具有更大优势, 能较好地处理基于传统最小二乘回归方法难以解决的问题, 在处理样本容量小、自变量多、变量间存在严重多重相关性问题方面具有独特的优势, 已广泛应用于诸多领域, 取得了良好的效果[8,9,10,11,12]。本文充分考虑影响316L不锈钢应力腐蚀敏感性指数的相关因素, 利用偏最小二乘回归方法建立模型, 挖掘影响因素中的信息。

一、偏最小二乘回归模型

在第一个成分t1和u1被提取后, 分别实施X对t1的回归以及Y对u1的回归。如果回归方程已经达到满意的精度, 则算法终止;否则, 将利用X被t1被解释后的残余信息以及Y被t1解释后的残余信息进行第二轮的成分提取。如此往复, 直到能达到一个较满意的精度为止。若最终对X共提取了m个成分, 偏最小二乘回归将通过实施yk对的回归, 然后再表达成yk关于原变量的回归方程 () 。

回归方程为

FAk是残差距阵FA的第k列。

二、应力腐蚀敏感性指数偏最小二乘回归分析

为了研究316L不锈钢应力腐蚀敏感性指数的影响因素, 记H2S的浓度为x1、Cl-浓度为x2、温度为x3, PH值为x4作为自变量x1 (i=1, 2, …, 8) F (A) 以应力-应变曲线下面积表示的应力腐蚀敏感性指数作为因变量y。

经交叉有效性检验, 计算得到, 因此取成分t1, t2, 模型的预测能力最好, 得到应力腐蚀敏感性指数偏最小二乘回归方程为:

图1给出了t1、t2与u1的平面图。从图1中可以看出, t1与u1存在明显的线性关系, t2与u1也存在着一定的线性关系, 但相对较弱。

为了验证模型的预测效果, 偏最小二乘回归模型验证应力腐蚀敏感性指数, 拟合结果如表2及图2所示。

从表及图中可以看出, 偏最小二乘回归模型预测较好的反映了应力腐蚀敏感性指数与影响因素的关系。

三、结论

本文应用偏最小二乘回归方法, 综合考虑影响应力腐蚀敏感性指数的各种因素, 建立了应力腐蚀敏感性指数预测的模型, 通过计算, 预测结果较好, 应用偏最小二乘回归方法, 对于探索316L不锈钢的应力腐蚀敏感性指数, 挖掘影响因素之间的信息具有重要意义。

参考文献

[1]OBERNDORFER M, KAESTENBAUER M, THAYERK.Application limit s of stainless steel s in the petroleum industry[C].USA:Soc Pet Eng (SPE) , 1999:395-403.

[2]HIBNER EDWARD L, FENDE D S.Conquer chlorides andalloy costs[J].Chemical Engineering Progress, 1999, 95 (4) :63-68.

[3]KANE R D, JOIA CJBM, SMALL ALLT, etal.Rapidscreening of stainless steels for environmental cracking[J].MaterialsPerformance, 1997, 36 (9) :71-74.

[4]BARKER JC, YU J, BROOK R, etal.Some environmental aspects of sulphide stress corrosion cracking stainless steels[C].USA:Int Soc ofOff shore and Polar Engineerns (ISOPE) , 1993:273-278.

[5]CHEN SH, YEH RT, CHENG TP, etal.Hydrogen sulphide stresscorrosion cracking of TIG and laser welded 304 stainless steel[J].CorrosionScience, 1994, 36 (12) :2029-2041.

[6]FANG Deming, LU Zhiming, GAO Zengliang.Stress corrosioncrack study of 316L stainless steel in H2S and Cl-aqueous solution[C].Spain:Spanish Council for Scientific Research, 2002:166.

[7]卢志明, 何正炎, 高增梁.316L不锈钢应力腐蚀敏感性指数计算与回归分析[J].浙江工业大学学报, 2007, 35 (2) :198-200.

[8]王惠文, 付凌晖.PLS路径模型在建立综合评价指数中的应用[J].系统工程理论与实践, 2004, 10:80-85.

[9]J.P.Gauchi.P.Chagnon, Comparison of selection methods ofexplanatory variable in PLS regression with application to manufacturingprocess data[J], Chemometrics and intelligent laboratory systems, 2001, 58:171-193.

[10]张伏生, 汪鸿, 韩悌, 等.基于偏最小二乘回归分析的短期负荷预测[J].电网技术, 2003, 27 (3) :36-40.

[11]李寿安, 张恒喜, 李东霞, 等.基于偏最小二乘回归的军用飞机采购价格预测[J].海军工程大学学报, 2005, 17 (4) :64-68.

[12]徐哲, 刘荣.偏最小二乘回归法在武器装备研制费用估算中的应用[J].数学的实践与认识, 2005, 35 (3) :152-158.

软件测试中回归测试 篇2

软件测试是一项批判性的工作，目的就是找出软件中的缺陷，这里暂时不去深究为什么要进行软件测试，以及软件测试带来的好处。只介绍软件测试中一些基本的测试方法。根据是否查看代码程序分为黑盒测试和白盒测试;根据是否运行软件又可分为静态测试和动态测试。

黑盒测试：又叫功能测试或行为测试，只需考虑各个功能，不需要考虑整个软件的内部结构及代码。

白盒测试：访问代码，通过检查代码的线索来协助测试。

静态测试：测试软件不运行的部分，只是检查和审核。

动态测试：使用和运行软件进行测试。

1、静态黑盒测试：检查产品说明书，并在软件编写之前找出问题

· 对产品说明书或软件需求报告进行高级审查：

(1)站在一个设计者的角度进行审查，找出根本性问题或遗漏之处

(2)站在客户(使用者)的角度来审查，因为软件质量的定义是满足客户的需求

(3)研究现有的标准和规范，可以是公司习惯用语和约定、行业要求、GUI、安全标准;检查所用标准是否正确、遗漏，是否与标准和规范相抵触

(4)审查和测试类似软件，检查它的规模、复杂性、测试性、质量和可靠性、安全性

· 对产品说明书或软件需求报告进行低层次测试：

一份优秀的产品说明书或者需求报告：必须是完整、准确、精确(不含糊、清晰)、一致、贴切、合理、代码无关、可测试性

2、动态黑盒测试：在不了解软件如何工作的前提下进行测试

两种基本方法：通过性测试和失效性测试

选择测试用例：等价类划分：把软件具有相似输入，相似输出，相似操作的分在一组，

一个等价类或等价类划分是指测试相同目标或者暴露相同软件缺陷的一组测试用例。

等价类划分的目标：把可能的测试用例集缩减到可控制且仍然足以测试软件的`小范围内。

(1)测试数据

通过性测试：

a) 边界条件：软件运行在计划操作界限的边界情况。测试边界包括测试临近边界的有效数据、测试最后一个可能有效的数据、测试刚超过边界的无效数据。

b)次边界条件：典型的次边界条件：2的幂、ASCII表

c)测试默认、空白、空值、零值和无这些数据

失效性测试：

d)测试非法、错误、不正确和垃圾数据

(2)测试状态

软件状态：软件当前所处的条件或者模式。

状态测试：测试程序的状态及其转换。

步骤：1)建立状态转换图

2)减少要测试的状态及其转换的数量

a. 每一种状态至少访问一次

b. 测试状态之间最不常用的分支

c. 测试所有错误状态及其返回值

d. 测试随机状态转换

e. 测试看起来是最常见和普遍的状态转换

通过性状态测试：审查软件，描绘状态，尝试各种合法可能性，确认状态及其转换正常。

系统软件测试中的测试需求分析 篇3

关键词：系统软件测试；测试；需求；分析

中图分类号：TP311

1 什么是测试需求

简单来说，测试需求就是确定在项目中需要测试什么。测试需求描述测试的目标，特别是描述了产品的质量需求，测试需求分析目的是帮助定义测试对象和测试范围，发现软件需求中不完善和不明确的地方并加以完善以节省测试时间的投入，便于软件需求基线化和跟踪业务需求的变更。

一条有用的测试需求是唯一的、精确的、有边界的、可测试的。例如：软件产品可能有这样一个测试需求“系统主要事务的响应时间能满足系统要求”。这就是一个不符合要求的测试需求，怎样的指标是“满足”？系统的要求又是什么都不清晰，测试就无法开展。

一个完整清晰的可测试的软件测试需求是这样的：在1G内存和1.73兆主频的计算机上在25个并发用户执行插入、更新和删除操作时端到端的响应时间在3秒时间内。符合标准的测试需求是存在一个明确的可预知的结果，可以通过某种方法对这个结果进行判断和验证

测试需求应覆盖已经定义的业务流程，功能及非功能方面的需求。

2 为什么要做测试需求分析

测试需求是测试计划的基础与依据，我们在测试活动中，首先需要明确测试需求（What），才能决定怎么测（How），测试时间（When），需要多少人（Who），测试的环境是什么（Where）。是衡量测试覆盖率的重要指标。

确立测试需求是为了保证测试质量与进度，测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。在软件工程项目中，存在一些普遍的现象例如：需求阶段的问题，到测试的最后阶段才被发现；开发、测试、市场等不同角色的人员对软件功能细节存在理解歧义。确立测试需求可以避免这些问题的产生。

3 什么时候开始做测试需求分析

软件生存期的各个阶段都可能产生错误。而软件需求分析、设计和实现阶段是软件的主要错误来源。因此一旦软件需求确定后，即可开始进行测试需求分析。

4 如何做测试需求分析

做测试需求分析有两个关键词，一个是“测试需求”，一个是“分析”，下面我从以下几个步骤来说明如何做测试需求的分析。

4.1 对软件需求说明书进行需求验证

一个良好的软件需求应当具有一下特点：（1）清晰性；（2）组织和完整性；（3）一致性；（4）可修改性；（5）可跟踪性；（6）可检验性；（7）接口：界面、接口的说明；（7）质量、性能属性；（8）可靠性；（9）软硬件；（10）特殊问题。

4.2 搜集和提取测试需求（包括隐性的需求）

测试需求并不等同于软件需求，它是从测试的角度出发并根据软件需求整理出一个测试列表，作为该软件的主要测试内容。提取测试需求要以软件需求说明书及规格说明书为依据，以业务功能为中心，深刻理解业务规则和隐式需求，通过与客户深入沟通，明确测试范围和质量目标，达到测试分析和设计全面、无遗漏。隐形需求包括：用户隐式的需求如业务规则；行业规范；编写人员的技术能力所限等。提取方法可通过列表的方式对软件开发需求进行梳理，先提取出所有的需求点。这些需求点可能存在重复和冗余，再根据项目的功能模块进行组织归类，删除重复的需求、细化测试粒度太大的需求、合并相关联的需求，最后根据业务规则及相关文档等，对测试需求进行检查和完善。测试需求主要通过以下途径来收集：（1）与待测软件相关的各种文档资料。如软件需求规格、Usecase、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。（2）与客户或系统分析员的沟通。（3）业务背景资料。如待测软件业务领域的行业标准及知识等。（4）正式与非正式的培训。（5）其他途径。

4.3 根据测试阶段和重点，整理测试需求

测试处于不同的阶段，测试的重点也是不同的，例如集成测试阶段主要是检验程序单元或部件的接口关系；系统测试阶段，重点是为了验证和确认系统是否达到了其原始目标，通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方。因此确立测试阶段和重点，才能在测试需求分析时，做到方向正确、目标明确。除了需要确保要求实现的功能正确，还要考虑软件的特性。银行/财务软件更强调数据的精确性，网站强调服务器所能承受的压力，ERP强调业务流程，驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型，并将其列入测试需求当中。关注测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解，从而得出的着重于某一方面的测试，如界面、业务流、模块化、数据、输入域等。系统功能测试需求分类：（1）业务功能测试需求；（2）可靠性测试需求；（3）安全性测试需求；（4）易用性测试需求；（5）可移植性测试需求；（6）可维护性测试需求。

5 测试需求评审

测试需求的评审是质量保证的必须步骤，通过评审可保证测试需求获得相关干系人的认可，做到有据可依。测试需求评审的内容包括完整性审查和准确性审查。完整性审查是检查测试需求是否覆盖了所有的软件需求、以及软件需求的各项特征，关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束、行业标准等。同时还要关注系统隐含的用户需求。准确性审查是检查测试需求是否清晰、没有歧义、描述准确，是否能获得评审各发的一致理解，在测试需求之间以及与开发需求没有矛盾和冲突，每一项测试需求都可以作为设计测试用例的依据。

测试需求评审的形式没有固定的要求，有条件可以采用正式的小组会议形式进行评审，在评审之前确定好参会人员的各个角色和相关的责任，确保评审之前参会人员已经拿到了评审材料并有了足够的了解，评审结束时以签名及会议纪要的方式把评审结果通知相关单位及人员。此方式的优点是有计划有组织地进行，评审更加有效和权威，缺点是需要协调相关人员时间及会议场地等，在很多实际项目中有较大难度。测试需求评审还可以采取非正式的走查和轮查形式，将需要评审的内容发给相关人员，收集他们的意见，并把统一意见修改确立后的测试需求再发给相关评审人员进行确认。这种方式的优点是方便有效，缺点是少了多方人员的讨论和沟通。对于大型的重要项目，可能还会采取正式审查方式进行评审，包含了制定评审计划、组织会议、会后跟踪分析审查结果等。参与测试需求评审的人员至少要包含：项目经理、开发负责人、测试负责人、系统分析人员、相关开发和测试人员。测试需求评审通过以后，才可以跟进测试需求来制定测试计划及编写测试用例。

6 测试需求维护

在实际的软件工程中，软件需求的变更是很常见的，甚至频繁变更软件需求。如果一直使用初始的测试需求来指导我们的测试工作，必然造成测试的结果存在错误和差异。因此必须及时维护测试需求，适应实际工作的需要。在需求变化频繁的情况下，作为测试人员，最重要的就是要搞清楚以下几点：（1）哪些需求发生了变化；（2）这些需求变化后，对测试工作会产生哪些影响。包括会不会影响测试用例，如果影响，会对哪些用例产生影响。当发生较大改动时，还要明确是不是影响到了测试需求？（3）明确这些变化，会对自己的工作进度产生多大的影响。（4）对于必须更改的测试需求变化，要及时更新测试方案和用例。

软件测试需求分析是做好软件测试工作的重要条件，好的需求分析可以为后面的工作指引方向，带来便利。

基于软件架构的回归测试 篇4

首先由于软件总在时刻变化着, 软件的不断演化, 例如软件的开发、维护、升级都需要修改一些软件的结构和代码, 而人类对软件的要求也从未停止过。软件的每次改变都会引入潜在的风险, 这是软件演化的缺陷。其次, 人类对软件变化有了一些新的要求, 关心软件修改后的功能是否达到预期以及原有的功能是否被损害[1,2,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″。这一步类似于在第三步中基于软件架构的测试。

f:测试执行。在T″已经被S″选择之后, 需要在P″中运行T″然后评估执行基于软件架构回归测试的结果。这一步跟第四步中基于软件架构的测试很相似。

摘要：当对可靠的系统结构化的时候, 除了通过构建的方式来改善系统的可靠性 (如容错和多余的机制) 外, 对于系统的评估也同样重要, 并由此来认可系统的可靠性。现有很多不同的方法来评估系统的可靠性, 测试因而成为一种重要的方式。目前关于软件结构测试的工作表明, 应用一致性测试技术产生可信度是可能的, 这种可信度是在软件架构中可期望的行为, 指定了架构描述语言。这项工作中, 探讨了为了减少重复测试而修改系统的费用, 回归测试可以怎样被系统化地应用在软件架构层面上, 评估了进化的系统的回归测试性。考虑了评估“自顶向下”和“自底向上”等进化方法, 是否通过简单修改就能够符合初始的架构, 这样的修改是否能够符合进化的架构。将回归测试应用在软件架构层面上将有助于评估和认定其是否具有更高的可信度。

关键词：软件架构 (SA) ,可靠性系统,回归测试,分析

参考文献

[1]R J Allen, R Douence, D Garlan.Specifying and Analyzing Dynamic Software Architectures[C]//Proceedings of the1998Conference on Fundamental Approaches to Software Engineering (FASE’98) , March 1998.

[2]S Beydeda, and V Gruhn.Integrating White-and Black-Box Techniques for Class-Level Regression Testing[C]//Proceedings COMPSAC2001, 2001:357-362.

[3]A Bucchiarone, H Muccini, P Pelliccione, and P Pierini.Model-Checking Plus Testing:From Software Architecture Analysis to Code Testing[C]//Proceedings International Work on Integration of Testing Methodologies (ITM’04) , October2004.

[4]UCI.The C2Style[EB/OL].http://www.ics.uci.edu/pub/arch/c2.html.

毛中概论测试题 篇5

2.社会主义究竟是什么？结合毛泽东第一代的社会主义实践，谈谈你对邓小平关于社会主义本质理论的认识。

3.我国的生态环境和资源现状如何？怎样处理发展与环境、资源的关系？试运用中国特色社会主义有关理论并联系实际来加以回答。

4.材料题

2008年6月28日, 贵州瓮安爆发了震惊全国的“6·28”事件，这一天，有成千上万名群众走上街头，由于对一位16岁少女溺水死亡处置不当不满，愤怒的人群先后冲击了县公安局、县政府和县委，并点火焚烧了3座办公大楼。

事件发生后，“瓮安执政”成了全国领导干部的一道考题，“瓮安之问”引发了社会的深沉思考。显然，“6·28”事件是当地社会矛盾长期积累，民间怨愤淤积太久的结果，是典型的泄愤式群体事件。

假如你是一名为政一方的地方官，面对民怨和矛盾，你将采取怎样的措施来解决？试运用毛泽东关于正确处理人民内部矛盾问题的相关理论来做出分析。

软件测试中回归测试 篇6

1 回归测试的过程管理

一套测试过程往往由一次初次测试以及多次回归测试的相结合。而测试项目一般按测试需求分析内容，以及测试策划与测试设计内容，和测试执行内容与测试总结工作这五个程序来完成测试。

软件回归测试的过程管理有一个框架，辅助人员进行测试环节，对重要的回归测试环节实施管理办法，并在回归测试的过程中能够保证测试数据与信息的安全及完整与一致性。

2 软件回归测试策略

选择前面一次测试的用例内容再测试是我们比较安全的策略，但这种测试成本比较高。同时伴随着测试环节的展开，这些用例内容连续多起来，从而重复原先的测试带来非常大的工作量，因此采取一些策略减少回归测试。

回归测试过程中的差错一般都会涉及到修改的或者剔除的代码。因此回归测试局限于其部分以及所影响到的部分，同时添加一些用例内容是妥善地回归测试策略方法。

2.1 修改软件其影响域分析环节

针对修改的回归测试时，如不对修改的影响域全面的分析，因修改而引起新错误会被忽略，因此造成测试结果的遗漏。所以回归测试需对前面一次测试修改进行分析总结，从而能够确保修改的影响范畴。

2.2 测试用例内容的设计原则

测试设计一般以修改影响域分析为基础，测试用例内容的设计原则有三点：首先是保留修改涉及的测试用例内容;其次剔除过时的测试用例内容;最后为增添新的测试用例内容。

3 在回归测试过程中自动化管理策略与实现

由于测试过程中测试时间比较短，而且任务重，保证辅助人员按测试规范开展的测试环节;于每次回归测试前对修改的域进行科学的分析;并针对影响域开展完整的测试设计;同时对后面多次回归测试的数据采取科学有效的管理，因此需要实现软件回归测试的过程自动化管理。

围绕着回归测试的过程自动化管理策略中重要设计思想，我们阐述将在下面进行。

3.1 软件的测试过程管理

在测试过程中为保证测试人员遵循规范，采用测试过程管理启发思想，人员通过树状图按测试规范开展测试环节。

测试过程中存在着初次测试与多次回归测试两种。首先初次测试是按测试阶段开始进行，而多次测试是以初次测试为出发点。由于回归测试时间短，因此可能不会按测试阶段来开始进行。因初次测试与回归测试的内容不一样，要为初次测试过程以及回归测试过程设计不一样的测试过程管理思想，人员测试按不同的测试阶段开展相应的环节。

(1)软件初次测试过程管理向导分别按五个阶段完成，它们分别为测试需求分析，及测试策划与测试设计，和测试执行与测试总结等等，如果辅助人员明确地测试需求，然后围绕着测试需求制定出测试计划，接着通过测试计划设计出测试用例内容，再由测试用例内容来开展软件测试，以及由测试结果自动分析总结出测试的结论，最后确保测试人员按规范展开初次测试的各项步骤。

(2)软件回归测试的过程管理向导思想是通过测试的五个阶段环节辅助人员开展的回归测试。

首先是回归测试需求分析第一阶段，而测试人员对前面一次测试的一切修改项开展影响域分析，辅助人员围绕被测软件的修改情况自动得出修改所影响的测试数据与信息。

其次是回归测试需求分析的基础上，辅助人员制定回归测试策略，然后进行回归测试环境与测试人员安排及测试进度的安排等环节内容，最后完成回归测试策划阶段的内容工作。

接着是回归测试设计这个阶段，根据以上回归测试的数据自动得出需继承前面一次测试的一切用例内容，然后辅助人员在继承用例内容的基础上增加新用例内容，剔除过时用例内容。

最后是回归测试执行这个阶段，辅助人员记下测试用例内容结果，记载回归测试过程中的问题。然后根据回归测试结果自动得出相关信息分析统计，辅助人员在此结果上完成回归测试总结环节工作。

3.2 软件修改影响域的自动化分析

测试工作开展的基础是软件需求，有些修改所涉及的软件需求是修改所影响域的开端，依据这些软件需求所做的回归测试设计都为此影响域范畴。因此正确地挖掘修改所设计的软件需求是完成修改影响域分析的重点。我们首先分析软件修改的种类，然后将其分为三个方面，并设计各方面修改影响域分析。

(1）因软件问题造成的修改影响域分析

解决前面一次测试所产生的问题可通过软件修改。

测试人员在初次测试过程中，首先整理分析软件需求，然后将整理后的需求作为测试依据，接着围绕每条测试依据开展测试项和测试用例内容的设计，再次实施测试并总结结果。围绕以上思路，通过软件问题与测试用例内容和测试项与软件需求相互的关系，自动得出每一个问题所影响的测试数据和信息。

(2）其他软件修改影响域分析

头一版被测软件测试结束后，人员会对部分程序加以完善优化。这种修改有可能产生新的错误，因此对这种种类的修改一样要分析到影响域。可根据软件修改数据上此类修改的相关说明，测试人员决定所修改程序的范畴，找出相应的测试依据。

在回归测试的过程管理向导中，辅助人员实施此类软件修改的影响域分析，设计出相应的向导环节。辅助人员按软件修改需求的相关内容信息，识别分析出此类修改的相关信息和数据，在前面一次测试所包含测试依据的集合中，辅助人员为此类的每个修改项明确所影响的测试信息根据。

(3）软件需求修改影响域分析

在回归测试的过程管理向导中，回归测试被测方所得出的软件需求有可能比前面一次测试得出的剔除了或者扩充了。因此辅助人员设计出测试依据用于维护向导环节，在以上两步中所得到的软件修改所涉以及测试数据与信息的依据基础上，辅助人员添加另外新的测试信息依据，并针对已经不用的测试依据实施剔除。

3.3 辅助设计的回归测试用例内容

辅助人员得到软件修改的测试依据后，然后自动获取继承用例内容的策略。根据以上修改影响域分析的两步得出的测试依据是前面一次测试依据。而前面一次测试以这些测试数据所设计的测试项都做为继承的测试项，为回归测试所采用。

在回归测试的过程管理向导中，辅助人员在继承用例内容的基础上开展测试用例内容的设计工作，设计了测试用例内容设计向导环节，将以上自动得出的测试项和测试用例内容集合按相应的层次关系自动显示在此环节对应模块里。辅助人员针对测试新添加的软件需求在此基础上，设计新的测试项，并在这些测试项下设计新测试用例内容。比如辅助人员不能使用有些测试项和用例内容，然后将其实施剔除，同时强制测试人员需要输入测试项和用例内容的剔除理由，这样可以避免造成误删。此外测试人员出于加强测试效果的考虑，还可在一些测试项中设计某些新的用例内容，让回归测试更加完善全面。

3.4 建立测试项目数据库策略

测试人员对多次测试的数据信息结果展开有效管理，得出了建立测试项目数据库的策略。在测试过程中测试人员多次回归测试一般会继承以及延用前一次的信息和数据。我们为有效保存测试的信息数据，将各层次数据分为2部分，分别为实体信息和实测信息，将它们存放在不同的数据表中，其中用于保存每个设计项的设计数据和信息是实体信息，而用于保存每个设计项的执行数据信息是实测信息。在数据库中设计项的设计信息只保留一份，但针对不同的测试版本这个设计项可能包含多份执行信息。这样实例多次引用的设计理念，有效地减少了数据库信息冗余存贮的问题，使信息存贮能够简化清晰。

3.5 自动化生成回归测试文档阶段

保证回归测试文档数据信息的完整以及一致性，同时简化人员耗时的文档收集及整理工作，此工具由回归测试文档的自动化产生，可以研究针对回归测试文档自动化生成的策略。通过Word底层对象编程技术办法能够实现一系列软件回归测试文档的自动化生成，从而大大提高了回归测试文档编制的效率水平，并且有效地提高了软件回归测试的过程管理自动化能力。

4 小结

事实说明，辅助人员为测试有效规范的回归测试环节，制定出了软件回归测试繁荣过程管理策略并给以实现，此策略能够高效让辅助人员按规范的回归测试过程进行适当的回归测试环节，修改影响域自动化分析与回归测试用例内容设计，回归测试结果自动化分析统计，回归测试文档自动化生成等等工作，并在回归测试过程中能够保证所有测试信息及数据的完整与一致性。

此策略不仅能在软件测试项目的回归测试使用，同时简化了测试人员的工作，而且明显增加了软件回归测试的过程管理自动化能力。

参考文献

[1]陈青;软件评测过程管理方法研究与实现;飞行器测控学报;2010.

图形用户界面的回归测试方法研究 篇7

图形用户界面 (GUI) 在当今的软件系统中应用十分广泛, 大约占据了软件系统一半的代码量[1], 因此软件系统中GUI的正确性对于确保整个系统的正确执行有着重要的意义。然而, 由于GUI本身的特性, 使其回归测试过程具有很大的挑战[2]。

尽管回归测试是软件测试和维护过程中的一个重要活动, 大约要花费三分之一的开销[3], 但是人们在GUI的回归测试方面仍然研究得较少[4]。传统软件的回归测试方法有[5]:重测所有 (Retest-all) 方法、最小化选择 (Min Tech) 方法、随机选择方法和安全选择方法 (Safe Tech) 。它们在测试时开销较大, 难以适用于GUI的回归测试。对于GUI的回归测试方法, White[6]提出了一种使用拉丁方来降低回归测试包大小的方法;“记录/回放” (Record/playback) 工具[7]是目前GUI测试最流行的工具, 但对于回归测试的帮助不大, 因为即使对GUI的布局进行一个小的改动, 都需要产生大量的测试用例。

我们知道当一个GUI被修改, 测试包中的测试用例就被分为两类:可用的和不可用的。如果GUI的每个版本都产生许多新的测试用例的话, 那么开销太大。为减少开销, 方便测试人员对GUI进行回归测试, 本文给出了一种GUI回归测试方法, 并给出了一个GUI回归测试器模型, 它可以识别修改, 检查测试用例是否可复用, 不可复用的是否可修复。

1 相关概念

1.1 GUI和测试用例的相关定义

定义1 GUI由一组对象的集合O和这些对象所具有的属性的集合P组成。O ={o1, o2, …, om}, P ={p1, p2, …, pn}, 其中oi (1≤i≤m) 表示文本框、表单、按钮等。pi (1≤i≤n) 表示字体、颜色等。

定义2 一个GUI有效的事件序列是指一系列事件e1, e2, e3, …, en, 其中事件ei+1在事件ei执行完后可以立即执行。

定义3 GUI的测试用例T = (S0, e1, e2, …, en) , 其中S0 ∈SI是T的初始状态, e1, e2, …, en表示一组有效序列。

定义4 不可用的GUI测试用例T= (S0, e1, e2, …, en) 是指:如果一个GUI的改动导致测试用例的初始状态S0不可达, 或事件序列e1, e2, …, en不可被完全执行。

定义5 可用的GUI测试用例T= (S0, e1, e2, …, en) 是指:如果T在修改过的GUI上仍可被完全执行那么T就称为可用的测试用例。

定义6 如果一个不可用测试用例的初始状态S0是可达的并且该测试用例的事件系列经过修复可变成对修改版GUI有效的事件序列, 那么称这个不可用测试用例是可修复的。

1.2 图形用户界面控制流图G-CFG和图形用户界面调用树GUI call-tree的定义

通过比较原GUI和修改版GUI的G-CFG (GUI control-flow graph) 和GUI call-tree来识别GUI结构的改变。

定义7 GUI组件C是一个有序对 (RF, UF) , RF代表一个模态窗体, UF是一个非模态窗体集合。每一个UF中的元素是由RF或UF里的事件触发的。

一个GUI组件用一个G-CFG表示。一个G-CFG静态的表示一个组件中事件的所有交互情况。

定义8 一个组件C的G-CFG是个四元组<V, E, B, I>

1) V 是一个顶点集, 表示组件中的所有事件 。每一个v∈V表示C中的一个事件。

2) E⊆V × V是顶点间有向边的集合。如:一条边 ( vx, vy) ∈ E 表示vx代表的事件执行完后, vy代表的事件可以立刻执行。

3) B⊆V 是一个顶点集, 表示组件C中的那些当组件第一次被触发时对用户有效的事件。

4) I⊆V 是一个可以触发其它组件的事件集。

定义9 一个GUI call-tree是一个三元组<N, R, B>, N表示GUI中的组件集, R∈N是一个被委托的组件, 称为Main组件 (任何GUI都有Main组件) 。B是表示组件间触发关系的有向边的集合。

2 基本思想

2.1 方法概述

本文所介绍的这个图形用户界面的回归测试方法如图1所示。

由图1可知, 回归测试包由三部分组成:被选择的可用的测试用例。可修复的测试用例和新生成的测试用例。我们知道生成GUI的测试用例是非常昂贵的, 本文所介绍的这种方法的目的就是尽可能地利用原GUI的测试用例 (即对其进行选择和修复后) 来对修改版GUI进行测试。其中虚线框部分所示的就是选择、修复过程。

该方法的实现是基于一个回归测试器模型的, 为方便理解, 我们先用一个简单的例子来初步了解一下该方法的思想。

2.2 实 例

图2表示的是一个住房管理系统的原GUI, 它包括五个事件:“添加”、“删除”、“修改”、“刷新”和“退出”。当GUI被触发后它们都可以被直接访问。图3表示修改后的GUI版本, 它也包含五个事件, 但是“刷新”事件被取消了, 其它四个事件只有通过点击下拉菜单按钮“编辑”才可以访问。

由第1节中的G-CFG的定义可画出原GUI和修改版GUI的G-CFG图, 如图4、图5所示。

比较两个GUI的G-CFG, 可得出以下四点:

1) 删除的事件有:{刷新 }。

2) 添加的事件有:{编辑}。

3) 删除的边有:{ (添加, 添加) , (修改, 修改) , (删除, 删除) , (刷新, 刷新) , (添加, 修改) , (添加, 删除) , (添加, 刷新) , (添加, 退出) , (修改, 添加) , (修改, 删除) , (修改, 刷新) , (修改, 退出) , (删除, 添加) , (删除, 修改) , (删除, 刷新) , (删除, 退出) , (刷新, 添加) , (刷新, 修改) , (刷新, 删除) , (刷新, 退出) }。

4) 添加的边有:{ (编辑, 编辑) , (编辑, 添加) , (编辑, 删除) , (编辑, 修改) , (编辑, 退出) , (添加, 编辑) , (删除, 编辑) , (修改, 编辑) }。

我们选取原GUI的四个较典型的测试用例进行分析, 从而初步介绍本方法的思想。如表1所示, 其中, 第一列表示测试用例的序号, 第二列表示测试用例的事件序列, 第三列表示测试用例所用到的G-CFG中的事件, 第四列表示测试用例所覆盖的G-CFG的边。

通过分析可知:

1) “删除”事件对于修改版GUI也是有效的, 所以序列1依然可用。

2) 边 (修改, 删除) , (添加, 修改) 和 (修改, 退出) 已经从GUI中删除, 所以事件序列2、3对于修改版本的GUI是无效的。

3) “刷新”事件已从GUI中删除, 所以事件序列4对于修改版本GUI是无效的。

通过比较原GUI和修改版GUI可知原序列2、3好像可以经过修复, 用于修改版GUI中。如可将序列2改为<修改;编辑;删除>, 将序列3改为<添加;编辑;修改;编辑;退出>。这样事件序列2、3对修改版GUI就变为有效的了。对于事件序列1, 它虽然对于修改版GUI也是有效的, 但由于它在原GUI中已执行过, 所以如果该序列中的事件没被改变, 那么我们可以不去重新执行它。对于序列4因为它包含了被删除事件“刷新”, 在本例中我们认为它不可修复, 将它丢弃。

上面我们通过一个例子介绍了一下该方法的思想, 下面我们介绍一下该方法的回归测试器模型。

3 GUI回归测试器模型

图6是该GUI回归测试器模型的主体部分, 其他部分由于篇幅限制, 我们暂且省略。

由图6可知该GUI回归测试器包含两个部分:一个是用来区分测试用例是否可用的检查器。如果不可用, 那么它也可以判断该测试用例是否可以被修复。第二部分是修复器, 它可以将那些不可用但通过修复能变成可用的测试用例进行修复。我们现在介绍一下测试用例检查器和修复器的设计细节。

3.1 测试用例检查器

测试用例检查器的主要功能是识别出不可用的测试用例并确定哪些用例是可修复的。测试用例检查器通过比较原版GUI和修改版GUI的G-CFG和G-call tree来判断一个测试用例的事件序列是否可以复用。

用G-CFG表示的一个组件中的事件可能被增加或删除一个顶点或边。如果GCFGo和GCFGm是一个组件的G-CFGs, 该组件分别存在于原版GUI和修改版GUI中, 通过执行集合减法可以获取下面四个改变的集合。

1) 新顶点的集合:Vertices (GCFGm) -Vertices (GCFGo) ;

2) 删除顶点集合:Vertices (GCFGo) -Vertices (GCFGm) ;

3) 新增边的集合: Edges (GCFGm) -Edges (GCFGo) ;

4) 删除边的集合: Edges (GCFGo) -Edges (GCFGm) ;

就像在第2.2节中介绍的那个实例一样, 以上四个集合可用来识别不可用测试用例。同样的, 一个call-tree可以通过增加或删除一个组件或边被改变。如果Go和Gm分别是原GUI和修改版GUI的call-tree, Nodes和CompEdges分别返回call-tree的集合N和集合B, 那么可得以下四个集合:

1) 新增组件的集合:Nodes (Gm) -Nodes (Go) ;

2) 删除组件的集合:Nodes (Go) -Nodes (Gm) ;

3) 新增边的集合:CompEdges (Gm) -CompEdges (Go) ;

4) 删除边的集合:CompEdges (Go) -CompEdges (Gm) ;

例如:假设有一个GUI, 它的原版本G-call tree (如图7所示) , 修改版本的G-call tree (如图8所示) , 则, G-call tree中添加的组件的集合为{打印文件}, 添加的边集合为{Main->打印文件}。

通过比较可知G-CFG的边与call-tree的边是不同的。G-CFG的边是有序的二元组 (ex, ey) , ex和ey是事件, G-call tree的边也是有序的二元组 (Cx, Cy) , 但它们是组件。

3.2 事件序列修复器

事件序列修复器修复无效的事件序列使它们可以被用在修改版的GUI中。一个无效事件序列中要么包含一个被删除的事件, 要么包含一条被删除的边。下面来看一下事件序列修复器的相关实现算法:

3.2.1 事件序列修复器算法

事件序列修复器的算法如下:

算法首先检测每一个从GUI中删除的事件ei, 如果事件序列S用到了这些事件, 那么它就是无效的。接着由算法repair_del_event来修复它。如果S可修复, 那么算法repair_del_event返回TURE, 否则算法EventSeqRepairer将终止。因为算法repair_ del_event可能会改变S中的事件, 所以比特向量EVENTS-USED也要更新。当S被完全修复后, 它的EDGES-USED要被更新。然后算法EventSeqRepairer开始检查从GUI中删除的边 (ei, ej) , 如果S中包含这种边, 那么它是无效的。算法repair_del_edge来修复它, 如果返回TRUE则S可被修复, 反之则不可修复。S会发生改变, 所以比特向量EVENTS-USED被更新。当事件序列被成功修复时, 算法EventSeqRepairer返回TURE, 反之返回FALSE。

3.2.2 修复删除事件的算法与修复删除边的算法

修复删除事件的算法如下:

该算法有两个参数:事件序列S和被删除的事件e。算法从左向右扫描子序列<ep+1; … ; en >如果可以找到ek, 使< e1; … ; ep-1; ek; … ; en >对修改版GUI有效则返回TRUE, 或者从修改版GUI的事件集中找一个ex, 使< e1; … ; ep-1; ex; ek; …; en >对修改版GUI有效, 那么也返回TRUE。例如, 前面2.2节实例中所举的例子, 由于“刷新”事件已从GUI中删除, 并且GUI在修改前后结构发生了改变, 所以原事件序列<添加, 修改>对修改版GUI无效, 算法可以从修改版GUI的事件集中找到ex=“编辑”, 从而将事件序列修复成有效序列<添加;编辑;修改>。修复删除边的算法与修复删除事件算法大体相似, 具体算法如下:

4 结 论

当GUI的结构稍作修改, 大量的测试用例将变为不可再用。针对GUI的这一特点, 本文给出了一种基于GUI的回归测试方法。该方法的主要思想是对原GUI中不可用的测试用例进行修复, 使之可用于修改版GUI测试中。通过用GUI-CFG来表示一个组件的事件行为, 用G-call tree来表示组件的触发行为。用这些图来表示原版GUI和修改版GUI, 并通过比较这些图来监测不可用测试用例并且可以修复它们。由于此方法尽量去维护测试用例而不是去生成它们, 因此可以既节省测试成本又节省测试时间, 但这种GUI回归测试方法仍有可以改进的地方, 如:此方法是完全的黑盒测试方法, 而对底层代码的改动没有考虑, 因此将白盒测试和黑盒测试方法综合起来考虑是一个有意义的研究方向。

参考文献

[1]Myers B A.User interface software tools[J].ACM Transactions onComputer-Human Interaction, 1995, 2 (1) :64-103.

[2]Memon A M.GUI testing:pitfalls and process[J].Software Technolo-gies, 2002:87-88.

[3]Pressman R S.Software engineering:a practitioner’s approach[J].McGraw Hill, 1994.

[4]Memon A M, Mary Lou Soffa.Regression testing of GUIs[C].in Pro-ceedings of the 9th European Software Engineering Conference Heldjointly with 11th ACM SIGSOFT International Symposium on Founda-tions of Software Engineering, September.1-5, 2003:118-127.

[5]刘凯枫, 张大方, 缪力, 等.一种基于测试状态的回归测试方法[J].计算机工程与科学, 2005, 27 (3) :80-82.

[6]White L.Regression testing of GUI event interactions[C].in Proceed-ings of the International Conference on Software Maintenance, Wash-ington, Nov.4-8, 1996:350-358.

软件测试中测试用例复用的研究 篇8

(一) 软件复用概述。

软件复用指的是将已有的软件中的有效成分用来构建新的软件, 强化复用的功能。在进行软件复用的过程中, 整个重新构建的软件系统并非零基础, 而是将旧有软件开发知识都调动起来, 从而加快新软件设计的脚步, 这是软件复用最大的优势体现。在实践中, 可以对已有软件进行百分百复用, 也可以针对源代码或相应的测试用例进行复用。

(二) 可复用测试用例的具体特征。

通过对大量测试用例和测试用例复用的各种应用情况进行了分析, 认为可复用测试用例应具有以下特性:通用性、有效性、独立性、标准化和完整性等等, 这些特征对于可复用测试用例而言是充分的也是必要的[1]。上述特性可作为评判一个测试用例是否具有可复用性的准则。

二、探究软件测试用例复用的相关内容

(一) 软件测试中的测试用例。

为了巩固软件研发后的功能符合实际设计需求, 则在软件正式投入使用前需要对软件进行科学化的测试。随着软件设计领域的日益变革, 软件功能也呈现出多样化的特征, 因此, 软件开发的复杂程度也不同以往。在这种情形之下, 软件测试阶段的设计就显得尤为重要, 在进行软件测试的过程中, 需要运用抽象化的软件测试用例来支撑整个测试环节。从概念上来看, 测试用例指的是对软件运行过程中所有可能存在的目标、过程、环境及结果的预测, 通过具体的数据以及文字将其描述出来, 模拟了该软件在实际上线以后的运行情况, 旨在从整个拟运行的过程发现实际问题, 并及时将其解决。在测试的过程中, 测试用例体现出测试方案以及策略的相关内容, 并通过文档的形式将测试的几个步骤和评估过程 (如测试目标评定、测试环境拟运行、测试结果等) 呈现给软件测试技术人员。

(二) 测试用例复用设计的思路。

对于测试用例的设计而言, 要遵循一定的设计原则以及基本的设计思路来展开软件测试用例设计。因为在软件测试的过程结束时, 最终的测试结果受到多重因素的影响, 包括测试的细节、测试前提、测试性能指标等等, 所以, 就要在执行软件测试时, 仔细钻研软件运行环境及其性能等要求, 进而保证软件测试过程的整体质量[2]。基于此, 在实际执行测试时, 选择恰当的实际用例十分关键, 通常选择复用现有的测试用例, 以期提升软件评估过程的效率。但实际上, 有很大一部分软件测评中心仅仅使用了测试用例集合当中的一个模块进行复用, 一方面在提高了软件测试用例服用度, 另一方面也能够保障新型测评系统能够与时俱进, 满足测试系统升级的目标。具体的软件测试中测试用例复用过程如图1所示:

从图1中可以清楚的看到, 软件测试中测试用例复用是一个较为复杂的过程, 需要各个环节的密切配合与协调, 并最终实现测试用例复用的过程, 提升软件测试及其设计的效率。实践证明, 对于专业的软件测试机构来说, 选择合理复用测试用例具备一定的可行性和经济性, 并且设计出来的测试用例能够顺利执行软件测评过程。

结束语

通过研究软件测试中测试用例复用了解到, 软件测试用例设计对于软件测试极为重要。在实践过程中, 软件测试是确保软件质量的可靠手段, 是软件开发过程中必不可少的重要环节。通常情况下, 面向复用的测试用例设计过程, 为测试用例复用提供了实现策略, 保证了软件上线以后的质量符合相关要求。另外, 测试用例的复用对于缩短软件开发周期和降低软件开发成本具有极其重要的意义。在未来, 需要深度探究软件测试中测试用例复用领域, 使其为软件研发提供更加有力的技术支撑, 促进软件行业朝向更为广阔的发展空间迸发。

摘要：随着国内外软件产业的迅猛发展, 有关软件工程领域的研究亦日趋深入, 给软件研发以及产业项目的发展提供了有力的策略支持。本文就软件测试中测试用例复用及其设计的相关内容做以论述, 探讨测试用例的复用对于缩短软件研发周期的影响, 并进一步探究软件开发的相关问题, 以期为软件工程领域的未来拓展提供有益的借鉴。

关键词：软件测试,测试用例复用,研究

参考文献

[1]张志国, 徐冰霖, 秦湘河.面向复用的航天测控软件测试用例建模研究[J].飞行器测控学报, 2011, 06 (06) :49-50.

软件测试中可复用测试用例研究 篇9

随着软件产业的快速发展, 软件作为一种产品被广泛应用于各个领域, 其功能越来越强大, 复杂度越来越高, 人们对软件质量的要求也越来越高。为满足不同领域、不同行业复杂多变的软件需求, 进一步提高软件开发的质量和效率, 软件开发者开始更多的关注和研究软件复用技术。软件复用技术的研究、应用给软件开发带来了效率、经济的双重好处。

在软件开发复用技术发展的影响下, 测试人员开始将复用的思想应用到软件测试领域, 特别是对测试用例复用的研究。测试用例复用就是将一个软件已经执行过的测试用例, 在不同时间、不同程度的应用到同一软件新的测试或是同类软件的测试中。有效的复用测试用例不仅能提高测试效率, 还能借鉴前人经验、解决经验不足的问题。测试用例是测试工作的指导, 是软件测试必须遵守的准则, 是编写测试脚本的“设计规格说明书”。目前对于测试用例复用的规范化、系统化方面仍有许多待解决的问题。

1 测试用例在软件测试中的作用

测试用例是软件测试过程的核心, 是测试执行的最根本依据。每个测试人员 (包括分析、设计、编程和测试人员) 的工作环境、技术背景、设计思路各不相同, 测试用例可以指导测试的实施, 控制测试的实施过程;规范测试数据的准备以及测试脚本的编写, 保证测试的规范性;测试工作组要有相应的测试审核部门, 通过一些量化的数据如测试覆盖率、测试合格率等衡量测试用例的优劣, 分析测试缺陷, 评估测试结果。

1.1 可复用测试用例的质量特性

文献[2]给出了可复用测试用例的特性, 以此来判定一个测试用例是否具有可复用性。本文在对大量测试用例及其复用情况进行了学习研究后, 认为可复用测试用例应具有以下四个必要质量特性:通用性、独立性、规范化和可维护性。

(1) 通用性

复用的测试用例要不局限于具体应用, 不过分依赖于开发的环境。一般来说, 在面向对象开发这样的主流模式中, 复用的组件或构件在功能上变化不大, 因此基于该模式开发的软件在测试过程中生成的测试用例可复用性很大。比如低层被测对象的测试用例或其部分内容常常被复用到对高层对象的测试中。

(2) 独立性

通常测试用例能否成功被复用, 很大程度上依赖于测试用例的独立性。测试用例之间往往存在着相互的联系, 一些测试用例的成功执行要取决于其他测试用例的执行状态。这就要求每个测试用例要完成的目标必须单一, 不能包含过多的实现细节。一个系统功能点集合F (F1, F2, ……, Fn) 对于任意两个功能点Fi、Fj (i≠j) , 则分别存在Fi、Fj对应的测试用例集Ti、Tj, 满足Ti∩Tj=φ。对一个项目测试产生的测试用例资源, 对其进行抽象化、规范化处理, 使其与被测项目的关联度降至最低, 此时生成的测试用例则可作为复用资源放入测试构件库中。

(3) 规范化

测试用例大都是测试人员根据个人经验和对被测软件的理解而设计的, 通常也都是用自然语言来描述, 没有统一的标准。一个好的测试用例不仅要体现软件的测试思想、技巧, 同时还要包含大量的测试数据、结果以及测试过程。用一定的规范将测试用例组织成一个统一的标准形式, 这样的测试用例才是可以被理解的、可复用的。此外对测试用例库的管理也要有一套规范的流程。

(4) 可维护性

对测试用例的复用研究其根本目的就是要形成一个成熟的、可靠的可复用测试用例库。通用性是可复用测试用例的基本特性, 那么对具体的测试而言就少了实现细节。因此为了应对不同被测软件的需求、设计和环境, 库中的测试用例应该能够稍加修改就可以在同一领域或相似领域进行广泛应用。

1.2 测试用例复用的优点和困难

通过大量研究实践得到如下测试用例复用的优点和困难。其优点如下: (1) 通过复用测试用例, 可以缩短软件的测试周期, 大大提高测试效率; (2) 在前人经验和测试用例库的基础上, 提高了测试的可靠性; (3) 降低了测试的费用, 节省了软件成本; (4) 在一定程度上解决了测试人员经验不足的问题。但是测试用例复用的困难也是不容忽视的, 其难点如下: (1) 测试用例的分类标准难以确定。测试用例库的组织方式有很多, 要让测试人员在最短的时间内检索到想要的可复用的测试用例, 需要对测试用例库的组织、存储进行科学有效的管理; (2) 最根本最关键的测试用例数据库的维护挑战, 相关人员 (如质量管理员、评审管理员、配置管理员等) 要对测试用例库进行有效、持续的科学管理; (3) 测试用例可复用度量标准的确定, 要有合理、准确的度量标准; (4) 被测软件之间的差异, 这就对可复用测试用例库的灵活性和可靠性提出了更高的要求。

2 软件测试中测试用例的复用

根据对软件测试复用经验和方法的研究得到了软件测试用例复用的组成:复用成分的获取、复用成分的管理和复用成分的利用。

(1) 复用成分的获取:通过分析确认有复用价值的测试用例, 对其进行标准化处理后, 按照领域、行业、项目等进行多级合理的分类, 并按一定的组织、存储方式, 将它们放入测试用例库中。同时提供检索机制, 以便于以后在库中能够迅速查找到最合适的用例。

(2) 复用成分的管理:对数据库中的测试用例实行有效维护。在维护中不断添加新的测试用例, 完善旧的测试用例, 删除有问题的测试用例。在软件的迭代开发中, 需求或功能不断变化, 所需的测试用例也要随着做相应的修改。对于软件需求没有变化, 只是入库的测试用例不是那么完善的, 在测试过程中要不断完善, 使测试效果更贴近用户需求;对于需求变化了, 功能增加了的, 需要设计新的测试用例, 新设计的测试用例经测试、评审、规范化后才可以放入到数据库中;对于需求变更, 有的功能模块被取消了的, 保留之前的测试用例, 有可能在同领域或功能相似的软件测试中会被用到。测试用例的维护模式如图1所示:

(3) 复用成分的利用:基于组件的软件工程, 在组件的开发过程中, 低层被测对象的测试用例或其部分内容常常被复用在高层被测对象的测试中[1].例如单元测试中产生的功能类测试用例资源在以后的集成测试或回归测试中就可以被拿来利用;软件的迭代开发过程中, 先前版本的测试用例可以复用到新版本的测试中去;同一行业不同项目之间的测试用例资源也可以相互借鉴利用。

3 测试用例复用的应用研究及实现过程

在同一领域的不同项目中, 或是基于组件开发的系统中, 都存在着测试用例复用的应用。测试用例是动态的, 要随测试环境、需求、设计、实现做相应的变化。本文主要对某大型物流系统仿真实际运行环境中满足需求的系统验收测试阶段产生的测试用例进行了分析研究。

用形式化的语言——六元组S={id, name, pre, in, ope, exp}来定义一个测试用例, 其中id为测试用例编号, name为测试用例名称, pre (取precondition前三个字母) 为测试的前置条件, in为测试输入, oper (取operation前四个字母) 为测试操作, exp (取expectation前三个字母) 为预期结果。

针对物流园车辆租赁的业务流程抽象出的场景测试流如图2所示:

需要进行测试的功能点集合F{F1, F2, ……, Fn}, 测试用例库为T{T1, T2, ……, Tn}, 输出满足条件的可复用测试用例的集合为S, 算法思想如下:

4 总结

测试用例的设计是软件测试中重要的一个环节, 其作为一种无形的有价值资产, 有效复用的研究意义重大。本文在学习研究大量可复用测试用例具体应用后, 提出了可复用测试用例的提取及数据库的维护过程。给某大型物流系统仿真实际运行环境的系统验收测试工作带来了便利。

摘要：软件测试是保证软件质量的重要手段, 测试用例是软件测试的关键环节, 测试用例的选择对测试质量有着至关重要的影响。为了提高测试效率、积累测试经验、节省测试成本, 测试用例复用的研究意义重大。本文在大量测试用例复用研究的基础上总结了可复用测试用例的质量特性、复用的优点以及存在的困难, 提出了可复用测试用例的提取及可复用测试用例数据库的维护过程。最后研究内容在某大型物流系统中进行了测试验证, 证明研究是有效的。

关键词：可复用性,质量特性,测试用例,提取,可复用测试用例库

参考文献

[1]徐仁佐, 陈斌, 陈波, 等.构造面向对象软件可复用测试用例的模式研究[J].武汉大学理工学报, 2003, 49 (5) :592-593.

[2]肖良, 杨根兴, 蔡立志.软件测试用例可复用性度量[J].计算机应用与软件, 2010, 27 (6) :46-49.

软件测试中回归测试 篇10

黑盒测试图发现以下类型的错误: (1)不正确或一遗漏的功能;(2)接口错误;(3)数据结构或外部数据库访问错误;(4)行为或性能错误;(5)初始化和终止错误。黑盒测试与白盒测试的不同之处是,黑盒测试应用于测试的后期阶段, 而白盒测试是应用工程测试的早期执行。 由于黑盒测试侧重于信息域因此不需要考虑控制结构。设计黑盒测试需要回答以下几个问题:1. 如何测试成功的有效性? 2. 如何测试系统的行为和性能? 3. 哪种类型的输入会产生好的测试用例? 4. 系统是否对特定的输入值特别敏感? 5. 如何分离数据类的边界? 6. 系统能承受什么样的数据速率和数据量? 7. 特定类型的数据组合会对系统运行产生什么样的影响?

黑盒测试的方法

一、基于图的黑盒测试方法:此类黑盒测试方法的第一步是理解软件中建模的对象及这些对象间的关系。这一步一旦完成,下一步就是定义一系列验证“所有对象之间具有预期关系”的测试。即软件测试首先是创建重要对象及其关系图,然后设计覆盖图的以系列测试用例,使得图中的每个对象和关系都测试到,并发现错误。为了完成这些步骤,软件工程师首先要创建图,其中结点表示对象,连接表示对象间的关系,结点权值描述结点的属性,连接权值描述连接的某些特征。

二、等价类划分的黑盒测试方法:此类黑盒测试方法是将程序的输入划分为若干个数据类,从中生成测试用例。理想的测试用例可以单独发现一类错误(如: 所有字符数据处理不正确),否则在观察搭配一般的错误之前需要运行许多测试用例。等价类划分的测试用例设计是基于对输入条件的等价类进行评估。若对象可以由具有对称性、传递性和自反性的关系连接,则存在等价类。等价类表示输入条件的一组有效的或无效的状态。通常情况下,输入条件要么是一个特定值、一个数据域、一组相关的值,要么是一个布尔条件。可以根据下述指导原则定义等价类: 1. 若输入条件指定一个范围,则可以定义一个有效等价类和两个无效等价类;2. 若输入条件需要特定的值,则可以定义一个有效等价类和两个无效等价类;3. 若输入条件指定集合的某个元素,则可以定义一个有效等级类和一个无效等级类;4. 若输入条件为布尔值,则可以定义一个有效等价类和一个无效等价类。通过运用设计等价类的指导原则,可以为每个输入域数据对象设计测试用例并执行。选择测试用例以便一次测试一个等价类的可能的属性。

三、在软件工程中大量错误发生在输入域的边界处,而不是发生在输入域的“中间”。这是将边界值分析(boundary value analysis, BVA)作为一种测试技术的原因。BVA不仅仅侧重于输入条件,也从输入域中导出测试用例。BVA的指导原则和等价划分的指导原则很类似。BVA的指导原则包含:1. 若输入条件指定为一组值,则测试用例应当包括a和b,略大于或小于a和b ;2. 若输入条件指定为一组值,则测试用例应当执行其中的最大值和最小值,以及略大于或略小于最大值和最小值;3. 指导原则1和2也适用于输入条件;4. 若内部程序数据结构有预定义的边界值,一定要设计测试用例,在其边界处测试数据结构。很多软件工程师在进行软件过程中会在某些时候凭直觉完成BVA,若是在边界测试时运用BVA的指导原则,边界测试会更加完全,从而更有可能发现一些错误。

四、许多传统的应用系统程序的输入域是相对有限的。即,输入参数的数量不多,且每个参数可取的值有明确的界定。当这些数量非常小时,则可能考虑每个输入排列,并对所有输入域进行测试。 然而,随着输入值数量的增加及每个数据项的离散值数量增加,我就需要正交数据组测试(orthogonal array testing)。正交数据组测试可以应用于输入域相对较小,对于发现区域错误(region fault)尤其有效,即有关软件构件内部错误逻辑的一类错误。为了说明正交数据组测试与更传统的“一次一个输入项”方法之间的区别, 考虑有3个输入项X、Y和Z的系统。每个输入项有3个不同的离散值。这样可能有33=27个测试用例。Phadke提出了一种几何观点,来组织与X、Y和Z相关的测试用例。一次一个输入项可能沿着每个输入轴在顺序上有变化。这就导致相对有限的输入域覆盖率。而当使用正交数据组测试时,创建测试用例的一个L9正交数组。L9正交数组具有“平衡特性”,即测试用例(黑点)均匀地分散在整个测试域中,整个输入域的测试覆盖会更完全。