软件系统的测试

软件系统的测试（精选11篇）

软件系统的测试 篇1

黑盒测试,又称之为行为测试,黑盒测试侧重于软件的功能需要。通过黑盒测试软件工程师可以设计出将测试程序所有功能需求的输入条件集合。黑河测试作为发现其他类型错误的辅助方法,并非是百合测试的替代品。

黑盒测试图发现以下类型的错误: (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正交数组具有“平衡特性”,即测试用例(黑点)均匀地分散在整个测试域中,整个输入域的测试覆盖会更完全。

为了表示L9正交数组的使用,我们使用传真应用系统的send函数。向函数send传递3个参数P1、P2、P3和P4。其中每个参数取3个不同的值。如,P1的取值(P1=1,现在发送;P1=2,一小时后发送;P1=3,半夜12点后发送)。P2、P3和P4也分别取值1、2、3,表示其他发送功能。如果选择“一次一个输入项”的测试策略,测试(P1、P2、P3、P4)的测试序列如下:(1,1,1,1),(2,1,1,1),(3,1,1,1), (1,2,1,1),(1,3,1,1), (1,1,2,1),(1,1,3,1),(1,1,1,2), (1,1,1,3)。只有确定这些测试参数不相交时,这些测试用例才有用。他们可以侦测出一个参数值使软件出现故障的逻辑错误。这种错误称为单模式错误(single mode fault)。这种方法不能查出两个或多个参数同时取某个值时使软件出现故障的错误。也就是说,它不能查出任何相互影响,它发现错误的能力是很有限额的。测试的方法使我们可以提供很好的覆盖,能够发现参数使软件过程出现故障的逻辑错误。

软件系统的测试 篇2

测试工作未来预见

更好的方法对测试人员更好的培训、更好的欣赏将改革软件产业。具体地说，诸如可执行的说明书、基于模型的测试产生、BUG 预防、系统模拟这些技术，将在这场演变过程中扮演重要的角色。

BUG 预防和早期检测

因为现在把重点放在产品交付的质量上来了(而不是在于找到了多少BUG)，预防实践和静态分析仪这样的检测工具将成为主流。

仿真测试

仿真工具变得很普遍，使得仿造计算机环境变得容易起来。在开发过程的早期就可以进行意外和错误流程的测试。代码稳定后，再用真实环境验证仿真是否准确无误。

及时的测试用例

庞大的测试用例管理系统将成为昔日的东西，大量的测试用例生成了却没有被使用。测试用例将不再像腐烂的存货一样被收藏起来，因此，让测试用例保持最新变得容易起来。积极的方法

误导人的方法，比如计算BUG 的数量、计算测试用例的数量，将不复存在。有用的方法，比如需求覆盖、模型覆盖、代码覆盖将驱动项目开发。

更少更精的测试人员

机器将代替测试人员做大部分他们以往创建测试所做的繁琐工作，测试小组需要比以往更少的测试人员，留下来的测试人员将是经过更多高度培训过的。他们所做的工作将更加有趣，因为在测试中他们将致力于更大的问题，而不是在抱怨中艰难地开展工作。

更多更好的测试

测试人员将可以在一天中进行成千上万的测试，所以，如何首先运行最有用的测试将成为一大挑战。相关的工具将允许测试人员为他们的测试区分优先级，以及将测试目标放在那些最易出现重大BUG 的地方。

测试人员的角色更换

测试中界限模糊，在测试领域工作使得专职测试的人员和专职创建测试工具的人员界限模糊，一个既是“通过程序破坏事物的测试员”又是“创建程序用于破坏事物的程序员”的专业出现了，――关于如何称呼这个新的专业，新闻圈内的人们还在进行着无休止的争论。测试与开发界限模糊，测试人员与开发人员一前一后，共同创造可测试的、高质量的代码。测试人员帮助开发人员消除需求中的问题，使得开发人员的工作更易完成，同时，开发人员写出更清晰、可测性更高的代码，使得测试人员的工作更易完成。顾客反馈与测试合为一体，交付的产品质量更高。测试人员进行根本原因的分析，我们会问比如“我们怎么会遗漏了这个BUG 呢？”或者“我们将来如何防止这类BUG？”这些问题，我们的工作就是使顾客满意。

新的挑战出现

复杂和相互关联的计算机世界使得了测试安全这一类的新问题让测试人员不断努力工作，但这没关系――因为这些挑战使测试人员精力充沛。

测试人员获得尊重

测试人员将不再是在最后时刻才被叫来“对产品狂轰烂炸”，他们将在整个软件开发过程中提供一个可见的、重要的、增值的服务。人们意识到，测试是有益的、有趣的甚至富有乐趣。

测试变得流行

软件测试人员开始扬眉吐气，而且，由于破坏事物至少可以带来创建事物一样的乐趣，人们开始在开发和测试角色之间转换，所有的人将学到更多关于如何得到良好代码的知识。激情“吸毒者”继续存在新的过程运行得如此良好，使得需求撰写者，开发人员以及测试人员不再具有生命力，这就使得那些在激情掌控的世界被提升的人惶惶不可终日，那样的世界意味着工作到深夜、最后一刻测试才参与，以及如同交战开火般的会议。而这些人对于那些还没有受新的运行过程控制的公司来说还具有吸引力。

测试人员该怎么做

不管我的预测是否成为现实，未来也会按照它自己的方式到来，下面就是如何准备面临 未来的五个意见：









 不要接受测试的现状，四处看看，并且思考“我们在做些什么毫无意义的事情？” 领悟如何更好的测试，并且分享这些知识。只有每一个人都试图使他所写的代码达到最佳状态时，整体质量才会改进。行业受软件测试的创新思维激发。用参加会议，加入邮件列表，网上冲浪，这些方式来了解在测试前沿发生的一切。参加一个编程学习班，即使你不打算编写大量的代码。将学习班当作是在BUG 领土上的一次侦察飞行。PC 先驱Alan Kay 所言：“预测未来的最好方式就是开创未来”。

软件测试工程师的素质

大体上从事软件测试工作，要做好这项工作，就要重点着重培养一下自己各方面的素质。因为软件测试正在向工程级发展

基本素质

沟通能力、自信心、幽默感、记忆力<挖掘以往错误>、耐心、怀疑精神、自我督促、洞察力<发现重点>；

广泛的经验；

表达能力、问题描述能力；

会提问，会寻求Help；

逻辑思维能力；

团队协作能力；

处理日常事务的能力和处理突发事件的能力

专业素质

对于系统测试，把握需求是第一位的。对产品熟练，能够快速熟悉新的产品需求，很 强的需求理解能力显得很重要；

测试基础：明确测试流程中各个阶段的工作，对测试的认知程度，决定了测试流程管理 的规范性，测试工作的质量；

测试方案的分析设计能力、测试案例的设计能力(测试案例的覆盖率、优先级等)；

测试工具的使用(包括测试管理和测试执行工具，也包括开发工具的能力)；

编程能力，数据库知识，网络知识，操作系统知识；

团队协作能力，与各个小组之间的沟通能力；

软件系统的测试 篇3

关键词：软件测试；软件质量保证；教学改革；软件测评师；实验教学

中图分类号：G642.0 文献标志码：A 文章编号：1674-9324（2014）51-0094-02

一、引言

随着我国软件产业迅速发展，企业面临着开发高质量软件系统的巨大压力，软件测试、软件质量保证受到越来越多的重视。软件企业对承担软件测试、质量保证工作的软件测试人才需要剧增，软件测试工程师的职业价值、发展前景得到前所未有的提升。为此，国内高校开设了软件测试相关课程。但是，由于其重理论、轻实践的教学模式使得培养出的学生软件测试实战能力差，导致大量毕业生应聘软件测试相关职位时受到冷遇。

为培养创新能力强、适应社会经济发展需要的软件测试人才，《软件测试与质量保证》实验教学亟需改变传统的教学理念，改进教学方法，更新教学内容。笔者结合自身教学科研和工程实践经验，分别从改革思路、实验教学内容设计等方面，论述常熟理工学院《软件测试与质量保证》实验教学改革的措施和体会。

二、实验教学面临诸多挑战

笔者调研国内高校软件测试课程的建设情况，发现普遍存在重理论、轻实践的教学倾向，实验教学环节存在诸多问题：

1.企业对软件测试工程师的能力要求是综合性的，要求软件测试人员具有软件项目经验，具备软件测试、软件质量保证知识，能够独立开展软件测试工作。但是，国内高校教学计划制定时片面强调软件测试的作用，对软件测试与软件质量保证之间的天然联系缺乏理解，对软件质量保证相关实验的重视程度，课时安排存在严重不足。

2.目前，《软件测试与质量保证》实验教材选择面临无书可选的尴尬局面。课程实验设计只能全凭任课教师把握，使得实验教学过程中存在较多风险。

3.国内高校在实验设计方面，多以基础性实验为主。这种单一的实验设计方式，难以适应软件测试工程实践能力培养的需要。

三、实验教学改革措施

在应用技术大学建设驱动下，以中小企业对软件测试人才的需求和软件测试工程师认证大纲为导向，我们整合已有的校企合作课程资源，按照Daniel Galan软件质量保证框架组织实验教学内容，采用项目驱动的案例教学法开展实验教学，让学生在实验实践中加深对软件测试与质量保证专业知识的理解，培养学生软件测试实践能力。

（一）教学改革基本思路

软件企业对软件测试人才的需求是软件测试课程改革的源动力和驱动力，软件测试相关的从业资格认证是学生入职的敲门砖。为此，在应用技术大学建设背景下，我们以切合中小企业对软件测试人才的需求为导向，结合全国计算机等级考试软件测试工程师认证、全国计算机技术与软件专业技术资格考试软件评测师认证的考试大纲要求，选择朱少民老师编写的《全程软件测试》[1]和NIIT培训教程《Software Testing and Quality Assurance：Student Guide》[2]作为课程教材，按照Daniel Galin软件质量保证框架组织教学内容。Daniel Galin软件质量保证框架[3]指出软件质量保证是建立企业软件质量文化所需的一些列活动的集合，认为软件测试是一种典型的软件质量保证措施，软件测试的目的是为了发现潜在的软件缺陷，软件测试工作贯穿软件项目的始终。按照Daniel Galin软件质量保证框架组织课程内容有助于保持软件测试与软件质量保证之间的内在联系，符合软件企业软件测试与质量保证的最新经验。

（二）实验设计

如何在有限的实验课时内，最大限度地加深学生对软件测试、软件质量保证的理解，增强其软件测试实践能力，是实验教学的主要任务。我们设计了导入性实验、基础性实验、创新项目实践三种类型的课程实验。导入性实验要求学生应用已修课程（包括程序设计、数据库设计、软件工程等）知识进行软件调试，在软件调试过程中理解软件调试与软件测试、软件质量保证之间的关系，实现到本课程学习的过渡；基础性实验目的在于强化课程基础理论、原理的理解，让学生在实验中理解所学知识，掌握软件测试工具的使用；创新项目实践以课程实训项目为载体，为学生运行所学知识解决软件测试实践过程中涌现的各类问题，锻炼学生的动手实践能力、自主学习能力，从而提高学生的工程实践素养。

1.导入性实验。软件测试的目的是发现软件系统中潜在缺陷，而缺陷的解决则通过软件调试手段实现。为此，设计导入性实验“软件调试”。本次实验以员工工资核算软件Employee作为实验对象，要求学生发现Employee中人为注入的软件缺陷，然后应用Java调试器的断点调试功能，结合回归测试手段修订所发现的缺陷。

通过导入性实验，学生体验了改正软件缺陷的艰辛，在教师引导下思考如何发现软件缺陷、如何提高软件质量。教师适时点拨学生，指出发现软件缺陷是软件测试工程师的职责，软件测试工程师需运行软件测试方法、技术和工具才能发现潜在的软件缺陷。教师进一步启发学生：提高软件质量需要开展包括软件测试在内的各项软件质量保证工作。

2.基础性实验。基础性实验旨在加深学生对课程基本概念、原理的理解，让学生在动手实践中加深对基础概念、原理的理解。课程安排8次基础性实验，实验2、3、4和5属于软件质量保证实验，6、7、8和9是软件测试实验。

（1）实验2：软件度量实践。实验2关注软件度量问题，介绍软件规模、项目工作量和软件成本之间的关系，要求学生掌握软件规模估算、工作量估算和成本估算的方法和过程。通过本次实验，学生可以应用USC CoCoMo II进行软件成本估算。（2）实验3：基于Microsoft Project的软件项目管理。软件项目计划及进度管理，是软件质量保证中重要的管理部件，也是开展软件测试活动的前提。实验3要求学生使用Microsoft Project建立软件项目计划、运用跟踪甘特图追踪项目进度，等等。（3）实验4：版本控制软件CVSNT。CVSNT是当前最流行的版本控制系统，是中小企业进行版本控制的利器。实验4讲解CVSNT的安装和使用，要求学生掌握CVSNT的操作技巧。（4）实验5：BugFree软件缺陷管理。软件缺陷管理贯穿软件测试项目的始终，记录软件缺陷从发现、修复直至关闭软件缺陷的全过程。实验5介绍开源缺陷管理软件BugFree的软件缺陷管理思想，要求学生掌握BugFree安装与配置、软件缺陷管理等技能。（5）实验6：软件静态测试。软件静态测试是软件测试技术中发现软件缺陷效率最高的技术。我们安排“软件静态测试”专题讲座，讲解软件制品阅读、静态分析的技巧，还介绍如何运用CheckStyle、FindBugs等静态测试工具分析程序源代码、目标程序中潜在缺陷。本次实验有学生利用课后时间，自主实践。（6）实验7：JUnit单元测试。实验7介绍单元测试工具JUnit的使用，要求理解JUnit单元测试框架，掌握单元测试脚本的编写技巧。本次实验还推荐学有余力的学生自学JMock，综合应用JUnit和JMock进行对Java应用系统进行集成测试。（7）实验8：软件功能测试。软件功能测试是检验目标软件是否正确实现了客户需求，是软件测试执行的重要内容。实验8要求学生使用QuickTest Professional（简称QTP）对机票预订系统进行功能测试。本次实验要求学生能够独立完成功能测试脚本的录制和编辑，掌握QTP检查点设计的方法及技巧。（8）实验9：软件性能测试。实验9介绍软件性能的概念和原理，讲述如何运用HP Mercury LoadRunner对Web系统进行性能测试，让学生在实验过程中理解虚拟用户技术，掌握基于LoadRunner的性能测试技术的过程及技巧。此外，本次实验要求学生利用课余时间使用开源的性能测试工具JMeter进行软件性能测试。

3.创新项目实践。为了培养学生的工程实践能力，我们从学生课程项目、毕业设计、大学生创新项目、开源软件项目等中筛选出软件规模适中的软件系统作为课程实训项目，让学生对课程实训项目进行系统化的软件测试，要到学生主动动手实践，在软件测试项目实践中培养工程素养。

在课程教学过程中，我们还加强对基础扎实、动手能力强、思维活跃的学生的培养，推荐这些学生参与到教师科研项目中，为学生在科研项目中积累软件评测经验。

四、结束语

《软件测试与质量保证》通过十余年的建设已形成了较完善的课程体系，十多轮的授课实践积累了丰富的教学经验，课程实验教学体系也日趋完善。

当前，我校正转型应用技术大学，这将对本课程的教学内容、教学方法、教学手段等提出更多、更高的要求。鉴于此，本课程教学团队正尝试通过校企合作模式开展课程教学活动，编写校本教材，多措并举提升学生软件测试能力。

参考文献：

[1]朱少民.全程软件测试[M].北京：电子工业出版社，2007.

[2]NIIT.Software testing and quality assurance[M].上海：NIIT（中国），2011.

生产测井地面系统测试软件的开发 篇4

在生产测井的实施过程中, 测井数据的收集、存储和展示是一项非常重要的工作, 而完成这项工作的必要前提就是生产系统的正常运行。完善的生产测井系统可以完成对测井资料的及时分析利用, 能够对测井过程中存在的问题进行快速处理, 并发现生产测井系统的缺陷, 从而可以进行及时的维护。因此, 生产测井过程中, 对生产测井地面系统进行测试就显得尤为重要。

这里, 我们针对生产测井的实施工艺, 开发出一套灵活实用的地面系统测试软件。该测试软件根据系统硬件的设计需要, 不仅可以快速检测出系统硬件电路的异常, 还可以对测井过程进行高度仿真。除此之外, 系统测试软件还可以对数据可靠性和稳定性进行测试, 并找出数据传输最优的方式。因此, 该套软件对于仪器的安全稳定操作和日常维护有着重要的作用。

2 生产测井地面系统测试软件综述

2.1 系统测试软件的主要功能

生产测井地面系统测试软件要求满足系统硬件的设计需要, 对生产测井实施过程提供支持和维护, 对测井系统进行时时的检测, 因此, 软件设计需要包括以下几个方面的内容:

2.1.1

能够在Windows操作系统下运行, 要求数据传输迅速、记录操作简便;

2.1.2

要求具有实时测井的功能, 测试内容主要包括测井信号采集和计算、数据存储、曲线绘制、打印出图等;

2.1.3

要有完善的操作控制界面, 主要有菜单、人机交互对话框、服务表的选择和编辑、输入法设置、联机帮助、文件管理以及对其他测井处理进程的调度等;

2.1.4

必要的格式转换功能, 主要用来把现场资料转换为解释资料, 以便于进行解释处理。

2.2 系统测试软件的技术特点

2.2.1 兼容性设计

软件设计要满足基本的向下兼容要求, 由于软件的设计需要在以前的硬件系统、软件系统上运行, 并且要求能够被相关人员快速熟悉使用。因此, 在改进以前出现的不足的同时, 保持了原软件基本的设计思想, 操作上与老版本基本相同, 对以前的测井数据同样可以处理。

2.2.2 测井曲线的校准

如果测井深度与钻探深度不一致, 就要分析钻探深度是否正确, 如果正确那就要对测井曲线进行校准。本软件按照均匀插入或者删除数据的方式来对曲线进行拉长或者压缩, 从而满足正确的深度要求。

2.2.3 测井资料的管理和保存

要求软件的资料管理人性化, 直观化, 能够根据具体的需要来对目录进行设置, 从而完成测井数据的管理工作。要求用户可以进行测井文件的命名, 在文件名称重复的情况下, 需要提醒用户改名。另外, 还要对数据的时时保存功能进行设计, 以防止电脑突发故障后的数据丢失问题的发生。

2.2.4 测井曲线叠加处理及输出

软件设计中把测井曲线同时显示的条数设置为10条, 而且操作方式也比以前更加方便。这样不仅增加了结果的可视程度, 更方便了相关数据的对比分析工作。另外, 测井资料成果可以使用打印机进行输出, 并且可以将成果图转换为AUTO CAD输出。

3 生产测井地面系统测试软件的主要组成

生产测井地面系统测试软件主要采用模块化的设计思想, 包括以下三个部分:

3.1 汉字处理模块。

汉字处理模块通常采用由32点阵的汉字库以及64点阵的汉字库组成。

3.2 数据处理模块。

3.3 信号采集模块。

信号采集模块的采集过程主要通过前端的单片机进行, 并通过汇编语言程序进行编写。

一般情况下, 软件采用定时器产生采集事件, 并且要求每50ms就发生一个时间中断。当完成一组数据的采集之后就需要将数据发送到主机。数据的格式要求为附带同步字的可变帧结构。同时还为了达到时时测量的目的, 传输需要使用57.6kbps波特率以上的传输速率, 每秒要求发送20帧。

相关的生产测井地面系统软件处理过程图如下所示。

4 生产测井地面系统测试软件的实现

该生产测井地面系统测试软件在Windows XP环境下开发完成, 并且应用核心态设备驱动程序对数据底层的采集进行实现。同时, 还进行了多线程的客户程序的编写, 实现了数据的实时处理功能操作, 并创建了友好的人机交互界面。

4.1数据采集

生产测井采用WTC电缆遥测系统对数据进行传输。在WTC正常工作的过程中, 每40ms就向地面传送一帧数据。不同工作模式下客户程序都会通过USB通道进行数据传输。安装于底层的设备驱动程序首先要打开USB设备, 并进行相应的自检操作。启动信号采集任务开始后, 通过底层读管道方式从USB接口进行数据采集。如果用户发出各种命令, 就通过USB底层写管道将该命令发送到单片机系统, 控制井下的仪器完成相应的操作。

4.2 数据处理

数据采集完成后进入主机, 处理软件就会根据测井要求显示基本信息。根据传输模式和工作方式的选择, 确定如何进行数据处理。系统会根据不同的标志对数据进行相应的计算处理和信息显示。系统还能够根据不同的工作方式要求, 定时刷新显示数据, 从而实现时时动态监测。

4.3 良好的人机交互界面

由于该测试软件采用了良好的人机界面, 相关的每一项操作都有具体的按钮进行实现, 所以用户只需要点击相关按钮, 就可随意的完成任何工作模式下对数据的测试操作。

5 结论

本文中我们针对生产测井的实施工艺, 开发出了一套灵活实用的地面系统测试软件。该测试软件可以根据系统硬件的设计需要快速检测出系统硬件电路的异常, 还可以对测井过程进行高度仿真以及对数据的可靠性和稳定性进行测试。因此, 该套软件对于仪器的安全稳定操作和日常维护都有重要的作用。在今后的研究过程中, 要重视生产测井地面系统测试软件的开发, 这对生产测井工艺的实施具有重要意义。

参考文献

[1]尤晋元, 等.Windows操作系统原理[M].北京:机械工业出版社, 2001年.

[2]李安宗.综合化测井地面系统实时多任务采集软件的设计与开发[J].测井技术, 2007年.

[3]曲朝阳, 等.软件测试技术[M].北京:中国水利水电出版社, 2006年.

系统测试在软件开发中的重要作用 篇5

关键词：系统测试；软件开发；在线即时通信

中图分类号：TP311 文献标识码：A 文章编号：1674-7712 （2012） 18-0022-02

为了开发的软件满足用户需求，软件设计开发人员运用了大量分析、设计和调试方法，在分析设计的每个部分结束前，对相应的分析设计结果进行严格的审查和评定。由于人为能力有一定的局限性，审查很难发现所有的错误和缺陷，而且在编码调试阶段会引出大量的错误，在所设计的软件投入运行之后，这些缺陷和错误最终会暴露出来。而这可以通过系统测试来解决，系统测试就是在软件投入运行之前，对软件的需求分析阶段、概要设计阶段、详细设计阶段和编码部分的最终审查，是保证软件质量的关键步骤[1]。

一、系统测试的含义

系统测试是指为了发现软件的错误而执行程序的过程。系统测试的最基本任务是尽可能多的、彻底的检查出程序运行中的错误，提高软件系统的可靠性，从而能检验出系统是否存在问题。在软件开发的整个过程中，通常使用大量保证软件质量的方法分析、设计和实现软件，但仍然难免会出现一定的错误，从而导致软件产品中隐藏一些错误和缺陷。尤其是对于规模较大、复杂性较高的软件更会如此。在这些错误和缺陷中，有些是致命的，如果不排除掉，就可能会导致重大损失。基于这种情况迫使设计者必须认真计划、彻底地进行系统测试[2]。

二、系统测试的原则

系统测试的原则是必须最大限度地模拟出被测试软件的实际运行环境，以保证测试的可靠性[3]。

在进行有效无误的系统软件测试之前，系统测试工程师必须了解软件系统测试的基本原则：

（1）查找错误的源泉。系统测试的最终目标在于查找软件错误，而最严重的错误（用户角度）就是完成的用户需求分析模型是错误的。

（2）系统测试计划要在需求分析模型完成时形成，详细的系统测试过程要在软件的任意代码产生之前就进行计划和设计。

（3）Pareto原则。Pareto原则意喻在系统测试中发现的错误有80%可能来源于程序模块中的20%。

（4）系統测试应按照有“小规模”到“大规模”的方式进行。最初的测试要把焦点定位在单个程序模块上，然后在逐渐向集成的模块簇转变，最后在整个系统中寻找错误。

（5）穷举测试是无法实现的。选择尽可能充分覆盖程序逻辑关系的数据。

（6）系统测试的实现要由第三方来独立完成。创建系统的软件设计工程师不是构造软件测试的最佳人选。

系统测试工作人员通常站在用户的角度（第三方）来把握系统，并且在软件开发的整个阶段中时刻与用户进行不间断的交流和沟通，理解系统业务需求、理顺业务关系，测试系统的可靠性、可用性、正确性、完整性和可维护性等。依据软件开发各阶段的规格说明和程序的内部结构认真设计各种测试用例，用这些精心设计的测试用例去执行程序进行系统测试，以发现程序的错误。软件测试所追求的是通过各种不同的系统测试方法，发现软件中错误，完善丰富的错误诊断信息，以便于改正错误，达到预错误的发生，减少软件相应开发费用的目标[1]。

如果系统测试对软件的审查不够严格，引起了大量的错误，待到那时，不仅要付出很高的代价来改正这些错误，还会造成无法弥补的损失。系统测试在软件整个生命周期中主要经历两个阶段：通常在编写出每一个模块之后就对它做必要的测试，这称为单元测试。编码与单元测试属于软件开发生命周期中的同一阶段。在结束这个阶段之后，对整个软件系统还要进行各种不同的综合测试，这是软件生命周期的另一阶段，即测试阶段[2]。

三、系统测试的方法

黑盒测试和白盒测试是系统测试的基本方法。这两种方法主要是依靠一组精心挑选的测试用例为输入执行程序，对程序的行为进行逐个检验，确定其是否与软件预期的结果相符。因此，对系统进行实时性测试时，要借助相应的测试工具对应用程序的算法复杂度和操作系统的任务调度进行分析测试。从测试是否针对具体实现算法的角度和系统的内部结构来看，软件测试可以分成黑盒测试和白盒测试。

（1）黑盒测试又称为功能测试，它是通过测试输入和输出来检测每个功能模块是否都能正常使用。在测试过程中，把每个功能模块程序看作是一个不能打开的黑盒子，在完全不考虑其程序内部结构和内部特性的情况下，在程序的输入和输出接口处进行测试，它仅仅检查程序的每个模块功能是否按照需求规格说明书的规定正常运行，以及程序是否能准确地接收输入数据而输出正确的结果信息。黑盒测试主要是从程序的外部结构出发，不考虑程序本身的内部逻辑结构，主要针对的是软件界面和软件基本功能进行测试。黑盒测试是站在用户的角度，从输入数据与输出数据的对应关系出发进行测试的。这种测试方法的缺点是如果程序外部特性本身有问题或规格说明的规定有误，用墨盒测试方法是检测不出来的。

（2）白盒测试又称为逻辑驱动测试或结构测试，它主要按照程序内部的结构来进行测试的，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都是按照预定要求进行正确工作的。这种方法是把被测试对象看作一个打开的盒子，测试工程师依据程序内部的逻辑相关信息，设计或选择对应测试用例，对程序所有可能的逻辑路径进行测试，通过在不同的测试点检查程序的状态，确定实际的状态是否与预期的状态一致[4]。

四、系统测试举例

这里以用户自行开发的一款在线即时通信系统为测试用例进行系统测试，本系统实现的通信功能极其复杂，运用多个线程进行前台和后台的消息发送和接收。使用ServerSocket创建要连接的端口，线程连接socket打通前后台的消息通道。在线即时通信系统登录界面如图1所示。

nlc202309021002

根据这一逻辑，在线用户登陆成功后就将登陆ID保存在线程中，打开在线好友通信窗口时，也会将接收者的ID进行保存，这样就能正确保证消息的发送者和接收者。消息的传递会通过前台发送给连接后台的线程，经后台线程处理后，找到接收者，再将信息进行转发，这样就完成了好友间的在线即时通信。同时，在用户登录时，也会进行上线提示，将自己在线情况通知给所有在线用户，又将所有在线用户的状态进行显示。这样就能正确的显示在线用户列表，也能准确的实现在线用户间消息传递。

在线即时通信模块功能测试过程和要求如下：

1.登录模块

（1）测试描述。用户需正确输入用户名和密码，才能正确登录并跳转到好友列表界面。系统默认用户名为1-50之内的任意数字，密码为123456。

（2）测试步骤。首先打开在线即时通信登录界面，输入用户名和密码；然后点击登录按钮；最后确认是否能够正常登录。

（3）合格标准。输入正确的用户名和密码后，能够成功登录，并跳转到我的好友列表；或者用户名和密码不正确时会弹出相应的错误提示。

2.好友列表界面

（1）测试描述。登录成功的用户在好友列表会以彩色头像显示，后登录的用户会通知所有在线用户更新好友列表。双击在线好友能正确打开通信对话框。

（2）测试步骤。首先由登录用户跳轉到好友列表，确认好友列表可以将自己的头像设置成彩色在线状态；然后再登录一个用户，确认能正确通知所有在线用户进行好友在线更新，鼠标滑过在线用户时，确认是否有不同颜色提示；最后双击在线好友头像，能实时打开通信对话框。

（3）合格标准。登录成功在好友列表显示自己的头像为彩色在线状态，并获取所有在线好友；后登录的用户会通知所有在线用户更新自己的在线好友列表；鼠标滑到在线用户名上时，用户名由黑色变为红色；鼠标滑过时，又会从红色变为黑色；双击在线好友，能成功打开通信对话框，发送者和接收者均正确。

3.通信界面

（1）测试描述。在线好友间的消息能够准确发送和接收，并正确显示在通信界面上。

（2）测试步骤。首先互相打开在线好友的通信界面；然后在文本框中输入通信内容，可以是任意字符，点击发送按钮；最后确认发送的消息是否能准确显示在接收者的通信界面上。

（3）合格标准。输入任意通信内容，点击发送后，接收者的通信界面上即时显示好友发送的消息，同时好友也能接收返回的信息，并正确显示。

五、总结

将系统测试的基本方法用于软件开发过程中，可以增加软件的可靠性，使软件在投入运行之后基本不出错误，或者错误很少。对实际开发的软件系统按照测试步骤进行测试，满足测试通过原则的软件系统安装到用户现场能够顺利实施和运行，得到用户认可。

参考文献：

[1]马瑞芳，王会燃.计算机软件测试方法的研究[J].小型微型计算机系统，2009，12.

[2]张新华，何永前.软件测试方法概述[J].科技视界，2012，2.

[3]郭远东，黄荣瑛.基于模块化设计的嵌入式软件测试方法[J].单片机与嵌入式系统应用，2005，1.

[4]冯博琴.软件开发技术[M].北京：高等教育出版社，1996.

[作者简介]王丽平（1974-），女，汉族，吉林长春人，长春工程学院，讲师。

软件系统的测试 篇6

软件测试是软件开发过程中必不可少的过程,其目的在于找出软件中潜在的错误或缺陷。一般而言,软件测试根据软件开发过程中规格和结构设计的测试用例进行,输入数据并运行程序,测试输出结果与预期的区别,以发现软件的错漏之处。因此,软件测试贯穿着软件开发的全过程,对于规范化设计软件意义重大。为了能用更少的测试用例来达到最大覆盖、查缺的结果,软件测试需要选用科学合理的策略。

1 软件测试策略

在软件测试之前,首先需要确定的是测试策略,它是软件测试的模板。软件测试策略一般分为2种:传统测试策略、现代测试策略。

传统软件测试策略将软件测试置于软件开发的最后阶段,在软件设计完成后才开始进行测试,对软件测试的重视程度缺乏。这种传统策略的缺点在于可能会导致软件开发前期中产生的错误缺漏不能被及时发现,为软件测试增添压力,也不利于软件测试得出详细、全面的分析结果。传统软件测试策略遵循的瀑布模型如图1所示。

现代测试策略能更好地强调了软件测试的重要性和贯通性。它将软件测试贯穿于软件开发全过程中,根据每一阶段进行详细的分析记录,以实现软件测试功用的最大发挥。现代软件测试策略具体内容如下:第1步,确定测试目的。根据不同软件的特性和要求确定好测试目的,只有确定了目的,才能够更好地进行软件测试;第2步,确定测试对象及范围。对象包括整个系统、子系统、模块、某变量等,测试范围覆盖功能、性能、恢复性等方面,将软件测试集中于特定对象和范围,能够达到事半功倍的效果;第3步,选择、描述测试环境和方法。第4步,记录并跟踪测试过程,最后得出测试结果。现代软件测试策略遵循的是双V模型,如图2所示。

2 软件测试方法简述

软件测试的目的和对象众多,因此其方法和手段也具有多样性。本文将对其中较基本的几种软件测试方法进行简述。

2.1 静态测试与动态测试

软件测试按使用的测试技术不同可以分为静态测试和动态测试2个阶段。

其中,静态测试是以文档文件、源程序做结构分析、数据定义控制等为基础,对软件进行分析,在不实际运行被测试的软件的情况下,找寻软件的逻辑设计错误。静态测试可以分为静态分析和代码审查,代码审查是一种人工测试方法,包括代码评审和走查,它的运用是测试人员通过经验来阅读程序的代码,发现软件编码和运行上的缺陷、错误。它采用的具体方法主要有:检查分析文档资料、寻找逻辑错误、讨论分析决定、利用工具审查程序代码等。

动态测试则是基于测试用例,通过运行软件来检验被测系统的动态行为,以动态的运行进行测试分析。动态测试两要素分别是被测试程序和测试用例,它的适用范围主要在单元测试、集成测试、验收测试等阶段。

2.2 黑盒测试与白盒测试

黑盒测试更侧重用功能性,又称为功能测试,它是将被测对象视为封闭的黑盒,不考虑其内部程序和结构,基于规格说明书对程序接口运行动态测试的方法。它着眼于验证软件功能正确性,根据软件产品的功能设计规格求证是否符合软件预期功能性要求,主要试图发现几类错误:功能不正确或遗漏、界面错误、输入和输出错误等。白盒测试与黑盒测试相对,把测试对象看做一个打开的盒子,更侧重于软件结构性测试,又被称为结构性测试。在计算机上按照程序内部的逻辑结构及相关信息进行测试,求证内部操作的规范性,并扩大软件覆盖程度。白盒测试是对软件细致的检查,它在不同点检查程序状态,在细节上更为注意。白盒测试主要采用逻辑驱动、基路测试等方法,它是穷举路径测试,因此,这一方法需要一定的前提,即测试者需要了解检查程序内部结构和逻辑,以此为基础确定测试数据。

2.3 积极测试和消极测试

积极测试是以验证软件是否符合需求为目的,通过输入一个积极值(即有效值)的方法进行有效性设置,因为它是直接输入数值并期望得到有效测试的方法故又称为正向测试。消极测试与之相对,又称反向测试,其原理是输入消极值(即无效值),看是否能得出输入值无效的结果。积极测试在于检测软件系统是否能有效运行,消极测试则是要中断软件执行,测试软件是否限定在有效范围内运行。一般来说,消极测试的方法更为开放,因此其测试用例数量远超过积极测试,消极测试是一种非常开放的测试方法。一般来说,消极测试用例的数量要远远大于积极测试用例的数量。

3 测试方法的应用

3.1 单元测试

单元测试是针对模块进行检测,通过测试来求证模块功能性和正确性。模块是软件设计中最小的单位,由于它规模小,功能单一,逻辑简单,因此在测试中选用白盒法和黑盒法结合、一个为主、另一辅助的手段。测试者在了解模块说明和源程序的基础上,明确被测模块的I/O条件及其逻辑结构,然后通过白盒法,利用测试用例最大覆盖的进行检测,同时以黑盒法加以辅助,达到内外逻辑、结构都彻底检测的结果,使任何合理、不合理的输入都能得到正确响应。

3.2 集成测试

集成测试是针对组装起来的模块进行检测,以寻找接口的问题和缺漏。将模块按照设计要求进行组装然后检测能够发现跟接口相关的一些问题:如数据丢失、模块间有害影响、组合功能偏差等。集成检测在软件检测过程中介于单元测试和系统测试之间,它对软件结构性能的测试起着承上启下的重要作用,通常,集成检测阶段会采用黑盒法和白盒法结合的方法。

3.3 系统测试

系统测试阶段旨在检查系统是否符合软件需求,相较于前2个阶段更为复杂,这是因为软件开发过程中任何变动都会改变功能的增删,需要根据情况不断更改程序,而更改完的程序也可能因为一些问题会重新测试。系统测试需要检测软件功能、用户界面、安全性等方面,对全面性和客观性要求较高,因此,在系统测试阶段中采用的测试方法一般是黑盒方式。鉴于系统测试的特殊性,其测试应由独立测试小组来执行,针对系统测试中各单元模块,一般组合按照自下而上法、自上而下法、隔离测试法相结合的先后顺序进行检测。

3.4 验收测试

验收测试是由用户执行的体验测试,这一阶段和系统检测除了执行者外没有很大区别,验收测试的目的是向未来用户展示软件运行的能力和有效性,其主要任务是验证软件是否符合用户的要求和期待。

在这4个测试过程完成后,软件基本上能够满足开发要求,然后提交给开发部门进行调整补缺最后交给用户。

4 结语

软件测试密切关系到软件的质量和用户满意程度,对于软件开发具有至关重要的作用,其重要性在近些年越来越凸显,受到人们的重视。为了更好的适应软件开发的进步和发展,软件测试的策略和方法也应当向适应大规模、复杂软件的方向转变,通过不断在应用中总结经验进行完善,更好地在软件测试中选用科学、合理的策略方法。

摘要：软件测试是软件开发过程中十分重要的一环。文章基于软件测试的策略和方法,探讨其在软件开发过程中的应用,着重探讨如何使软件测试工作高效而可靠地运行。

软件系统测试类型及测试用例设计 篇7

随着航空型号功能的日趋复杂, 软件在型号中的应用越来越多, 其规模和复杂度也日趋上升。由软件所导致的问题的比例也在上升, 软件已经成为影响航空型号产品质量和可靠性的关键因素之一。软件测试作为软件研制的重要环节, 其是否充分、有效, 将直接影响到软件产品的质量[1]。

软件测试类型按照开发阶段分为单元测试、部件测试、配置项测试和系统测试[2]。对于航空型号软件而言, 系统测试是最重要的测试, 它能够发现软件中潜藏的时序、软硬件接口等方面的问题。

1 系统测试概述

系统测试是在真实系统工作环境下或系统仿真环境下检验完整的软件配置项能否和系统正确连接, 并满足系统设计文档的要求[3]。系统测试过程描述见图1。

2 系统测试类型及测试用例设计要求

常见的系统测试类型分为功能测试、性能测试、边界测试、接口测试、余量测试、安全性测试、强度测试等[3]。不同的测试类型, 在设计测试用例时, 其测试点各有不同, 下面结合测试实践经验, 对不同的测试类型的测试点进行分析。

2.1 功能测试

功能测试是对软件需求规格说明中的功能需求逐项进行的测试, 以验证其功能是否满足要求。其测试点包括:

1) 用正常值的等价类输入数据值测试;

