浅谈白盒测试

我大胆的推广下二八原则,国内软件测试的现状是百分之八十以上的测试人员在做黑盒测试工作,不到百分之二十的测试人员做过白盒子测试工作。这不到百分之二十的测试人员许多又是在与开发人员共同完成的白盒测试工作。白盒测试也正在越来越受重视,前景也越来越好。虽然未必做白盒测试,但是白盒子测试用例的设计方法是需要软件测试人员掌握的,许多公司笔试,还有软测试考试的时候都会有白盒测试用例设计的题目出现。(我的意思不是为了应付考试而掌握哈,即使你现在没做白盒的测试,也要时刻为做白盒测试而准备着。)

  在软件测试一书中,白盒测试是这样定义的:“软件测试人员可以访问程序员的代码,并通过检查代码来协助测试---可以看盒子里面。”

  白盒子测试也分静态和动态两种:

  静态白盒测试是在不执行的条件下有条理地仔细审查软件设计、体系结构和代码,从而找出软件缺陷的过程,有时也称为结构分析。进行静态白盒子测试的首要原因就是尽早发现软件缺陷,以找出动态黑盒子测试难以揭示或遇到的软件缺陷;另一个好处是为接受该软件测试的黑盒测试员的测试案例提供思路,他们不必了解代码细节,但是根据审查备注,可以确定似乎有问题或者存在软件缺陷的特性范围。动态白盒测试是指利用查看代码功能和实现方式得到的信息来确定哪些要测试,哪些不要测试,如何开展测试。

  动态白盒测试的另一个常用名称是结构化测试,因为软件测试员可以查看并使用代码的内部结构,从而设计和执行测试。 动态白盒测试包括四部分:
    1.直接测试底层功能、过程、子程序和库。即应用程序接口(API)
    2.以完整程序的方式从顶层测试软件,但是要根据对软件运行的了解调整测试案例。
    3.从软件获得读取变量和状态信息的访问权,以便确定测试与预期结果是否相符,同时,强制软件以正常测试难以实现的方式运行。
    4. 估算执行测试时“命中”的代码量和具体代码,然后调整测试,去掉多余的,补充遗漏的。

  静态的白盒测试我没做过,在此就不叙述了。和黑盒测试一样,动态白盒测试也是按部就班的来,首先写测试计划,然后设计测试用例,再次执行用例,写测试报告,最后写测试总结。我做过的白盒测试,驱动程序都是开发人员做好了的,我只是按每个类里的每个函数设计测试用例,测试函数返回值。(许多内部保护类都是无法测试的。)下面我说说用例的设计。


  白盒测试有六种用例有六种覆盖的方法分别是:

  1.语句覆盖。这个是起码要做到的覆盖了,程序里的每条可执行的语句都要至少执行一次。这个设计起来比较简单,用例数据很直观的就能看出来。但是语句里的判定,分支等就没什么意义了。可以说这样的测试是最低的要求了。
  2.判定覆盖。每个判断的真假分支至少执行一次,就是真要至少取一次,假要至少取一次。这个设计起来也不难,覆盖率要比语句覆盖高近乎一倍,但是也在判定语句中也会遗漏许多路径,因为每个条件的取值是不在考虑范围内的。
  3.条件覆盖。和判定覆盖思路一样,只是把重点从判定移动到条件上来了,每个判定中的每个条件可能至少满足一次,也就是每个条件至少要取一次真的,再取一次假的。同样它也会遗漏许多路径,条件取真假并不能满足判定也取到真假两次。
  4.判定条件覆盖。既然上面的判定和条件多是片面的,那么这个两个覆盖相结合是呼之欲出判定条件覆盖。它要求判断中的每个条件所有可能至少出现一次,并且每个判定本身的判定结果也要出现一次。不要以为这样就行了,要看看条件,条件和判定不一样,判定取真假就覆盖了判定,可是条件取真假两次完全不能满足条件的各种组合。所以才有了5~。
  5.条件组合覆盖。每个判定中条件的各种可能组合至少满足一次。条件各种可能都出现了,必然把判定给覆盖了,它覆盖了上面的4个哦,可是用例数量大大增加了!看项目情况定吧。
  6.路径覆盖。概念比较好理解,把所有可能路径至少都走一遍,但是用例数量可想而知了。

  方法是固定的,掌握方法不能只记概念,实践!实践出真知!下面举个实际的例子。


  这是我以前做的测试试卷一里的题

对下面给出的程序控制图,分别以各种不同的测试方法写出最少的测试用例。


1:语句覆盖
要点:每个可执行语句至少执行一次.
A=5 B=6 X=2 走ace路,可将语句全覆盖

2: 判定覆盖
要点:每个判断的真假分支至少执行一次
有两个判定,设计两真两假就达到判定覆盖条件
假假分支:ace A=5 B=6 X=2 f1f2
真真分之:abd A=2 B=5 X=3 t2t2(小写表示判断真假),大写表示条件真假)

