测试用例设计方法例子

测试用例设计方法例子（精选8篇）

测试用例设计方法例子 篇1

报表的测试主要分为以下几个方面:界面,安全性,准确性,展示速度(性能)

数据统计方面

1、报表统计数据的正确性；

2、报表统计数据的完整性；

3、报表统计数据的合法性；比如，统计金额字段需求要求有“$”等；

报表格式

1、表头字段表示的正确性；

2、表头字段表示的完整性；

3、表头字段表示的字体，字号，美观程度；

4、各统计字段的显示是否满足需求；比如：数据过长时要求折行还是缩小；

5、页眉和页角的表示；

报表的预览和印刷

1、预览中的显示完整性；

2、多页情况下，第2页的表头显示；

3、能否实现需求要求的特定印刷情况；（比如，印刷使用指定的模板）

4、预览后印刷；

5、不预览，直接印刷

6、需求规定各类打印机的测试；

数据准确性测试，带有报表测试的系统分为两类，一类是业务系统中，带有统计分析功能模块，该模块中包含分析报表，这个系统的主体是业务系统，报表是为办理业务的而提供帮助的。

比如说，应年检统计报表，某月应交罚款车辆统计报表，这样的报表数据准确与否，可通过增加、删减、修改相关业务或相关业务的参数，查看统计报表数据变化，检查数据准确性。

另一类是系统只有统计功能，就是我说的数据仓库展现这类，它与业务系统分离，并且经过多层处理，比如数据仓库的数据，经过抽取，清洗，展现前会经过数据挖掘，数据再处理，有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂，当然检查出数据错误，修改定位也是很不容易的。

从整个项目节约成本看，逐层测试效果是最好的。完全修改率也是最高的。

首先建立测试数据模型，模拟所有应用表，建立简单易跟踪的数据用例，底层的数据表测试，方法很原始，嘿嘿，通过SQL语句和手工计算，对数据进行比对。对系统中的报表数据准确性测试方法较为灵活，①系统中报表重叠的进行比对

②对子报表汇总与父报表比对，就是对月报表汇总与年报表比对，日报表汇总与月报表比对，这只是一个方面，可以从维度关系考虑，地域，行政级别、时间，个人等方面下手，进行汇总比对

③这个方法如果延伸点呢，可以将报表间的业务逻辑关系作为比对依据。呵呵，这要看测试人员的需求了解深度个人能力了。插几句不想干的话，做测试工作总让我保持快乐状态，前两天我的一个同事说，公司里一直没有人喜欢做测试工作，这个工作太枯燥。嘿嘿，我当时就说我做了这么多年的测试工作从来没有感觉到枯燥。重复性工作不代表枯燥，编程其实不也是重复嘛，人每天谁不重复昨天的事啊，吃饭，吃这个动作重复一生，有谁觉得麻烦枯燥啦？

④使用SQL和手工计算进行比对。以上是差错方式，接下来讲一下查什么错？哪些地方容易出错

●原始表使用错误：因为表比较多，又加上没有统一的数据关系对应表，很容易表使用错误，当然这应该是单元测试检查出来的错误。

●数据处理逻辑错误：这一点容易因为测试人员和开发人员对需求理解有偏差造成争执，所以在需求评审时，对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误，逻辑编写有偏差，边界值、特殊情况处理不当。

●数据权限：不同用户对数据有着不同的查看权限。这关系到数据的安全性。

●数据误差：数据的保留位数，数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。

●由于字典表，数据错误，而造成的数据错误，如，根据性别统计，购买量，表中的男女颠倒，或者没有考虑性别缺失项，用了ifelse,这样就是把表中缺失该项内容的算成了else条件里。或者逻辑中应该考虑用户状态，数据状态类似的字段，容易被忽略，测试应该考虑到。

●最后一项，当数据量相当大的时候，统计应该考虑，切割速度，也就是数据的完整性，由于数据切割的滞后，带来的数据不完整，而造成统计结果不完整。如统计昨天的销售情况，而昨天的数据并没有完全从业务系统数据到数据池，再者月底数据，由于最后一天的数据切割不完整而造成的正月统计数量不准确。

报表的界面和输入输出测试

界面分为输入界面和输出界面；统一的界面要求：美观、统一、易操作。

输入界面要求是：

①输入项字段长度不允许超过字段长度；

②输入不符合字段要求的，不允许查询。如money类型，在输入汉字，字母、特殊字符等不允许查询，并有友好的操作提示。

③用户权限范围外的输入，不允许查询。如用户输入不是其权限范围内的客户号，不允许查询，并有友好的操作提示。

对于选项，应不出现可选择的用户权限以外的选项。

对于汉字模糊查询，考虑不常见字，如“?”即汉字因译码问题，造成的汉字存储出现乱码问题。

输出界面要求：

①因为是报表所以应该有打印、打印预览、报表导出等功能。不能因为报表导出丢失数据，不能因为打印缺少了报表表格框

②报表排列方式可调，用户可按任意列升序或降序排列，或者，按某一关键列的一定规则排序

③报表标题明确，不能含糊误导用户

④报表内可关联查询的项，应能特殊显示，如鼠标有箭头变为手掌，子报表格式与父报表格式统一，数据统一。

报表测试根据项目的定义有大有小,有时只是作为软件的一个部分进行测试,有时整个项目都是测试各种报表.但不论如何,报表的作用始终都是将系统中已经存在的数据根据用户的设置计算加工/整理汇总/最终以清晰的格式展示给用户,以便用户进一步做数据分析或统计.软件中的报表实现一般分为定义报表的所需数据(一般可以通过选择或手工输入条件来缩小数据范围)和定义报表格式两个部分.报表格式除了如国家各行业标准中规定的报表使用固定格式外,大多是根据企业或用户的需要定制报表.所以,做报表测试时要注意以下方面:

