测试用例的设计 提高测试覆盖率

测试用例的设计 提高测试覆盖率
测试用例的设计 提高测试覆盖率

说到测试用例的设计,我想每个有过测试经历的测试工程师都会认为很简单,不就是:按需求或概要设计,得到软件功能划分图,然后据此按每个功能,采用等价类划分、临界值、因果图等方法来设计用例就行了。

但事实上撇开测试数据的设计不谈,仅就测试项来说,我们发现,对同一个项目,有经验的测试人员,在写用例或测试时总会有更多的测试考虑点,从而发现更多的问题;而有些测试人员测试用例的撰写却只有那么三板斧,表面看好象已经把页面所有信息的测试都考虑到了,实际上却还是遗漏了大量测试覆盖点,导致其测试出来的程序总是比较脆弱。

究其原因,我觉得还是测试用例的撰写水平不到位,更确切地说是测试用例的覆盖度太低。说实话我认为系统测试用例真正做到100%覆盖是很难的。难道说按设计中的功能划分,每个功能都写到了这个用例就覆盖完整了?错,这还远远不够。因为我们知道还有大量的内部处理、转换、业务逻辑、相互影响的关系等都是需求或设计中所不会点明的。而这些一方面需要靠测试人员对项目本身的了解,另一方面要靠测试人员的经验,来一一找到这些隐藏点并予以测试,才能真正地保证我们的测试覆盖度。

所以本文抛开具体的测试数据设计方法,主要从测试覆盖度的角度来介绍用例设计时,如何才能考虑地更周全,如何才能将隐藏的测试项一一找出,从而使我们的测试更全面更完整。

想法虽然美好,可是毕竟每个测试的项目都是各不相同,针对不同项目我们的经验也会告诉给我们不同的想法,这些想法通常很感性,很难用严密的逻辑理论来把它升华。因此本文的内容仍是很简陋且不成熟,只是希望能以本文为砖,引起大家的思考,一起来补充完善,以使我们的测试用例设计水平不断提高。

正文

一、测试用例的切面设计

1、功能点切面

2、特定切面

3、隐含切面

(1)、后台功能

(2)、完整业务流程的测试

(3)、某种特定情况下的系统运行(4)、其它相关系统

(5)、除功能测试外的其它测试类型

二、详细用例的设计

1、功能切面表面用例设计

(1)、具体功能测试

(2)、组合操作的测试

(3)、GUI界面的测试

(4)、数据初始化情况测试

(5)、业务需求实现是否正确

2、功能切面隐含测试项用例设计:(1)、数据完整性的测试

(2)、后台的特殊处理

(3)、功能业务之间的关联与转换(4)、从设计实现发掘测试点(5)、并发操作时的测试

3、特定切面用例设计

4、隐含切面用例设计

(1)、无界面的后台功能

(2)、与业务流相关的测试

(3)、其它测试类型

三、测试数据的设计

一、测试用例的切面设计

所谓测试切面设计,其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型,也就是从上到下,逐渐细分,大模块包括小模块,小模块包括更小的模块。但仅仅如此是不够的,我们还要从更多的角度切入系统,从不同的角度把系统切分成一块一块的,来进行测试,从而确保测试大项的完整性。

1、功能点切面

这是最常见的切面,通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度,按每个功能;或一个功能点分多页;或多个功能点合成一页来进行用例的撰写。

2、特定切面

除此以外,还有一种特定切面的划分方法,也是用例撰写时经常会用到的。所谓的特定切面,就是忽略掉表面上的功能点,而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能,从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成,这时我们就可以把“授权记录生成”单独拿出来做一个测试项,而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页,也是一种特定切面。所以如果说将用例按功能点划分是一种纵向划分法,那么特定切面就是从横向的角度分析所得到的切面。在普通功能点划分上再根据实际情况设计特定切面,可以使我们的用例阅读性、理解性、操作性更强。

3、隐含切面

这类用例是最容易被忽略的。它往往不是明显的某个功能项,可能是功能项后台的隐含处理,也可能是多个功能项之间的关联处理,甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解,来进行挖掘。

(1)、后台功能

常见的如一些定时自动启动的服务;以及某种特定情况下自动执行的操作等。它们在界面上往往是不体现的,但许多在需求设计中还是会提到,也有一些比较细小的功能可能会被忽略,就需要测试人员根据对项目的了解程度来进行挖掘。所以说一个熟悉项目的和一个不熟悉的测试人员,写出来的用例就完全是两个层次的。

(2)、完整业务流程的测试

我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线,其中的某个按钮是点,多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。

事实上目前公司的软件本来都是业务型应用软件,将各种功能从业务流中切割出来单独写用例,肯定也会有涉及到整体流程的情况。若不加以区分,将细节与全局搅在一起,不仅思路混乱,也容易考虑不周。因此在系统测试阶段,建议用例设计要有分有合,针对具体功能的就只围着这个功能转:而在业务流程测试项中,再完全从整体的业务流角度出发去考虑用例,这样不仅不容易产生疏漏,用例阅读与执行也更清楚。

(3)、某种特定情况下的系统运行

这类用例的设计往往与系统实际业务情况密不可分。比如财务软件,通常需要在月尾一天、月头一天、年尾一天、年头一天,对所有相关功能中的日期处理进行测试;又比如WIN2000环境开发测试的系统,要测试在98、XP、2003等操作系统下是否能运行自如;再有如存在大量动态图片视频等的网页,在普通网速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑,来进行测试补充。

(4)、其它相关系统

即指在当前项目中直接使用的其它成果,包括公司自有的系统模块、组件、函数;以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚,是否需要测试。若时间紧张或其它原因决定不测的,应在测试计划中说明。若需要测试的,则具体可根据实际情况来设计,可以是通过系统某个功能的测试来涉及,此时就不需要单独划分测试项;若相对比较独立的,也可以通过单独的测试项来对其专门进行测试。

(5)、除功能测试外的其它测试类型

包括可靠性、安全性、恢复性、配置安装测试等等,这些测试类型都是一个单独的测试项。

所谓好的开始是成功的一半,保证测试项划分的完整、合理、正确,会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑,并要在测试过程中随着对软件的深入了解,不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来就可以了。

二、详细用例的设计

划分好了测试项,接着就是针对各个测试项,考虑具体的测试用例了。根据测试项的特点,测试用例的设计角度也有所不同。下面我们就来看看通常的功能点测试用例,该从哪些角度出发来进行设计:

1、功能切面表面用例设计

(1)、具体功能测试

根据需求分析设计,按页面提供的各个功能项,采用黑盒测试的各种方法,设计用例。比如页面提供了增、删、改、查功能,那么这四个功能是否正确实现就是我要验证的。这是最简单、最基本,同时也是必须的测试用例,通常我们的编码人员自测也就是做到这个程度。^_^

