测试法用例的设计作业

测试法用例的设计作业（精选4篇）

测试法用例的设计作业 篇1

在编写一个软件或者模块的测试用例时候，一定要明白这个功能的原始需求，也就是软件的使用者（客户）的需求。理解原始需求后，编写的测试用例才更有目的性。

2、熟悉软件的功能需求（测试点）

这个功能需求是指软件的细化需求点，这个一般在需求文档里面都会体现。这里要做的是把 “粗略”的需求，细化成一个个小需求点。熟悉功能需求后，要知道软件是怎么使用的，这也才能覆盖到各种操作。

总之，测试用例一定要全部覆盖所有的需求点，这是最基本的一点。

3、熟悉软件的实现原理（测试点）

在理解原始需求和软件的功能需求后，根据需求编写的测试用例，基本上都能覆盖得比较全面了。

在此基础上，熟悉软件的实现原理，理解软件的内部处理。

（1）熟悉原理的过程是进一步深入熟悉软件的过程。如果单单是从需求点上面覆盖案例，测试用例只能覆盖“表面”的一层。一些内部的处理流程也许没有覆盖到，而这些没有覆盖到的代码很可能就是一个风险点。

（2）熟悉模块原理后，还有一点就是易于分析软件模块的关联性。一个大型的软件，都是一些小模块的组合而成。软件越是大型，耦合就越大，“互相影响”就会越多，若设计用例单单从模块本身考虑的话，很可能就会对其他模块造成风险。

4、用户场景和网上问题（测试点）

从用户的使用场景考虑，这在一些网络设备比较重要，比如软件后期在一些真实的使用环境中使用。

还要就是从一些网上问题总结出来的，那些地方容易出错，在设计案例的时候需要考虑进去。

5、测试用例的框架

一个测试用例的框架体现了一个测试人员在设计测试用例的整体思路。框架也是从大到小划分下来，可以是：

UI界面，功能，容错，兼容，性能等几大类，每个大类在根据软件的逻辑等进行划分成小类，最后细分到测试点。

6、测试步骤（测试技巧方法）

前面4点都是从测试点的角度考虑，测试用例在完成测试点外，接下来就是测试步骤和测试结果啦。

测试用例可以写的很详细，也可以写的比较简单。这要看公司的要求，有些公司要求测试步骤很细很细，包括测试结果和测试步骤一一对应。

要求测试步骤写的很详细的公司，一般是怕执行人员的执行力不到位，导致没有理解案例的目的，导致漏测。一般出现在新员工对软件系统的不熟悉。如果测试步骤写的很详细的话，会很耗时间，而且过于详细的会限制执行人员的思维。个人认为测试用例的重点在于测试点上。

7、测试用例的一些思路

在设计测试用例中，通常较多使用的是边界值，等价类，通过和不通过测试。下面从单个模块或者单个功能点考虑：（结合一些网上文章的观点）

（1）UI界面：易用性，提示信息，整体布局，按钮图标，色彩，中英文标点错别字。

（2）数据的多样性：有效数据，合法的无效数据（边界值），非法的异常数据，产生错误输出的合法数据组合等各种数据的组合。

（3）操作多样性：添加删除编辑查询，多用户的操作。

（4）容量测试

（5）用户权限：使用权限，各种操作的权限。

（6）升级安装卸载：平滑升级

（7）日志相关（包括调试日志）

（8）软件功能的逻辑划分：功能上划分未能覆盖的代码逻辑，可以添加白盒灰盒用例。

（9）可靠性，容错性

（10）兼容性：浏览器，系统，支撑软件。

（11）安全性

（12）性能（这里的性能是指，单个模块或者子系统的性能）

总之测试用例首先要能覆盖所有功能需求点，然后搞懂软件处理逻辑，可以找开发一起看测试用例，把没有覆盖到的代码流程相应的用例补充，至此，用例基本不会出现基本功能的问题。

测试法用例的设计作业 篇2

长期以来,我国软件企业一直被软件质量问题所困扰,它有多方面的原因。其中对软件测试的忽视,是一个重要因素。事实上,软件测试可以检测软件中存在的错误,确保软件产品质量。