1.数据的正确

用户使用报表就是期望通过一个简单方便的平台能快速的查找到他所需要的数据.所以在测试报表时首先就要检查报表中的数据是不是用户需要的数据,如果没有加工的数据,是否保持了原貌;加工过的数据查看加工的结构是否和手工加工的结果一致.简言之,需要测试以下内容.数据的来源：来源于哪张表,哪个字段,数据库中的数值与界面数据的对应.如数据库中性别的数据可能是0或1,但界面显示为男或女,这个对应关系是否正确.数据的范围：是否只显示了报表设置的对应范围；特别要注意边界数据,要清楚报表的需求,是否需要过滤掉被选择的数据.如时间选择为200627~200727,那么是否应该包含9-27这天.数据的对应关系：数据库中的字段是否与报表中的信息对应

数据的格式：小数位,千位符,四舍五入等是否与报表设置一致；单位或税率转换是否正确；组合显示的数据是否合理

数据的排序：排序方式是否与报表设置一致(如果没有设置,是否有一个清晰的默认排序方式,如按字母或数字排序)

流水号：如报表有使用流水号,流水号的生成和格式是否正确.取消操作是否会生成流水号.明细与合计的一致性：各部分明细或小节是否与最后总和一致

其他

测试这一部分内容需要对业务逻辑相当熟悉,对数据库的设计也要非常了解.必要时可以通过自己写查询语句查看数据.有些报表的条件有多有少,但测试方法都是一样.根据条件通过等价类划分和排列组合设置各种条件组合.千万不要盲目的测试,否则会导致该测的没测,多余的测试做了一堆..一般来说有类别划分的(一般界面表现为下拉框),每个类别都要测试到,如性别中的男,女都要测试.输入的可以用等价类来划分要测试的数据.2.格式的正确

数据验证正确后,就需要看看报表的输出格式是否符合要求.可以从以下几方面来检查.报表的整体风格：报表是否符合规定的或用户设置的格式

报表标题：报表的标题是否是正确的报表名称；如报表中有嵌入的数据(会跟随用户的选择而变化的).需要检查数据是否正确,如XX企业9月份财务报表,这个9月就是用户选择的;或者XX公司200627~200727的网站访问量,这个时间段也是用户选择的.公司的一些标志：如logo,名称,地址之类的是否正确

报表的页首与页尾：是否采用了一致的规则.分页：当输出的内容多时,分页是否正确.翻页功能是否正确

友好性：数据或图表是否清晰,一目了然,数据的展示符合用户的习惯；需要特别提醒的数据(如合计,异常数据)是否突出显示；复杂算法处,用户不明白或容易混淆处是否有注释；一些默认的格式是否让人感觉舒服,如对齐,边界,间隔等

3.权限的控制

对于有权限控制的系统，报表当然也应该和用户所具有的权限相一致。需要从两方面校验权限的控制。

报表的条件定义:在条件选择区域，有些下拉框中应该不能显示用户权限范围外的数据。如普通文员在使用报表时，报表名称下拉框中是不可以显示管理者才能查看的报表的。有些以输入的文本框有级别的划分时，都应该要测试输入超越权限的数据的相应。

注意这里一定要测试每个条目。

报表内容：报表中的内容不能显示用户本没有权限查看的数据。

4.报表的输出

报表在电脑上生成后，并不是报表的结束。报表一般都需要打印出来他用，如开会或者提交审批之类。所以报表的打印功能也是非常重要的。测试主要分成三部分：

●打印设置

●打印预览

●实际打印效果

测试用例设计方法例子 篇2

关键词：黑盒测试,等价类划分法,边界值分析法,决策表法,测试用例

随着人们对软件需求日益增长, 对软件的质量要求也越来越高。但是, 由人开发的软件, 缺陷是在所难免的, 这便是需要对开发的软件进行测试的原因。软件测试可以极大缩短软件开发周期, 它是软件质量保证的一个重要环节, 它可以验证软件是否实现了期望的功能。在软件测试方法中黑盒测试方法是其中一种测试方法。它避开软件内部程序, 相当于是直接从盒子表面对盒子特征进行测试, 直接测试的是程序本身所具备的功能。

在有限时间与资源的条件下, 想要进行完全测试, 找出所有软件缺陷和错误是不可能的。也就是说想要进行穷尽测试是不可能的, 那么在这种条件下应如何运用有限测试资源, 如何利用最少时间使测试做到充分、高效?解决这个问题就非常重要。想要在最短时间内达到最佳测试效果, 这就需要根据软件需求对软件设计相关的测试用例。

1 黑盒测试

黑盒测试 (又称功能测试、基于规格说明的测试或数据驱动测试) , 它对软件所实现的功能进行测试, 验证软件开发的功能是否满足开发文档的功能要求及性能要求。它主要的缺陷包括:

(1) 功能实现错误或有遗漏;

(2) 接口输入、输出结果错误;

(3) 界面报错;

(4) 性能无法满足需求;

(5) 数据结构或外部结构访问错误;

(6) 初始化或终止条件错误。

2 测试用例设计

2.1 等价类划分

等价类划分是黑盒测试方法中的一种典型测试方法。它是将输入的数据 (有效的数据、无效的数据) 划分成多个区间 (等价类) , 然后在每个区间选取具有代表性的值, 设计成测试用例 (由有效等价类和无效等价类的代表组成) 。利用有效等价类可验证软件是否实现了规格说明书中规定的功能和性能。利用无效等价类可验证软件是否包含了不符合规格说明书中规定的功能和性能。

等价类的划分方法包括:按区间划分、按数值划分、按数值集合划分、按限制条件或规划划分等。