(2)、组合操作的测试

这是从上一角度扩展出来的,相对而言也是编码人员不会去测试的,所以需要测试人员多作考虑。

所谓组合操作测试,也就是选择某几个操作项,按一定的顺序进行操作,验证系统不会出现意外错误。当然要将所有功能项排列组合一遍来测试不仅不必要,也是不可能的。所以具体要将哪些功能项进行结合,要按怎样的步骤来操作,还是需要测试人员根据实际情况来作设计(所以说在IT业人才就是一切呀,呵呵:)。

一般来说我们会考虑功能项之间的数据是否会存在关联,若有就需要考虑这种组合了。常见的如查询功能,需要将各条件逐一累加进行测试;增完的数据能否改,改完能否删,删完能否再增,这之间能否查询到正确结果;按钮的连续多次点击会否出现异常;有严格前后顺序要求的几个操作,尝试颠倒顺序去操作,系统能否控制等等。

不仅在某功能内部,扩展到有关联的多个功能项之间,同样有组合操作测试的存在。如申报完了能才反馈;如申报成功或失败后再尝试申报等。当然对于这类用例既可以写到某个功能切面中,也可以单独写到完整业务流程的切面中,这就取决于可能涉及用例的数量了,若关

系比较复杂,当然是单独写比较好;若也就是三五个用例数,那就直接在某个功能的用例中补充好了。

(3)、GUI界面的测试

这类测试是测试人员的强项,具体测试项目如限长、非法输入等等,就不必赘述了。要提醒的是在测试时,一定要从实际使用者的操作习惯出发。要知道界面原型所能确定的也只是页面的摆放显示,而实际操作时的控制实现仍是编码人员自行实现的,即使有编码指南,其所及范围也是十分有限。而许多编码人员在用户操作方便性上的考虑往往差强人意。所以测试人员就必须要把好这一关。

(4)、数据初始化情况测试

不该为空的数据是否有校验;该有默认值的数据默认值是否正确;引用其它功能生成的数据,是否会实时刷新;页面关闭或系统重启后,数据的初始化设置等都是这类用例。

(5)、业务需求实现是否正确

这类问题往往是由于我们的需求说明欠详细,而编码人员的需求了解程度又较低造成。作为测试人员自然要对需求进行深刻研究,来对软件实现进行把关。这里常见的一些关注点有:

u数据的长度、类型控制是否合理(比如控制纳税人识别号只能为数字,但实际业务中是会有字母出现的);

u业务逻辑控制是否合理(比如某数据项不提供修改,但实际业务中该数据项经常会需要改动);

u提供的实现方式是否合理(比如只在某一页面提供某数据的获取功能,但根据业务划分有些人员不能操作此页面,却必须要能看到该数据);

u所做的数据控制是否合理(比如必须在A功能中新增数据,然后才能在B功能中操作,但实际业务中有可能会出现相反操作);

u所做的数据控制是否完整(如授权的方式有普通按月、有买断、有按数量控制,那么当同一企业尝试同时存在以上几种授权方式时,系统是否能有必要的控制);

u还有其它一些操作细节上的满足(如业务上需要批量操作的数据有否提供批量操作功能、导入失败的结果文件是否能修改后直接再导入等)。

对于不满足的需求,经开发组长、需求经理等确认不作修改的,就要作为软件的缺限或限制在测试报告中进行说明民。

2、功能切面隐含测试项用例设计:

(1)、数据完整性的测试

当某数据被其它功能引用;或当前功能要引用其它来源的数据,就会涉及到数据完整性的测试。最常见的如被引用的数据删除了,或关键字被修改了,引用的数据会否出错;两个途径进入的数据会否冲突或重复;此外还有因为相关的几个功能由不同人员编码,从而导致彼此的控制不一致,如A功能进入的数据在可允许的极端情况下,到B功能中引用会否异常(最常见如用户名录入时允许长度10,但引用到某个单子填写时允许长度是8,此时就会异常了)。

(2)、后台的特殊处理

是指某功能除了表面所见以外的程序处理。比如订单录入,表面所见的就是订单的保存,但后台还会有重复数据的判断、非法数据的处理、业务逻辑上冲突情况的处理以及其它种种根据需求设计所特有的处理。又比如备份功能,在备份前可能有数据的清空、备份目录的清空、备份目标是否存在的校验、备份文件重复时的处理等等。类似这些在分析设计中就未必会写全了,还是要测试人员多花心思去思考挖掘。

(3)、功能业务之间的关联与转换

相关联的几个功能之间数据的传递,会否产生影响。比如新增录入的某种特殊字符,要查询时会引起查询SQL语句异常;又如某下载文件名中存在中文等字符,下载时由于编码问题导致乱码的出现;再有报表填写时到小数点后四位,生成报文时会不会被忽略成两位了等等。象这种问题,通常只能是在每个功能设计用例时,尽量保证用例中的数据能涉及到允许范围的各种情况,即充分运用等价类划分+边界值的方法设计出各种“稀奇古怪”的数据,并需验证这些数据从头流到尾,都还是能保持其正确性,而不仅仅是在当前功能中正确。

(4)、从设计实现发掘测试点

这个就是我们测试中最难捉的BUG了,它往往是由编码人员自己在编码时创造出来的,连设计人员都不会知道。

比如内部管理系统中,正常的产品,其类别通常是2位数字;如果是模块,其类别就以产品代码来取代。这时如何来判断该产品是模块呢?最保险的当然是校验其产品类别字段的值能否在产品表中找到;也有比较简单的方法就是直接判断类别代码大于2位还是小于等于2位。此时若能确切知道采用的是哪种实现方法,就可以直接找到其漏洞所在。比如采用后一种方法,当产品类别长度变化时,明显系统会出错。那么即使确认该实现方式不改,测试人员也应将其作为限制写入测试报告,。让大家知道这个产品类别长度是不能随意变化的。

而让人郁闷的是,类似这样的实现,有太多的编码人员都是随性处理的,它们细而隐蔽,在系统数据正常情况下根本不会被发现;而在漫漫的软件使用道路中,由于需求变更等原因对原有一些设计做维护变化,这种问题就会突然暴发出来让人措不及防。所以要杜绝这类漏洞,除了测试人员要做土拨鼠,不停地对软件各功能的实现细节进行挖掘外,也要多给编码人员灌输完美实现的理念,多用复杂但抗压性高的代码,来替代简单但依赖性强的代码。

(5)、并发操作时的测试

即两个或多个用户同时操作同一功能时,会否引起数据的混乱。通常在C/S结构下,如果有同时操作的可能,是需要作此测试的;而在B/S结构下由于其特殊性,此问题通常难以解决。除非就是某用户一旦使用过某功能后,在一定时间内锁定不允许再用,但这也会带来实际应用中的不便,所以除非是特别核心的数据,一般我们也不会去做此控制,当然对于可能出现的并发冲突也就作为系统的限制进行遗留了。