2) 用非正常的等价类输入数据值测试;

3) 进行每个功能的合法边界和非法边界值输入的测试;

4) 用一系列真实的数据类型和数据值运行, 测试超负荷、饱和及其他“最坏情况”的结果;

5) 对控制流程的正确性、合理性等进行验证。

功能测试是最基本的测试, 同时也是最重要的测试。在进行功能测试时, 首先要明确功能测试的正常等价类, 同时在用例设计中别遗漏了正常等价类;根据输入数据的属性展开想象, 设计非正常的功能测试用例, 并且注意预期结果;设计测试用例时, 一方面分析输入数据, 另一方面分析操作流程。

2.2 性能测试

性能测试是对软件需求规格说明中的性能需求逐项进行测试, 以验证其性能是否满足需求。其测试点包括:

1) 数据采集功能的测试;

2) 测试在获得定量结果时程序计算的精确性 (处理精度) ;

3) 测试其时间特性和实际完成功能的时间 (响应时间) ;

4) 测试为完成功能所处理的数据量;

5) 测试程序运行所占用的空间;

6) 测试负荷潜力;

7) 测试软件的性能和硬件性能的集成;

8) 测试系统对并发事物和并发用户访问的处理能力。

性能测试经常与余量测试、强度测试、容量测试一起进行, 基本的性能度量应当首先以没有争议的方式在主要的功能上被执行;其次在系统处于竞争模式下进行, 即在一种苛刻的环境中衡量资源的使用常常是必要的。

