[Tommas] 测试用例覆盖率(二)

二、详细用例的设计

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

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

(1)、具体功能测试

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

(2)、组合操作的测试

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

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

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

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

(3)、GUI界面的测试

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(2)、后台的特殊处理

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

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

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

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

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

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

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

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

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

3、特定切面用例设计

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

4、隐含切面用例设计

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

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

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

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

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

(3)、其它测试类型

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

[Tommas] 测试用例覆盖率(二),布布扣,bubuko.com

时间: 2024-10-16 09:15:52

[Tommas] 测试用例覆盖率(二)的相关文章

[Tommas] 测试用例覆盖率(三)

三.测试数据的设计 每一个测试思路最终都要转化成具体的数据才能来执行.关于测试数据设计的方法也不外乎那几种,就不再赘述了.此处单就一些经常易犯的错误,提出一些注意点,作为用例数据设计时的参考: 1.尽量避免可能出现歧义测试结果的数据:即你设计的数据必须能唯一正确地反映出你所希望测试的结果.比如一组测试数据,有可能得到结果A或结果B,此时单用此数据来测试预期结果为A的用例,那明显就产生了歧义. 2.对于不便具体列示的数据,则必须详细描述其各项特性:有时我们在设计用例时为节约时间,不一定要到具体的一

[Tommas] 测试用例覆盖率(一)

一.测试用例的切面设计 所谓测试切面设计,其实就是测试用例大项的划分.测试用例划分的经典方法是瀑布模型,也就是从上到下,逐渐细分,大模块包括小模块,小模块包括更小的模块.但仅仅如此是不够的,我们还要从更多的角度切入系统,从不同的角度把系统切分成一块一块的,来进行测试,从而确保测试大项的完整性. 1.功能点切面 这是最常见的切面,通常我们认为页面上的一个按钮就是一个功能点.然后我们可以根据功能的复杂程度,按每个功能:或一个功能点分多页:或多个功能点合成一页来进行用例的撰写. 2.特定切面 除此以外

黑盒测试用例设计二

正交试验法 正交表的由来         n阶拉丁方 正交设计的基本概念 在一项试验中 ,把影响试验结果的量称为试验因素(因子) ,简称因素.因素可以理解为试验过程中的自变量,试验结果可以看成因素的函数.在试验过程中,每一个因素可以处于不同的状态或状况,把因素所处的状态或状况,称为因素的水平,简称水平. 每列中不同数字出现的次数相等.这特点表明每个因素的每个水平与其它因素的每个水平参与试验的几率是完全相同的,从而保证了在各个水平中最大限度地排除了其它因素水平的干扰,能有效地比较试验结果并找出最优

测试用例(二)

2018-08-20     09:08:12 登录 1)空白 用户名和密码均为空/用户名填写,密码为空/用户名为空,密码填写 2)错误校验 输入错误的用户名和密码/用户名错误密码正确/用户名正确密码错误 3)大小写区分(如:用户名和密码都为小写时) 用户名和密码均大写/用户名大写,密码小写/用户名小写,密码大写 4)存在空格 合法的用户名或密码前插入空格/合法的用户名或密码中间插入空格/合法的用户名或密码后插入空格 5)已注销的用户名登录 6)已禁止/锁住的用户名登录 7)长短校验 在给定的用

robotframework+appium 创建第一条测试用例(二)

一:打开APP 1.http://localhost:4723/wd/hub: Appium所在的url路径(这里appium搭建在本机,所以url格式固定不变) 2.platformName: 被测的平台名称,Android或ios 3.platformVersion: 平台版本,如Android的版本号 4.deviceName: 设备名称,即运行得模拟器或真机的设备型号 通过adb devices  即可得到设备名称 5.appPackage: app的包名 6.appActivity:

测试用例概论

一.什么是功能测试用例 测试用例是为某个特殊目标而编制的一组测试输入.执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求. 通俗的讲:就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来. 测试的目的 我们让它做的它必须会做. 我们不让它做的它必须不会做. 可能你会发现有附加功能的时候,就是客户没有要求,我们加了这样的功能,可能加了这点功能系统看上去会更好.这时怎么办?算问题么? 作为开发人员,中规中矩的做东西最好,如果真的有非常好的功能要加的话,需要和客户沟通,然后写到

高效测试用例组织算法pairwise之Python实现

------------------------------------------本文专为<光荣之路培训 >原创,如有转载请注明出处---------------------------------- 开篇: 测试过程中,对于多参数参数多值的情况进行测试用例组织,之前一直使用[正交分析法]进行用例组织,说白了就是把每个参数的所有值分别和其他参数的值做一个全量组合,用Python脚本实现,就是itertools模块中product方法(又称笛卡尔积法). 正交分析法的优点是测试用例覆盖率100

测试用例的设计方法

测试用例的设计方法有: 等价类划分方法,边界值分析方法,错误推理方法,因果图方法,判定表驱动分析方法,正交实验设计方法,功能图分析方法,场景设计方法 等价类划分方法: 基本概念: 一.方法简介 1.定义 是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 2.划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等

如何设计测试用例

测试用例设计方法 一. Android系统功能测试设计的测试用例: a.对所测APP划分模块 b.详细列出每个模块的功能点(使用Xmind绘制功能图) c.使用等价类划分.边界值.场景法等对各功能点编写测试用例(考虑中断功能测试用例) d.执行测试之后,反思总结补充相关用例 二. 1)根据业务需求文档.业务逻辑文档和流程图 等业务资料,整理测试方案和测试功能点: 2)将测试方案和测试功能点 内容细化,细化成一条条用例,包括页面元素显示.页面功能交互.底层数据交互.接口交互等: 3)针对每一个测试