junit单元测试教程教程

测试的概念

长期以来，我所接触的软件开发人员很少有人能在开发的过程中进行测试工作。大部分的项目都是在最终验收的时候编写测试文档。有些项目甚至没有测试文档。现在情况有了改变。我们一直提倡UML、RUP、软件工程、CMM，目的只有一个，提高软件编写的质量。举一个极端的例子：如果你是一个超级程序设计师，一个传奇般的人物。（你可以一边喝咖啡，一边听着音乐，同时编写这操作系统中关于进程调度的模块，而且两天时间内就完成了！）我真得承认，有这样的人。（那个编写UNIX中的vi编辑器的家伙就是这种人。）然而非常遗憾的是这些神仙们并没有留下如何修成正果的README。所以我们这些凡人－－在同一时间只能将注意力集中到若干点（据科学统计，我并不太相信，一般的人只能同时考虑最多7个左右的问题，高手可以达到12个左右），而不能既纵览全局又了解细节－－只能期望于其他的方式来保证我们所编写的软件质量。

为了说明我们这些凡人是如何的笨。有一个聪明人提出了软件熵（software entropy）的概念：一个程序从设计很好的状态开始，随着新的功能不断地加入，程序逐渐地失去了原有的结构，最终变成了一团乱麻。你可能会争辩，在这个例子中，设计很好的状态实际上并不好，如果好的话，就不会发生你所说的情况。是的，看来你变聪明了，可惜你还应该注意到两个问题：1)我们不能指望在恐龙纪元（大概是十年前）设计的结构到了现在也能适用吧。2)拥有签字权的客户代表可不理会加入一个新功能是否会对软件的结构有什么影响，即便有影响也是程序设计人员需要考虑的问题。如果你拒绝加入这个你认为致命的新功能，那么你很可能就失去了你的住房贷款和面包（对中国工程师来说也许是米饭或面条，要看你是南方人还是北方人）。

另外，需要说明的是我看过的一些讲解测试的书都没有我写的这么有人情味（不好意思...）。我希望看到这片文章的兄弟姐妹能很容易地接受测试的概念，并付诸实施。所以有些地方写的有些夸张，欢迎对测试有深入理解的兄弟姐妹能体察民情，并不吝赐教。

好了，我们现在言归正传。要测试，就要明白测试的目的。我认为测试的目的很简单也极具吸引力：写出高质量的软件并解决软件熵这一问题。想象一下，如果你写的软件和Richard Stallman（GNU、FSF的头儿）写的一样有水准的话，是不是很有成就感？如果你一致保持这种高水准，我保证你的薪水也会有所变动。

测试也分类，白箱测试、黑箱测试、单元测试、集成测试、功能测试...。我们先不管有多少分类，如何分类。先看那些对我们有用的分类，关于其他的测试，有兴趣的人可参阅其他资料。白箱测试是指在知道被测试的软件如何（How）完成功能和完成什么样（What）的功能的条件下所作的测试。一般是由开发人员完成。因为开发人员最了解自己编写的软件。本文也是以白箱测试为主。黑箱测试则是指在知道被测试的软件完成什么样（What）的功能的条件下所作的测试。一般是由测试人员完成。黑箱测试不是我们的重点。本文主要集中在单元测试上，单元测试是一种白箱测试。目的是验证一个或若干个类是否按所设计的那样正常工作。集成测试则是验证所有的类是否能互相配合，协同完成特定的任务，目前我们暂不关心它。下面我所提到的测试，除非特别说明，一般都是指单元测试。

需要强调的是：测试是一个持续的过程。也就是说测试贯穿与开发的整个过程中，单元测试尤其适合于迭代增量式（iterative and incremental）的开发过程。Martin Fowler（有点儿像引用孔夫子的话）甚至认为：“在你不知道如何测试代码之前，就不应该编写程序。而一旦你完成了程序，测试代码也应该完成。除非测试成功，你不能认为你编写出了可以工作的程序。”我并不指望所有的开发人员都能有如此高的觉悟，这种层次也不是一蹴而就的。但我们一旦了解测试的目的和好处，自然会坚持在开发过程中引入测试。

因为我们是测试新手，我们也不理会那些复杂的测试原理，先说一说最简单的:测试就是比较预期的结果是否与实际执行的结果一致。如果一致则通过，否则失败。看下面的例子：

//将要被测试的类

public class Car {

public int getWheels() {

return 4;

}

}

//执行测试的类

public class testCar {

public static void main（String[] args) {

testCar myTest = new testCar();

myTest.testGetWheels();

}

public testGetWheels() {

int expectedWheels = 4;

Car myCar = Car();

if (expectedWheels==myCar.getWheels())

System.out.println("test [Car]: getWheels works perfected!");

else

System.out.println("test [Car]: getWheels DOESN'T work!");

}

}

如果你立即动手写了上面的代码，你会发现两个问题，第一，如果你要执行测试的类testCar，你必须必须手工敲入如下命令：

[Windows] d:>java testCar

[Unix] ％java testCar

即便测试如例示的那样简单，你也有可能不愿在每次测试的时候都敲入上面的命令，而希望在某个集成环境中(IDE)点击一下鼠标就能执行测试。后面的章节会介绍到这些问题。第二，如果没有一定的规范，测试类的编写将会成为另一个需要定义的标准。没有人希望查看别人是如何设计测试类的。如果每个人都有不同的设计测试类的方法，光维护被测试的类就够烦了，谁还顾得上维护测试类？另外有一点我不想提，但是这个问题太明显了，测试类的代码多于被测试的类！这是否意味这双倍的工作？不！1）不论被测试类－Car 的getWheels 方法如何复杂，测试类－testCar 的testGetWheels 方法只会保持一样的代码量。2）提高软件的质量并解决软件熵这一问题并不是没有代价的。testCar就是代价。

我们目前所能做的就是尽量降低所付出的代价：我们编写的测试代码要能被维护人员容易的读取，我们编写测试代码要有一定的规范。最好IDE工具可以支持这些规范。好了，你所需要的就是JUnit。一个Open Source的项目。用其主页上的话来说就是：“JUnit是由Erich Gamma 和Kent Beck 编写的一个回归测试框架（regression testing work）。用于Java开发人员编写单元测试之用。”所谓框架就是Erich Gamma 和Kent Beck 定下了一些条条框框，你编写的测试代码必须遵循这个条条框框：继承某个类，实现某个接口。其实也就是我们前面所说的规范。好在JUnit目前得到了大多数软件工程师的认可。遵循JUnit我们会得到很多的支持。回归测试就是你不断地对所编写的代码进行测试：编写一些，测试一些，调试一些，然后循环这一过程，你会不断地重复先前的测试，哪怕你正编写其他的类，由于软件熵的存在，你可能在编写第五个类的时候发现，第五个类的某个操作会导致第二个类的测试失败。

通过回归测试我们抓住了这条大Bug。

回归测试框架-JUnit

通过前面的介绍，我们对JUnit有了一个大概的轮廓。知道了它是干什么的。现在让我们动手改写上面的测试类testCar使其符合Junit的规范－－能在JUnit中运行。

//执行测试的类（JUnit版）

import junit.work.*;

public class testCar extends TestCase {

protected int expectedWheels;

protected Car myCar;

public testCar(String name) {

super(name);

}

protected void setUp() {

expectedWheels = 4;

myCar = new Car();

}

public static Test suite() {

/*

* the type safe way

*

TestSuite suite= new TestSuite();

suite.addTest(

new testCar("Car.getWheels") {

protected void runTest() { testGetWheels(); }

}

);

return suite;

*/

/*

* the dynamic way

*/

return new TestSuite(testCar.class);

}

public void testGetWheels() {

assertEquals(expectedWheels, myCar.getWheels());

}

}

