不浪费光阴,不虚度年华,在充实中享受,在享受中充实.
好东西要一起分享才会更有价值
发布新日志
-
2008-12-29 10:15:50
转自:http://www.51testing.com/?action_viewnews_itemid_7254.html
发布时间: 2007-4-13 09:53 作者: jerry 来源: 网络
软件测试覆盖包括分支覆盖,语句覆盖以及条件覆盖,这是白盒测试中一个很基本的测试概念,但是最近和几位搞了多年测试的朋友谈及此事,大家都搞不大清楚。下面我通过一个例子来深入探讨一下这个问题:
我们首先来看一下这几些测试覆盖的定义:
定义一、语句覆盖:它要求被测程序的每一可执行语句在测试中尽可能都检验过;
定义二、分支覆盖:要求程序中所有判定的分支尽可能得到检验;
定义三、条件覆盖:当判定式中含有多个条件时,要求每个条件的取值均得到检验;
从这些定义我们可以很容易理解到语句覆盖是把程序中的所有的语句都给覆盖到;分支覆盖是把程序中每个分支都给覆盖到;条件覆盖是把判断条件中所有的条件都给覆盖到。
下面我们通过一个简单的例子来描述一下
0:
1:if ((a<150)||(b<200)){
2: for (i=a;i<100;i++)
3: {
4: println(“A”);}
5:}else{
6:println (“B”);
7:}
分支覆盖:
1)在0处设置a=120,b 任意
将执行1,2,5
2)在0处设置a=200,b=400
将执行1,5,6,7
这里所有的分支都走到,也就是说要达到分支覆盖率100%,要设计2组测试用例
语句覆盖:
1)在0处设置a=40,b 任意
将执行1,2,3,4,5
2)在0处设置a=200,b=400
将执行1,5,6,7
这里所有的语句都走到了,也就是说要达到语句覆盖率100%,要设计2组测试用例
而在分支覆盖中语句3,4没有走到
条件覆盖:
由于第一个条件是if ((a<150)||(b<200)) 所以需要设计测试用例
a |
b |
备注 |
40 |
50 |
全部满足 |
160 |
150 |
a不满足,b满足 |
40 |
250 |
a满足,b不满足 |
150 |
250 |
a,b都不满足 |
条件覆盖只要求把所有的条件都覆盖就可以了。
这样一来我们就把这几个概念搞得很清楚了。
顺便我在这里想说一句心里话,我们现在的不管是书籍还是网站上的文章都太倾向于理论了,而到实际运用上来就说不清楚了,我希望能够有更多又讲理论又讲实践的文章和书籍能够出现。
查看(348)
评论(0)
收藏
分享
管理
-
2008-12-11 16:14:42
对流程尤其是网站的架构了解是十分重要的,了解了流程,就可以减少很多冗余的测试用例。网站的浏览器端是以页面为单位的,各页面是独立而又相互关联的,一个页面的各个功能通常来自不同的子系统及相关的后台数据库,所以在编写功能点的时候把各页面的功能模块记录后,应该再进一步整理,把它们归类到相应的子系统中,这样才能对系统及其流程个有清晰的概念及轮廓,才能有助于用例的设计。这一次测试的最大弊端是对各个功能没有再进行整理,以为把各个功能都写出来就完了,可以开始写测试用例了,导致失去整体概念,流程不清晰,像一盘散沙,出现了很多冗余的测试用例。所以前期的工作很重要,磨刀不误砍柴功,不能写完计划就写用例,尤其是在没有详细设计的情况下。
查看(525)
评论(0)
收藏
分享
管理
-
2008-12-11 15:56:28
测试数据:
1.文件上传,图片上传方面:图片的大小,格式限制,能否处理文件名为中文名等等。
2.某些非法操作:输入错误路径,输入不存在的文件名,测试系统的容错性、安全性。
3.Tab,Enter,Pageup,pagedown等等常用功能键的操作结果。
4.数据输入分显式输入和隐式,显式输入即表单、下拉菜单及其他选择的项等等。隐式输入,如所点击的链接的URL的参数传递,比如URL里的ID=7,即为一种隐式输入。
5.非法输入:总的来说就是不被允许输入的数据,例如上传图片:上传非图片格式的文件,表单中要求输入整数,则输入非整数,可以是字母、中文、小数、分数等等。
6.在实际中不存在的事或者无意义的数据:比如,年龄,可以考虑输入200岁,看程序怎么处理。
7.注意对空格、"0"、空值的处理。
操作:
每个修改、增加、删除等等对数据库产生影响的更新操作,在提示更新成功后要进行相关的显式验证,可以到调用该数据的其他相关页面查看是否已更新,验证测试输出结果,而不仅仅是在当前页验证,如果必要还要进行其它诸如退出再登录或者更换登录名的操作以作验证。并且这些操作也应该作为测试案例的操作步骤记录下来,并把看到的相关结果作为输出的实际结果记录下来。这些操作及结果实质上都是该测试案例的一部分。
其它:
1.在描述输出结果时,应说明执行什么步骤有什么结果,才能把用例描述清楚,而不是把输出结果一股脑写进实际输出结果中。
2.测试摘要中最好概括地说明模块及功能,输入及测试的目的或者功能等等。让人一目了然,因为并不是每一个人都会详细地阅读测试用例。尤其是项目经理等等。
3.一个功能块中如果若干个逻辑判断,最同意出错的是在最初一个与最后一个判断。
4.对操作发现的意外情况要及时记录,包括每一步的操作和输入数据,最好把每一步操作的结果都记录下来,以利于测试的重现。
5.可以把一些后台直接调用到前台的功能的用例放在相关的操作功能之后,结合在一起进行测试,协商相关的用例编号。可以去除一些不要的用例。
6.当出现BUG时,必要的时候可以进一步补充测试用例来帮助程序员定位BUG,缩小检查的范围。
7.在报告BUG的时候,可以借助截图工具截图并标注出BUG,以更直接明了的方式报告BUG。
8.安全测试方面:在进行权限方面的安全测试时,可分析URL,如果该URL包含了有关用户方面的参数,例如UID等等,则复制URL并以不同的身份登录,粘帖并打开,看是否可以越权限操作,例如修改用户信息等等。
查看(648)
评论(0)
收藏
分享
管理
-
2008-12-11 14:57:51
容易忽略的测试范围:
界面测试:
- 网页架构的影响因素:标题长短(是否有限制),字体大小。
- 各项位置是否正确。
- 易用性测试:说明是否详细,是否会引起误解。
- 易用性测试:链接是否可跟踪,也即点击过的链接是否用同一的颜色区别于未点击的链接。
- 界面是否杂乱无章。
- 是否有太多的浮动图标。
- 按钮的大小、颜色。
- 格局是否统一,主要是导航栏,页面的顶部,下部,页脚,左右等等。
功能测试:
除了非常明显的功能:如注册、搜索类似于按钮之类的显式功能外,从后台调用数据显示到前台也是功能之一,数据的输入为后台数据库,前台即为输出。
查看(540)
评论(0)
收藏
分享
管理
-
2008-12-11 14:40:07
Loadrunner是一个基于通信协议的测试工具,通过捕获数据包并进行分析,所以选择正确的协议是进行测试的第一步。
LR中的协议应该是客户端和第一服务器(最前端的服务器)间的协议,基本上都是基于应用层的通信协议。
在scrīpt中,选择脚本在Vuser_init\Vuser_end及Action的区别:
Vuser_init应用与在Action()发生前的程序运行,只运行一次,而Action()中则存放那些多次迭代的动作/行为,Vuser_end()发生于Action()之后,也只运行一次。例如:一个用户登录,在网站上进行了一系列的编辑,删除,浏览,点击等动作后,退出该网站,利用LR开发测试脚本时,则可以把“登录”放在Vuser_inti中,后面的一系列动作则放在Action()中,“退出”放在Vuser_end中。
要精通性能测试一定要开发基础扎实。
查看(629)
评论(0)
收藏
分享
管理
-
2008-12-11 14:09:38
1. 好的测试用例的定义:能发现到目前为止没有发现的缺陷的用例是好的用例,但不是盲目测试,发现BUG不是测试的最终目的。要能完整覆盖测试要求;测试程序做了它该做的事情,没有做它不应该做的事情,这是用例最起码的要求,如果做不到这些要求,即使发现BUG也不一定是好的用例,因为不符合需求,所以不应该针对单个的测试用例去评判好坏。
2. 测试用例的详细程序根据需要确定。
3. 测试用例文档是“活的”文档,要与需求和设计同步更新。
4. 测试用例可以包含实际的数据即测试数据,不过要维护有方。
5. 测试用例中需要明显的验证手段,尤其是与数据库相关的功能测试。
查看(701)
评论(0)
收藏
分享
管理
-
2008-12-07 16:53:48
很快就要进入测试这一行了,太高兴了!我喜欢测试。。。哈哈。。。兴趣是最好的老师,是最强的动力!
在这里开通日志,一来是为了自己便于查阅,二来是好东西要分享才会更有价值。
I will start the testing career soon. It is so great!! it makes me so happy!! I like testing...haha... The interest is the best teacher, the strongest power!
To open the blog here, first, is to consult more convenient for myselt, second, I think the good thing must be shared then it will be more valuable.
查看(260)
评论(0)
收藏
分享
管理