3、特定切面用例设计

所谓特定切面,其实就是从另一个角度切割出来的用例面,所以具体的用例撰写方式其实与功能切面是一致的。

4、隐含切面用例设计

隐含切面分以下几种情况:

(1)、无界面的后台功能

对这类测试项,需要通过参数设置、代码调用等方式来实现测试,但具体的测试设计其实与普通功能测试并无二致。这里要注意,因为测试时往往前台、后台是分开来分别进行的,而实际运行时两者很可能是交集的,所以测试时要多注意后台功能的执行与前台的一些功能执行会否产生冲突?比如后台有个文件搬运的服务,那有没有可能在前台文件生成过程中,后台执行文件搬运了?若有可能就要注意会否出现问题了。

(2)、与业务流相关的测试

这类测试用例的设计,就要从完整业务角度来设计数据了。从理论上来讲,应该要将各个功能可能出现的各种数据排列组合到一起,按业务流程逐一进行测试。但实际上我们不可能去做全覆盖。所以设计这类用例时,最好有一张草稿,将所有相关功能按业务流程逐一列示,然后再将每个功能可能出现的特定数据一一标上,最后将图中最可能出现的、最可能出错的、最核心的数据取出来,分别组合成一个个完整的业务数据用例,来进行测试。这样就可以按清晰的思路,找出最实用、最有效的测试数据。

(3)、其它测试类型

这一类的测试通常都有其特定的方法。如要测可靠性就准备大量数据不停地执行;要测安全性就考虑数据的加密、数据的传输、数据的破坏;恢复性一般从网络、电源方面着手;配置安装则根据系统可支持的配置,搭建相应环境进行功能验证,此处的验证也要掌握技巧,即要多测试那些涉及到:数据库读写、磁盘文件读写、文件上传下载、文件加解密、数据统计、图表展现、打印等方面的功能。

三、测试数据的设计

每一个测试思路最终都要转化成具体的数据才能来执行。关于测试数据设计的方法也不外乎那几种,就不再赘述了。此处单就一些经常易犯的错误,提出一些注意点,作为用例数据设计时的参考:

1、尽量避免可能出现歧义测试结果的数据:即你设计的数据必须能唯一正确地反映出你所希望测试的结果。比如一组测试数据,有可能得到结果A或结果B,此时单用此数据来测试预期结果为A的用例,那明显就产生了歧义。

2、对于不便具体列示的数据,则必须详细描述其各项特性:有时我们在设计用例时为节约时间,不一定要到具体的一个数值,这也是允许的,但前提是你必须要详细描述清楚你要测试的数据特性。比如数据库字段限长20,要测试超长数据时,可以描述为:尝试输入长度为21位的半角英文字符;尝试输入长度为19位的半角英文字符,然后切换到中文全角再输入一位全角字符等。千万不能写成:尝试输入超长字符,因为这只能是测试方案,作为方案是可以这样写,但到用例阶段,必须要是具体的、明确的、可操作的。

3、测试数据的设计必须有明确目的性:即测试数据是从测试方案衍生而来的。如上例测试方案是测超长字符输入控制,所以测试数据就要根据具体字段长度来录入超长数据,如果一味录入长15位、长16位的数据那就没意义了。好的测试数据是可以同时针对多个测试方案的,此时可以在用例边注明一下该数据的测试目的,因为随着时间推移,对着具体的数据你

也许会忘了它到底是测什么的,而这对你最后总结测试,查验测试覆盖率是非常不利的,所以随时记下你的思路想法吧,好记性不如烂笔头。

4、测试数据可省略描述:测试数据描述以能让人看懂为准则。所以写用例时当碰到连续几个用例,仅某几个关键数据值改动,其余均是一样的情况下,不必每个用例都要重复描述所有数据,可以在第一个用例描述完整之后,其余用例中仅列示不同的数据,并标明其余数据同上第X个用例,即可。这样测试时仍能复原测试数据,且该用例的测试目的一眼就明,增加了用例的清晰性。

至些,我根据测试用例设计的顺序,从测试数据的切面设计(即测试项划分),到详细测试用例设计,再到测试数据设计三个层面,逐一介绍了如何来提高测试用例的覆盖度。因为具体项目中的具体情况太多,以上叙述的内容也只能是管窥蠡测。至于其中的疏漏错误之处应也难免,只希望各位阅后能打开思路,从自己多年的测试经验中多总结、提炼出一些想法思路,进一步补充完善这个文档,使大家的测试用例设计能力都能进一步提升。

软件测试用例设计方法---决策表

决策表,也叫判定表。在所有的功能性测试方法中,基于决策表的测试方法被认为是最严格的,因为决策表具有逻辑严格性。 在一些数据处理问题当中,某些操作的实施以来与多个逻辑条件的组合,既针对不同逻辑条件的组合之,分别执行不同的操作;决策表就是分析和表达多逻辑条件下执行不同操作情况的工具。 1 决策表通常由以下4部分组成: 条件桩(condition stub):列出了问题的所有条件。通常认为列出的条件的次序无关紧要。 动作桩(action stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。 条件项(condition entry):列出针对它所列条件的取值,在所有可能情况下的真假值。作项(action entry):列出在条件项的各种取值情况下应该采取的动作。 2 决策表的生成: (1)确定规则的个数 ?有n个条件的决策表有2n个规则(每个条件取真、假值)。(2)列出所有的条件桩和动作桩 (3)填入条件项 (4)填入动作项,得到初始决策表 (5)简化决策表,合并相似规则

?若表中有两条以上规则具有相同的动作,并且在条件项之间存在极为相似的关系,便可以合并。 ?合并后的条件项用符号“-”表示,说明执行的动作与该条件的取值无关,称为“无关条件”。 举个例子↓↓

3 决策表的优缺点: 决策表最突出的优点是,能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。 ? 利用决策表能够设计出完整的测试用例集合。 ? 运用决策表设计测试用例可以将条件理解为输入,将动作理解为输出 4 何种情况下使用? ? 规格说明以决策表形式给出,或较容易转换为决策表;

测试用例设计思路举例(参考)

ECShop2.7.2用例设计思路举例 说明 用例设计方法的运用非常灵活,没有绝对的套路可言,以下用例设计思路仅供参考。 操作流程举例 参考文档: ?ECShop_2.7.2_简易操作手册V1.0, ?B2C商城ECShop需求规格说明书_2.7.2V1.0 设计思路: 根据操作手册,理清业务逻辑前后关系,再结合SRS文档确定具体的流程细节和分支流程。可以通过画流程的方式梳理流程(流程分析法),下面是部分主流程的案例: ?正向订单流程_余额付款 1)前台页面浏览商品->加入购物车->结算中心->余额付款 2)后台管理中心订单查询->配货->生成发货单->确认生成发货单->去发货->发货 3)前台页面确认收货END ?正向订单流程_货到付款 1)前台页面浏览商品->加入购物车->结算中心->货到付款 2)后台管理中心订单查询->配货->生成发货单->确认生成发货单->去发货 ?逆向订单流程 1)前台页面确认收货->后台管理中心退货->填写退货信息点确定按钮->确认退货 ?商品添加流程_新商品 1)后台管理中心商品管理->新建商品类型/新建商品分类/新建商品品牌->添加新商品(通用信息,详细描述,其他信息,商品属性,商品相册,关联商品,配件,关联 文章) 考虑完所有流程后,再补充考虑部分异常情况,例如:流程中的先后顺序发生变化,或者跳过某个步骤后,系统能否完成后续流程作业。(有些流程是不可能调换顺序或跳过的) Q:流程分析法在设计测试用例的时候会经过很多页面,操作很多字段,这些页面和字段该如何取值呢? A:流程分析法一般考虑页面或字段的有效取值(一般取等价类中最不容易出错的值),测试过程中不关注页面输入域的各种取值情况,特别是错误取值的情况。目的是为了确保流程是可用的。 Q:流程分析法既然不能证明某个页面或字段没有问题,那用此法有何意义呢,为何不直接考虑验证每个页面和模块的各种有效和无效的取值?