2.3 边界测试

边界测试是对软件处在边界或端点情况下运行状态的测试。边界测试测试点包括:

1) 软件的输入域或输出域的边界或端点的测试;

2) 状态转换的边界或端点的测试;

3) 功能界限的边界或端点的测试;

4) 性能界限的边界或端点的测试;

5) 容量界限的边界或端点的测试。

边界测试是最为普遍的测试类型之一, 几乎所有的软件都有边界测试。看到有范围和数值要求时, 应立刻联想到数值边界;同时注意不同分辨率 (数据精度) 的边界, 如整数和浮点数的范围、角度的范围、时间的范围等。

2.4 接口测试

接口测试是对软件需求规格中的接口需求逐项进行的测试。接口测试的测试点包括:

1) 测试所有外部接口, 检查接口信息的格式及内容;

2) 对每一个外部输入/输出接口必须做正常和异常情况的测试;

3) 测试硬件提供的接口是否便于使用;

4) 测试系统的特性 (如数据特性、错误特性、速度特性) 对软件功能、性能特性的影响;

5) 对所有的内部接口的功能、性能进行测试。

接口测试往往与软件的功能测试结合在一起, 但是接口测试的关注点是接口。接口测试同样需要考虑正常与异常数据的情况, 并且明确所测对象有哪些接口, 然后根据接口的格式特点设计用例。

