【原创】第一次白盒测试

        这里名为第一次白盒测试，其实是为了更进一步具体话以前所说的一些理论，来说明如何做和为什么那样做的。这些实例内容大都是我在看了相关的资料后摘取出来的，然后也补充上了我在学习过程中的一些我的见解。
         从一个典型类开始
        第一个典型的 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等小工具，可用来管理测试用例，生成测试用例，进行单元性能测试等等。感兴趣的话可以进一步进行研究和使用，而且它们也都是开源的。
（本文不是很完整，将在以后的文章中进行补充）