改版后的testCar已经面目全非。先让我们了解这些改动都是什么含义，再看如何执行这个测试。

1>import语句，引入JUnit的类。（没问题吧）

2>继承TestCase 。可以暂时将一个TestCase看作是对某个类进行测试的方法的集合。详细介绍请参看JUnit资料

3>setUp()设定了进行初始化的任务。我们以后会看到setUp会有特别的用处。

4>testGetWheeels()对预期的值和myCar.getWheels()返回的值进行比较，并打印比较的结果。assertEquals是junit.work.Assert中所定义的方法，junit.work.TestCase继承了junit.work.Assert。

5>suite()是一个很特殊的静态方法。JUnit的TestRunner会调用suite方法来确定有多少个测试可以执行。上面的例子显示了两种方法：静态的方法是构造一个内部类，并利用构造函数给该测试命名(test name, 如Car.getWheels )，其覆盖的runTest()方法，指明了该测试需要执行那些方法－－testGetWheels()。动态的方法是利用内省（reflection ）来实现runTest()，找出需要执行那些测试。此时测试的名字即是测试方法（test method，如testGetWheels）的名字。JUnit会自动找出并调用该类的测试方法。

6>将TestSuite看作是包裹测试的一个容器。如果将测试比作叶子节点的话，TestSuite就是分支节点。实际上TestCase，TestSuite以及TestSuite组成了一个composite Pattern。JUnit的文档中有一篇专门讲解如何使用Pattern构造Junit框架。有兴趣的朋友可以查看JUnit资料。如何运行该测试呢？手工的方法是键入如下命令：

[Windows] d:>java junit.textui.TestRunner testCar

[Unix] ％java junit.textui.TestRunner testCar

别担心你要敲的字符量，以后在IDE中，只要点几下鼠标就成了。运行结果应该如下所示，表明执行了一个测试，并通过了测试：

.

Time: 0

OK (1 tests)

如果我们将Car.getWheels()中返回的的值修改为3，模拟出错的情形，则会得到如下结果：.F

Time: 0

There was 1 failure:

1) testGetWheels(testCar)junit.work.AssertionFailedError: expected:<4> but was:<3>

at testCar.testGetWheels(testCar.java:37)

FAILURES!!!

Tests run: 1, Failures: 1, Errors: 0

注意：Time上的小点表示测试个数，如果测试通过则显示OK。否则在小点的后边标上F，表示该测试失败。注意，在模拟出错的测试中，我们会得到详细的测试报告“expected:<4> but was:<3>”，这足以告诉我们问题发生在何处。下面就是你调试，测试，调试，测试...的过程，直至得到期望的结果。

Design by Contract（这句话我没法翻译）

Design by Contract本是Bertrand Meyer（Eiffel语言的创始人）开发的一种设计技术。我发现在JUnit中使用Design by Contract会带来意想不到的效果。Design by Contract的核心是断言（assersion）。断言是一个布尔语句，该语句不能为假，如果为假，则表明出现了一个bug。Design by Contract使用三种断言：前置条件（pre-conditions）、后置条件（post-conditions）和不变式（invariants）这里不打算详细讨论Design by Contract的细节，而是希望其在测试中能发挥其作用。

前置条件在执行测试之前可以用于判断是否允许进入测试，即进入测试的条件。如expectedWheels > 0, myCar != null。后置条件用于在测试执行后判断测试的结果是否正确。如expectedWheels==myCar.getWheels()。而不变式在判断交易(Transaction)的一致性（consistency）方面尤为有用。我希望JUnit可以将Design by Contract作为未来版本的一个增强。

Refactoring（这句话我依然没法翻译）

Refactoring本来与测试没有直接的联系，而是与软件熵有关，但既然我们说测试能解决软件熵问题，我们也就必须说出解决之道。（仅仅进行测试只能发现软件熵，Refactoring则可解决软件熵带来的问题。）软件熵引出了一个问题：是否需要重新设计整个软件的结构？理论上应该如此，但现实不允许我们这么做。这或者是由于时间的原因，或者是由于费用的原因。重新设计整个软件的结构会给我们带来短期的痛苦。而不停地给软件打补丁甚至是补丁的补丁则会给我们带来长期的痛苦。（不管怎样，我们总处于水深火热之中）

Refactoring是一个术语，用于描述一种技术，利用这种技术我们可以免于重构整个软件所带来的短期痛苦。当你refactor时，你并不改变程序的功能，而是改变程序内部的结构，使其更易理解和使用。如：该变一个方法的名字，将一个成员变量从一个类移到另一个类，将两个类似方法抽象到父类中。所作的每一个步都很小，然而1－2个小时的Refactoring工作可以使你的程序结构更适合目前的情况。Refactoring有一些规则：

1> 不要在加入新功能的同时refactor已有的代码。在这两者间要有一个清晰的界限。如每天早上1-2个小时的Refactoring，其余时间添加新的功能。

2> 在你开始Refactoring前，和Refactoring后都要保证测试能顺利通过。否则Refactoring没有任何意义。

3> 进行小的Refactoring，大的就不是Refactoring了。如果你打算重构整个软件，就没有必要Refactoring了。

只有在添加新功能和调试bug时才又必要Refactoring。不要等到交付软件的最后关头才Refactoring。那样和打补丁的区别不大。Refactoring 用在回归测试中也能显示其威力。要明白，我不反对打补丁，但要记住打补丁是应该最后使用的必杀绝招。（打补丁也需要很高的技术，详情参看微软网站）

IDE对JUnit的支持

目前支持JUnit的Java IDE 包括IDE 方式个人评价（1－5，满分5）

Forte for Java 3.0 Enterprise Edition plug-in 3

JBuilder 6 Enterprise Edition integrated with IDE 4

Visual Age for Java support N/A

在IDE中如何使用JUnit,是非常具体的事情。不同的IDE有不同的使用方法。一旦理解了JUnit 的本质，使用起来就十分容易了。所以我们不依赖于具体的IDE，而是集中精力讲述如何利用JUnit编写单元测试代码。心急的人可参看资料。

JUnit简介

既然我们已经对JUnit有了一个大致的了解，我希望能给大家提供一个稍微正式一些的编写JUnit测试文档的手册，明白其中的一些关键术语和概念。但我要声明的是这并不是一本完全的手册，只能认为是一本入门手册。同其他OpenSource的软件有同样的问题，JUnit的文档并没有商业软件文档的那种有规则，简洁和完全。由开发人员编写的文档总是说不太清楚问题，全整的文档需要参考"官方"指南，API手册，邮件讨论组的邮件，甚至包括源代码中及相关的注释。

事实上问题并没有那么复杂，除非你有非常特别的要求，否则，只需参考本文你就可以得到所需的大部分信息。

安装

首先你要获取JUnit的软件包，从JUnit下载最新的软件包（截至写作本文时，JUnit的最新版本是3.7）。将其在适当的目录下解包。这样在安装目录（也就是你所选择的解包的目录）下你找到一个名为junit.jar的文件。将这个jar文件加入你的CLASSPATH系统变量。（IDE的设置会有所不同，参看你所喜爱的IDE的配置指南）JUnit就安装完了。太easy了！

你一旦安装完JUnit，就有可能想试试我们的Car和testCar类，没问题，我已经运行过了,你得到的结果应该和我列出的结果类似。（以防新版JUnit使我的文章过时）

接下来，你可能会先写测试代码，再写工作代码，或者相反，先写工作代码，再写测试代码。我更赞成使用前一种方法：先写测试代码，再写工作代码。因为这样可以使我们编写工作代码时清晰地了解工作类的行为。

要注意编写一定能通过的测试代码（如文中的例子）并没有任何意义，只有测试代码能帮助我们发现bug，测试代码才有其价值。此外测试代码还应该对工作代码进行全面的测试。如给方法调用的参数传入空值、错误值和正确的值，看看方法的行为是否如你所期望的那样。你现在已经知道了编写测试类的基本步骤：