2.5 余量测试

余量测试是对软件是否达到需求规格说明中要求的余量的测试。按照国军标要求, 一般至少留有20%的余量。余量测试的测试点为:

1) 全部存储量的余量;

2) 输入/输出及通道的吞吐能力余量;

3) 功能处理时间的余量。

余量测试需要分析能够进行余量测试的测试项。余量测试一般为隐含需求, 一般要求留有20%的余量;只要所测对象含有数据要求均可考察其余量, 目前比较重视主要是硬件配置方面的余量;余量测试需在任务较繁重的前提下进行, 并对余量提取是否合适进行确认。

2.6 安全性测试

安全性测试是检验软件中已存在的安全性、安全保密性措施是否有效的测试。其测试点包括:

1) 对安全性关键的软件部件, 必须单独测试安全性需求;

2) 在测试中全面检验防止危险状态措施的有效性和每个危险状态下的反应;

3) 对设计中用于提高安全性的结构、算法、容错、冗余及中断处理等方案, 必须进行针对性测试;

4) 对软件处于标准配置下其处理和保护能力的测试。

5) 应进行对异常条件下系统/软件的处理和保护能力的测试;

6) 对输入故障模式的测试;

7) 必须包含边界、界外及边界结合部的测试;

8) 对安全性关键的操作错误的测试;