为了开发出高质量的软件,众多软件企业从之前单纯的以编码为核心向软件工程化方向进军,形成了一套比较完善的软件测试理论体系。软件测试越来越规范化,可以划分为单元测试,集成测试,确认测试和系统测试等,它往往占用了软件开发生命周期40%～60%的时间。但是在实际工作中,还有很多企业,设计出比较低劣的测试用例,时常有些地方被遗漏,不能完全覆盖;有的虽然考虑得面面俱到,但设计的测试用例庞大无比,冗余现象十分普遍,浪费人力物力;更有的企业在新的软件版本或者测试环境中,彻底抛弃原有的测试工作,重新开发测试用例,这是很不经济的。本文希望能够总结以往的经验,提出一些有效的测试用例设计和复用方法,用以帮助测试人员更有效地应用于整个测试流程。

1 测试用例的设计

所谓测试用例是指按照一定顺序执行的与测试目标相关的一系列测试。在测试阶段,软件测试方法可以分为单元测试,集成测试,功能测试和系统测试。单元测试是最小的单位,测试小段特定代码,由开发人员来主导完成;集成测试是把各个应用程序组合起来进行的测试;功能测试即黑盒测试,是立足于用户的角度来进行测试,根据需求和软件运行的平台进行测试;系统测试是把整个软件系统和它所依赖的其他软件或者硬件集成在一起,覆盖所有的功能进行测试:比如压力测试和性能测试等。如何设计出有效的测试用例?下面结合作者在工作中的经历,阐述一些测试用例设计中的问题。

其一,测试用例设计的时间性问题:越早地设计和执行测试用例越好。

目前很多测试模型都是V模型,就是将测试依次划分为几个阶段,进行完了一个阶段然后再展开下一个阶段的测试。这种分阶段测试最大的缺点就是定性地将测试分为几个固定的阶段,其实很多测试可以提前展开,尽早发现错误。而V模型显然有点违背了越早发现错误越有利的原则。在开发嵌入式产品VOIP网关时,我们采用了一种比较灵活的方法,将测试用例的设计提前进行。在需求阶段,便开始考虑和实施系统测试用例;当需求规格书确定后就开始设计功能性测试用例,同时概要设计也并行进行;等概要设计好了进行详细设计时,同时展开集成测试用例的设计。这样当开始编码的时候,我们便可以开始测试准备好的单元测试用例,而且也可以执行集成测试用例和系统测试用例;这样伴随编码同步地进行这些测试用例,可以及时发现错误,得到反馈信息,用以纠止软件设计中的错误。另外一个好处就是在编码阶段就展开集成测试、功能测试和系统测试,能尽早发现错误。

其二,在结构性测试用例设计中,我们要注意的原则:尽可能利用路径覆盖方法设计测试用例来覆盖程序所有可能路径,尤其在程序本身的复杂度高的情况下。

一般说来,在编码过程中,程序本身设计的复杂度也决定了测试用例设计的复杂度。下面结合VOIP网关产品中的状态机进行说明。对于一个VOIP系统,核心之一是有限状态机的设计。一般包含空闲状态,用户摘机状态,拨号状态,等待连接建立状态(其中又可以分为信令连接建立阶段,语音通道建立阶段),通话状态,对方挂机状态,对方电话忙碌状态等。在每一个状态下,事件源可以是:摘挂机事件,拨号事件,建立连接返回事件,如:对方不在线,无法连通因特网等。在某个状态下,接收到不同的事件驱动程序转向其他状态。每次通话过程从空闲状态重新回到空闲状态,这是一个非结构性的循环结构。在这种情况下,就需要采用路径覆盖的方法,来设计结构性测试用例,列出所有的可能性路径,针对其中的每一条路经设计出相应的测试用例。依据图1所展示的一个简单状态机,可能存在的路径包括:AB,ACEG,ADFG等,这就需要我们在进行测试用例设计的时候,细心地把存在的路径一个个找出来,才能设计出比较严谨的测试用例。

另外在结构性测试用例的设计中,还经常采用的方法有:

· 语句覆盖 就是使程序中的每个可执行语句至少执行一次。

· 判定覆盖 使程序中的每个判定至少都获得一次“真”和“假”值。

· 条件覆盖 使每个判定中的每个条件的可能取值至少满足一次。

