白盒测试

[ 来源：网络转载 | 作者：佚名 | 时间：2007-9-03 13:36 ]

  

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

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

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

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

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

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

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

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

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

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