9) 对具有防止非法进入软件并保护软件的数据完整性能力的测试;

10) 对重要数据的抗非法访问能力的测试。

2.7 强度测试

强度测试是强制软件运行在不正常到发生故障的情况下 (设计的极限状态到超出极限) , 检测软件可以运行到何种程度的测试。其测试点包括:

1) 最大处理的信息量;

2) 数据能力的饱和实验指标;

3) 最大存储范围 (如常驻内存、缓冲等) ;

4) 在人为错误 (如寄存器数据跳变、错误的接口) 状态下进行软件反应的测试;

5) 需进行持续一段规定的时间, 而且连续不能中断的测试。

3 软件系统测试设计

3.1 系统测试用例设计策略

具体的软件测试项目中, 设计测试用例有多种方法, 对于简单的功能, 选取一种适合的方法即可满足要求, 而对复杂的功能, 运用某一种方法设计出的用例显然不能全面的覆盖各个测试点, 应该联合使用各种的方法, 形成一种综合策略。具体地说, 可以归纳为下述策略:

1) 将测试需求分解为测试项, 选用的测试类型的集合要覆盖规定的测试类型, 对现有条件无法测试的测试项 (不可测项) 要给出不可测的原因, 并给出降低风险的方法;

2) 在编写某一测试类型测试用例时, 要尽可能多地覆盖相应的测试要求;

3) 对重要功能使用频度高的功能, 可适当增加测试用例数量 (包括对各种可能出现的异常情况的考虑) ;

4) 对静态分析中复杂度高的模块所对应的功能适当增加测试用例数量;

5) 在一个功能中发现缺陷后, 要生成用例测试其余功能是否存在同样缺陷;

6) 依靠专业积累, 彻底全面地思考测试场景, 发现并有效的找出隐错;

7) 测试类型并非正交的, 多个测试类型之间存在交叉, 设计测试用例时应把握二个原则:即不能重复、不能遗漏。

3.2 测试实践

在某软件系统测试过程中, 依据软件设计文档进行了测试需求分析和策划, 制定了测试计划, 明确了测试项, 并编制了测试说明, 对软件进行了全面的测试, 共设计了31个测试项目、648个测试用例, 覆盖了功能、性能、边界、接口、余量、强度和安全性所有的测试类型 (见表1) , 达到了国军标对软件测试类型的覆盖要求, 也对软件设计文档的各项设计要求及相关指标进行了测试验证。

表1测试项目及测试用例覆盖情况统计表

在设计测试用例过程中, 有些用例可以按照第2章节描述的方法进行独立设计, 但大部分测试用例的设计需要采用组合策略, 既满足覆盖性要求, 同时也提高测试的效率。表2列举了在测试过程中, 针对不同的测试类型分解的部分测试项的实例。从表2可以看出, 既有通过组合设计的测试项目, 也有进行独立设计的测试项目。

3.3 测试结果评价

在某软件的测试中, 根据以上测试类型综合设计测试项, 使设计出的测试用例更合理, 更全面。通过执行这些用例, 对软件功能进行了全面的测试, 发现了软件在设计方面存在的问题。软件测试工作通过了上级部门组织的评审, 对软件是否实现了预期的功能和是否可以进行系统联试起到了良好的评价作用。

4 结论