(1) 按区间划分, 可确定一个有效等价类和两个无效等价类。如:在取值范围为[5, 10]整数中, 它的有效等价类为5≤X≤10, 无效等价类为X<5, X>10。

(2) 按数值划分, 即一组数据 (包含N个数据值) , 可确定N个有效等价类 (每个数值为一个有效等价类) 和一个无效等价类 (不在这N个数据值的数据) 。如:变量X的取值范围为{1, 3, 5, 7, 9, 16}, 那么它的有效等价类有6个, 分别为X=1, X=3, X=5, X=7, X=9, X=16, 无效等价类为X≠1, 3, 5, 7, 9, 16。

(3) 按数值集合划分, 在规定了数值的集合中, 可确定一个有效等价类和一个无效等价类。如:变量X的取值为5位长度的字符串, 那么它的有效等价类为X的字符串长度5位, 无效等价类为X的字符串长度不等于5位。

(4) 按限制条件或规划划分, 划分等价类中各个元素的处理方式。它可以确定一个符合限定条件或规则的有效等价类和若干个不符合条件的无效等价类。如:要求密码首字母必须为英文字母, 有效等价类为密码的首字母为英文字母, 无效等价类为密码的首字母为非英文字母的字符。

2.2 边界值分析法

边界值分析法也是黑盒测试方法之一。其是对输入或输出的边界进行测试的一种方法。这种测试方法是对等价类分析方法的补充, 其用例来自等价类的边界。通过经验证明, 大量错误通常发生在边界上, 通常对其进行测试可取得良好测试效果。因此, 通常针对各种边界情况设计测试用例, 这种对输入、输出边界附近情况设计测试用例应给予足够重视。边界类分析法的取值取的是它的正常值、它的边界 (即正好等于左右边界的值) 及它的次边界 (即刚刚大于左边界或刚刚小于右边界的值) 作为测试数据, 即取min、min+、nom、max-、max。如:变量5≤X≤10, 且X为正整数, 那么测试用例中变量X的取值为左边界最小值5、略大于左边界最小值6、值域内任意值 (7、8中的任一取值) 、略小于右边界最大值9、右边界最大值10。

2.3 决策表法

决策表法 (也被称为判定表法) , 它是黑盒测试方法中最为严格也是最具有逻辑性的测试方法。它可以分析和表达多逻辑条件下系统执行不同的操作情况。因为在实际开发应用中, 输入的条件往往是由多个因素构成的, 而非由单一因素构成。因此, 采用决策表法可以对多个输入条件的情况进行组合设计。如:判断x、y、z三个正整数能否构成三角形, 可根据相应问题生成决策表, 再将决策表转换为测试用例, 相关的决策表如表1所示:

2.4 状态转换测试

状态转换测试是黑盒测试技术中的一种, 它针对特定需求设计测试用例。因为测试对象的输出与行为方式不仅仅受到当前输入数据的影响, 同时也受到对象执行前的情况或之前输入数据的影响。因此, 通过状态转换测试对系统的每个状态以及与状态有关的函数进行测试, 通过不同的状态验证程序的逻辑流程。如打开Word进行编辑浏览状态图如图1所示:

设计用例如表2所示:

2.5 基于经验的测试

经验对于各行各业的工作者来说都是非常重要的。对于软件测试而言, 经验同样也拥有非常重要的地位。在软件测试中有时会遇到基础文档不全或不完善的情况, 这时便需要依赖测试人员的技术、知识与经验预测可能发生故障的地方, 也可作为其他测试方法的补充方法对软件进行测试。它采用逆向思维方式, 可以有针对性地设计系统的测试用例, 使测试变得更充分、高效。如:对日历进行测试时, 利用经验法会着重对日历软件易发生错误的几个方面进行测试。包括:

(1) 是否能正确分清闰年闰月;

(2) 大小月日期是否正确;

(3) 日期与星期是否能对上等。

3 结语

软件出错是无法杜绝的, 为了让用户在正式使用之前可以尽可能多发现和修改潜在错误, 应加强对软件进行测试。黑盒测试从输入和输出数据的对应关系对软件进行测试, 不涉及内部结构。在实践中证明了通过黑盒等测试方法对软件进行优化, 可以使得软件更加系统化、灵活化, 使软件质量、可靠性得到明显提升。因此, 本文对黑盒测试中的等价类划分、边界值分析法、决策表法、状态转换测试、基于经验的测试这几种测试方法进行探析。

参考文献

[1]陈威.软件测试的概述及方法[J]数字化用户, 2013 (30) .

[2]武剑洁, 陈传波, 肖来元.软件测试技术基础[M].武汉:华中科技大学出版社, 2008.

[3]殷人昆, 郑人杰, 马素霞, 等.实用软件工程 (第三版) [M].北京:清华大学出版社, 2010.

[4]陈卫卫.软件测试[M].西安:西安电子科技大学出版社, 2011.

[5]中华人民共和国国家质量监督检验检疫总局, 中国国家标准化管理委员会.GB/T 25000.51-2010/ISO/IEC25051:2006软件工程软件产品质量要求与评价 (SQua RE) 商业现货 (COTS) 软件产品的质量要求和测试细则[S]北京:中国标准出版社, 2011.

[6]国际软件测试认证委员会.ISTQB测试人员认证初级 (基础级) 大纲[M].北京:人民邮电出版社, 2011.

[7]蔡建平.软件测试大学实验指导教程[M].北京:清华大学出版社, 2009.

回归测试中机器挑选用例方法研究 篇3

【关键词】机器学习；回归测试；测试用例

1.引言