1>扩展TestCase类；

2>覆盖runTest()方法（可选）；

3>写一些testXXXXX()方法；

Fixture

解下来的问题是，如果你要对一个或若干个的类执行多个测试，该怎么办？JUnit对此有特殊的解决办法。

如果需要在一个或若干个的类执行多个测试，这些类就成为了测试的context。在JUnit中被称为Fixture（如testCar类中的myCar 和expectedWheels ）。当你编写测试代码时，你会发现你花费了很多时间配置/初始化相关测试的Fixture。将配置Fixture的代码放入测试类的构造方法中并不可取，因为我们要求执行多个测试，我并不希望某个测试的结果意外地（如果这是你要求的，那就另当别论了）影响其他测试的结果。通常若干个测试会使用相同的Fixture，而每个测试又各有自己需要改变的地方。

为此，JUnit提供了两个方法，定义在TestCase类中。

protected void setUp() throws https://www.sodocs.net/doc/de6554716.html,ng.Exception

protected void tearDown() throws https://www.sodocs.net/doc/de6554716.html,ng.Exception

覆盖setUp()方法，初始化所有测试的Fixture（你甚至可以在setUp中建立网络连接），将每个测试略有不同的地方在testXXX()方法中进行配置。

覆盖tearDown()（我总想起一首叫雨滴的吉他曲），释放你在setUp()中分配的永久性资源，如数据库连接。

当JUnit执行测试时，它在执行每个testXXXXX()方法前都调用setUp()，而在执行每个testXXXXX()方法后都调用tearDown()方法，由此保证了测试不会相互影响。

TestCase

需要提醒一下，在junit.work.Assert类中定义了相当多的assert方法，主要有assert(), assert(), assertEquals(), assertNull(), assertSame(), assertTrue(), fail()等方法。如果你需要比较自己定义的类，如Car。assert方法需要你覆盖Object类的equals()方法，以比较两个对象的不同。实践表明:如果你覆盖了Object类的equals()方法，最好也覆盖Object类的hashCode()方法。再进一步，连带Object类的toString()方法也一并覆盖。这样可以使测试结果更具可读性。

当你设置好了Fixture后，下一步是编写所需的testXXX()方法。一定要保证testXXX()方法的public属性，否则无法通过内省（reflection）对该测试进行调用。

每个扩展的TestCase类（也就是你编写的测试类）会有多个testXXX()方法。一个testXXX()方法就是一个测试。要想运行这个测试，你必须定义如何运行该测试。如果你有多个testXXX()方法，你就要定义多次。JUnit支持两种运行单个测试的方法：静态的和动态的方法。

静态的方法就是覆盖TestCase类的runTest()方法，一般是采用内部类的方式创建一个测试实例：

TestCase test01 = new testCar("test getWheels") {

public void runTest() {

testGetWheels();

}

}

采用静态的方法要注意要给每个测试一个名字（这个名字可以任意起，但你肯定希望这个名字有某种意义），这样你就可以区分那个测试失败了。

动态的方法是用内省来实现runTest()以创建一个测试实例。这要求测试的名字就是需要调用的测试方法的名字：

TestCase test01 = new testCar("testGetWheels");

JUnit会动态查找并调用指定的测试方法。动态的方法很简洁，但如果你键入了错误的名字就会得到一个令人奇怪的NoSuchMethodException异常。动态的方法和静态的方法都很好，你可以按照自己的喜好来选择。（先别着急选择，后面还有一种更酷的方法等着你呢。）

TestSuite

一旦你创建了一些测试实例，下一步就是要让他们能一起运行。我们必须定义一个TestSuite。在JUnit中，这就要求你在TestCase类中定义一个静态的suite()方法。suite()方法就像main()方法一样，JUnit用它来执行测试。在suite()方法中，你将测试实例加到一个TestSuite对象中，并返回这个TestSuite对象。一个TestSuite对象可以运行一组测试。TestSuite和TestCase 都实现了Test接口（interface），而Test接口定义了运行测试所需的方法。这就允许你用TestCase和TestSuite的组合创建一个TestSuite。这就是为什么我们前面说TestCase，TestSuite 以及TestSuite组成了一个composite Pattern的原因。例子如下：

public static Test suite() {

TestSuite suite= new TestSuite();

suite.addTest(new testCar("testGetWheels"));

suite.addTest(new testCar("testGetSeats"));

return suite;

}

从JUnit 2.0开始，有一种更简单的动态定义测试实例的方法。你只需将类传递给TestSuite，JUnit会根据测试方法名自动创建相应的测试实例。所以你的测试方法最好取名为testXXX()。例子如下：

public static Test suite() {

return new TestSuite(testCar.class);

}

从JUnit的设计我们可看出，JUnit不仅可用于单元测试，也可用于集成测试。关于如何用JUnit 进行集成测试请参考相关资料。

为了兼容性的考虑，下面列出使用静态方法的例子：

public static Test suite() {

TestSuite suite= new TestSuite();

suite.addTest(

new testCar("getWheels") {

protected void runTest() { testGetWheels(); }

}

);

suite.addTest(

new testCar("getSeats") {

protected void runTest() { testGetSeats(); }

}

);

return suite;

}

TestRunner

有了TestSuite我们就可以运行这些测试了，JUnit提供了三种界面来运行测试

[Text UI] junit.textui.TestRunner

[AWT UI] junit.awtui.TestRunner

[Swing UI] junit.swingui.TestRunner

我们前面已经看过文本界面了，下面让我们来看一看图形界面：

界面很简单，键入类名－testCar。或在启动UI的时候键入类名：

[Windows] d:>java junit.swingui.TestRunner testCar

[Unix] ％java junit.swingui.TestRunner testCar

从图形UI可以更好的运行测试可查单测试结果。还有一个问题需要注意：如果JUnit报告了测试没有成功，JUnit会区分失败（failures）和错误（errors）。失败是一个期望的被assert 方法检查到的结果。而错误则是意外的问题引起的，如ArrayIndexOutOfBoundsException。由于TestRunner十分简单，界面也比较直观，故不多介绍。朋友们可自行参考相关资料。

JUnit最佳实践

Martin Fowler（又是这位高人）说过：“当你试图打印输出一些信息或调试一个表达式时，写一些测试代码来替代那些传统的方法。”一开始，你会发现你总是要创建一些新的Fixture，而且测试似乎使你的编程速度慢了下来。然而不久之后，你会发现你重复使用相同的Fixture，而且新的测试通常只涉及添加一个新的测试方法。

你可能会写许多测试代码，但你很快就会发现你设想出的测试只有一小部分是真正有用的。你所需要的测试是那些会失败的测试，即那些你认为不会失败的测试，或你认为应该失败却成功的测试。

我们前面提到过测试是一个不会中断的过程。一旦你有了一个测试，你就要一直确保其正常工作，以检验你所加入的新的工作代码。不要每隔几天或最后才运行测试，每天你都应该运行一下测试代码。这种投资很小，但可以确保你得到可以信赖的工作代码。你的返工率降低了，你会有更多的时间编写工作代码。

不要认为压力大，就不写测试代码。相反编写测试代码会使你的压力逐渐减轻，应为通过编写测试代码，你对类的行为有了确切的认识。你会更快地编写出有效率地工作代码。下面是一些具体的编写测试代码的技巧或较好的实践方法：

1. 不要用TestCase的构造函数初始化Fixture，而要用setUp()和tearDown()方法。

2. 不要依赖或假定测试运行的顺序，因为JUnit利用Vector保存测试方法。所以不同的平台

会按不同的顺序从Vector中取出测试方法。