本文介绍了常见的系统测试类型及其用例设计方法, 这些方法都是在日常测试任务中实用的设计方法。在实际的测试过程中, 通过各种测试类型的交叉和组合应用来设计用例, 可以有效地对软件进行测试, 提高了测试效率, 降低了测试成本。该系统测试用例设计方法已用于多个型号软件的测试过程, 经证明是一个通用性强、切实有效的设计方法。

参考文献

[1]弹载软件系统测试方法研究.科学技术与工程[J].2008, 8 (13) :3559-3562.

[2]石柱.软件工程标准手册[M].北京:中国标准出版社, 2004.

嵌入式软件中断系统的测试研究 篇8

1 静态测试技术

软件静态测试技术主要包括代码审查和静态分析。不同的芯片中断代码的设计也存在一定的差异,且中断处理代码存在的问题可能根据具体应用的不同而存在,因此静态分析工具一般不具备对中断代码存在问题的详细分析。因此对中断程序的静态测试技术主要还是采用代码审查方法进行。代码审查的要点主要包括以下几类。

1)中断资源冲突检查

中断资源使用冲突是中断使用中最有可能发生的问题。中断资源冲突检测主要对中断中使用的公共资源进行分析,包括全局变量、寄存器、缓存区域、标识等。检查的第一步是筛选出中断与主程序、中断与中断中均使用的公共资源。第二步是对这些资源的读写情况进行分析,每个资源在程序中的使用存在三种情况:只读、只写和读写,这三种情况在主程序、中断处理程序中都可能存在。通常,一个资源在中断和主程序或不同中断中均为只读,或者主程序只在中断未使能状态下对资源进行访问时,一般不存在冲突。而在主循环和中断中,或不同中断中进行了修改的资源则一般需要仔细分析冲突的可能。图1则描述了一个中断资源冲突案例。

图1 中中断程序用于接收数据,接收完成之后置接收标志。主程序用于处理接收到的数据,处理完毕后清接收标志。接收第一帧数据接收完成后,主程序开始处理数据,如果在处理过程中又接收一帧新数据,则该数据会丢失不被处理。对共用资源进行冲突检测通常还需结合软件时序进行分析。

2)中断现场备份和恢复

中断处理程序执行会打断主程序,且主程序中发生中断的位置一般不固定,为了保护被打断的主程序现场,需要在中断程序开始处对主程序现场进行备份,并在出口处进行恢复。对中断程序进行代码审查时需要检查需要备份的资源是否都进行了备份。这些资源通常包含程序状态寄存器、与主程序共用的寄存器以及一些全局变量。中断处理程序在入口处会对这些资源进行压栈操作,而在出口则进行出栈操作。代码审查需要检查需要被保护的资源是否已经全部被保护,各资源入栈和出栈的顺序是否匹配。

3)中断优先级

各种不同的芯片对中断优先级的处理是不一样的,例如8051 芯片只能设置高、低两种级别的中断;TI的F2812 芯片则各中断源的中断优先级固定的;而ARM芯片的中断优先级则是可编程的。且有些芯片的中断是可嵌套的,有些芯片则不能嵌套。对中断程序的代码审查应考虑到各芯片的具体特点,例如对不可嵌套的中断,则需考虑高优先级中断被延迟的问题,即如果在低优先级中断执行时,高优先级中断到来,则高优先级中断被延迟执行,该延时是否满足设计的要求。而对于可嵌套的中断,则需要考虑低优先级的中断被高优先级打断后,共用的中断资源是否存在冲突。对于中断优先级可编程的芯片,代码审查时还需检查中断优先级的设置是否正确,低优先级的中断被延迟或打断后,是否满足设计的要求。

以上是对中断程序进行代码审查时,需重点检查的要点。当然代码审查还应根据具体应该包括其他一些方面,例如对有些安全性要求比较高的软件则要求对未使用的中断应设置跳转到陷进程序,以防止软件异常进入未使用中断时,能够进行复位防止跑飞。还有一些芯片的编译器会对内存访问进行优化处理,则中断和主程序的共用资源则需声明为volatile类型,使芯片每次从内存取数,防止内存和寄存器数据不一致引发问题。在对中断程序进行代码审查时,如果注意到以上几点,能够有效地减少代码中存在的问题,提高软件的质量。

2 动态测试技术

对中断程序的动态测试主要包括测试中断程序的响应时间和处理时间。中断响应时间是从触发中断到中断程序开始执行之间的时间,中断处理时间则是从中断开始处到结束处的执行时间。对于响应时间和处理时间的测试,主要是测试时间是否满足软件需求的要求。

软件只存在一个中断,或存在多个中断,但不会同时发生时,一般响应时间和处理时间可直接测试;当软件存在多个可同时执行的中断时,则很难直接得到中断的响应时间和处理时间。存在以下几种情况:

1)两个中断同时到来,则程序会先执行高优先级,则低优先级中断被延迟执行,因此其响应时间则应包括高优先级中断的处理时间;

2)程序执行一个中断时,另一个中断触发,但该芯片不支持嵌套执行,则第二个中断响应时间包括第一个中断的部分执行时间;

3)程序执行低优先级中断时,发生高优先级中断,且该芯片支持中断嵌套,则低优先级的处理时间应包括高优先级中断的执行时间。

测试人员一般需要得到中断最长的响应时间和处理时间,上述情况在动态测试时不一定能够测量到,因此测试人员可先测量每个中断单独发生时的响应时间和处理时间,再根据芯片特点和程序中断执行时序计算理论上的最长响应时间和处理时间。

动态测试时,还需考虑中断处理时间对主循环处理时间的影响。例如,一个程序,存在两个中断,每个中断的处理时间均为200ms,程序主循环要求500毫秒内执行完毕,不发生中断时主循环的处理时间为200ms。当在一次主循环执行过程中,只发生一个中断时,程序主循环执行时间满足要求,但如果两个中断均发生,则执行时间为600ms,不满足处理要求。尽管该事件可能很少发生,但程序仍存在潜在问题。

3 结束语

本文从静态和动态两方面总结了嵌入式软件中断测试技术,这些技术在实际的嵌入式软件测试工作中的应用可有效减少中断程序的错误。嵌入式芯片类型多种多样,应用场景也各不相同,因此这些技术在实际测试工作中也需要灵活使用。

摘要：由中断引发的软件故障往往具有隐蔽性和随机性,因此嵌入式软件中断系统测试是嵌入式软件测试中的难点。该文对中断测试技术进行了研究,从静态和动态测试两方面总结了测试需关注的重点,通过使用文中的测试方法,发现中断系统中一些常见的问题。

软件系统的测试 篇9

关键词：软件测试,软件工程,认识误区,持续改进

1 引言

随着市场对软件质量的不断提高和国内软件测试行业的逐渐发展, 软件测试不断受到重视, 有越来越多的软件企业更加重视软件测试, 并已经形成了一套基本的软件测试流程。然而, 认识误区的存在需要我们进一步改进软件测试过程。

2 软件测试概述

软件测试就是在软件投入运行前, 对软件需求分析、设计规格说明书和编码的最终复审, 是软件质量保证的关键步骤。一般按四个步骤进行, 即单元测试、集成测试、确认测试和系统测试及发版测试。随着软件危机的频频出现, 人们已经开始认识到测试开始的时间越早, 测试执行的越频繁, 所带来的整个软件开发成本的下降就会越多。所以, 软件测试在软件项目实施过程中的重要性日益突出。

3 软件测试过程中的认识误区

3.1 软件开发完成后进行软件测试

人们一般认为, 软件项目要经过以下几个阶段:需求分析, 概要设计, 详细设计, 软件编码, 软件测试, 软件发布。据此, 认为软件测试只是软件编码后的一个过程, 这是不了解软件测试周期的错误认识。软件测试是一个系列过程活动, 包括软件测试需求分析, 测试计划设计, 测试用例设计, 执行测试。因此, 软件测试贯穿于软件项目的整个生命过程。在软件项目的每一个阶段都要进行不同目的和内容的测试活动, 以保证各个阶段的正确性。软件开发与软件测试应该是交互进行的, 否则, 测试的时间将会很短, 测试的覆盖面将很不全面, 测试的效果也将大打折扣。

3.2 测试过程不够完善

在软件开发领域, 确实存在一些东西看起来要比另外一些东西难测试一些, 但是远非无法测试。只不过这种不可测试性不是由于被测试的软件内部的过紧耦合造成的, 而是和外部某些很难测试的部分耦合过紧, 从而表现出被测试的软件本身很难测试。这些很难测试的部分比较常见的有:图形界面、硬件、数据库等。

3.3 强调测试用例设计得越详细越好

在确定测试用例设计目标时, 一些项目管理人员强调测试用例“越详细越好”。这种做法和观点最大的危害就是耗费了很多的测试用例设计时间和资源, 可能等到测试用例设计、评审完成后, 留给实际执行测试的时间所剩无几了。因为当前软件公司的项目团队在规划测试阶段, 分配给测试的时间和人力资源是有限的, 而软件项目的成功要坚持“质量、时间、成本”的最佳平衡, 没有足够多的测试执行时间, 就无法发现更多的软件缺陷, 测试质量更无从谈起了。

3.4 追求测试用例设计“一步到位”