系统测试用例设计方法

系统测试用例设计方法 --------------王永安

目录 一、测试用例格式以及写作要点 (3) 二、系统测试用例设计方法 (4) 1、等价类划分法 (5) 2、边界值分析法 (6) 3、判定表法 (7) 4、因果图法 (9) 5、状态迁移图法 (15) 6、流程分析法 (20) 7、正交试验法 (35) 8、错误推测法 (42)

一、测试用例格式以及写作要点 测试用例编号 测试用例编号是由字母和数字组合而成的,用例的编号应该具有唯一性,易识别性。比如可以采用统一的约定,产品编号—ST—系统测试项名—系统测试子项名—编号。这样看到编号就可以知道是做的什么测试,测试的对象是什么。也方便维护。 测试项目 你现在这个测试用例所测的项目名,可以是测试用例所属的大类,被测需求,被测的模块,或者是被测的单元。例如:计算器加法功能。 测试标题 测试标题是对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复,因为每个测试用例的测试点是不一样的。例如:手机在没有SIM 卡的情况下,拨打119。 重要级别 重要级别分为高中底三等: 高:保证系统基本功能、重要特性、实际使用频率比较高的用例; 中:重要程度介于高和底之间的测试用例; 底:实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。 注:一般情况下,重要级别为高的测试用例,一个测试子项里有且尽有一个,大多数都是重要级别为中的测试用例。因为一般我们会进行一个系统测试预测试,如果重要级别为高的太多,则就失去了预测试的实际意义。 预置条件 就是执行当前测试用例的前提条件,如果不满足这些条件,则无法进行测试。 输入 测试用例执行时,需要输入的外部信息。例如某一个文件,数据记录等。

白盒测试用例设计方法

1白盒测试用例设计方法 1.1白盒测试简介 白盒测试又称结构测试、逻辑驱动测试或基于程序的测试,一般多发生在单元测试阶段。白盒测试方法主要包括逻辑覆盖法,基本路径法,程序插装等。 这里重点介绍一下常用的基本路径法,对于逻辑覆盖简单介绍一下覆盖准则。 1.2基本路径法 在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出独立路径集合,从而设计测试用例,设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。 在介绍基本路径测试方法(又称独立路径测试)之前,先介绍流图符号: 图1 如图1所示,每一个圆,称为流图的节点,代表一个或多个语句,流程图中的处理方框序列和菱形决策框可映射为一个节点,流图中的箭头,称为边或连接,代表控制流,类似于流程图中的箭头。一条边必须终止于一个节点,即使该节点并不代表任何语句,例如,图2中两个处理方框交汇处是一个节点,边和节点限定的范围称为区域。 图2

任何过程设计表示法都可被翻译成流图,下面显示了一段流程图以及相应的流图。 注意,程序设计中遇到复合条件时(逻辑or, and, nor 等),生成的流图变得更为复杂,如(c)流图所示。此时必须为语句IF a OR b 中的每一个a 和b 创建一个独立的节点。

(c)流图 独立路径是指程序中至少引进一个新的处理语句集合,采用流图的术语,即独立路径必须至少包含一条在定义路径之前不曾用到的边。例如图(b)中所示流图的一个独立路径集合为: 路径1:1-11 路径2:1-2-3-4-5-10-1-11 路径3:1-2-3-6-8-9-10-1-11 路径4:1-2-3-6-7-9-10-1-11 上面定义的路径1,2,3 和4 包含了(b)流图的一个基本集,如果能将测试设计为强迫运行这些路径,那么程序中的每一条语句将至少被执行一次,每一个条件执行时都将分别取true 和false(分支覆盖)。应该注意到基本集并不唯一,实际上,给定的过程设计可派生出任意数量的不同基本集。如何才能知道需要寻找多少条路径呢?可以通过如下三种方法之一来计算独立路径的上界: 1. V=E-N+2,E 是流图中边的数量,N 是流图节点数量。 2. V=P+1,P 是流图中判定节点的数量 3. V=R,R 是流图中区域的数量 例如,(b)流图可以采用上述任意一种算法来计算独立路径的数量 1. V=11 条边-9 个节点+2=4 2. V=3 个判定节点+1=4 3. 流图有4 个区域,所以V=4 由此为了覆盖所有程序语句,必须设计至少4 个测试用例使程序运行于这4 条路径。 在采用基本路径测试方法中,获取测试用例可参考以下方式:

报表测试用例设计方法总结

报表测试用例设计方法总结 报表的测试主要分为以下几个方面:界面,安全性,准确性,展示速度(性能) 数据统计方面 1、报表统计数据的正确性; 2、报表统计数据的完整性; 3、报表统计数据的合法性;比如,统计金额字段需求要求有“$”等; 报表格式 1、表头字段表示的正确性; 2、表头字段表示的完整性; 3、表头字段表示的字体,字号,美观程度; 4、各统计字段的显示是否满足需求;比如:数据过长时要求折行还是缩小; 5、页眉和页角的表示; 报表的预览和印刷 1、预览中的显示完整性; 2、多页情况下,第2页的表头显示; 3、能否实现需求要求的特定印刷情况;(比如,印刷使用指定的模板) 4、预览后印刷; 5、不预览,直接印刷 6、需求规定各类打印机的测试; 数据准确性测试,带有报表测试的系统分为两类,一类是业务系统中,带有统计分析功能模块,该模块中包含分析报表,这个系统的主体是业务系统,报表是为**业务的而提供帮助的。 比如说,应年检统计报表,某月应交罚款车辆统计报表,这样的报表数据准确与否,可通过增加、删减、修改相关业务或相关业务的参数,查看统计报表数据变化,检查数据准确性。