机器学习（Machine Learning， ML）是一门交叉型学科，它涉及到了多个领域，包括：概率与统计学、高等数学、逼近和凸分析等。机器学习人类的学习过程和学习行为，并且加以计算机的模拟或实现。在机器学习过程中，机器本身了获取新的知识或技能。

在机器学习和人工智能的壮大发展的时代背景，对传统的测试工作提出了一些新的挑战。研究通过机器学习的方法，提升传统的测试工作的效率，进一步的提高整个软件开发活动的劳动生产率。

2.软件测试工程的研究综述

软件测试是用于分析是否程序出现错误的过程，测试使用人工操作或者软件自动运行的方式。每个不同的软件有对自身错误的定义方式：通常是软件需求规格中定义了预期结果。

软件测试分类

1、从是否要变异/执行被测试软件分类，分为静态测试和动态测试。如基于代码审查的单元测试，以及相关代码审查工具，都属于静态测试的范畴。

2、从是否要针对软件结构、算法进行覆盖分类，分为白盒测试和黑盒测试。

3、从测试活动在软件开发过程中所处的不同阶段分类，分为单元测试、集成测试、系统测试、验收测试。

我们这里讨论的“回归测试”是属于系统测试的最后一个阶段。

在修改了旧代码后，需要对这部分子都进行测试，以确保这个代码修订没产生新的错误。在大多数情况下，回归测试占测试周期和测试自由的50%。因此，如果能够制定更有效的回归测试用例，将极大的提升整个测试的效率。

回归测试的流程如下：

（1）找出程序中因为新增需求或者故障解决，而被修改的代码

（2）从总的用例库中，去除掉不再合适的测试用例：这部分用例可能是修改没涉及的功能，也可能是一些系统性稳定性的低优先级的测试用例

（3）针对修改的影响部分，增加一部分相关模块的测试用例

（4）搜索出最基本的测试用例，纳入到测试计划：这部分测试用例保证软件不出现意外的基本功能错误

（5）用上述2～4的测试用例集合，形成回归测试的测试范围

3.现有回归测试用例选择方法

对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。

针对修改部分的测试是我们希望改进的内容

当前是优秀的高级工程师逐一的查看开发提交的各个修改点，根据自己对相关部分的理解，以及对开发修改点的学习。整理出需要回归的测试点：这种方法的主要问题是：

需要优秀的工程师参与，这位工程师必须同时具备：既了解测试组的全部测试用例库，也需要能够理解开发提供的修订说明。

每一轮测试完成后，就需要人工干预，从而产生下一轮的测试用例

替代人工的方法是，为每一轮测试，执行类型level 0/1/2这样的测试用例等级。这样同样会带来冗余的测试用例执行，拉长了测试进度。

4.机器选择测试用例的方法

用机器来模拟和替代人工的挑选测试用例：是在回归测试中引入智能化方法的先决条件。整体按照如下的流程：

首先进行的是为每一条测试用例，生成不同的特征向量。在这个步骤中，将原始的测试用例转变成为“记录每个词出现的频率”的数学符号。最后生成如下表格：

其中行代表不同的测试用例，列代表不同的词语描述，数字代表不同的词语在不同测试用例中出现的词频。

然后，根据TFIDF算法将测试用例生成的文本特征向量，转换成为最终的文本特征向量。

这样，表一通过TFIDF算法最终转化的向量表示如下：

完成了特征词语的选择后，就要给选出的特征词语赋以权重。比如“测试”一词，在每个测试用例中都有出现，那么这个词虽然词频很高：但是“权重为零”——也就是说这个词对于描述不同测试用例的不同特征，无任何帮助。对于本研究方案而言，我们使用TF*IDF算法，计算出精确的统计量，以描述特征词语对于中文内容的重要性。

最后，将代码变更说明收集起来，计算特征向量。同时将测试用例库中的内容也做成特征向量。逐个的拿代码变更的特征向量，与用例库中的特征向量进行对比：选出与代码变更特征向量相识程度最高的。这个特征向量所代表的测试用例，既为下一轮回归测试的输入。在这个模块中，我们选择KNN算法，KNN算法也叫K最近邻算法。抽取测试用例库中的每个文本，逐一的与被测试的向量进行比较，每个比较完成后相似度被计算出来。下一步：找出K个最相似的测试用例。并在此基础上给每个被选出的测试用例打分，取分值大者作为比较结果。具体计算公式为：

其中：d为待测文本（开发提交的代码变更说明）向量，q为训练集中文本（原始的测试用例描述）向量。

这里给出一个具体实践：

开发提交了一个代码变更说明如下

最后机器推荐的相关性最紧密的四个用例，如下表：

可以看出，这四个被挑出来的点，都是对ACL重定向的测试：并且测试覆盖了物理端口、AP端口、SVI端口三种不同的端口类型。

进一步的，对这部分的测试进行基于代码覆盖率的验证，可以证明机器挑选出的四个测试用例，确实的有测试覆盖到开发修订的代码。

5.结束语

让机器来自主选择回归测试用例，然后将这个方法融入到自动化测试框架中。让自动化测试框架具有一定智能，能够“自主的产生回归测试用例的变化集合”。譬如整个ACL模块测试用例个数达到300，如果全部回归费时费力，而人工参与分析则会打断持续的自动化测试过程。新方法使用四个测试用例，就可以对开发修订提交的代码进行覆盖；这样一方面我们减少了回归测试的测试用例个数，另外一方面开发修订的代码，也被完整的测试了。

参考文献

[1]米歇尔（Mitchell，T.M.）.机器学习.机械工业出版社，2008-03-01

[2]盧苇，彭雅.几种常用文本分类算法性能比较与分析.湖南大学学报（自然科学版）， 2007.

[3]JOACHIMST.A probabilistic analysis of the rocchio algorithm with TFIDF for text categorization Nashville：1997：143-151.