3. 避免编写有副作用的TestCase。例如：如果随后的测试依赖于某些特定的交易数据，就不要提交交易数据。简单的会滚就可以了。

4. 当继承一个测试类时，记得调用父类的setUp()和tearDown()方法。

5. 将测试代码和工作代码放在一起，一边同步编译和更新。（使用Ant中有支持junit的task.）

6. 测试类和测试方法应该有一致的命名方案。如在工作类名前加上test从而形成测试类名。

7. 确保测试与时间无关，不要依赖使用过期的数据进行测试。导致在随后的维护过程中很难重现测试。

8. 如果你编写的软件面向国际市场，编写测试时要考虑国际化的因素。不要仅用母语的Locale进行测试。

9. 尽可能地利用JUnit提供地assert/fail方法以及异常处理的方法，可以使代码更为简洁。

10.测试要尽可能地小，执行速度快。

事实上，JUnit还可用于集成测试，但我并没涉及到，原因有两个：一是因为没有单元测试，集成测试无从谈起。我们接受测试地概念已经很不容易了，如果再引入集成测试就会更困难。二是我比较懒，希望将集成测试的任务交给测试人员去做。在JUnit的网站上有一些相关的文章，有空大家可以翻一翻。

JUnit与J2EE

如果大家仔细考虑一下的话，就会发现，JUnit有自己的局限性，比如对图形界面的测试，对servlet/JSP以及EJB的测试我们都没有举相关的例子。实际上，JUnit对于GUI界面，servlet/JSP，JavaBean以及EJB都有办法测试。关于GUI的测试比较复杂，适合用一整篇文章来介绍。这里就不多说了。

前面我们所做的测试实际上有一个隐含的环境，JVM我们的类需要这个JVM来执行。而在J2EE框架中，servlet/JSP，EJB都要求有自己的运行环境：Web Container和EJB Container。所以，要想对servlet/JSP，EJB进行测试就需要将其部署在相应的Container中才能进行测试。由于EJB不涉及UI的问题（除非EJB操作XML数据，此时的测试代码比较难写，有可能需要你比较两棵DOM树是否含有相同的内容）只要部署上去之后就可以运行测试代码了。此时setUp()方法显得特别有用，你可以在setUp()方法中利用JNDI查找特定的EJB。而在testXXX()方法中调用并测试这些EJB的方法。

这里所指的JavaBean同样没有UI的问题，比如，我们用JavaBean来访问数据库，或用JavaBean 来包裹EJB。如果这类JavaBean没有用到Container的提供的服务，则可直接进行测试，同我们前面所说的一般的类的测试方法一样。如果这类JavaBean用到了Container的提供的服务，则需要将其部署在Container中才能进行测试。方法与EJB类似。

对于servlet/JSP的测试则比较棘手，有人建议在测试代码中构造HttpRequest和HttpResponse，然后进行比较，这就要求开发人员对HTTP协议以及servlet/JSP的内部实现有比较深的认识。我认为这招不太现实。也有人提出使用HttpUnit。由于我对Cactus和HttpUnit 了解不多，所以无法做出合适的建议。希望各位先知们能不吝赐教。

正是由于JUnit的开放性和简单易行，才会引出这篇介绍文章。但技术总在不断地更新，而且我对测试并没有非常深入的理解；我可以将一个复杂的概念简化成一句非常容易理解的话。但我的本意只是希望能降低开发人员步入测试领域的门槛，而不是要修改或重新定义一些概念。这一点是特别要强调的。最后，如果有些兄弟姐妹能给我指出一些注意事项或我对某些问题的理解有误，我会非常感激的。

用Junit测试计算器单元对象类

实验报告五 课程名称：软件测试 学生姓名：董月 班级：浦计1104班 学号：P1401110402 指导教师：韩志刚 实验日期：2014-5-8 南京工业大学电子与信息学院

实验五 一、实验内容 用java语言编写一个计算器类，求实现加、减、乘、除、求平方根、求绝对值、求倒数1/x,方法，并用junit进行对象类的单元测试。参阅帮助文档。（说明，设计求除法、求倒数的方法，可在方法中不检测x是否为0,测试用例用y/0去测试、求平方根可不检测x>0,用负数测试） 二、实验步骤 首先新建一个项目叫JUnit_Test，我们编写一个Calculator类，这是一个能够简单实现加减乘除、平方、开方的计算器类，然后对这些功能进行单元测试。 建立一个hzg包: 建立一个Calculator类:

把代码输进类中： package hzg; public class Calculator { private static int result; // 静态变量，用于存储运行结果 public void add(int n) { result = result + n; } public void substract(int n) { result = result - 1; //Bug: 正确的应该是result =result-n } public void multiply(int n) { result=result*n; } public void divide(int n) { result = result / n; } public void square(int n) { result = n * n; } public void squareRoot(int n) { result= (int) Math.sqrt(n); } public void clear() { // 将结果清零 result = 0; } public void reciprocal(int n) { result=1/n; } public void absolute(int n) { result=Math.abs(n); } public int getResult() { return result; } }

Junit单元测试技术

JUnit单元测试 （一）、JUnit介绍： 测试对于保证软件开发质量有着非常重要的作用，单元测试更是必不可少，JUnit是一个非常强大的单元测试包，可以对一个/多个类的单个/多个方法测试，还可以将不同的TestCase组合成TestSuit，使测试任务自动化。Eclipse同样集成了JUnit，可以非常方便地编写TestCase。 （二）、为什么使用JUnit? 不知道大家以前在对自己的项目是怎么进行测试的。反正我的测试方法是在一个类中都写一个main函数，然后根据类中方法的参数传入相应的值。这样做很麻烦，最大的缺点就是如果项目功能模块很多的话，那就完了。：） （三）、eclipse中建立一个完整的单元测试 Junit3 package cn.itcast.example; public class Demo1 { private int n; public Demo1(int n) { this.n = n; } // 返回绝对值： public int foo() { return n>0 ? n : (-n); } } package cn.itcast.example; public class Demo2 { public int add(int x, int y) { return x + y; } public static int divide(int x, int y) { return x / y; } public static int multiple(int x, int y) { return x * y; } } 测试用例

public class Demo1Test extends TestCase { private Demo1 s1, s2; protected void setUp() throws Exception { s1 = new Demo1(10); s2 = new Demo1(-7); } protected void tearDown() throws Exception { } public void testFoo() { assertTrue(s1.foo()==10); assertTrue(s2.foo()==7); } } public class Demo2Test extends TestCase { Demo2 demo; protected void setUp() throws Exception { super.setUp(); demo = new Demo2(); System.out.println("go........."); } protected void tearDown() throws Exception { super.tearDown(); } public void testAdd() { assertEquals(7, demo.add(3, 4)); } public void testDivide() { assertEquals(4, demo.divide(8, 2)); } public void testMultiple() { assertEquals(20, demo.multiple(4, 5)); } } public class AllTests {

在Eclipse中使用JUnit4进行单元测试

在Eclipse中使用JUnit4进行单元测试 首先新建一个项目叫JUnit_Test，我们编写一个Calculator类，这是一个能够简单实现加减乘除、平方、开方的计算器类，然后对这些功能进行单元测试。这个类并不是很完美，我们故意保留了一些Bug用于演示，这些Bug在注释中都有说明。该类代码如下：

第二步，将JUnit4单元测试包引入这个项目：在该项目上点右键，点“属性”，如图： 在弹出的属性窗口中，首先在左边选择“Java Build Path”，然后到右上选择“Libraries”标签，之后在最右边点击“Add Library…”按钮，如下图所示： 然后在新弹出的对话框中选择JUnit4并点击确定，如上图所示，JUnit4软件包就被包含进我们这个项目了。 第三步，生成JUnit测试框架：在Eclipse的Package Explorer中用右键点击该类弹出菜单，选择“New à JUnit Test Case”。如下图所示： 在弹出的对话框中，进行相应的选择，如下图所示：

点击“下一步”后，系统会自动列出你这个类中包含的方法，选择你要进行测试的方法。此例中，我们仅对“加、减、乘、除”四个方法进行测试。如下图所示： 之后系统会自动生成一个新类CalculatorTest，里面包含一些空的测试用例。你只需要将这些测试用例稍作修改即可使用。完整的CalculatorTest代码如下：

第四步，运行测试代码：按照上述代码修改完毕后，我们在CalculatorTest类上点右键，选择“Run As à JUnit Test”来运行我们的测试，如下图所示： 运行结果如下：

JUnit in java单元测试用例实战

JUnit in java单元测试用例实战 单元测试基础 当今软件测试十分盛行时，本人通过项目实践和个人亲身体会浅谈单元测试，本人一直坚持“用代码说话的原则”，同时也希望个人能给出宝贵意见，共同探讨、共同进步，为中国软件事业有更大的发展共同奋斗! 最早我们项目组开发的项目时，写代码都是从底层一直写到表现层到jsp，然后开发人员在web层调试页面，近乎98%都会报一大堆exception,然后再在代码中加断点一步一步查到底哪一层代码出现问题……,比较好点做法就是在各个类中加上main方法测试，但总体很不理想，给web层开发人员的调试和质量控制人员带来繁重的工作压力;使用单元测试后，针对每一个方法都做严格的把关，大大减少调试的时间;同时质量控制人员返回过来的bug 少了近60%，现在对于开发人员写测试用例非常熟练，并且本人根据实际情况对测试用例做了点小小改动(这部分主要在后面代码中详述)，带来很好的效果! 单元测试到底给实际开发带来什么好处那? (1)首先对于开发人员来说大大减少调试工作的时间，同时也规范了对于代码安全管理(我们知道那些方法是可以调用的); (2)对于整个项目来说，有了完整的测试，保证项目最后交付测试有了可靠依据; (3)对于测试人员大大减少bug的反馈; (4)对于项目经理整个项目达到很好的可控; (5)最主要的完整的单元测试给后期维护人员带来很大的便捷! 单元测试好处可能还有很多，但本人只能理解和感悟这么多,希望观者补充! 单元测试配置： 将使用eclipse+myEclopse给大家介绍关于JUNIT的环境的简单配置;右键点击项目选择“属性”，在弹出窗口中到环境变量中添加junit.jar包，这样下一步我们就可以进行单元测试了;

MyEclipse中使用Junit插件进行单元测试

Eclipse中使用Junit插件进行单元测试 测试是软件开发的重要环节之一。按照软件开发的过程测试可分为：单元测试、集成测试、系统测试、域测试等。我们这里将讨论面向程序员的单元测试。 一、什么是单元测试 单元测试指的是使用编写好的测试代码来检验需要被测试的代码。我们通常给要测试的方法传入一些参数值，然后检测方法的返回值跟预期是否一致。一般情况下我们会传入一些容易引发错误的数据，例如给计算除法的方法传入除数0，并且测试的参数也会传入许多组，这样才能保证测试效果。 二、为什么要使用单元测试 注：如果你时间不多请直接看后面的粗体 每当别人提起“单元测试”都会让william的内心难受上好长一阵子，往往他的好心情也会一扫而光。这又是为什么呢？ 5年前William的软件公司很顺利的拿到美国ADC电讯公司（ADC Telecommunications ）的一单软件开发的生意，总价值1500万美元，利润在32%上下。面对着几百万的收益，William 兴奋地对自己的妻子说：“Catherine，不久我们的银行户头上就会多出几百万美元。做完这笔生意，你老爸再也不会抱怨他的女儿嫁给了一个贫困街区出生并且没受过高等教育的乡巴佬。还真想不到你老爸再见到我的时候会是什么样的表情……”。 作为同William生活了12年的Catherine很清楚的知道，William这个人实际的本事没多少，然而大话却说了不少。当初她正因为轻信了William的许诺才嫁给他，然而当年的承诺从来就没兑现过。虽说William这个人没什么本事，可是他却有着令别人羡慕的“狗屎运”。 高中毕业之后，他参了军，在越南战争中他所在的小队中了越南人的埋伏，却唯独William 一个人活着回来。（William牢记美军士兵手册其中一条训令：永远不要和比你作战勇敢的战友躲在同一个散兵坑，因为他会给你们招来致命炮火打击。）William回来后向自己的上司编造了谎言，因而被提升为中尉，授予紫心勋章。 退役后有幸运结识底特律市长的千金——Catherine，并且让这位市长千金以身相许。William 的岳父虽说从来就没看上过这位贫穷、没教养还时常夸夸其谈的女婿，可最终还是出资给William创办公司。William的运气不得不让人羡慕，可是这回软件开发他还会这么幸运么？ 翌日，William一大早就来到公司，他第一件事情就是要和项目经理谈话。 “嘿！John。我们的项目要立即投入人力着手开发，别让那些程序员慢吞吞的。”William认真的说。 “先生，我们的项目还不能立即开发，因为我们还没有做项目需求。”项目经理John提醒着。

Junit单元测试

JUnit java单元测试 首先须导入JUnit包：所在项目右击->Build Path->Add Libraries ->选择JUnit->选择一个版本->Finish 一．手动生成 1.测试方法，必须符合下列条件 *方法必须声明成：public，void *JUnit3方法名必须以test开头，JUnit4则不需要 *方法无参数 如：JUnit3：Public void testAdd(){} JUnit4：@Test （org.junit.Test） Public void AddTest(){} 2. JUit3 与 JUit4的区别 源码和测试代码分开放在不同的Source Folder，测试代码所在的包名最好和源码中的包名一一对应。JUnit3测试方法中的类必须继承TestCase （junit.framwork.TestCase）；而JUnit4类则不需要继承任何类，但在方法前须加上注解@Test（org.junit.Test）此测试方法，标注该程序是以JUnit的方式来运行的。 JUit3：在方法前加上TestCase类的方法setUp()，在执行每一次测试方法之前都会被调用，可把在测试方法中都需要的程序放在这里；最后加上

tearDown()方法，在执行每一次方法后都会被调用。 JUit4：与JUit3不同的是，在JUit4中是在方法前用注解 @BeforeClass:globeInit(),无论执行多少测试方法，它只执行一次，且运行在最前 @Before：把方法注解成Before，init()与JUit3中的setUp()方法作用一样@After：把方法注解成After，destroy()与JUit3中的tearDown ()方法作用一样 @AfterClass:无论执行多少测试方法，它只执行一次，且运行在最后 下面分别以JUit3和JUit4为例子来运行测试： 例1.JUit3 源代码： package com.sinyee.unit; public class ArrayUnit { /** *传入一个数组，返回该数组的最大值 *@param array *@return */ public int getMaxValue(int[] array) throws Exception { if (array==null) { throw new NullPointerException("空指针异常"); } if (array.length == 0) { throw new ArrayIndexOutOfBoundsException("数组不能为 空!"); } int temp = array[0]; for (int i = 1; i < array.length; i++) { if (temp < array[i]) { array[i] = temp; } } // 取出该数组的最大值 return temp;

单元测试(JUnit)的应用

单元测试(JUnit)的应用 一．概要 单元测试不仅仅是保证代码在方法级别的正确性，它还能改进设计，易于对代码重构。凡是容易编写单元测试的代码，往往是优秀的设计和松耦合的组件，凡是难于编写单元测试的代码，往往是设计不佳和耦合度高的系统，因此，编写单元测试不仅仅是掌握单元测试柜架的用法，更重要的是在编写单元测试的过程中发现设计缺陷，改进系统结构，从而实现良好的可扩展性。 任何一个项目，单元测试应该在详细设计之后开始进行，首先根据详细设计文档进行单元测试用例的编写，编写完成后进行代码开发，代码完成后运行单元测试，如果通过，则该方法可以发布运行，如果不通过需要进行代码改造，再进行单元测试，直到单元测试运行通过为止。 每新增一个功能时的开发流程如图1所示： 编写测试用例 编写代码 完成 对代码做小的修改 运行测试通过失败 图1 本文首先按照上图所示流程进行一个简单功能的开发，同时使用JUnit 4 提供的

各种功能开展有效的单元测试，接着对JUnit技术进行了简单的介绍。 二．软件支持 Eclipse：最为流行的 IDE，它全面集成了 JUnit，并从版本 3.2 开始支持 JUnit 4。当然 JUnit 并不依赖于任何 IDE。您可以从https://www.sodocs.net/doc/de6554716.html,/上下载最新的 Eclipse 版本。 Ant：基于 Java 的开源构建工具，您可以在https://www.sodocs.net/doc/de6554716.html,/上得到最新的版本和丰富的文档。Eclipse 中已经集成了 Ant。 JUnit：它的官方网站是https://www.sodocs.net/doc/de6554716.html,/。您可以从上面获取关于 JUnit 的最新消息。如果您和本文一样在 Eclipse 中使用 JUnit，就不必再下载了。 三．JUnit的实际应用例子 3.1功能需求 将Java对象名称（每个单词的头字母大写）按照数据库命名的习惯进行格式化，格式化后的数据为小写字母，并且使用下划线分割命名单词，要求对输入数据进行非法验证。 3.2编写测试 首先新建一个 Java 工程—— TestJUnit。打开项目 TestJUnit的属性页 -> 选择“Java Build Path”子选项 -> 点选“Add Library…”按钮 -> 在弹出的“Add Library”对话框中选择 JUnit（图2），并在下一页中选择版本 4.1 后点击“Finish”按钮。

课程设计-基于Junit的单元测试

课程设计(论文)任务书 软件学院软件工程（软件测试）专业2012－班 一、课程设计(论文)题目基于Junit(/Nunit)的单元测试 二、课程设计(论文)工作自 2015年 6 月 15 日起至 2015年 6 月 19 日止。 三、课程设计(论文) 地点: 创新大楼软件实训中心机房406 四、课程设计(论文)内容要求： 1．本课程设计的目的 （1）使学生能掌握黑盒功能测试的基本思路和方法，学会使用单元测试工具Junit(/Nunit)进行单元功能测试； （2）培养学生分析、解决问题的能力； （3）提高学生的科技论文写作能力。 2．课程设计的任务及要求 1）基本要求： （1）选择待测试函数或类，分析测试需求，认真设计好测试用例； （2）重点运用Junit/Nunit进行单元测试的开发； （3）认真分析测试结果；分析测试用例对被测对象的覆盖程度。 2）创新要求： 在基本要求达到后，可以对更复杂一些的函数设计用例，进行单元测试。 3）课程设计论文编写要求 （1）要按照书稿的规格打印书写课程设计论文 （2）论文包括目录、设计思路、具体实现、运行调试与分析讨论、设计体会与小结、参考文献、附录等 （3）课程设计论文装订按学校的统一要求完成 4）答辩与评分标准： （1）出勤和学习态度：10分； （2）课设检查：20分； （3）回答问题：20分； （4）课设论文：50分； 5）参考文献： （1）参考单元测试的PPT

（2） 6）课程设计进度安排 内容天数地点 构思及收集资料1图书馆 设计与测试 2.5实验室 撰写论文 1.5图书馆、实验室 学生签名： 2015年6月19日 课程设计(论文)评审意见 （1）测试内容（10分）：优（）、良（）、中（）、一般（）、差（）； （2）设计分析（40分）：优（）、良（）、中（）、一般（）、差（）； （3）测试开发（30分）：优（）、良（）、中（）、一般（）、差（）； （4）结果分析（20分）：优（）、良（）、中（）、一般（）、差（）； 评阅人：职称：副教授 2015年6月22日

软件测试实验-JUnit单元测试

第三章JUnit单元测试 实验1 开始使用JUnit 【实验目得】 1、学习使用JUnit4、X进行单元测试； 2、掌握JUnit4、X编写测试代码得方法； 3、应用JUnit进行单元测试，掌握最佳实践编写测试代码。 【实验环境】 1、Windows环境，MyEclipse或Eclipse，JUnit4、x。 2、每个学生操作1台电脑。 【实验原理】 JUnit就是一个开源得Java编程语言得单元测试框架，最初由Erich Gamma 与Kent Beck 编写。Junit测试就是一种白盒测试工具。JUnit就是一套框架，继承TestCase类，就可以用Junit进行自动测试了。具有JUnit经验对于应用“测试驱动开发（TDD）”得程序开发模型就是非常重要得。 JUnit本质上就是一套框架，即开发者制定了一套条条框框，遵循这此条条框框要求编写测试代码，如继承某个类，实现某个接口，就可以用JUnit进行自动测试了。 由于JUnit相对独立于所编写得代码，可以测试代码得编写可以先于实现代码得编写，XP 中推崇得test first design得实现有了现成得手段：用JUnit写测试代码，写实现代码，运行测试，测试失败，修改实现代码，再运行测试，直到测试成功。以后对代码得修改与优化，运行测试成功，则修改成功。 Java 下得team 开发，采用cvs(版本控制) + ant(项目管理) + JUnit (集成测试) 得模式时，通过对ant得配置，可以很简单地实现测试自动化。 【实验内容】 根据下面得实验步骤完成实验。 1、JUnit包下载。 (1) 从http://下载Junit，打开该链接，会有一个下载链接，下载Junit4、X、zip，保存在用户机得文件系统中。 (2) 解包Junit-4、X，得到如图3-1得解包文件。

软件测试实验3--Junit单元测试

南京理工大学泰州科技学院实验报告书 课程名称：《软件测试与质量保证》 实验题目：实验三 Junit单元测试 班级： 学号： 姓名： 指导教师：

一、实验目的 1．了解Junit测试框架用途及相关框架组成要素 2．掌握Junit3.8中断言的使用及Assert静态类的相关用法 3．掌握在Eclipse中如何结合JUnit3.8进行单元测试的过程 二、实验内容 1、使用java语言编写一个类，该类用于完成简单的数学四则运算；然后使用Junit单元测试方法对编写的类进行测试。 三、实验步骤及结果 1、 （1）实验程序 package https://www.sodocs.net/doc/de6554716.html,; import https://www.sodocs.net/doc/de6554716.html,.apache.bcel.internal.generic.NEW; import junit.framework.Assert; import junit.framework.TestCase;

public class MathTest extends TestCase{ public void testAdd() { Math math=new Math(); int result=math.add(1,2); Assert.assertEquals(3,result); } public void testMin(){ Math math=new Math(); int result=math.min(1,2); Assert.assertEquals(-1,result); } public void testMui(){ Math math=new Math(); int result=math.mui(1,2); Assert.assertEquals(2,result); } public void testDiv(){ Math math=new Math(); int result=0; try{ result=math.div(6,2);} catch(Exception e){ e.printStackTrace(); } Assert.assertEquals(3,result); } public void testDiv1(){ Throwable throwable=null; Math math=new Math(); try{ int result=math.div(6,0);} catch(Exception e){ throwable=e; } assertNotNull(throwable); assertEquals(Exception.class,throwable.getClass()); assertEquals("除数不能为零",throwable.getMessage()); } } （2）实验结果

用Junit测试计算器单元对象类

实验报告五课程名称：软件测试 学生姓名：董月 班级：浦计1104班 指导教师：韩志刚 实验日期：2014-5-8 南京工业大学电子与信息学院 实验五 一、实验内容 用java语言编写一个计算器类，求实现加、减、乘、除、求平方根、求绝对值、求倒数1/x,方法，并用junit进行对象类的单元测试。参阅帮助文档。（说明，设计求除法、求倒数的方法，可在方法中不检测x是否为0,测试用例用y/0去测试、求平方根可不检测x>0,用负数测试） 二、实验步骤 首先新建一个项目叫JUnit_Test，我们编写一个Calculator类，这是一个能够简单实现加减乘除、平方、开方的计算器类，然后对这些功能进行单元测试。建立一个hzg包: 建立一个Calculator类: 把代码输进类中： package hzg; public class Calculator { private static int result; // 静态变量，用于存储运行结果 public void add(int n) { result = result + n; } public void substract(int n) { result = result - 1; //Bug: 正确的应该是result =result-n } public void multiply(int n) { r esult=result*n; } public void divide(int n) { result = result / n;

} public void square(int n) { result = n * n; } public void squareRoot(int n) { result= (int) Math.sqrt(n); } public void clear() { // 将结果清零 result = 0; } public void reciprocal(int n) { result=1/n; } public void absolute(int n) { result=Math.abs(n); } public int getResult() { return result; } } 第二步，将JUnit4单元测试包引入这个项目：在该项目上点右键，点“属性”，在弹出的属性窗口中，首先在左边选择“Java Build Path”，然后到右上选择“Libraries”标签，之后在最右边点击“Add Library…”按钮，如下图所示： 然后在新弹出的对话框中选择JUnit4并点击确定，如上图所示，JUnit4软件包就被包含进我们这个项目了。 第三步，生成JUnit测试框架：在Eclipse的Package Explorer中用右键点击该类弹出菜单，在弹出的对话框中，进行相应的选择加、减、乘、除，之后系统会自动生成一个新类CalculatorTest，里面包含一些空的测试用例。只需要将这些测试用例稍作修改即可使用。完整的CalculatorTest 代码如下： package hzg; import static import import import import import public class CalculatorTest { private static Calculator calculator = new Calculator(); @BeforeClass public static void setUpBeforeClass() throws Exception { } @AfterClass public static void tearDownAfterClass() throws Exception { }

Junit学习总结

Junit学习 （一）TDD简介： 许多书上都讨论了自动测试，但是只有很少的著作注意到这么一个问题，那就是怎样把这些测试组织起来。随着测试的增加，放置和调用这些测试却变得更加麻烦。这将成为一个重要问题，以至于出现了TDD，极限编程（XP）使TDD得以普及。另外，你可以这样理解TDD：通过测试来开发。 TDD（Test-Driven Development：测试驱动开发）本质和优势 测试驱动开发不是一种测试技术，它是一种分析技术、设计技术，更是一种组织所有开发活动的技术。相对于传统的结构化开发过程方法，它具有以下优势： 1) TDD根据客户需求编写测试用例，对功能的过程和接口都进行了设计，而且这种从使用者角度对代码进行的设计通常更符合后期开发的需求。因为关注用户反馈，可以及时响应需求变更，同时因为从使用者角度出发的简单设计，也可以更快地适应变化。 2) 出于易测试和测试独立性的要求，将促使我们实现松耦合的设计，并更多地依赖于接口而非具体的类，提高系统的可扩展性和抗变性。而且TDD明显地缩短了设计决策的反馈循环，是我们几秒或几分钟之内就能获得反馈。 3) 将测试工作提到编码之前，并频繁地运行所有测试，可以尽量地避免和尽早地发现错误，极大地降低了后续测试及修复的成本，提高了代码的质量。在测试的保护下，不断重构代码，以消除重复设计，优化设计结构，提高了代码的重用性，从而提高了软件产品的质量。 4) TDD提供了持续的回归测试，使我们拥有重构的勇气，因为代码的改动导致系统其他部分产生任何异常，测试都会立刻通知我们。完整的测试会帮助我们持续地跟踪整个系统的状态，因此我们就不需要担心会产生什么不可预知的副作用了。 5) TDD所产生的单元测试代码就是最完美的开发者文档，它们展示了所有的API该如何使用以及是如何运作的，而且它们与工作代码保持同步，永远是最新的。 6) TDD可以减轻压力、降低忧虑、提高我们对代码的信心、使我们拥有重构的勇气，这些都是快乐工作的重要前提。 TDD现状 由于发展时间不长，相关应用并不是很成熟。现今越来越多的公司都在尝试实践测试驱动开发，但由于测试驱动开发对开发人员要求比较高，更与开发人员的传统思维习惯相违背，因此实践起来有一定困难。