另一类是系统只有统计功能,就是我说的数据仓库展现这类,它与业务系统分离,并且经过多层处理,比如数据仓库的数据,经过抽取,清洗,展现前会经过数据挖掘,数据再处理,有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂,当然检查出数据错误,修改定位也是很不容易的。 从整个项目节约成本看,逐层测试效果是最好的。完全修改率也是最高的。 首先建立测试数据模型,模拟所有应用表,建立简单易跟踪的数据用例,底层的数据表测试,方法很原始,嘿嘿,通过SQL语句和手工计算,对数据进行比对。对系统中的报表数据准确性测试方法较为灵活, ①系统中报表重叠的进行比对 ②对子报表汇总与父报表比对,就是对月报表汇总与年报表比对,日报表汇总与月报表比对,这只是一个方面,可以从维度关系考虑,地域,行政级别、时间,个人等方面下手,进行汇总比对 ③这个方法如果延伸点呢,可以将报表间的业务逻辑关系作为比对依据。呵呵,这要看测试人员的需求了解深度个人能力了。插几句不想干的话,做测试工作总让我保持快乐状态,前两天我的一个同事说,公司里一直没有人喜欢做测试工作,这个工作太枯燥。嘿嘿,我当时就说我做了这么多年的测试工作从来没有感觉到枯燥。重复性工作不代表枯燥,编程其实不也是重复嘛,人每天谁不重复昨天的事啊,吃饭,吃这个动作重复一生,有谁觉得麻烦枯燥啦? ④使用SQL和手工计算进行比对。以上是差错方式,接下来讲一下查什么错?哪些地方容易出错 ● 原始表使用错误:因为表比较多,又加上没有统一的数据关系对应表,很容易表使用错误,当然这应该是单元测试检查出来的错误。 ● 数据处理逻辑错误:这一点容易因为测试人员和开发人员对需求理解有偏差造成争执,所以在需求评审时,对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误,逻辑编写有偏差,边界值、特殊情况处理不当。 ● 数据权限:不同用户对数据有着不同的查看权限。这关系到数据的安全性。 ● 数据误差:数据的保留位数,数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。 ● 由于字典表,数据错误,而造成的数据错误,如,根据性别统计,购买量,表中的男女颠倒,或者没有考虑性别缺失项,用了if else,这样就是把表中缺失该项内容的算成了

计算器软件测试报告

江西工业职业技术学院 毕业综合实践 课题名称:安卓手机计算器 作者:廖杰学号:20112715 分院:电子与信息工程分院 专业:计算机网络技术 指导老师:占华为专业技术职务讲师 2013年 11 月 14日

一、问题描述: 用Java实现求两整数的加、减、乘、除运算结果,要求两整数的范围都是[0,100]。从键盘输入数m,数n,判断他们的范围,若不在[0,100]范围内,则输出提示语,要求重新输入,并且在做除法运算时,当除数为0时,输出提示语,说明除数不能为0。 将两数的范围定在[0,100],以更好的进行边界值分析,等价类测试等黑盒测试方法;为充分体现白盒测试的特点,有些地方故意用了if-else语句,while循环;另外,加、减、乘、除运算分别用了四个函数来计算,这样既可以在主函数中调用,又可以在Junit框架中分别对这四种运算进行测试。 二、程序源代码: 1. import java.util.Scanner; 2. public class Computer { 3. private int a; 4. private int b; 5. public Computer (int x,int y) //构造函数,初始化 6. { 7. a=x; //注意:Juint中需要输入测试值在0~100范围内 8. b=y; 9. } 10. public double add() //加法 11. { 12. return a+b; 13. } 14. public double minus() //减法 15. { 16. return a-b; 17. } 18. public double multiply() //乘法

软件测试中的测试用例设计方法场景VS功能

软件测试中的测试用例设计方法场景VS功能 发布: 2010-7-16 10:20 | 作者: 网络转载 | 来源: 领测软件测试网采编 | 查看: 92次 | 进入软件测试论坛讨论软件测试中的测试用例设计方法场景VS功能 1、目的 不管我们在做哪些测试我想第一我们要站在用户的角度,以用户的使用逻辑及操作习惯为出发点,结合功能用例的设计方法,使用例设计更符合用户使用逻辑更具有可执行性,从而最大程度上覆盖用户需求。2、使用者 在使用者看来,用例设计、执行及热爱测试的人员 3、测试用例设计方法 按照不同的规则可以将测试用例分为四个部分:场景用例(用户场景)、系统用例(用户场景的细化)、功能用例(基于业务规则、界面)、设计指标(基于环境、性能、安全等)。 ◆ 用户场景用例:按照用户的实际操作与业务逻辑设计用例,不必涉及很复杂的操作或逻辑,把用户最常用的、正常的操作流程作为一个场景设计测试用例 ◆ 系统用例:是用户场景的细化,包含正常场景、分支场景和异常场景,是两个或多个有关联的功能组合而成的场景。 ◆ 功能用例:用于验证各功能点的业务规则,包括界面元素和各功能的业务规则验证。主要针对单个功能点。 ◆ 设计指标:系统所需要达到的各级指标。主要包含环境、性能、安全等方面的指标。 第一步:用户场景用例(关键字:模拟用户实际操作)

描述用户的主要业务目标,包含完整的系统级场景和模拟用户实际操作的不同场景,几个功能点的组合也算是用户场景,这类的用例不宜过多。 第二步:系统各角色的系统用例 将系统划分多个角色,再将每个角色分解为多个任务,每个任务就是一个系统用例。系统用例分别正常流程、异常流程,分支流程,以场景的形式描述。 系统用例命名原则:正常(异常、分支)流程_描述 第三步:功能用例 描述单点功能的逻辑规则及页面元素,分层描述逻辑规则,对逻辑规则细化可直接作为用例的操作步骤描述。 第四步:设计指标 设计指标包含三种类型的用例:环境测试用例、性能测试用例、安全性用例。 环境测试用例可依照操作系统版本,浏览器版本不同划分为多个用例。每个用例下可直接调用已有的用户场景用例、系统用例、功能用例,可无须单独编写用例。 4、用例设计规则 规则如下: 1)每个用例需要选择优先级,分为高、中、低三种。 每个用例需要关联项目。 2)需要特别强调的是,用户场景用例,一定要脱离系统提供功能,站在用户角度来设计用例,从用户实际可能的操作场景考虑。

测试用例实例—常见功能测试点