软件测试用例设计编写技巧 篇4

一、问题

许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验(或习惯)，希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。

当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：

从此几乎很少被执行

执行用例发现的bug很少

根本没有时间为新的功能需求增补用例

有时间补充，但用例结构越来越乱

特性的用例与通性用例之间联系不明确(以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化)

知道怎样执行这个用例，但它要说明什么呢?(多数用例给我们的感觉是只见树木，不见森林，只对某一功能，无法串起)

通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益 处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。

但没有用例或简略用例的编写我们又会舒服很多么?不言自明，谁也不想倒退发展吧。

二、原因

事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：

1、没有适合的规范

“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义，但它适合我们当前的项目么?

每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好?

在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范?于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往“的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。

我们有太多经验，但却没有形成适合的规范。

2、功能与业务的分离

我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。

边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。

复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中(点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体)。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。

用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。

3、测试未能跟上变化

想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢?当地区特性，软件版本越来越多的时候，测试是否在积极响应呢?变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。

疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法很快发现。

永远是变化决定我们的下一步工作，这也是混乱的开始。

三、可能解决的办法

在这里我希望以探讨的方式提出一些可能的解决办法，因为上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。不用拘泥形式，最适合的就是最好的。

1、测试驱动开发，用例指导结果，数据记录变化

“测试驱动开发”(TDD)是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效(Work)更洁净(Clean)，“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。

首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80%以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。

如何在黑盒测试中做到测试驱动开发?我认为可以从用例级别做起，以业务用例指导过程和结果。

开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很明确的指出应该实现怎样的结果，这使得从业务到功能出现一个“阅读上的障碍”，如果最后程序错误了还需返工，这样耗费的人力物力就非常大了。使用业务用例驱动开发，就是一个比较好的方法，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。

业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。

这就是测试主导变化的另一点“数据记录变化”。

我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段(业务段与程序中以窗体或页面的划分是不一样的)，使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。

再进一步的话“数据库”就开始涉及到程序内部的接口了，这需要开发人员的配合。

为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。

为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。

2、功能用例与业务用例分开组织

将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作(例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理?)。

3、审核用例，结对编写

测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例(前提是你有两个以上的测试人员)，内部审核。

测试用例不是一个人编写一个人执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理，提高组员的参与积极性。

四、发展

自动售货机测试用例 篇5

1.售货机有零钱找 2.投入1元硬币 3.投入5角硬币

4.押下橙汁按钮 5.押下啤酒按钮

结果：

21.售货机〖零钱找完〗灯亮

22.退还1元硬币

23.退还5角硬币

24.送出橙汁饮料 25.送出啤酒饮料 2.画出因果图

如图所示。所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示处理的中间状态。中间结点：

11.投入1元硬币且押下饮料按钮 12.押下〖橙汁〗或〖啤酒〗的按钮 13.应当找5角零钱并且售货机有零钱找 14.钱已付清

3.转换成判定表：

4.设计测试用例

1)在售货机有零钱找的情况下，投入1元硬币，押下橙汁按钮，找回5角硬币并送出橙汁饮料。

2)在售货机有零钱找的情况下，投入1元硬币，押下啤酒按钮，找回5角硬币并送出啤酒饮料。

3)在售货机有零钱找的情况下，投入1元硬币，系统不做任何处理。

4)在售货机有零钱找的情况下，投入5角硬币，押下橙汁按钮，送出橙汁饮料。5)在售货机有零钱找的情况下，投入5角硬币，押下啤酒按钮，送出啤酒饮料。6)在售货机有零钱找的情况下，投入5角硬币，系统不做任何处理。7)在售货机有零钱找的情况下，押下橙汁按钮，系统不做任何处理。8)在售货机有零钱找的情况下，押下啤酒按钮，系统不做任何处理。

9)在售货机没有零钱找的情况下，投入1元硬币，押下橙汁按钮，售货机“零钱找完”灯亮，并退还1元硬币。

10)在售货机没有零钱找的情况下，投入1元硬币，押下啤酒按钮，售货机“零钱找完”灯亮，并退还1元硬币。

11)在售货机没有零钱找的情况下，投入1元硬币，售货机“零钱找完”灯亮。

12)在售货机没有零钱找的情况下，投入5角硬币，押下橙汁按钮，售货机“零钱找完”灯亮，并送出橙汁饮料。

13)在售货机没有零钱找的情况下，投入5角硬币，押下啤酒按钮，售货机“零钱找完”灯亮，并送出啤酒饮料。

一种改进的软件测试用例生成方法 篇6

1 图论

用图来描述软件系统,具有直观的优点。比如一个简单的图,G=(V,E),包含一个点集V,一个边集E,每一条边都连接一对顶点,图1(i),(ii),(iii)是图的几个例子。

1.1 用位串来表示一个图

因为在遗传算法中使用的关键数据结构是位串,所以引入图的关联矩阵,用关联矩阵来把一个图表示成一个位串。对于一个有43个顶点的图,它的关联矩阵是一个43×43的矩阵,图的每一个横坐标i以及每一个纵坐标j,都代表这个图中的一个顶点。而矩阵中的Mi,j代表连接顶点i和顶点j的边。用1来表示两个顶点之间存在一条边,而0则代表两个顶点之间无边,图2是一个用位串来表示图的例子。

2 遗传算法