基于JUnit的单元测试报告

实验3 基于JUnit的单元测试 一、实验目的与要求 1、通过动手实际操作，巩固所学的单元测试相关知识 2、初步了解JUnit工具的使用方法，加深对单元测试的认识 3、熟悉eclipse工具的基本操作，掌握基于Eclipse工具的Java编程 4、学会使用EclEmma对测试覆盖率进行分析 5、通过实际代码案例，掌握单元测试的操作步骤 二、实验设备 1、电脑PC 2、Eclipse 3、Junit工具 4、EclEmma工具 三、实验过程 步骤一：确定单元测试方案 本实验选择StringUtils.java类中的四个方法作为Java单元测试的对象，选用Eclipse作为Java开发工具，下载并安装JUnit和EclEmma工具，使用JUnit进行单元测试，使用EclEmma进行覆盖率分析来辅助进行单元测试。 步骤二：JUnit的下载安装 JUnit是一个开源的Java测试框架，是单元测试框架体系xUnit的一个实例，目前已经成为Java单元测试的标准。JUnit软件包可以从网站http:https://www.sodocs.net/doc/de6554716.html, 中下载，本次实验中使用的是JUnit4.10版本。 无须解压JUnit压缩包，选中eclipse中的工程，在Eclipse菜单Project的子项Properties中选择Java Build Path，单击Libraries标签，单击Add External JARs 按钮，选择junit4.10.jar后单击“打开”按钮，完成JUnit安装，安装完成后重启Eclipse，如图3-1所示。