测试用例实例--常见功能测试点 笔者在网上看到了一篇文章,个人认为此文对于“软件常用功能测试点”总结的很好,特此摘录下来和大家一起分享。 1. 登陆、添加、删除、查询模块是我们经常遇到的,这些模块的测试点该如何考虑 1)登陆 ①用户名和密码都符合要求(格式上的要求) ②用户名和密码都不符合要求(格式上的要求) ③用户名符合要求,密码不符合要求(格式上的要求) ④密码符合要求,用户名不符合要求(格式上的要求) ⑤用户名或密码为空 ⑥数据库中不存在的用户名,不存在的密码 ⑦数据库中存在的用户名,错误的密码 ⑧数据库中不存在的用户名,存在的密码 ⑨输入的数据前存在空格 ⑩输入正确的用户名密码以后按[enter]是否能登陆 ------------------------------------------------------------------------------------------------------ 2) 添加 ①要添加的数据项均合理,检查数据库中是否添加了相应的数据 ②留出一个必填数据为空

③按照边界值等价类设计测试用例的原则设计其他输入项的测试用例 ④不符合要求的地方要有错误提示 ⑤是否支持table键 ⑥按enter是否能保存 ⑦若提示不能保存,也要察看数据库里是否多了一条数据 ------------------------------------------------------------------------------------------------------ 3) 删除 ①删除一个数据库中存在的数据,然后查看数据库中是否删除 ②删除一个数据库中并不存在的数据,看是否有错误提示,并且数据库中没有数据被删除 ③输入一个格式错误的数据,看是否有错误提示,并且数据库中没有数据被删除。 ④输入的正确数据前加空格,看是否能正确删除数据 ⑤什么也不输入 ⑥是否支持table键 ⑦是否支持enter键 ------------------------------------------------------------------------------------------------------ 4)查询 精确查询:

软件测试用例设计--场景分析方法

·软件测试用例设计--场景分析方法 方法简介 现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。 基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2和4)。 二.实战演习 1. 例子描述 下图所示是ATM例子的流程示意图。

表3-8 场景设计 注:为方便起见,备选流3和6(场景3和7)内的循环以及循环组合未纳入上表。 3.用例设计 对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各 列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例

ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。 表3-9 测试用例表 4.数据设计 一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。

测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据,如表3-10所示。 表3-10 测试用例表

测试用例范例

讨论用TestDirector管理测试用例 编制时间:2007-03-16 编制部门:测试组 编制人:郭宏元 “测试用例”虽有国标作蓝本,但实际中,一直以来“测试用例”是所有测试人员有争议的地方,此所谓“仁者见仁,智者见智”。而“法无定法,则无定则”,所有的规范与标准都是围绕更适应人们的工作环境而创建。在此,我就我的一些体会在此与大家分享。 一般来说,“测试用例”的编写主要分三大类,贯彻的原则与基本架构如下: 分类: 1、对验证过程的一个记录; 2、展现一个功能; 3、描述一个场景步骤; 原则: 1、有“对象”属性的描述; 2、阐述了某个“对象”的方法或事件。 3、对属性、方法或事件有详细的定义。 基本架构: 1、目的; 2、前提条件; 3、输入步骤(输入动作或数据,预期结果) 以下总结了一些针对测试用例的“编写要点”作出一些较简单的规范。以方便统一测试用例的编写,并保证使用最用效的测试用例来保证测试质量。我们都知道根据详细设计文档编写测试用例的目的不在于验证软件达到的功能,而在于验证软件应该达到的功能,这样可以去除软件开发过程中的随意性。所以下面就明确测试用例的“目的”、“范围”、“原则”是什么?以及采用的方法做了一点描述。 1、目的: 围绕测试名称或满足实现测试功能而进行。 2、范围:

适用于所要测试的质检项目。 3、功能测试用例编写原则 3.1单元测试功能用例的编写目的 单元测试用例的目的在于验证单个模块是否达到了详细设计说明书中规定的功能,由于是单个模块所以无法检验关联性,可能会牵扯到数据库的操作,例如:删除时,需要查看数据库是否完全删除了数据。 3.2集成测试功能用例的编写目的 集成测试功能用例的目的在于验证软件连接时,模块的连接是否正确(及数据的传递是否正确)。.我们的软件中体现出来的是,是否正确调用界面,界面之间显示的数据是否正确,特别是财务、费用、数据方面的。 集成测试用例的编写过程中,经常将功能用例与业务流程混合编写,因为在集成测试时需验证业务流程中的数据正确性,以及界面之间的数据传递的准确无误。 3.3系统测试业务流程用例的编写目的 系统测试业务流程用例的目的在于验证软件最终数据的准确性,我们的软件体现为,手工数据与报表数据的一直性。用例与用例之间有着一定的关系,目的性十分明确。 4、测试用例设计的原则 4.1全面性 指编写的测试用例应该覆盖所有的“概要设计文档”或“需求文档”以及“测试申请文档”中描述的功能。 4.1.1数据库程序基本的增、删、改功能 增、改测试用例重点在于数据合法性、正确性的检验和提示信息的正确性的检验。输入的数据可能有无限种组合,此时可以采用等价类划分和边界值法,下面有较详细的说明。 删除的测试用例比较简单,只有操作没有数据的输入,但是应该在“备注”中注明,删除的限制条件,以及数据库中应该删除的表的情况,有条件限制时,测试用例应该包含各种删除条件,必要时在添加或修改的测试用例后面或中间紧跟删除的测试用例。 4.1.2对于无输入的操作,应该详细描述其具体的操作步骤和结果

常见的测试用例设计方法都有哪些

常见的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。 1. 等价类划分 常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2. 边界值分析法 边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3. 错误推测法 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例. 4. 因果图方法 前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 5. 正交表分析法 有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。 6. 场景分析方法

如何设计和执行测试用例

如何设计和执行测试用例测试需求收集完毕后,开始测试设计。 测试用例是什么?测试用例就是一个文档,描述输入、动作、或者时间和一个期望的结果,其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题: 测试用例的基本格式: 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果,下面逐一介绍。 用例编号:测试用例的编号有一定的规则,比如系统测试用例的编号这样定义规则: PROJECT1-ST-001 ,命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号,便于查找测试用例,便于测试用例的跟踪。 测试标题:对测试用例的描述,测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时,软件的响应情况”。 重要级别:定义测试用例的优先级别,可以笼统的分为“高”和“低”两个级别。一般来说,如果软件需求的优先级为“高”,那么针对该需求的测试用例优先级也为“高” ;反之亦然, 测试输入:提供测试执行中的各种输入条件。根据需求中的输入条件,确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性,如果软件需求中没有很好的定义需求的输入,那么测试用例设计中会遇到很大的障碍。 操作步骤:提供测试执行过程的步骤。对于复杂的测试用例,测试用