达尔文的自然选择学说是一种被人们广泛接受的生物进化学说。这种学说认为,生物要生存下去,就必须进行生存斗争。在生存斗争中,具有有利变异的个体容易存活下来,并且有更多的机会将有利变异传给后代;具有不利变异的个体就容易被淘汰,产生后代的机会也少的多。遗传算法是模拟达尔文的遗传选择和自然淘汰的生物进化过程的计算模型,它是一类借鉴生物界的进化规律(适者生存,优胜劣汰遗传机制)演化而来的随机化搜索方法。其主要特点是直接对结构对象进行操作,不存在求导和函数连续性的限定;具有内在的隐并行性和更好的全局寻优能力;采用概率化的寻优方法,能自动获取和指导优化的搜索空间,自适应地调整搜索方向,不需要确定的规则。遗传算法的这些性质,已被人们广泛地应用于组合优化、机器学习、信号处理、自适应控制和人工生命等领域。它是现代有关智能计算中的关键技术之一。

2.1 初始化

遗传算法的第一步就是要随机地从搜索范围内选择一定量的个体样本。在本文中,选择250个个体的样例,这些随机样例是互相独立的。

2.2 交叉操作

在遗传算法中,有2个主要的操作———交叉和变异。在交叉操作中,两个原始的解结合形成两个新的解或者子孙。通过解的适应度函数,从基底群中选择父类基底。有三种方法选择交叉操作的解。下面对前两种方法进行简单介绍。第一种方法就是使用基于解的适应度的可能性,如果f(Si)是解Si的适应度,并且是基底群体中所有成员解适应度的总和,那么解Si被复制拷贝到下一代基因中的概率是第二种方法是竞赛选择法。具体做法是,随机地选择两个解,有更高适应度的解获胜,将被复制到下一代基因中。这种方法是模仿生物的匹配模式(两个有着相同性别的成员竞争与有着不同性别的第三个成员交配)。

2.3 变异

遗传算法的另一个重要特征是变异,有两种变异的方法。在第一种方法中,一个功能只能取代一个功能,一个终端只能取代一个终端。在第二种方法中,一个完整的替补树可以取代另一个替补树。

2.4 适应度

现在总共有250个个体,需要通过一些方法来比较出哪些图比其他的图要好。那么就要用适应度来对这些个体进行排序。较高的适应度个体被选取作为父类个体。

2.5 比赛

现在每一个个体都有一个适应度值,为了对基底群进行排序,接下来进行个体之间的比赛。比赛的大小为2,个体们竞争产生后代的机会。在本实验中,随机地从基底群中抽取两个个体,比较这两个个体的适应度值,有更高适应度值的个体被选来做父类基底。这与生物界的“适者生存”是类似的。

2.6 再结合

更优秀的个体被选来通过点变异和点交叉来产生后代。在本实验中,选择变异的比率为50%,与交叉的比率差不多。

点变异就是随机地从位串中选择一个,然后对其进行操作。如果它是0,将其变为1,反之亦然。这就对应图中增加或者减少一个图,图3是变异的一个例子。

点交叉就是选择两个个体,然后将它们合并。首先选择一个随机点n(在本实验中,每个个体包含的位串总数为902),新产生的个体的0到n-1位是从第一个父类个体中复制得来,而n到902位是从第二个父类个体中复制得来,图4是一个单点交叉再结合的例子。

2.7 替换

现在新的后代已经创建好,它们取代了基底群中适应度差的个体。在本实验中,替换比率为25%,这也就意味着每次比赛结束的时候都会有一个个体被替换。在25%的基底群体被替换以后,新的一代就产生了。

2.8 重复

重复上述操作(适应度值的估计、比赛、再结合以及替换),直到适应度值基本上没有什么提高的空间。在本次实验中,选择重复的次数为380,因为在380代以后,基底群体中的多样性减少,所有的个体看起来都很像。

3 采用的方法

在本文中,采用图论与遗传算法相结合的方法来生成软件测试用例。首先,画出软件所有状态的图。为了实现系统的全部状态,在这里使用有限状态自动机和图灵机。一旦图画好了,给每条边定一下方向,在产生的对偶图中选出需要的方向图,接下来就从方向图中找出测试用例。根据输入的遗传算法的基因,选择每个对偶图。在这个过程中,要产生一个染色体集。

3.1 步骤

根据系统所有可能的状态,得到系统的模型。在接下来的方法中,它将以一个对偶图的形式出现。

1)创建原始图的对偶图(在该图中,原始图中的弧都被转换成了节点)。

2)在原始图中,如果弧1是一个节点的输入,而弧2是相同节点的输出,那么在对偶图中,创建一个从节点1到节点2的弧。比如:在图5中,弧“a”是一个节点的输入,而弧“b”是该节点的输出。那么在对偶图中,从节点“a”到节点“b”有一个弧。

3)重复前面的过程,直到原始图中每一个有输入输出弧的节点都在对偶图中有所体现。

4)标出对偶图中经过的每一个节点的名称。

5)完成。

产生的序列是长度为2的字符串的集合(在对偶图中,每两个中间有弧的节点都组成了一个字符串,如“b c”,“b f”,以及“b g”都被生成)。图5中对应的最终序列为“a b c b f e c b g d e f e g”。

下一步就是通过将对偶序列用0和1的格式编码,从而把这个序列转换成遗传基底。然后创建在生成的图中对偶号码的顺序的一个矩阵。在基底群里,使用变异和交叉操作来生成子类。重复这些操作,直到整个图都被覆盖至少一次。从输出的结果可以得到对于给定软件系统所需要的测试用例集。

4 结论

通过这种结合遗传算法和图论的生成测试用例的方法,对于一个给定的系统来说,路径未被测试的可能性会减小,测试覆盖率将会有显著的提高。实验结果表明其效率高于传统的测试用例生成方法。

摘要：文章介绍了一种新开发的基于图论和遗传算法的软件测试用例生成方法。实验表明,该方法在测试覆盖率方面,优于传统的测试用例生成方法。

关键词：软件测试,遗传算法,图论