现在软件公司都意识到了测试用例设计的重要性了, 但是一些人认为设计测试用例是一次性投入, 测试用例设计一次就“万事大吉”了, 片面追求测试设计的“一步到位”。这种认识造成的危害性使设计出的测试用例缺乏实用性, 或者误导测试用例执行人员, 误报很多不是软件缺陷的“Bug”, 这样的测试用例在测试执行过程中“形同虚设”, 难免沦为“垃圾文档”的地步。

4 软件测试过程的持续改进

4.1 计划与风险

项目计划对项目过程的实施有着直接的指导作用, 它的重要性是不言而喻的。对于软件测试来说, 测试计划也是指导后续测试工作的基础, 只有对过程中各任务进行更详细的计划, 才有利于在测试过程中对项目进度的把握有一个明确的目标;同时, 风险策略的制定, 也有利于对及早对测试过程中可能遇到的问题做出分析, 以便在问题出现时能够尽可能的减少规避风险的成本。

4.2 评审

在测试过程中的每个阶段结束前, 都会输出一些资源, 文档、用例等等, 这些资源往往是下一个测试阶段或软件开发的下一个环节执行的依据。评和审是结合在一起的, 每个角色根据自己对项目的了解, 从各自角度来审核测试报告的充分性, 对质量风险发表各种见解。最终, 对报告的规范性也要进行考察。另外, 也最好根据实际情况组织会议评审来对一定规模的问题统一评审。

4.3 文档

文档的编写对于测试人员来说是一个十分重要的任务, 深入的、充分的投入测试的测试人员能写出高质量的测试文档。所以, 测试文档的质量, 往往反映了测试人员执行测试的广度和深度。而在文档的编写方面, 首先必须形成统一规范;另外, 针对不同项目的测试, 可以适当对文档标题、内容进行简化。总之, 文档模板一旦形成, 必须严格遵守。

4.4 方法与策略

测试方法和测试策略, 测试的重中之重。测试的策略一般要求从全局方面对测试的阶段、每个阶段的测试类型进行考虑、定义。而测试的方法更多是体现在一个具体的测试中, 采取怎样的测试思路。另外, 在测试过程中, 对资源的协调也非常关键, 需要能保证测试资源充分利用, 每个测试人员都有适度并且相当的工作量。

4.5 总结测试经验

在测试的过程中, 测试人员应该及时总结发现的错误并归类, 标明经常容易出错的地方, 将意见提交项目经理, 审核后, 制定出一份统一标准并提供给开发人员, 这样就可以提前避免错误、避免重复错误和重复测试, 提高测试效率。不仅如此, 项目结束后的各项总结报告将是项目的后期维护或二次开发的宝贵参考资料。

4.6 缺陷分析、度量

对测试活动过程中发现的缺陷进行分析、度量, 寻找软件开发过程中存在的问题, 并持续改进开发过程, 提高质量。缺陷的分析、度量从时间上分为两个方面, 首先是在软件开发过程中发现的缺陷进行分析、度量;然后就是, 对软件产品发布后, 对用户提出缺陷进行统计、分析。

5 结论

测试是用来保证软件开发过程的高效性, 以及保证开发出来的软件产品的高质量和可用性的。软件开发本身就是一件非常困难的事情, 这也决定了有效的测试是非常重要的环节, 我们要加强对软件测试的关注, 使大家对于测试首先有一个正确的认识, 避免误区的存在, 并积极探索测试方法的持续改进问题, 真正使软件测试真正起到它应有的作用。

参考文献

[1]郑人杰.计算机软件测试技术[M].北京:清华大学出版社, 1992.

[2]Fewster M, Graham D.软件测试自动化技术[M].北京:电子工业出版, 2000.

[3]林锐, 王慧文, 董军.CMM13级软件过程改进方法与规范[M].北京:电子工业出版社, 2002.

关于软件测试的阶段分析 篇10

关键词：软件测试；信息技术；故障

中图分类号：TP311 文献标识码：A 文章编号：1674-7712 (2012) 06-0088-01

随着计算机软件技术的诞生，软件测试软件业应运而生。在对软件进行测试则不是简单的测试，在测试过程中，还应该包含对BUG进行解决的开发任务，这也就是说，在软件测试的周期范围之内必须进行测试时间以及开发修复的时间进行充分的评估。而且进行软件测试的主要任务就是为了对软件产品和系统当中所存在的各种各样的问题能够迅速、快捷的找出，并且在此基础上，敦促对这些问题程序员要做到尽快的进程处理和解决，使得具备高质量的软件产品能够向客户及时的进行提供。通过研究发现，进行软件开发过程当中所面临的重要内容之一就是进行软件测试，这是对所提供的软件的质量进行保证的关键性因素之所在。在整个软件开发的开发生命周期当中必须使用软件测试进行贯穿，也就是说，在软件项目刚开始实施，伴随着的就是继续软件测试，再一直延伸到对软件产品的市场需求进行分析审查，乃至对软件进行的验收测试。将软件中的故障寻找并且纠正这是进行软件测试的主要目的，软件测试并不仅仅是对软件中的错误发现的过程，还应该对软件的质量进行评价。软件测试所选取某个程序或者是系统属性作为目标进行评价的活动，而且软件质量的度进行区分就是软件测试。对于被测软件的质量进行度量和提高这就是软件测试的原因，并且贯穿于工程设计、维护和实施的整个测试件的整个生命周期过程当中。在所有的工科学科当中，其中基本的组成单元则为软件测试，软件测试这也可以作为进行软件开发的重要组成部分二存在。进行软件测试的基本要求的必须对软件测试进行组织。而随着当前我国不断增大的软件开发规模，这其中所包含的复杂程度也相应的增大，对于软件当中的错误作为目标去寻找进行测试工作则显得难度增大。可是在进行程序当中的错误尽最大可能的找出，使得所生产出来的软件产品具备高质量，这就显得非常重要对组织和管理测试工作。并且要做到进行软件测试的过程中做到合适测试方法的选择。通常来说，一整套完整的软件测试必须分为以下五个阶段实施：

一是对软件测试进行计划。首要的就是必须按照客户的需求报告当中相关的性能指标和功能要求等的规格说明书，对相对应的软件测试需求报告进行科学定义，这也就是对于黑盒测试当中的最高标准进行制订，以后所进行的软件测试工作必须根据软件测试要求进行实施，当软件应用程序对软件测试需求相符合的话则表示该应用程序合格，而当软件应用程序对软件测试需求不相符合的话则表示该应用程序不合格。另外，要对软件测试的内容进行合理的选择，对测试资源、测试时间和测试人员等进行科学合理的安排。

二是对软件测试进行设计。通过对软件测试计划阶段当中所制订出来的软件测试需求进行有效的细化和分解为能够有效执行的测试过程，由于选择的测试用例的好坏对于测试结果的有效性能够产生直接的影响，所以在所有的软件测试过程当中对软件测试用例进行合理的选择。

三是对软件测试进行开发。在这一过程当中可以根据能够重复使用的软件自动测试过程进行建立。

四是对软件测试进行执行。对软件自动测试的过程进行有效建立这是对软件开发阶段进行执行的有效举措，并且对软件进行跟踪管理所发现的缺陷。通常来说，进行软件的测试执行一般所分成的组成步骤是回归测试、系统联调、集成测试、组合测试和单元测试，软件测试人员在进行软件测试的时候必须抱有的态度是负责科学，按照程序进行测试。

五是对软件测试进行评估。结合量化的測试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。

然而，传统的测试技术和方法，对面向对象技术开发的软件多少显得有些力不从心。鉴于此，提出了面向对象的测试技术！面向软件测试技术是新兴的软件测试技术，是专门针对使用面向对象技术开发的软件而提出的一种测试技术。面向对象软件测试是根据面向对象的软件开发过程结合面向对象的特点提出的。它包括分析与设计模型测试技术、类测试技术、对象交互测试技术、类层次结构测试技术、面向对象系统测试技术等。

当然给软件带来错误的原因很多，具体地说，主要有如下几点：

1.交流不够、交流上有误解或者根本不进行交流。

2.软件复杂性。

3.程序设计错误。

4.需求变化。

5.时间压力等等。

要解决这些错误就应该做好测试工作，尽早的开始测试工作，并且测试工作贯穿于软件开发的整个生命周期。必须认真地做好每一步测试工作。当需要运行的测试多于现有资源所能运行的测试用例的测试时，一定要考虑分层增量测试。要学会采用软件测试工程化的思想，要求建立正式的测试组织、明确测试的目标和流程、确定测试的活动、对测试的过程和活动进行监控，从而保证软件测试的质量。

参考文献：

[1]张英.软件测试过程管理控制的研究[J].南昌航空工业学院学报(自然科学版),2005,2

[2]刘伟,谭振江.针对面向对象软件的测试[J].吉林师范大学学报(自然科学版),2009,4

[3]许健才.从纵横两个方向谈软件测试的生命周期[J].大众科技,2011,2

面向对象的软件测试 篇11

1 面向对象测试与传统测试技术的异同

首先, 这两种技术的测试过程是相同的。都要对整个测试进行计划, 设计出测试用例, 运行测试用例, 根据结果进行测试分析, 最后是用户验收。其次, 这两种技术的测试目标也是相同的。测试的目的都是为了使得设计出来的软件能够达到期望的功能。再次, 测试也是为了用尽可能少的工作量测试出软件尽可能多的错误, 虽然在这三个方面这两种技术都是相同的, 但是在测试计划和设计测试用例的时候是有很大的区别的, 这主要是归结于面向对象软件和传统的软件的设计思路不同。传统的软件是由各个功能模块组成的, 那么在测试计划和设计测试用例的时候就要注意的就是这些功能模块之间的关系。他们之间的关系, 它们之间是调用的关系。而面向对象的软件, 它更加注重的是对象之间的相互交流。它们是通过对象来传递它们之间的消息。这也是在测试计划和设计测试用例的时候需要考虑的, 怎样的测试用例才能够更好使得软件的功能的优缺点体现出来。