· 判定/条件覆盖 使判定中的每个条件的可能结果和每个判定本身的判定结果均至少出现一次。

· 条件组合覆盖 使得每个判定中条件的各种可能组合都至少山现一次。

其三,在功能性测试用例设计中,我们常常需要:把百分之八十的精力投入到那些边界情况和失效数据作为输入的测试情况。

功能测试即黑盒测试,一般由测试人员来执行,而测试用例的设计,最好在需求阶段依据需求规格书进行设计。如果设计测试用例的人员没有完全理解需求规格书,这里面就会引起一些问题,到产品最后验收的时候,就会发现产品根本不能交付使用,大大延误了产品上市时间。测试人员依据功能测试用例来进行测试,对软件内部结构和运作并不了解。一般初期设计出来的测试用例往往又会遗漏很多边界条件。在我们开发的一套客户机/服务器系统中,就出现了不少类似问题。首先客户机安装后必须向服务器进行注册,用户的名字在服务器端数据库里面作了限定,由于客户机没有进行检测,最后导致服务器不能为部分用户服务。由于功能性测试在用例中没有包含进去,等产品交付使用后,才发现这个错误。这需要在设计功能性测试用例的时候,不仅仅要考虑有效等价类,那些无效的等价类更加重要,因为这些都是人们容易忽视的,无论开发人员还是测试人员,往往有定势思维,总感觉自己的产品没有问题,他们也习惯性地输入一些一定满足条件的数据进行测试,无形中掩盖了潜在的失效数据的处理。其次边界值划分法也是一种常用的方法。在我们那套客户机/服务器系统中,客户机每隔三分钟会把统计的资料信息传送到服务器。如果服务器正常,则返回正确消息;否则可能返回服务器忙碌信息,此时客户机需要调整策略,延长发送间隔,然后把累积统计的数据在下一次发送时传送给服务器。此外,服务器每天会定时在线备份,这个时段,客户机要调整发送间隔到十分钟,等服务器备份完毕,再提交统计的资料。这就需要我们在设计测试用例的时候,既要包括正常情况下的状况,也要把服务器在不同忙碌等级下的情况,服务器备份的情况统统包含进去。总之,边界情况和失效等价类是设计测试用例时必须要使用到的。这样才能设计出好的功能性测试用例。当然还有其他一些比较常用的方法,如错误推测法和因果图法。

2 测试用例的复用

设计出好的测试用例是确保软件质量的大前提,有效复用现有的测试用例更能提升企业软件开发过程。目前很多软件企业,对测试用例的复用没有引起足够的重视。软件开发往往时间紧张,客观上也成了开发测试人员的借口,设计出来的软件或者测试用例,过于局限于本产品使用,依赖性非常强,根本就不利于升级或者拓展。这里我们提到的就是测试用例的复用。我们要能够将所有的测试用例有效地组织起来,使得测试用例集合里面的每一个测试用例都能够独立地运行,这样才能提高软件测试用例的复用度。结合工作中的经验,传统的测试用例设计有很多方法,看上去相互间没有统一的结构。我们所需要注意的是:能够将测试用例综合起来分析,然后让所有的测试用例组织在一起,它们具有统一的输入、输出接口,并且每个测试用例独立性比较强,这样即使以后软件运行环境发生变化,测试用例还能够继续加以使用。拿我们的VOIP产品来说,我们在推出第一版的时候,测试用例设计得就非常的独立,可以有效地检测状态机的运作。等我们在添加了会议电话功能后,我们基于之前的测试用例,进行了最大程度的复用,节省了大量的时间和精力。测试用例独立性强,采用一致的结构,是测试用例复用度高的关键。

3 结 语

软件测试用例的设计,是软件测试中比较重要的一环。只有设计出更多更好地测试用例,才可以更快更好的发现潜在的错误与失效。使用最少的测试用例,实现最大的测试覆盖,可复用度好,并且在需求分析阶段提前展开测试用例的设计,是我们软件测试的目标。只有制定出完善的测试计划,有效的测试用例,进行测试结构分析以及文档管理,才能保证软件测试的成功。