参考文献

[1]宫云战.软件测试教程[M].北京:机械工业出版社,2008.

[2]施寅生,邓世伟,谷天阳.软件安全性测试方法与工具[J].计算机工程与设计,2008,29(1):27-29.

[3]吕宝林,王晓东,刘文光,等.航天遥感相机TDI CCD成像系统逻辑软件测试平台的设计[J].硅谷,2010(2):1-2.

打破思维定式的例子与方法 篇7

日本有个“东洋人造丝公司”，他们在生产中遇到一个难题，即合成每根纱的5根线粗细总是纺不均匀。技术人员想尽办法也解决不了这个难题。大量次品直接影响了公司的效益。这时有个生产班长建议.既然5根线纺不均匀，索性就生产一种表面粗糙的面料，为何不给一贯追求光滑闪亮衣服的顾客来个惊喜呢?公司采纳了他的建议，结果这种表面粗糙、质地柔软的新型面料投放市场后，很受欢迎。次品的处理办法通常是降价销售，而日本那家公司转换思路，使次品摇身一变成为畅销品，收到了意想不到的效果。

测试用例设计方法例子 篇8

关键词：遗传算法,适应度函数,测试用例,遗传算子,自适应

0 引言

软件测试过程中最重要的一个环节就是测试数据的选择和生成，针对被测程序中一条测试路径需要找到一组具有代表性的测试数据，才能准确地判断被测程序是否按照预期执行。然而随着计算机技术的进步，计算机软件的规模越来越庞大，软件测试不仅要借助对语法、语义等静态软件检测工具[1]，而且应借助对软件内部逻辑进行检测的动态工具。对于大多数程序，难以实现对所有路径覆盖，并且这个工作无疑是繁琐、重复而容易出错的。因此找到一种针对被测路径的测试数据自动生成的方法是非常具有意义的。

测试用例的生成是对给定路径在一个数据集中搜索满足测试标准要求的一组最优输入数据的过程，近年来出现了把测试用例的生成问题转化成路径搜索问题的思想。但是由于软件规模和复杂度的提升，多样化的被测试程序不确定性加大，一般搜索算法很难满足要求。遗传算法具有不受搜索空间的限制性条件约束和不需要其他辅助信息的特点，有很强的自适性，因此遗传算法应用于测试用例的生成有很大的优势。近些年来很多学者对GA算法进行了深入的研究。Ankur Pachauri[2]等人提出了对种群中精英个体的保留以及执行记忆策略，在执行过程中，保留上一代最优个体，用来替换最差个体，以保证种群朝优秀的方向进化;Jin-Cherng Lin[3]等提出将与适应度最大个体相似的数据以较大的概率保留下来，加快了收敛速度;赵庆兰等[4]人对在不同的覆盖准则下应用进化算法时适值函数的设计方法进行了研究;姚尧[5]提出“加速选择法”，使优秀个体被选中的概率增加，较差个体被选中的概率减小。

在很多研究中一般是设定固定交叉和变异概率，然而在遗传后期较大的交叉和变异概率会破坏较优个体，从而影响算法的收敛性。本文提出一种遗传算子的改进方法，使得算法自适应地执行，保证了优秀个体遗传，提高了算法的搜索效率，经过对比试验获得了较好的效果。

1 遗传算法及其应用

遗传算法是模拟生物在自然环境中的遗传和进化过程而形成的一种自适应全局优化概率搜索算法。它最早由Holland[6]教授提出，80年代有Goldberg进行归纳总结，形成了遗传算法基本框架。

它的操作对象是个体或染色体，由一串符号表示，符号串中的单个符号称作基因，而一系列的个体组成一个种群。种群通过染色体的交叉，少部分的基因突变，来产生下一代种群。遗传算法的一般执行过程如图1所示。

由图1可以得出遗传算法的基本执行步如下:

步骤一:初始化。设置进化代数计数器t←0:设置最大进化代数T;随机生成M个个体作为初始种群P(0)。

步骤二:个体评价。计算群体P(t)中各个个体的适应度。

步骤三:选择运算。将选择算子作用于群体。

步骤四:交叉运算。将交叉算子作用于群体。

步骤五:变异运算。将变异算子作用于群体。群体P(t)进过选择、交叉、变异运算之后得到下一代群体P(t+1)。

步骤六:终止条件判断。若t≤T，则:t←t+1，通过解码之后转到步骤二;若t>T，则以进化过程中所得到的具有最大适应度的个体作为最优解输出，终止计算。

2 遗传算法生成测试用例的方法

2.1 适应度函数的构造

被测程序一般有若干个分支，而分支往往都出现在选择结构和循环结构的判断语句中，因此每一个分支都可以由一个判断语句的谓词，即“分支谓词”来表示，“分支谓词”可以表示此分支将被通过的情况。用分支距离来表示当前输入与为了覆盖给定分支所需输入之间的靠近程度。Tracey分支距离计算的方法[7]是计算分支距离的经典方法，本文所采用的分支函数就是在Tracey计算分支距离概念的基础构造的，其具体计算规则如表1所示。

假设被测程序路径上有n个分支，在选定路径上各支点前插入的分支函数分别为f(1),f(2)，…，f(n)。要想得到该指定路径的覆盖情况，只需令F'=f(1)+f(2)+…+f(j)+…+f(n)(其中j=1,2,3，…，n)。F'的值反映了指定路径的执行时的覆盖情况，当F'值为0的时候，表示对给定路径分支完全覆盖，此时的输入数据就是满足要求的测试用例，反之则不是。可见，函数F'可作为评价一组测试数据对指定路径的适应情况。但是遗传算法中适应度函数一般应该取正数，并且最好是搜索它的最大值，所以还需对分支函数进行修改才可以作为评价函数使用。本文对其进行幂指数变换，使其求最小值变成求最大值，适应度函数表达式如式为:

其中f(i)表示指定路径中第i个分支函数。在给定路径完全覆盖的情况下F的值最大。

2.2 算子改进

遗传算法包含三个基本算子:选择、交叉、变异算子，这三个算子对下一代更优种群的产生有着至关重要的作用。

选择算子按照“适者生存，优胜劣汰”的思想进行改进。每个个体自身都有一定的环境适应度和种群贡献度，个体对种群的贡献度决定个体遗传到下一代的概率。个体的贡献度p(ai)表示如下:

其中f(ai)表示个体的适应度。有很多研究者采用混合算法[8]解决遗传算法的最优选择问题，而本文是将贡献度p(ai)作为个体ai被选中进行下一步遗传操作的初始概率，经过自适应调节概率来达到最优选择效果。不难看出p(ai)的值越小，ai被淘汰的概率越小。反之，被保留并遗传的概率越大。如果种群的数量过大而个体的适应度差别不是很明显的时候，本文采用的策略是将大于种群平均适应度favg的个体p(ai)+σ作为选择概率(σ为不大于种群中最小适应度fmin的个体对种群的贡献度pmin(ai))，小于平均适应度favg的个体p(ai)-σ作为选择概率。这样就可以加快收敛速度，提高搜索效率。

对于交叉和变异运算来说最重要的就是交叉和变异概率的设定，一般来讲这两种概率是固定值，但是较大的概率在进化后期将会破坏较优个体，较小的概率会抑制种群的多样性，所以本文在不同的阶段动态地改变每个个体在种群中的交叉和变异概率。

在参与交叉运算两个个体中，如果适应度较大的个体的适应度fmax小于种群平均适应度favg，那么此次交叉运算的概率是固定值pc1;如果fmax大于种群的平均适应度，就动态在pc1和pc2之间改变交叉概率(pc1,pc2需要预先设置)。具体的取值如下:

式中，f'表示个体的适应度，0<pc2<pc1<1。对于变异概率使用同样的取值，在进化过程中使得大于平均适应度的个体得以保留，小于适应度的个体加速进化，在进化后期算法仍能保留一定的交叉与变异能力。

3 实例

这里采用三角形分类程序作为被测程序来检验改进后的算法的效果。实验选用三角形分类程序作为面向路径[9]的测试程序，利用改进遗传算法生成测试用例的程序流程如下:

1)随机产生3N数量的初始数据作为初始种群，每个数据大小在1～255之间;首先单独对每个数据进行编码，然后对三个参数采用级联编码方式编码成一个染色体;

2)将种群传递给适应度评价程序，得到每个基因的适应度;

3)计算种群的平均适应度，通过比较每个个体适应度与平均适应度的大小来决定是否调整个体被选中的概率(个体对种群的贡献度)，整个选择过程利用轮盘赌策略，最终产生进入下一步操作的交配池;

4)随即匹配选择出来的种群个体，按照交叉概率执行交叉和变异操作，利用式(3)来确定交叉和变异个体的操作概率;

5)若找到最优个体或者满足终止条件，则输出最优个体，否则重复执行第2步操作直到满足终止条件。

对被测程序按照表1中的规则进行对分支路径插装分支函数，使得执行程序后得到对应测试数据的适应度，插装评价程序如下:

分支函数插装之后，对于一组测试数据只要满足F5的值为0，那么该组数据就是满足给定路径的一个测试用例。分别用标准算法和改进算法进行实例测试，最后得到结果如图2和表2所示。

从图2和表2中可以看到，对于相同种群规模，在迭代次数相同的情况下，改进后的算法相对于标准遗传算法，有更高的路径覆盖率，有更高的效率。对于种群规模较大的时候，改进后的算法明显比传统的GA算法的收敛速度快。

4 结语

本文主要是针对遗传算法在种群个体集中的情况下容易出现局部收敛、早熟等问题进行了相应的改进，并进行了实验验证。整个进化过程中种群的交叉、变异概率是自适应改变的，在进化中后期，低于平均适应度的个体被选择参与下一步遗传操作的概率减小。但是一旦被选中，其交叉、变异的概率较大，保证了种群的多样性，而高于平均适应度的个体被保留的概率增加。由实验结果分析，改进之后的遗传算法与标准遗传算法相比搜索性能有较为明显改善。

参考文献

[1]王雅丽,李建良.基于检测工具的软件脆弱性分析模型研究[J].计算机应用与软件,2014,31(7):21-23,54.

[2]Ankur Pachauri,Gursaran Srivastava.Automated test data generation for branch testing using genetic algorithm:An improved approach using branch ordering,memory and elitism[J].The Journal of Systems and Software,2012,86(7):1191-1208.

[3]Jin Cherng Lin,Pu Lin Yeh.Automatic test data generation for path testing using GAS[J].Information Sciences,2001,131(1-4):47-64.

[4]赵庆兰,艾丽蓉,刘西洋,等.基于进化算法的软件测试数据生成的自动化[J].计算机测量与控制,2006(10):1420-1422.

[5]姚尧.一种基于遗传算法的软件测试用例生成新方法[J].计算机与数字工程,2009(1):18-21.

[6]Holland J H.Adaptation in Nature and Artificial Systems[M].MIT Press,1992.

[7]Tracey N,Clark J,Mander K,The way forward for unifying test case generation:The optimization based approach.International workshop on dependable computing and its applications[C]//Dept of Computer Science,University of Witwatersrand,Johannesburg,South Africa,1998:169-180.

[8]胡岳峰,高建华.一种面向对象测试用例自动生成的混合算法[J].计算机应用研究,2008(3):786-788.