图3-1在Eclipse中安装JUnit 步骤三：EclEmma的下载与安装 EclEmma是一个开源的覆盖率工具，可以帮助大家在单元测试的时候分析代码覆盖情况，可从网站https://www.sodocs.net/doc/de6554716.html,/download.html中下载Jacoco 的Eclipse插件EclEmma最新版，本实验中使用的是Eclemma3.1.2版本解压eclemma-3.1.3.zip到Eclipse安装路径下的dropins目录中，并且保留如图3-2中的文件和文件夹。打开Eclipse，在工具栏help菜单中选择Install New Software，在Install窗口中单击Add按钮，并在Local的弹出框中选择EclEmma所在路径，添加name，完成后在Install列表中勾选展示的EclEmma 程序，单击Next按钮直到安装完成，如图3-3所示，安装完成后重启Eclipse，工具栏中会出现一个Coverage图标，如图3-4所示。 图3-2将eclemma解压到Eclipse的dropins路径下

实验一使用Junit进行单元测试

实验报告 实验名称使用Junit进行单元测试第 1 次实验实验日期 2011-10-16 指导教师程宝雷 班级软件10届学号 0993 姓名徐玮明成绩 一．目的和要求 JUnit是一款由Erich Gamma（《设计模式》的作者）和Kent Beck（极限编程的提出者）编写的开源的回归测试框架，供Java编码人员做单元测试之用。当前版本4.1，可以从3相比，JUnit 4.1依赖于Java 5.0的新特性，因此无法兼容于jdk 1.4，可以说是一个全新的框架。 由于这里使用的IDE是Eclipse ，已经集成了junit 4.1，因此便免去下载和配置类库的麻烦了 二．实验内容 参考案例《Junit测试》，完成如下内容 1、创建项目 下面打开Eclipse，点击菜单“文件”->“新建”->“项目”或“新建”按钮，打开“新建”对话框： 请选中“Java项目”，点击“下一步”，进入“新建Java项目”对话框： 在这个对话框中需要设置项目的名称以及项目所在目录，我为自己的项目起名为JUnitTest，目录为F:\YPJCCK\JUnit\Eclipse\JUnitTest。由于Eclipse自带了JUnit类库，因此此时点击“完成”即可。 2、编写用于测试的JavaBean 用于测试的JavaBean很简单，名为Book，只有id和name两个属性，这两个属性将分别用于两个用例当中。下面开始编写该JavaBean。 请点击“文件”->“新建”->“类”，打开“新建Java类”对话框，设置包为，名称为Book，并确保“public static void main(String[] args)”选项没有选中，然后点击“完成”。修改代码如下：package ; public class Book { private String id = null; private String name = null; public String getId() { return id; } public void setId(String id) { this.id = id; } public String getName() {

软件测试实验-单元测试工具JUNIT

武汉轻工大学 软件测试实验报告 实验一单元测试工具JUNIT 姓名：李娅娅 学号： 1505110015 班级：软工1503 指导老师：丁月华

1. 实验目的 了解自动化测试工具JUnit的架构、功能，学习如何下载、安装JUnit，掌握使用JUnit对Java程序进行单元测试的方法。 2. 实验步骤 2.1 导入jar包 右击项目名，单击Build Path中的Add Libraries.. 选择User Libariry。

新建一个存放Junit的包的库

将junit-4.7.jar导入

Jar包导入完成。 2.2 编写第一个Junit测试类 2.2.1 Calculator类 编写被测试类Calculator：(拷贝) private static int result; // 静态变量，用于存储运行结果 public void add(int n){ result = result + n; } public void substract(int n){ result = result - 1; //Bug: 正确的应该是 result =result-n } public void multiply(int n){ } // 此方法尚未写好 public void divide(int n){ result = result / n; } public void square(int n){ result = n * n; } public void squareRoot(int n){ for (; ;) ; //Bug : 死循环 }

Junit单元测试实验报告

实验二Junit单元测试实验报告 实验内容：利用Junit对实验程序进行单元测试 实验目的：掌握单元测试的方法，掌握在Eclipse里进行Junit测试的技术。 实验步骤和结果： 1、修改之前的Calculator的测试结果： (1)自动生成的CalculatorTest类代码： package andycpp; public class Calculator { private static int result; // 静态变量，用于存储运行结果 public void add(int n) { result = result + n; } public void substract(int n) { result= result- 1; //Bug: 正确的应该是 result =result-n } public void multiply(int n) { } // 此方法尚未写好 public void divide(int n) {

result = result / n; } public void square(int n) { result = n * n; } public void squareRoot(int n) { for (; ;) ; //Bug : 死循环 } public void clear() { // 将结果清零result = 0; } public int getResult() { return result; } } (2)运行结果：

自动生存的测试类 完善测试类后的运行结果

2、修改和完善Calculator类： package andycpp; public class Calculator { private static int result; // 静态变量，用于存储运行结果 public void add(int n) { result = result + n; } public void substract(int n) { result = result - n; //Bug: 正确的应该是 result =result-n } public void multiply(int n) { result =result*n; } public void divide(int n) { result = result / n; } public void square(int n) { result = n * n; } public void squareRoot(int n) { result=(int)(n); //Bug : 死循环

junit单元测试教程教程

测试的概念 长期以来，我所接触的软件开发人员很少有人能在开发的过程中进行测试工作。大部分的项目都是在最终验收的时候编写测试文档。有些项目甚至没有测试文档。现在情况有了改变。我们一直提倡UML、RUP、软件工程、CMM，目的只有一个，提高软件编写的质量。举一个极端的例子：如果你是一个超级程序设计师，一个传奇般的人物。（你可以一边喝咖啡，一边听着音乐，同时编写这操作系统中关于进程调度的模块，而且两天时间内就完成了！）我真得承认，有这样的人。（那个编写UNIX中的vi编辑器的家伙就是这种人。）然而非常遗憾的是这些神仙们并没有留下如何修成正果的README。所以我们这些凡人－－在同一时间只能将注意力集中到若干点（据科学统计，我并不太相信，一般的人只能同时考虑最多7个左右的问题，高手可以达到12个左右），而不能既纵览全局又了解细节－－只能期望于其他的方式来保证我们所编写的软件质量。 为了说明我们这些凡人是如何的笨。有一个聪明人提出了软件熵（software entropy）的概念：一个程序从设计很好的状态开始，随着新的功能不断地加入，程序逐渐地失去了原有的结构，最终变成了一团乱麻。你可能会争辩，在这个例子中，设计很好的状态实际上并不好，如果好的话，就不会发生你所说的情况。是的，看来你变聪明了，可惜你还应该注意到两个问题：1)我们不能指望在恐龙纪元（大概是十年前）设计的结构到了现在也能适用吧。2)拥有签字权的客户代表可不理会加入一个新功能是否会对软件的结构有什么影响，即便有影响也是程序设计人员需要考虑的问题。如果你拒绝加入这个你认为致命的新功能，那么你很可能就失去了你的住房贷款和面包（对中国工程师来说也许是米饭或面条，要看你是南方人还是北方人）。 另外，需要说明的是我看过的一些讲解测试的书都没有我写的这么有人情味（不好意思...）。我希望看到这片文章的兄弟姐妹能很容易地接受测试的概念，并付诸实施。所以有些地方写的有些夸张，欢迎对测试有深入理解的兄弟姐妹能体察民情，并不吝赐教。 好了，我们现在言归正传。要测试，就要明白测试的目的。我认为测试的目的很简单也极具吸引力：写出高质量的软件并解决软件熵这一问题。想象一下，如果你写的软件和Richard Stallman（GNU、FSF的头儿）写的一样有水准的话，是不是很有成就感？如果你一致保持这种高水准，我保证你的薪水也会有所变动。 测试也分类，白箱测试、黑箱测试、单元测试、集成测试、功能测试...。我们先不管有多少分类，如何分类。先看那些对我们有用的分类，关于其他的测试，有兴趣的人可参阅其他资料。白箱测试是指在知道被测试的软件如何（How）完成功能和完成什么样（What）的功能的条件下所作的测试。一般是由开发人员完成。因为开发人员最了解自己编写的软件。本文也是以白箱测试为主。黑箱测试则是指在知道被测试的软件完成什么样（What）的功能的条件下所作的测试。一般是由测试人员完成。黑箱测试不是我们的重点。本文主要集中在单元测试上，单元测试是一种白箱测试。目的是验证一个或若干个类是否按所设计的那样正常工作。集成测试则是验证所有的类是否能互相配合，协同完成特定的任务，目前我们暂不关心它。下面我所提到的测试，除非特别说明，一般都是指单元测试。 需要强调的是：测试是一个持续的过程。也就是说测试贯穿与开发的整个过程中，单元测试尤其适合于迭代增量式（iterative and incremental）的开发过程。Martin Fowler（有点儿像引用孔夫子的话）甚至认为：“在你不知道如何测试代码之前，就不应该编写程序。而一旦你完成了程序，测试代码也应该完成。除非测试成功，你不能认为你编写出了可以工作的程序。”我并不指望所有的开发人员都能有如此高的觉悟，这种层次也不是一蹴而就的。但我们一旦了解测试的目的和好处，自然会坚持在开发过程中引入测试。 因为我们是测试新手，我们也不理会那些复杂的测试原理，先说一说最简单的:测试就是比较预期的结果是否与实际执行的结果一致。如果一致则通过，否则失败。看下面的例子：