摘要：软件测试是企业保证软件产品质量的一个重要手段,其中测试用例的设计是软件测试的关键,它一般包括功能测试用例的设计,结构测试用例设计以及系统方面的测试用例设计等。结合实际经验,系统地阐述了如何有效地进行测试用例的设计以及复用。并给出两个案例进行分析,探讨测试用例设计中的一些注意事项。

关键词：软件测试,测试用例,复用技术

参考文献

[1]Beizer B.Software Testing Techniques.Boston,International ThompsonComputer Press,1990.

[2]Pressman R.Software Engineering:A Practitioner s Approach.Boston,McGraw Hill,2001.

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

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

1.测试项目：电梯

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

界面测试:查看电梯外观

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

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

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

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

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

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

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

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

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

2.测试项目：杯子

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

界面测试: 查看杯子外观

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

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

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

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

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

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

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

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

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

测试用例的复用技术的研究 篇4

随着信息技术应用在人们的日常生活工作中起到越来越大的作用, 软件业也迅猛地发展起来, 软件的功能由简单变得强大, 软件的复杂程度也越来越高。软件作为一种广泛使用的产品, 其质量的重视程度在被不断提升, 特别像一些高风险的行业, 例如证券行业, 软件质量的好坏直接关系到客户的交易是否安全, 顺畅。软件测试作为软件生命周期的一个重要阶段, 是在软件开发, 维护阶段对软件产品进行质量控制, 检验软件系统是否满足需求的重要手段之一, 是整个软件质量保证的关键一环。

在软件的测试过程中, 选择合适的测试用例很重要, 这将决定最后测试是否能顺利地按时按质完成。在软件测试中, 测试用例设计是软件测试步骤中最重要的环节之一, 测试用例的设计人员的水平不一, 低水平的测试用例设计人员的测试效率低, 会降低测试效率, 这样也会影响软件交付的时间。测试人员经验不足同时也会导致测试用例设计质量的低下, 设计出的测试用例不能发现足够多的软件问题, 对保证软件项目质量不利。软件测试中, 一些测试内容会经常反复进行, 相同或者相似测试用例的重复设计的劳动经常发生, 浪费人力物力和时间, 这样会提高软件开发和维护的成本。软件测试用例的复用技术在软件复用技术较好的应用和发展的影响下, 也得到了发展, 这对解决测试中的冗余现象, 提高软件测试效率提出了很好的方法。软件测试复用技术广泛地应用在软件开发和维护的各个阶段, 本文研究了测试用例复用技术, 并对测试用例复用在证券软件测试中如何实现做了研究。

2、软件测试用例

测试用例 (Test Case) 是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果, 以便测试某个程序路径或核实是否满足某个特定需求。

3、测试用例在软件测试中的作用

测试用例是软件测试全部过程的核心, 是测试执行环节的基本依据, 在软件测试过程中起着很大的作用。没有测试也可以进行软件测试, 但测试是无序的, 只是按照自己的测试思路进行测试, 难免有所遗漏。有了测试用例, 就有了测试的依据, 可以按照测试用例有序的执行测试步骤, 不易遗漏测试点, 能过较好保证最后的测试质量。每个测试人员的测试环境, 技术背景, 测试思路等都不一定相同, 不同的测试者的测试方法都不一样, 一个较大的软件在测试过程中, 许多测试人员一起测试, 不能保证测试各个测试点的测试质量。通过测试用例的设计, 可以把测试目的, 内容等编成文档, 保存在用例库中, 便于其他测试人员借鉴, 共同提高测试技能。测试中可以引入审核部门, 对测试用例进行评估, 通过一些量化的数据, 如测试覆盖率、测试合格率、重要测试合格率等, 衡量测试用例的优劣, 总结测试用例设计中产生的问题, 评估各个测试用例设计人员的工作绩效, 将评估结果反馈给测试人员, 测试人员可以改良测试用例, 并把结果存入测试用例库中, 在下次同一模块或相似模块的测试中就能提高效率和准确性。测试用例存入测试用例库中, 也可以专门由人进行维护, 不断更新和完善测试用例。一个好的测试用例库必然会让共享的测试人员获益, 从而提高工作效率, 更好保证产品质量。

4、测试用例设计方法

软件测试方法众多, 主要有黑盒测试方法, 也称功能测试;白盒测试方法, 也称结构测试或逻辑驱动测试。

5、软件测试复用