例的输入需要分为几个步骤完成,这部分内容在操作步骤中详细列出。 预期结果:提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。 软件测试用例的设计主要从上述 6 个域考虑,结合相应的软件需求文档,在掌握一定测试用例设计方法的基础上,可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍,白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍。 一般来说,每个软件公司的项目可以分为固定的几大类。可以按业务类型划分,比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等;可以按软件结构来划分,比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例,会有很大的借鉴意义。如果,公司中有同类别的软件系统,千万别忘记把相关的测试用例拿来参考。如果,系统非常接近,甚至经过对测试用例简单修改就可以应用到当前被测试的软件。“拿来主义”可以极大的开阔测试用例设计思路,也可以节省大量的测试用例设计时间。 加强测试用例的评审: 测试用例设计完毕后,最好能够增加评审过程。 同行评审是 CMM3 级的一个 KPA ,如果因为公司没有通过 CMM3 级,就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审,提交评审意见,然后根据评审意见更新测试用例。如果认真操作这个环节,测试用例中的很多问题都会暴露出来,比如用例设计错

计算器测试报告

计算器测试报告

计算器测试报告 共 7 页 拟制孙姝萍2014 年 4 月24 日审核李晨曦2014 年 4 月25 日会签易厚旭2014 年 4 月25 日

1 范围 本文档适用于windows计算器的功能测试。 1.2 系统概述 使用“计算器”可以完成任意的通常借助手持计算器来完成的标准运算。“计算器”可用于基本的算术运算,比如加减运算等。同时它还具有科学计算器的功能,比如对数运算和阶乘运算等。 1.3 文档概述 本文档用于对windows计算器的测试工作阶段成果的描述。包括对软件测试的整体描述,软件测试的分类和级别,软件测试的过程描述,软件测试的结果等内容。 2 使用文档 《计算器帮助文档》 《计算器测试计划》 《计算器测试用例》 3 测试概述 本次测试主要完成一下目标: 1.执行简单的加减乘除运算,记录结果 2.执行科学计算,记录结果 3.执行统计计算,记录结果 4.在标准型和科学型间转换数据,记录结果; 5.使用数字分组,查看结果; 3.1 测试小结 本次测试对windows计算器进行了功能测试,重要依据为计算器的帮助文档所描述的功能。测试工作分为三个阶段。第一阶段进行了测试计划制定,第二阶段测试用例设计、第三阶段执行测试。

测试过程中,使用了自动化测试(QTP)和人工测试两种方法,分别记录了测试结果和画面截屏。 测试结果表明,windows计算器的功能比较完善,基本符合用户需求。 3.2 测试结果记录 目标1:执行简单的加减乘除运算

错误为超出范围。此时使用人工测试截屏。如下:

当超出范围时,显示如上。 目标2:执行科学计算 实际输出见测试用例文档,测试结果表明,计算器功能完善。目标3:执行阶乘

常见的测试用例设计方法都有哪些

常见的测试用例设计方法都有哪些 常见的测试用例设计方法都有哪些? 请分别以具体的例子来说明这些方 法在测试用例设计工作中的应用。 1. 等价类划分常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并 合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2. 边界值分析法边界值分析方法是对等价类划 分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入

输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3. 错误推测法基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0 的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例. 4. 因果图方法前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查

用户名密码测试用例编写方法

用户名密码测试用例编 写方法 标准化管理处编码[BBX968T-XBB8968-NNJ668-MM9N]

别小看了这个用户名密码这么简单的输入框。可测试的内容还是很多的,并且引发的问题也有很多种类。下面就说一说他的测试方法。? 一、用户注册 只从用户名和密码角度写了几个要考虑的测试点,如果需求中明确规定了安全问题,Email,出生日期,地址,性别等等一系列的格式和字符要求,那就都要写用例测了~ 以等价类划分和边界值法来分析 1.填写符合要求的数据注册:用户名字和密码都为最大长度(边界值分析,取上点) 2.填写符合要求的数据注册:用户名字和密码都为最小长度(边界值分析,取上点) 3.填写符合要求的数据注册:用户名字和密码都是非最大和最小长度的数据(边界值分析,取内点)