3:条件覆盖
要点:每个判定中的每个条件可能至少满足一次
题中有两个判定,每个判定里两个条件,也就是四个条件.
四个条件分别去真假两种可能,只要在用例中出现条件四种真和四种假就可以
    A<5取真 T1,取假F1
如上B=5     T2     F2
    A=2     T3     F3
    X>2     T4     F4
F1F2F3F4 A=5 B=6 X=2 走ace
T1T2T3T4 A=2 B=5 X=3 走abd
A B A X 四个条件的真假都取到了,条件覆盖完成了,也可以用T1F2F3T4和
F1T2T3F4来设计,只要TN和FN都出现就可以,但是要注意F1和T3不能同时出现,因为A<5不成立,A=2一定不成立,以下几种方法也要考虑这个条件,还要注意如果路径走ace和acd的时候X的值会有变化)

4:判定条件覆盖
要点:判断中的每个条件所有可能至少出现一次,并且每个判定本身的判定结果也要出现一次.
判定条件覆盖就是把判定覆盖和条件覆盖要考虑的东西合在一起考虑
两个判定的真假要分别出现,四个条件的真假也要分别出现.
此题是巧合,判定覆盖可以和条件覆盖设计一样的用例
F1F2F3F4 A=5 B=6 X=2 走ace f1f2
T1T2T3T4 A=2 B=5 X=3 走abd t1t2
完全满足了判定条件覆盖~

5:条件组合覆盖
要点:每个判定中条件的各种可能组合至少满足一次
这个稍微复杂一点先搞第一个判定中的条件,先把这两个条件组合在一起,两个条件,分别真假有四种组合方式:
(1)A<5 B=5 T1T2
(2)A<5 B!=5 T1F2
(3)A>=5 B=5 F1T2
(4)A>=5 B!=5 F1F2
第二个判断
(5)A=2 X>2 T3T4
(6)A=2 X<=2 t3f4
(7)A!=2 X>2 F3T4
(8)A!=2 X<=2 F3F4

把 第一个判断中四个条件和第2个判断中四个条件组合
其中(3)(4)不能和(5)(6)组合因为A>=5就不能有A=2
来组合下吧
(1)(5): T1T2T3T4    A=2 B=5 X=3 走abd        
(2)(6):  T1F2T3F4    A=2 B=6 X=2  走acd
(3)(7):  F1T2F3F4    A=3 B=5 X=2 走abe
(4)(8):  F1F2F3F4    A=5 B=6 X=2 走ace   居然覆盖四条路径了(纯属巧合)一般的情况下条件组合是不能保证路径全被覆盖的。

6:路径覆盖
所有路径:一眼就能看出有四条路径,分别是ace abd abe acd
在这里偷点工,因为条件组合里恰巧覆盖里路径,就不再写用例了

你可以通过这个链接引用该篇文章:http://wujiaxiang11.bokee.com/tb.b?diaryId=15980532

 

 

更多精彩内容请访问       www.17testing.com

 
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1.简介 1.1目的   本文档是将系统在测试过程出现的问题陈列出来,使得开发人员清楚的知道系统中所存在的问题与不足,从而加以改进,使系统更加健壮安全,增强系统的可运行性和可维护性。本文档的读者为开发人员和测试人员。 1. 2范围 本文档从编程人员编写代码开始就能使用,在用户登录系统、用户订餐系统、会员管理系统、订餐信息处理系统、菜式管理系统、系统用户管理系统等六大模块中均适用,在每一个模块都必须进行单元测试,到软件完整开发出来后进行综合测试。本文档将会解决测试问题、环境、结果、缺陷和评价等问题。 2. 测试内容 2.1 用户登录模块用户订餐系统会员管理系统订餐信息处理系统菜式管理系统 用户输入ID和密码,如验证无误便可登陆成功,在登陆状态下所做的定购额记入用户总积分。如果用户不登陆或为非会员,则定购额无法记入总积分。 2.2 用户订餐系统 用户首页上显示的菜式片来点选自己喜欢的菜式和饭食,也可以对快餐进行分类查询。点选确认后放入虚拟购物车。可点选多样菜式。最后在虚拟柜台提交所有定购的物品,定购金额在10元以上才可提交,否则弹出对话框提示定购额不足。 2.3会员管理系统 对注册为会员的用户的信息进行管理。可以每月对会员进行积分排名,星级会员评定,以及对用户资料进行删除。 2.4 订餐信息处理系统 对订餐的信息进行管理和分类。将全天定餐信息显示在服务器端,分记录显示。记录分为两种状态:“未派送”和“已派送”。此系统的操作人员把刚刚送出的“未派送”记录进行标记,该记录则变为“已派送”。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值