5.1 软件复用的概念

软件复用 (SoftWare Reuse) 是将已有软件的各种有关知识用于建立新的软件, 以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。

5.2 软件测试的复用

软件测试复用可以理解为在两次或多次不同的软件测试过程中重复使用相同或相近的测试资源来组织测试, 它的目的是充分继承以前软件测试中的经验, 将已经使用过的测试用例标准化后存档, 在未来的某个时间进行检索后的借鉴或者复用, 减少设计测试用例的时间, 增强测试的效率和可靠性, 而不是每次用例设计都从头开始, 增加更多的冗余时间。测试用例复用是把一个软件的测试用例在新的软件测试中使用, 或者在软件作出修改时在新的一轮测试中使用, 作为软件测试的核心内容, 它的复用也就成为整个软件测试复用工作的关键环节。

6、软件测试用例的复用

6.1 测试用例的复用

所谓测试用例复用就是指测试工程师在执行一项新的测试工作时, 通过直接调用或修改现有的、适合此项测试的测试用例, 并将它们运用其中的过程。也就是说测试用例要实现复用必须具备三个条件, 必须有可复用的测试用例, 要复用的用例必须有用, 测试工程师知道如何使用, 而这三个条件恰恰通过测试用例的创建、维护、执行管理就可以实现。

6.2 测试用例复用数据库的维护

要对测试用例进行复用, 首先要有能够复用的测试用例, 然后将测试用例进行归类存档, 以一定的形式保存在测试用例库中, 接下来就要对测试用例进行维护, 在维护中不断添加新的测试用例, 更新旧的可完善的测试用例, 删除有问题的测试用例。测试用例的设计由于每个设计人员的水平, 设计的用例的复杂度, 不太可能每个设计的测试用例都能完美无缺的满足测试需求, 总是会有些测试用例编写的并不符合要求, 测试执行过程里肯定会发现有些测试路径或数据在用例里没有覆盖一些应用场景, 那么在测试用例维护时, 该将其补充到用例库里, 以方便他人和后续版本的测试。现在比较流行迭代的软件开发方式, 这是为了符合客户对软件功能不断变更的需求, 相应的, 在当前迭代版本的测试要使用前一个版本的测试用例时, 由于需求的改变, 测试用例也要随之变更。测试用例的维护分不同的情况, 可以用不同的方法分别进行处理。其一, 软件需求并没有发生变更, 只是原先设计的测试用例不是很完善, 没有完全满足测试需求, 在测试过程中, 不断地细化, 深入分析需求文档时, 有了更完整, 清楚的认识, 这时, 就需要完善测试用例, 让测试用例的测试效果更能贴近客户的需求, 然后修改需要更新的测试用例;其二, 测试需求没有发生变更, 但是软件的功能增强了, 原测试用例只对未增强的功能模块有效, 我们就需要设计新的版本的测试用例, 符合增强后的功能的测试需求, 也就是增加一个测试用例, 而原来的测试用例对增强前的功能依然有效;其三, 需求变更, 增加了新的功能, 这就需要添加新的测试用例;其四, 需求变更, 原功能被取消了, 相应的测试用例失去了作用, 但测试可能在将来被其他人在相似的测试中借鉴或修改复用, 这时只要将与该功能对应的测试用例在标志位上置为无效标记。测试用例维护流程的模式如图1。

6.3 测试用例的复用思路

要实现测试用例的复用, 首先要测试用例规范化。统一的用例建模, 统一的标识规范, 例如都由测试用例ID、测试概要、和用例描述3个部分组成, 将设计好的测试用例放入测试用例库, 并按照用例各自的属性特点进行多级合理的分类、组织、存储, 这样, 在测试用例复用时, 就能够快速的检索到所需要借鉴或复用的测试用例。然后, 对测试用例库中的测试用例进行维护, 及时更新测试用例库, 不断地进行完善, 通过提供有助于复用的多种查询方式, 确保测试用例的复用程度。最后, 对数据库中的测试用例具体实现复用, 通过测试需求分析, 检索测试用例库, 查找可以借鉴和复用的测试用例。同时对测试用例库做必要的更新。测试用例的复用能在保证软件测试质量的前提下提高测试效率。复用的简单流程的模式如图2。