4.必填项分别为空注册 5.用户名长度大于要求注册1位(边界值分析,取离点) 6.用户名长度小于要求注册1位(边界值分析,取离点) 7.密码长度大于要求注册1位(边界值分析,取离点) 8.密码长度小于要求注册1位(边界值分析,取离点) 9.用户名是不符合要求的字符注册(这个可以划分几个无效的等价类,一般写一两个就行了,如含有空格,#等,看需求是否允许吧~) 10.密码是不符合要求的字符注册(这个可以划分几个无效的等价类,一般写一两个就行了) 11.两次输入密码不一致(如果注册时候要输入两次密码,那么这个是必须的)

12.重新注册存在的用户 13.改变存在的用户的用户名和密码的大小写,来注册。(有的需求是区分大小写,有的不区分) 14.看是否支持tap和enter键等;密码是否可以复制粘贴;密码是否以* 之类的加秘符号显示 备注:边界值的上点、内点和离点大家应该都知道吧,呵呵,这里我就不细说了~~ 二、修改密码 当然具体情况具体分析哈~不能一概而论~ 实际测试中可能只用到其中几条而已,比如银行卡密码的修改,就不用考虑英文和非法字符,更不用考虑那些TAP之类的快捷键。而有的需要根据需求具体分析了,比如连续出错多少次出现的提示,和一些软件修改密码要求一定时间内有一定的修改次数限制等等。

测试用例总结

测试用例 一、写测试用例时我们可以侧重从需求上看需要完成的功能方面来写(比如说某一标签或某一按钮点击以后会实现的功能以及页面跳转等) 然后在看输入框界面等 二、测试用例设计考虑的方面 完成了测试需求分析和软件流程分析后,开始着手设计测试用例。测试用例设计的类型包括功能测试,边界测试,异常测试,性能测试,压力测试等。在用例设计中,除了功能测试用例外,应尽量考虑边界、异常、性能的情况,以便发现更多的隐藏问题。 (1)功能测试:测试某个功能是否满足需求的定义,功能是否正确,完备。 适合的技术:由业务需求和设计说明导出的功能测试、等价类划分 (2)边界测试:对某个功能的边界情况进行测试。 适合的技术:边界值划分 (3)异常测试:对某些功能来说,其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的,类似这样的情况需要书写相关的异常测试。 适合的技术:由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、 (4)性能测试:检查系统是否满足在需求中所规定达到的性能,性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置,系统资源使用状况;外部因素包括响应时间,吞吐量等。 适合的技术:业务需求和设计说明导出的测试 (5)压力测试:压力测试又称强度测试,主要是检查系统运行环境在极限情况下软件运行的能力,比如说给一个相当大的负荷或网络流量给应用软件兼容测试:测试软件产品在不同的平台,不同的工具,相同工具的不同版本下功能的兼容性。 三、以登陆窗口为例来设计测试用例 我把这个测试用例分为三层结构,表单测试、逻辑判断、业务流程。 第一层,表单测试为最底层(最基础的)。这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的测试。一般来说登陆用户名和登陆用户密码是输入框的形式体现,那么,我们需要的是针对这两个输入框进行功能的测试。这时,我们只要考虑这个输入框的功能,而不需要考虑业务方面的内容。这样,我们考虑就是这个输入框的长度限制是多少?能否输入特殊字符?能否输入全角字符?当然,登陆窗口还有其他按钮,例如登

计算器黑盒测试

计算器黑盒测试 一、测试目的 按照等价类法设计测试用例、使用边界值法设计测试用例 二、测试内容 (一)、实现一个小的计算器程序,只需要完成加、减、乘、除运算,用等价类法设计 测试用例,进行测试。然后假设运算数值的范围在0到100之间,使用边界值法设计测试用例,并测试。 三、测试步骤 (一)、计算器: (1)等价类测试: 1、4个等价类测试用例的分析过程如下: 2、对应测试的结果: 整型: 1.加(60+50)

2.减(55-31) 3.乘(22*23) 4.除(65/21) 小数 1.加(24.1+65.3) 2.减(77.6-54.2) 3.乘(23.6*33.7) 4.除(6 5.3/23.6)

5.(其中算式写法错误导致正常运算错误) 负数 6.加 -55+-76 7.减((-38)-(-54)) 8.乘-54*-12 (其中算式写法错误导致正常运算错误) 9.除 65.3/23.6 (其中算式写法错误导致正常运算错误) 无效输入 1.加(e5+t6):

程序中无效数字无法正常输入,程序无法进行。 2.减(g6-k4) 程序中无效数字无法正常输入,程序无法进行。(同上)3.乘(i6*l9) 程序中无效数字无法正常输入,程序无法进行。(同上)4.除(Ff/se) 程序中无效数字无法正常输入,程序无法进行。(同上)(2)边界值法设计测试: 加法: 1、计算器4个标准等价类测试用例的分析过程如下:

2、对应测试与结果: 测试结果运算均属正常,对应的部分的示图如下:Test1结果: Test2结果: Test3结果: Test4结果: Test5结果:

软件测试中UI测试及其测试用例设计

界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够,直到最近网页制作的兴起,才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。 目前流行的界面风格有三种方式:多窗体、单窗体以及资源管理器风格,无论那种风格,以下规则是应该被重视的。 按钮名称应该易懂,用词准确,屏弃没楞两可的字眼,要与同一界面上的其他按钮易于区分,能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。 易用性细则: 1) 完成相同或相近功能的按钮用Frame框起来,常用按钮要支持快捷方式。 2) 完成同一功能或任务的元素放在集中位置,减少鼠标移动的距离。 3) 按功能将界面划分局域块,用Frame框括起来,并要有功能说明或标题。 4) 界面要支持键盘自动浏览按钮功能,即按Tab键的自动切换功能。 5) 界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。 6) 同一界面上的控件数最好不要超过10个,多于10个时可以考虑使用分页界面显示。 7)分页界面要支持在页面间的快捷切换,常用组合快捷键Ct r l+Tab 8) 默认按钮要支持Ent er及选操作,即按Ent er后自动执行默认按钮对应操作。 9) 可写控件检测到非法输入后应给出说明并能自动获得焦点。 10) Tab键的顺序与控件排列顺序要一直,目前流行总体从上到下,同时行间从左到右的方式。 11) 复选框和选项框按选择几率的高底而先后排列。 12) 复选框和选项框要有默认选项,并支持Tab选择。 13) 选项数相同时多用选项框而不用下拉列表框。 14) 界面空间较小时使用下拉框而不用选项框。 15) 选项数叫少时使用选项框,相反使用下拉列表框。

测试用例编写的总结

测试用例编写的总结 通过软件测试培训,在大庆浦东软件平台有限公司经过一周的软件测试实训,从对软件测试没有什么经验的我初步掌握了软件测试的方法和技能,收获颇多的心得。下面是为大家收集整理的软件测试培训心得,欢迎大家阅读。 软件测试培训心得篇1 20xx年x月x日。我怀着对提高并实现自我价值的心态,走进深圳走秀网络科技有限公司的大门,开始了自己大学里兼职实习工作。转眼间。6个月的实习时间就要过去了。回想起这段时间的工作过程,我深深的认识到在走秀网实习的选择是绝对正确的,走秀网和公司的同事们对我个人产生的积极影响也是超越我料想之中的。现将这段时间的工作进行如下总结。 首先,要具有良好的学习能力。刚进走秀,带我的老大是哈尔滨人,我跟她很投缘。开始的一个星期,我只是熟悉公司的一些业务和我们前端的测试范围,在熟悉业务的过程中,我发现这些页面上的东西看上去挺简单的,但是要深入了解还是需要很长的一段时间。期间老大叫一个老员工带着我去测试一些之前xiu2.0所遗留的简单的bug。走秀网的测试部还比较大,所以对工作的流程和上线之前的版本控制的非常严格。我们在上线之前,会经过两套环境,功能测试环境和镜像环境,功能测试环境是对需求和功能的一个详细的验证环境,镜像环境是模拟生产环境回归之前我们在功能测

试环境上锁遗留的一些小的bug。因为不知道这些转测试的bug是怎么产生的,所以需要去跟开发人员沟通,开始的时候自己一个人不敢过去开发部,就让老员工(才哥)带着过去,一段时间过后,我开始自己去和开发沟通交流,从发现问题的重现,到催促开发修改和转测试,这一段时间让我深刻体会到沟通时多么重要。 在走秀期间,我们测试部总监还会对我们不定时的培训。教会我们测试的工作流程和每个阶段应该展开的工作范畴。作为测试,必要会使用的缺陷管理工具bugzilla和测试用例管理工具testlink,还给我们培训了,如何使用自动化工具ruby+watir来对一些测试点进行自动化脚本的编写。慢慢的,在对公司的业务了解的比较透的时候,老大就开始让我们自己对一些小需求进行测试,测试的过程中,不仅仅是对页面和表面功能进行测试,还要根据需求文档和页面的显示对数据库表进行查询操作,查看页面的显示和功能是否和数据表里面的一致,还要在后台日志中查看是否有报错。所以,测试并不是像我想象中的那么简单,不是在页面上点来点去就可以测的好的。 实习可以使每一个学生有更多的机会尝试不同的工作,扮演不同的社会角色,逐步完成职业化角色的转化,发现自己真实的潜力和兴趣,以奠定良好的事业基础,也为自我成长丰富了阅历,促进整个社会人才资源的优化配置。作

相关文档
最新文档