2 面向对象测试的意义与现状

类是面向对象软件中最重要的概念, 也是面向对象程序的最基本的组成要素。传统的软件是面向过程的, 软件的推进必须是一个过程完结的输出作为下一个过程的输入, 必须这样按部就班的进行下去。计算机的功能就是模拟人的行为的。这样的一种软件的方法是不能达到前面讲的效果的。人是一种群体动物, 必须是在一个团体下才能够使得事情向更好的方向发展。也就是在团体的作用之下才能使资源更优, 而面向对象方法的出现就是应了这样的需求。类就是实现这种需求的最好方法, 它既可以是对象又可以是事件, 通过类之间的相互作用也达到了这种消息之间的传递。这是因为这种软件方法的改变也就造就了软件测试的改变, 传统的软件测试方法完全不能达到用小的工作量来测试软件的错误。针对软件方法面向对象的软件测试也就应运而生了。而面向对象测试是势在必然的。

3 面向对象测试

3.1 面向对象的测试模型

大家比较熟悉的软件开发模型就是瀑布模型, 它包括了需求分析, 设计, 实现和测试。面向对象的开发模型变为了面向对象分析 (OOA) 、面向对象设计 (OOD) 和面向对象编程 (OOP) 3个阶段。面向对象分析阶段需要做的就是将整个问题总结出来, 转换成计算机能够识别的语言, 那么在这个阶段就需要选择使用什么样的编程语言。在面向对象设计阶段则需要的是选择什么样的类结构, 也就是需要些什么类, 这些类能够完成些什么工作。最后的面向对象编程阶段, 用选定的编程语言来实现设计出来的类结构。这种方法有个很大的优点就是在用户需求发生变化的时候, 能够不改变原有程序。测试模型如图1所示:

从上面的图中可以看出, 对面向对象开发模型的各个阶段都进行了测试的, 对面向对象分析的测试和面向对象设计的测试是非常必要的。如果把软件的前期工作做好了, 那么后续的工作进行的才有意义, 进行完了面向对象编程测试以后, 还有三个非常重要的测试, 就是面向对象单元测试, 面向对象集成测试和面向对象系统测试。其中面向对象单元测试和面向对象集成测试是两个工作量比较大的地方。而最后的面向对象系统测试就是要参考前面两个阶段测试结果了, 主要是以用户的需求为主的。六个阶段的测试是相辅相成的, 但是在每个阶段又有不同, 它们采用的方法也会不尽相同。下面就分别介绍单元测试, 集成测试和系统测试。

3.2 面向对象的单元测试

3.2.1 基础类测试

什么是基础类, 就是我们在面向对象设计时, 设计的类, 这些类可能是些对象, 也可能是些事件, 这里并不包括那些需要继承的类, 就是一些独立的类, 没有任何的消息传递。软件的测试就是要构造测试用例, 构造的这些测试用例必须满足两个条件:前置条件和后置条件。所谓前置条件就是发生这些测试用例要满足什么样的条件, 后置条件就是使用了这些测试用例会产生什么样的后果。测试用例既要满足前置条件又要满足后置条件。在设计测试用例的时候需要根据状态转换图, 因为状态转换图中的节点代表的是状态, 而节点与节点之间的连线则表示的是一个动作, 而测试用例就是需要了解如何促使这些动作发生。满足这些动作的发生应该是在一定的范围进行的, 那么对于临界值的设计是至关重要的, 在选择测试用例的时候临界值是非常好的一个标志。设计好了测试用例需要的是怎样来使它运行, 那么就还需要一个测试用例驱动程序。测试用例驱动程序主要的工作就是运行测试用例和得到运行结果。目前用的最多的测试驱动程序是Tester类。Tester类是抽象的概念, 使用这个类的最大好处就是能够为所有的测试人员提供默认的实现。测试人员可能会有如下的操作:运行其他所有类的测试驱动程序的公共函数, 记录下这些测试用例的结果, 必须运行所有要测试的类的测试用例, 检查所有类的所有常量。具体的Tester类主要负责实现测试用例的方法, 并将它们作为测试系列不可缺少的一部分来运行。

3.2.2 交互对象测试

面向对象的程序顾名思义就是由很多的对象构成的, 这些对象相互作用来解决某类问题的。程序中的这些对象有条不紊的相互工作这是这个程序成功的关键。完成了上面提到的单元类的测试, 那么交互对象测试则是为了这些单元类之间的消息传递能够正常的进行。交互测试有两种方法:一种是把设计的测试用例嵌入到程序的交互对象中去, 另一种方法则是用上面提到的Tester类提供的测试环境, 在这个环境下使得对象之间相互作用。这种测试的前提条件就是发送对象能不能够满足接受对象的要求。单位类测试的时候采用了临界值的方法, 这里是一些动作的发发生, 临界值的方法不并不适用。如果采用穷举的方法, 那么工作量将会变得很大, 也有可能出现无穷的情况, 交互对象的测试采用的是正交阵列的方法, 这种方法就是从影响交互对象的所有因素中选出那些对所有交互对象都有影响的子集中来确定测试用例。

如何选出这个子集是正交阵列提供的一种特殊方法, 该方法首先要设计出交互对象配对的方法, 选择的组合方式必须要限制组合数量的急剧递增。正交阵列就如下表1所示是一个数值矩阵。表中的每一行都是一个变量, 这个变量在测试的软件中就是表示的那些具有相同特性的类群。变量则会有一定的取值, 每一个取值则代表了某一个特定的类。把每个变量的所有取值都列举出来就成为了一个矩阵, 也列举出了所有可能的情况。

3.2.3 层次结构类测试

面向对象程序有一个很重要的特征就是继承, 继承的好处可以减少工作量, 不会使得工作变得冗余, 大大的提高程序的性能, 这是因为这些特点也使得继承具有一定的缺点, 那就是错误的传播率提高。继承是面向对象软件新出的概念, 那么在测试的时候对这一部分怎样设计测试用例是新的问题。如果对某个类的父类已经做了完整的测试, 那么对它的子类如何进行测试呢, 为了达到测试的目标就是用尽可能少的工作量来完成测试, 那么就需要复制对父类的某些测试部分, 又因为子类不仅仅继承了父类还有自己一些新的动作或者规范, 因此除去复制的部分再添加一些对新的动作或规范起作用的测试部分即可。这样就会大大的提供工作效率。

3.3 面向对象的集成测试

面向对象的集成测试即涉及到面向对象的结构集成又涉及到面向对象的功能集成。要实现结构和功能的集成则会有类之间的关联、聚合、多态、继承。那么在测试的时候可以分成以下几种情况:

1) 关联和聚合关系的测试:将所有具有关联和聚合关系的类放到一起, 这里不需要涉及新的测试用例, 只需要找到这些类中哪个类是最开始发出动作的, 最先发出动作类的测试用例作为这种关系的测试用例, 应用驱动程序来运行这个测试用例, 观察类之间的消息传递情况。

2) 继承关系的测试:在前面的层次结构类中提到了继承关系的测试, 参照前面的方法即可。

3) 多态/动态绑定的测试:面向对象中的多态增加了程序的运行路径的多样性, 那么在设计测试用例的时候就要考虑到这个因素, 由于运行的轨迹不同那么测试用例的设计可能就会出现变化。那么测试用例的数量就会发生变化, 应该包括所有的执行路径。

3.4 面向对象的系统测试

面向对象的系统测试和传统的系统测试是一样的, 都是为了验证设计出来的软件有没有达到用户的需求, 在满足了用户需求的前提下再考虑软件的性能是不是满足了最开始面向对象分析时提出的要求。系统测试的时候可以采用传统的系统测试的方法, 但是在设计测试用例的时候还是会有不同的, 测试用例的设计还是需要考虑从对象入手。

4 总结

通过对面向对象测试过程方法的分析, 根据本文中的图1就可以了解到测试并不是和开发过程分开的, 它们之间是密不可分的。在整个开发过程要随时都做到随时测试, 这样做的好处就是能够尽早的发现问题, 这样就会及时作出修改。该文中提到了很多解决不同阶段的测试方法, 但是这些都是在理论层次的探讨, 在实施的过程中仍然会遇到这样或那样的问题, 因此后面的研究就着重在如何使理论和实际达到高度的统一。

摘要：软件的测试时软件开发的重要部分, 是保证软件质量提高软件性能的关键。面向对象的软件测试具有它自己的特点, 需要与传统的软件测试相区别, 因此面向对象的软件测试则被分成不同的阶段, 本文将面向对象软件测试层次划分为六个个层次, 主要介绍了面向对象软件测试的以下三个层次:类测试、集成测试和系统测试。

关键词：面向对象,单元测试,集成测试,系统测试

参考文献

[1]武海丽.面向对象的软件测试[J].中国高新技术企业, 2008 (12) .

[2]李伟龙.面向对象的软件测试[J].科技资讯, 2008 (26) .

[3]刘维光.面向对象软件测试的方法研究[J].电脑知识与技术, 2006 (29) .