【原创】第一次白盒测试

原创 2005年02月27日 23:38:00
        这里名为第一次白盒测试,其实是为了更进一步具体话以前所说的一些理论,来说明如何做和为什么那样做的。这些实例内容大都是我在看了相关的资料后摘取出来的,然后也补充上了我在学习过程中的一些我的见解。
        从一个典型类开始
        第一个典型的 Java 程序一般都包含一个打印 "Hello World" 的 main()。在清单 1 中,我创建了一个 HelloWorld 对象的实例并调用 sayHello() 方法,该方法会打印这句习惯说法。
        清单 1. 我的第一个 Java 应用程序 "Hello world"
/*
 *  HelloWorld.java
 *  My first java program
 */
class HelloWorld {
    /**
     * Print "Hello World"
     */
 void sayHello() {
          System.out.println("Hello World");
      }
    /**
     * Test
     */
    public static void main( String[] args ) {
        HelloWorld world = new HelloWorld();
        world.sayHello();
    }
}
        main() 方法是我的测试。哦噢!我将代码、文档、测试和样本代码包含在了一个模块中。保佑 Java!但随着程序越变越大,这种开发方法很快就开始显现出了缺陷:
        混乱
类接口越大,main() 就越大。类可能仅仅因为正常的测试而变得非常庞大。
        代码膨胀
由于加入了测试,所以产品代码比所需要的要大。但我不想交付测试,而只想交付产品。
        测试不可靠
既然 main() 是代码的一部分,main() 就对其他开发者通过类接口无法访问的私有成员和方法享有访问权。出于这个原因,这种测试方法很容易出错。
       很难自动测试
要进行自动测试,我仍然必须创建另一程序来将参数传递给 main()。
        这种方法对应于“在类中调用Main方法,并且在Main方法体中写入需要运行的测试用例,然后编译该类执行”。它最大的有点是所见即所得,但是除了上面得缺陷外,我们还不的不考虑它得另外一些缺陷:
        不利于后期测试代码得维护
        不利于测试代码的复用
        交付后的程序必须逐个提出测试编码

        由此我们引进了Junit测试框架,如果您想了解更多有关这方面的知识(包括我们该如何考虑改进、如何实施改进等一系列内容)请参考IBM Developer网站的文章利用 Ant 和 JUnit 进行增量开发http://www-900.ibm.com/developerWorks/cn/java/j-ant/index.shtml】。另外为了减少测试人员的阅读负担,这里我将继续引用原文的一些内容和我自己的一些阐述来我们的旅程。
        用过Rational Testmanage的人可能会知道,在使用它管理测试脚本时首先要创建一个测试套件(Suite),可以说它是用来组织测试脚本的一个容器,用来包含单独的测试脚本,也可以包含其它的测试套件,甚至包含测试场景(scenario比如把环境初始化或者现场恢复的所有脚本可以放到一个场景中,这样便于每个测试用例都能够运行在同样的环境中)。Rational Testmanage 中Suite的设置可以是灵活多样的,基本上能够满足各种业务逻辑,这里需要说明的是实际上我认为自动化的测试套件都可以用这一套概念来理解,使用不同语言编写的测试套件只是在语法上有所不同,他们都可以抽象为以上的描述。每个测试脚本都可看作是一个测试用例,也可以把多个测试脚本组合成一个测试用例,这就在于读者在实际运用中的实践和用例设计的需要。
        有些以上这些思路,我认为作为一个黑盒测试人员应该对Junit测试框架下生成的测试脚本的了解有了一定的头绪。说到这里我想到一些更为重要的与测试用例有关的东西,Junit官方网站上同时也提供了一些小工具,比如jtestcase-2.2.0.zip,jub.zip,junitperf-1.9.1.zip,junitscenario-0.1.zip等小工具,可用来管理测试用例,生成测试用例,进行单元性能测试等等。感兴趣的话可以进一步进行研究和使用,而且它们也都是开源的。
(本文不是很完整,将在以后的文章中进行补充)

白盒测试方法-静态结构分析法

程序的结构形式是白盒测试的主要依据。研究表明程序员38%的时间花费在理解软件系统上,因为代码以文本格式被写入多重文件中,这是很难阅读理解的,需要其它一些东西来帮助人们阅读理解,如各种图表等,而静态结构...

白盒测试中的代码覆盖率简介

白盒测试(也称为透明盒测试、结构化测试等)是指对源代码的内部结构和内部行为进行测试。在白盒测试中,主要使用内部视角以及编程技术来设计测试用例。测试人员通过选择不同的输入,来测试不同的路径。 白盒测试可...

白盒测试 [代码规范][Java] 二

3. 注释规范 3.1 注释 vs 代码 注释宜少二精,不宜多而滥,更不能误导 命名达意,结构清晰, 类和方法等责任明确,往往不需要,或者只需要很少注释,就可以让人读懂;相反,代码混乱,再多的注...
  • lala515
  • lala515
  • 2011年08月04日 10:33
  • 2711

白盒测试 [代码规范] [C++] 一

文件结构 文件头注释 所有C++的源文件均必须包含一个规范的文件头,文件头包含了该文件的名称、功能概述、作者、版权和版本历史信息等内容。标准文件头的格式为:...
  • lala515
  • lala515
  • 2011年08月04日 10:38
  • 1301

白盒测试:语句覆盖、条件覆盖、判定覆盖、条件-判定覆盖、组合覆盖、路径覆盖

1语句覆盖 使所有的判断语句都能执行一次的条件案例,例如当判断语句事组合语句的时候,并且用or连接,只满足一个案例即可   2判定覆盖(分支覆盖)  针对判断语句,在设定案例的时候,要设定Tr...

嵌入式平台使用gtest进行白盒测试

嵌入式平台使用gtest进行白盒测试   转自:http://www.cnblogs.com/StitchSun/p/4430362.html 看了coderzh大神写的gtest(ht...

白盒测试中逻辑覆盖的六种方法

1.语句覆盖。这个是起码要做到的覆盖了,程序里的每条可执行的语句都要至少执行一次。这个设计起来比较简单,用例数据很直观的就能看出来。但是语句里的判定,分支等就没什么意义了。可以说这样的测试是最低的要求...

JUnit白盒测试-第1天

什么是单元测试 写了个类,要给别人用,但是不知道有没有bug,测试一下,即可,一般都用main方法测试,也就是比如用System.out.println(a);的样子将要测试的东西答应出来找...
  • psiitoy
  • psiitoy
  • 2014年04月07日 15:26
  • 840

白盒测试实战——NITIAN Word

最近,我在编写一款自娱自乐的单词对比记忆的软件NITIAN WORD,这里选取它的一部分逻辑,利用白盒方法进行测试,算是理论联系实际吧。...

白盒测试中的六种覆盖方法

【IT168 技术文档】   摘要:白盒测试作为测试人员常用的一种测试方法,越来越受到测试工程师的重视。白盒测试并不是简单的按照代码设计用例,而是需要根据不同的测试需求,结合不同的测试对象,使用适合...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:【原创】第一次白盒测试
举报原因:
原因补充:

(最多只允许输入30个字)