6.4 证券行业软件测试用例复用的实现过程

金融行业中的证券行业软件复用常常发生在测试用例复用发生在系统维护阶段应急演练测试, 系统新功能上线后的系统测试, 系统部分参数变更时的测试, 同一测试软件在系统不同的测试阶段的测试。

(1) 系统维护阶段应急演练测试。在系统维阶段, 为了维护系统的在客户使用时地稳定性, 会为平时运行的系统安排应急措施, 这样, 当主系统发生故障时, 能够启用系统的备份方案, 维系系统的功能仍然有效。这种测试在对系统稳定, 风险较大的行业, 像金融业等, 经常会定期进行, 其目的是让系统维护熟悉系统的应急措施, 确保系统在出现问题时, 能在最短的时间内恢复系统的正常功能, 减少或消除客户和公司的损失。系统功能的复杂性越高, 系统地风险越大, 这种测试也会变得更频繁, 制定详细地可复用的测试用例, 放在测试库里。同时制定测试计划, 当某功能测试需要实施时, 从测试用例库中调用相应的测试用例进行复用。这样可以节省时间, 同时也能当不同的维护人员做同一测试时, 能运用以前测试人员的方法, 快速实施测试。这种测试用例的复用其实也是一种有效地故障处理方法。

(2) 系统升级后的系统测试。同一个系统在运维时期, 功能往往不会一尘不变的。这种系统的变更往往是被动发生的。业务需求的变更是系统功能变更的主因。例如金融公司, 不断会有创新业务产生, 需要随着业务的需求变化, 不断地增加新功能, 这些新功能的增加, 需要测试系统的新功能, 而新功能和以前地功能往往具有相似性, 我们可以查找测试用例库, 具有类似功能的模块的测试用例, 做一些相应的适当改动, 满足新的功能的测试需求。然后将新的测试用例放入测试用例库, 作为以后的定期功能测试时复用, 或者其它新的相似功能模块上线时测试用例复用和测试用例设计参考使用。

(3) 系统部分参数变更时的测试。系统的整体功能并没有改变, 只是由于业务需求的原因, 改变了一些系统参数, 这种情况在金融业时有发生, 例如国家的金融宏观调控, 一些政策发生改变, 某些收费比率会发生变更。政策的变化导致了系统参数的变更, 使用该系统进行资金往来或者交易的客户往往因为政策改变交易策略, 会引起交易市场的震荡, 这种情况在证券市场时有发生, 这就需要通过测试来检验系统的稳定性, 了解市场波动给系统带来的影响, 从而才取相应的应对措施。由于这些参数的改变, 对系统地功能并没有大的影响, 可以查找测试用例库, 复用以前的测试用例进行测试, 测试系统的稳定性, 为系统是否需要改进, 或系统的硬件是否需要升级, 做评估。

(4) 同一测试软件在系统不同的测试阶段的测试。证券软件从软件开发的过程按阶段划分有单元测试、集成测试、确认测试和系统测试及验收测试。在不同的开发过程中的测试所对应的对象会有许多功能模块在先前的测试阶段已经测试过, 例如集成测试中的测试对象在单元测试中已经测试过, 我们可以查找测试用例库, 把前一个阶段使用过的测试用例拿出来继续使用, 对软件进行测试。如果测试需要改进, 可以稍作修改后, 将新产生的测试用例做好分类标识后放入测试用例库, 供以后软件测试的复用。

7、结语

本文通过介绍软件测试过程中测试用例的设计的作用、测试用例的设计方法、软件测试用例库的维护, 软件测试复用的具体思路、方法, 在证券软件中测试复用的具体实现过程, 说明了软件测试复用的可行性, 在复用技术的研究提高下, 能在保测试证质量的前提下, 提高测试的效率, 更好完成测试任务。

参考文献

[1]杨根兴, 蔡立志, 陈昊鹏, 蒋建伟.软件质量保证、测试与评价北京:清华大学出版社, 2008.6.

[2]卜国峰, 孙志刚, 丁小良.软件测试用例的复用研究[J].四川兵工学报, 第3O卷第5期, 2009.5:34—35.

[3]尹平.可复用测试用例研究[J].计算机应用, 2010, 5.

[4].胡正芳.测试用例复用技术研究.2009.