如何使用junit4写单元测试用例
2014年8月21日posted by 大岩不灿 in 编程语言
JUnit4是JUnit框架有史以来的最大改进，其主要目标便是利用Java5的Annotation特性简化测试用例的编写。
先简单解释一下什么是Annotation，这个单词一般是翻译成元数据。元数据是什么？元数据就是描述数据的数据。也就是说，这个东西在Java里面可以用来和public、static等关键字一样来修饰类名、方法名、变量名。修饰的作用描述这个数据是做什么用的，差不多和public描述这个数据是公有的一样。想具体了解可以看Core Java2。废话不多说了，直接进入正题。
我们先看一下在JUnit 3中我们是怎样写一个单元测试的。比如下面一个类：
public class AddOperation {
public int add(int x,int y){
return x+y;
}
}
我们要测试add这个方法，我们写单元测试得这么写：
import junit.framework.TestCase;
import static org.junit.Assert.*;
public class AddOperationTest extends TestCase{
public void setUp() throws Exception {
}
public void tearDown() throws Exception {
}
public void testAdd() {
System.out.println(\”add\”);
int x = 0;
int y = 0;
AddOperation instance = new AddOperation();
int expResult = 0;
int result = instance.add(x, y);
assertEquals(expResult, result);
}
}
可以看到上面的类使用了JDK5中的静态导入，这个相对来说就很简单，只要在import关键字后面加上static关键字，就可以把后面的类的static的变量和方法导入到这个类中，调用的时候和调用自己的方法没有任何区别。
我们可以看到上面那个单元测试有一些比较霸道的地方，表现在：
1.单元测试类必须继承自TestCase。
2.要测试的方法必须以test开头。
如果上面那个单元测试在JUnit 4中写就不会这么复杂。代码如下：
import junit.framework.TestCase;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import static org.junit.Assert.*;
/**
*
* @author bean
*/
public class AddOperationTest extends TestCase{
public AddOperationTest() {
}
@Before
public void setUp() throws Exception {
}
@After
public void tearDown() throws Exception {
}
@Test
public void add() {
System.out.println(\”add\”);
int x = 0;
int y = 0;
AddOperation instance = new AddOperation();
int expResult = 0;
int result = instance.add(x, y);
assertEquals(expResult, result);
}
}
我们可以看到，采用Annotation的JUnit已经不会霸道的要求你必须继承自TestCase了，而且测试方法也不必以test开头了，只要以@Test元数据来描述即可。
从上面的例子可以看到在JUnit 4中还引入了一些其他的元数据，下面一一介绍：
@Before：
使用了该元数据的方法在每个测试方法执行之前都要执行一次。
@After：
使用了该元数据的方法在每个测试方法执行之后要执行一次。
注意：@Before和@After标示的方法只能各有一个。这个相当于取代了JUnit以前版本中的setUp和tearDown方法，当然你还可以继续叫这个名字，不过JUnit不会霸道的要求你这么做了。
@Test(expected=*.class)
在JUnit4.0之前，对错误的测试，我们只能通过fail来产生一个错误，并在try块里面assertTrue （true）来测试。现在，通过@Test元数据中的expected属性。expected属性的值是一个异常的类型
@Test(timeout=xxx):
该元数据传入了一个时间（毫秒）给测试方法，
如果测试方法在制定的时间之内没有运行完，则测试也失败。
@ignore：
该元数据标记的测试方法在测试中会被忽略。当测试的方法还没有实现，或者测试的方法已经过时，或者在某种条件下才能测试该方法（比如需要一个数据库联接，而在本地测试的时候，数据库并没有连接），那么使用该标签来标示这个方法。同时，你可以为该标签传递一个String的参数，来表明为什么会忽略这个测试方法。比如：@lgnore(“该方法还没有实现”)，在执行的时候，仅会报告该方法没有实现，而不会运行测试方法。
在Eclipse中使用JUnit4进行单元测试（初级篇）
我们在编写大型程序的时候，需要写成千上万个方法或函数，这些函数的功能可能很强大，但我们在程序中只用到该函数的一小部分功能，并且经过调试可以确定，这一小部分功能是正确的。但是，我们同时应该确保每一个函数都完全正确，因为如果我们今后如果对程序进行扩展，用到了某个函数的其他功能，而这个功能有bug的话，那绝对是一件非常郁闷的事情。所以说，每编写完一个函数之后，都应该对这个函数的方方面面进行测试，这样的测试我们称之为单元测试。传统的编程方式，进行单元测试是一件很麻烦的事情，你要重新写另外一个程序，在该程序中调用你需要测试的方法，并且仔细观察运行结果，看看是否有错。正因为如此麻烦，所以程序员们编写单元测试的热情不是很高。于是有一个牛人推出了单元测试包，大大简化了进行单元测试所要做的工作，这就是JUnit4。本文简要介绍一下在Eclipse3.2中使用JUnit4 进行单元测试的方法。
首先，我们来一个傻瓜式速成教程，不要问为什么，Follow Me，先来体验一下单元测试的快感！
首先新建一个项目叫JUnit_Test，我们编写一个Calculator类，这是一个能够简单实现加减乘除、平方、开方的计算器类，然后对这些功能进行单元测试。这个类并不是很完美，我们故意保留了一些Bug用于演示，这些Bug在注释中都有说明。该类代码如下：
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;
}
}
第二步，将JUnit4单元测试包引入这个项目：在该项目上点右键，点“属性”，如图：
在弹出的属性窗口中，首先在左边选择“Java Build Path”，然后到右上选择“Libraries”标签，之后在最右边点击“Add Library…”按钮，如下图所示：
然后在新弹出的对话框中选择JUnit4并点击确定，如上图所示，JUnit4软件包就被包含进我们这个项目了。
第三步，生成JUnit测试框架：在Eclipse的Package Explorer中用右键点击该类弹出菜单，选择“New àJUnit Test Case”。如下图所示：
在弹出的对话框中，进行相应的选择，如下图所示：
点击“下一步”后，系统会自动列出你这个类中包含的方法，选择你要进行测试的方法。此例中，我们仅对“加、减、乘、除”四个方法进行测试。如下图所示：
之后系统会自动生成一个新类CalculatorTest，里面包含一些空的测试用例。你只需要将这些测试用例稍作修改即可使用。完整的CalculatorTest代码如下：
package andycpp;
import static org.junit.Assert.*;
import org.junit.Before;
import org.junit.Ignore;
import org.junit.Test;
public class CalculatorTest …{
private static Calculator calculator = new Calculator();
@Before
public void setUp() throws Exception …{
calculator.clear();
}
@Test
public void testAdd() …{
calculator.add(2);
calculator.add(3);
assertEquals(5, calculator.getResult());
}
@Test
public void testSubstract() …{
calculator.add(10);
calculator.substract(2);
assertEquals(8, calculator.getResult());
}
@Ignore(“Multiply() Not yet implemented”)
@Test
public void testMultiply() …{
}
@Test
public void testDivide() …{
calculator.add(8);
calculator.divide(2);
assertEquals(4, calculator.getResult());
}
}
第四步，运行测试代码：按照上述代码修改完毕后，我们在CalculatorTest类上点右键，选择“Run As àJUnit Test”来运行我们的测试，如下图所示：
运行结果如下：
进度条是红颜色表示发现错误，具体的测试结果在进度条上面有表示“共进行了4个测试，其中1个测试被忽略，一个测试失败”
至此，我们已经完整体验了在Eclipse中使用JUnit的方法。在接下来的文章中，我会详细解释测试代码中的每一个细节！
在Eclipse中使用JUnit4进行单元测试（中级篇）
我们继续对初级篇中的例子进行分析。初级篇中我们使用Eclipse自动生成了一个测试框架，在这篇文章中，我们来仔细分析一下这个测试框架中的每一个细节，知其然更要知其所以然，才能更加熟练地应用JUnit4。
一、包含必要地Package
在测试类中用到了JUnit4框架，自然要把相应地Package包含进来。最主要地一个Package 就是org.junit.*。把它包含进来之后，绝大部分功能就有了。还有一句话也非常地重要“import static org.junit.Assert.*;”，我们在测试的时候使用的一系列assertEquals方法就来自这个包。大家注意一下，这是一个静态包含（static），是JDK5中新增添的一个功能。也就是说，assertEquals是Assert类中的一系列的静态方法，一般的使用方式是Assert. assertEquals()，但是使用了静态包含后，前面的类名就可以省略了，使用起来更加的方便。
二、测试类的声明
大家注意到，我们的测试类是一个独立的类，没有任何父类。测试类的名字也可以任意命名，没有任何局限性。所以我们不能通过类的声明来判断它是不是一个测试类，它与普通类的区别在于它内部的方法的声明，我们接着会讲到。
三、创建一个待测试的对象。
你要测试哪个类，那么你首先就要创建一个该类的对象。正如上一篇文章中的代码：private static Calculator calculator = new Calculator();
为了测试Calculator类，我们必须创建一个calculator对象。
四、测试方法的声明
在测试类中，并不是每一个方法都是用于测试的，你必须使用“标注”来明确表明哪些是测试方法。“标注”也是JDK5的一个新特性，用在此处非常恰当。我们可以看到，在某些方法的前有@Before、@Test、@Ignore等字样，这些就是标注，以一个“@”作为开头。这些标注都是JUnit4自定义的，熟练掌握这些标注的含义非常重要。
五、编写一个简单的测试方法。
首先，你要在方法的前面使用@Test标注，以表明这是一个测试方法。对于方法的声明也有如下要求：名字可以随便取，没有任何限制，但是返回值必须为void，而且不能有任何参数。如果违反这些规定，会在运行时抛出一个异常。至于方法内该写些什么，那就要看你需要测试些什么了。比如：
@Test
public void testAdd() …{
calculator.add(2);
calculator.add(3);
assertEquals(5, calculator.getResult());
}
我们想测试一下“加法”功能时候正确，就在测试方法中调用几次add函数，初始值为0，先加2，再加3，我们期待的结果应该是5。如果最终实际结果也是5，则说明add方法是正确的，反之说明它是错的。assertEquals(5, calculator.getResult());就是来判断期待结果和实际结果是否相等，第一个参数填写期待结果，第二个参数填写实际结果，也就是通过计算得到的结果。这样写好之后，JUnit会自动进行测试并把测试结果反馈给用户。
六、忽略测试某些尚未完成的方法。
如果你在写程序前做了很好的规划，那么哪些方法是什么功能都应该实现定下来。因此，即使该方法尚未完成，他的具体功能也是确定的，这也就意味着你可以为他编写测试用例。但是，如果你已经把该方法的测试用例写完，但该方法尚未完成，那么测试的时候一定是“失败”。这种失败和真正的失败是有区别的，因此JUnit提供了一种方法来区别他们，那
就是在这种测试函数的前面加上@Ignore标注，这个标注的含义就是“某些方法尚未完成，暂不参与此次测试”。这样的话测试结果就会提示你有几个测试被忽略，而不是失败。一旦你完成了相应函数，只需要把@Ignore标注删去，就可以进行正常的测试。
七、Fixture（暂且翻译为“固定代码段”）
Fixture的含义就是“在某些阶段必然被调用的代码”。比如我们上面的测试，由于只声明了一个Calculator对象，他的初始值是0，但是测试完加法操作后，他的值就不是0了；接下来测试减法操作，就必然要考虑上次加法操作的结果。这绝对是一个很糟糕的设计！我们非常希望每一个测试都是独立的，相互之间没有任何耦合度。因此，我们就很有必要在执行每一个测试之前，对Calculator对象进行一个“复原”操作，以消除其他测试造成的影响。因此，“在任何一个测试执行之前必须执行的代码”就是一个Fixture，我们用@Before 来标注它，如前面例子所示：
@Before
public void setUp() throws Exception …{
calculator.clear();
}
这里不在需要@Test标注，因为这不是一个test，而是一个Fixture。同理，如果“在任何测试执行之后需要进行的收尾工作”也是一个Fixture，使用@After来标注。由于本例比较简单，没有用到此功能。
在Eclipse中使用JUnit4进行单元测试（高级篇）
一、高级Fixture
上一篇文章中我们介绍了两个Fixture标注，分别是@Before和@After，我们来看看他们是否适合完成如下功能：有一个类是负责对大文件（超过500兆）进行读写，他的每一个方法都是对文件进行操作。换句话说，在调用每一个方法之前，我们都要打开一个大文件并读入文件内容，这绝对是一个非常耗费时间的操作。如果我们使用@Before和@After，那么每次测试都要读取一次文件，效率及其低下。这里我们所希望的是在所有测试一开始读一次文件，所有测试结束之后释放文件，而不是每次测试都读文件。JUnit的作者显然也考虑到了这个问题，它给出了@BeforeClass 和@AfterClass两个Fixture来帮我们实现这个功能。从名字上就可以看出，用这两个Fixture标注的函数，只在测试用例初始化时执行
@BeforeClass方法，当所有测试执行完毕之后，执行@AfterClass进行收尾工作。在这里要注意一下，每个测试类只能有一个方法被标注为@BeforeClass 或@AfterClass，并且该方法必须是Public和Static的。
二、限时测试。
还记得我在初级篇中给出的例子吗，那个求平方根的函数有Bug，是个死循环：public void squareRoot(int n) …{
for (;;) ; //Bug : 死循环
}
如果测试的时候遇到死循环，你的脸上绝对不会露出笑容。因此，对于那些逻辑很复杂，循环嵌套比较深的程序，很有可能出现死循环，因此一定要采取一些预防措施。限时测试是一个很好的解决方案。我们给这些测试函数设定一个执行时间，超过了这个时间，他们就会被系统强行终止，并且系统还会向你汇报该函数结束的原因是因为超时，这样你就可以发现这些Bug 了。要实现这一功能，只需要给@Test标注加一个参数即可，代码如下：
@Test(timeout = 1000)
public void squareRoot() …{
calculator.squareRoot(4);
assertEquals(2, calculator.getResult());
}
Timeout参数表明了你要设定的时间，单位为毫秒，因此1000就代表1秒。
三、测试异常
JA V A中的异常处理也是一个重点，因此你经常会编写一些需要抛出异常的函数。那么，如果你觉得一个函数应该抛出异常，但是它没抛出，这算不算Bug呢？这当然是Bug，并JUnit 也考虑到了这一点，来帮助我们找到这种Bug。例如，我们写的计算器类有除法功能，如果除数是一个0，那么必然要抛出“除0异常”。因此，我们很有必要对这些进行测试。代码如下：
@Test(expected = ArithmeticException.class)
public void divideByZero() …{
calculator.divide(0);
}
如上述代码所示，我们需要使用@Test标注的expected属性，将我们要检验的异常传递给他，这样JUnit框架就能自动帮我们检测是否抛出了我们指定的异常。
四、 Runner (运行器)
大家有没有想过这个问题，当你把测试代码提交给JUnit框架后，框架如何来运行你的代码呢？答案就是——Runner。在JUnit中有很多个Runner，他们负责调用你的测试代码，每一个Runner都有各自的特殊功能，你要根据需要选择不同的Runner来运行你的测试代码。可能你会觉得奇怪，前面我们写了那么多测试，并没有明确指定一个Runner啊？这是因为JUnit中有一个默认Runner，如果你没有指定，那么系统自动使用默认Runner来运行你的代码。换句话说，下面两段代码含义是完全一样的：
import org.junit.internal.runners.TestClassRunner;
import org.junit.runner.RunWith;
//使用了系统默认的TestClassRunner，与下面代码完全一样
public class CalculatorTest …{…}
@RunWith(TestClassRunner.class)
public class CalculatorTest …{…}
从上述例子可以看出，要想指定一个Runner，需要使用@RunWith标注，并且把你所指定的Runner作为参数传递给它。另外一个要注意的是，@RunWith是用来修饰类的，而不是用来修饰函数的。只要对一个类指定了Runner，那么这个类中的所有函数都被这个Runner 来调用。最后，不要忘了包含相应的Package哦，上面的例子对这一点写的很清楚了。接下来，我会向你们展示其他Runner的特有功能。
五、参数化测试。
你可能遇到过这样的函数，它的参数有许多特殊值，或者说他的参数分为很多个区域。比如，一个对考试分数进行评价的函数，返回值分别为“优秀，良好，一般，及格，不及格”，因此你在编写测试的时候，至少要写5个测试，把这5中情况都包含了，这确实是一件很麻烦的事情。我们还使用我们先前的例子，测试一下“计算一个数的平方”这个函数，暂且分三类：正数、0、负数。测试代码如下：
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
import static org.junit.Assert.*;
public class AdvancedTest …{
private static Calculator calculator ＝new Calculator();
@Before
public void clearCalculator() …{
calculator.clear();
}
@Test
public void square1() …{
calculator.square(2);
assertEquals(4, calculator.getResult());
}
@Test
public void square2() …{
calculator.square(0);
assertEquals(0, calculator.getResult());
}
@Test
public void square3() …{
calculator.square(-3);
assertEquals(9, calculator.getResult());
}
}
为了简化类似的测试，JUnit4提出了“参数化测试”的概念，只写一个测试函数，把这若干种情况作为参数传递进去，一次性的完成测试。代码如下：
import static org.junit.Assert.assertEquals;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;
import java.util.Arrays;
import java.util.Collection;
@RunWith(Parameterized.class)
public class SquareTest …{
private static Calculator calculator = new Calculator();
private int param;
private int result;
@Parameters
public static Collection data() …{
return Arrays.asList(new Object[][]…{
…{2, 4},
…{0, 0},
…{－3, 9},
});
}
//构造函数，对变量进行初始化
public SquareTest(int param, int result) …{
this.param = param;
this.result = result;
}
@Test
public void square() …{
calculator.square(param);
assertEquals(result, calculator.getResult());
}
}
下面我们对上述代码进行分析。首先，你要为这种测试专门生成一个新的类，而不能与其他测试共用同一个类，此例中我们定义了一个SquareTest类。然后，你要为这个类指定一个Runner，而不能使用默认的Runner了，因为特殊的功能要用特殊的Runner嘛。
@RunWith(Parameterized.class)这条语句就是为这个类指定了一个ParameterizedRunner。第二步，定义一个待测试的类，并且定义两个变量，一个用于存放参数，一个用于存放期待的结果。接下来，定义测试数据的集合，也就是上述的data()方法，该方法可以任意命名，但是必须使用@Parameters标注进行修饰。这个方法的框架就不予解释了，大家只需要注意其中的数据，是一个二维数组，数据两两一组，每组中的这两个数据，一个是参数，一个是你预期的结果。比如我们的第一组{2, 4}，2就是参数，4就是预期的结果。这两个数据的顺序无所谓，谁前谁后都可以。之后是构造函数，其功能就是对先前定义的两个参数进行初始化。在这里你可要注意一下参数的顺序了，要和上面的数据集合的顺序保持一致。如果前面的顺序是{参数，期待的结果}，那么你构造函数的顺序也要是“构造函数(参数，期待的结果)”，反之亦然。最后就是写一个简单的测试例了，和前面介绍过的写法完全一样，在此就不多说。
六、打包测试。
通过前面的介绍我们可以感觉到，在一个项目中，只写一个测试类是不可能的，我们会写出很多很多个测试类。可是这些测试类必须一个一个的执行，也是比较麻烦的事情。鉴于此，JUnit为我们提供了打包测试的功能，将所有需要运行的测试类集中起来，一次性的运行完毕，大大的方便了我们的测试工作。具体代码如下：
import org.junit.runner.RunWith;
import org.junit.runners.Suite;
@RunWith(Suite.class)
@Suite.SuiteClasses(…{CalculatorTest.class, SquareTest.class})
public class AllCalculatorTests …{}
大家可以看到，这个功能也需要使用一个特殊的Runner，因此我们需要向@RunWith标注传递一个参数Suite.class。同时，我们还需要另外一个标注@Suite.SuiteClasses，来表明这个类是一个打包测试类。我们把需要打包的类作为参数传递给该标注就可以了。有了这两个
标注之后，就已经完整的表达了所有的含义，因此下面的类已经无关紧要，随便起一个类名，内容全部为空既可。
实验报告五 课程名称：软件测试 学生姓名：董月 班级：浦计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; } }
如何编写单元测试用例（白盒测试）。 一、单元测试的概念 单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。 测试的覆盖种类 1.语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。 2.判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。 3.条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。 4.判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。 5.条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。 6.路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。 用例的设计方案主要的有下面几种：条件测试，基本路径测试，循环测试。通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。 二、开始测试前的准备
在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。穷举测试是不可能的。所以现在进行单元测试我选用的是现在一般用的比较多的基本路径测试法。 三、开始测试 基本路径测试法：设计出的测试用例要保证每一个基本独立路径至少要执行一次。 函数说明：当i_flag=0；返回 i_count+100 当i_flag=1；返回 i_count *10 否则返回 i_count *20 输入参数：int i_count ， int i_flag 输出参数： int i_return; 代码： 1int Test(int i_count, int i_flag) 2 {
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进行单元测试 首先新建一个项目叫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”来运行我们的测试，如下图所示： 运行结果如下：
测试方案模板 Edit by LJ. 1 概述 1.1 编写目的 [说明编写本测试方案的目的是为软件开发项目管理者、软件工程师、系统维护工程师、测试工程师提供关于**系统整体系统功能和性能的测试指导。] 1.2 读者对象 [本测试方案可能的合法读者对象为软件开发项目管理者、软件工程师、测试组、系统维护工程师] 1.3 项目背景 [可以如下那样简单说明，根据项目的具体情况，方案编写者也可以进行详细说明 项目名称：*** 简称：*** 项目代号：*** 委托单位：*** 开发单位：*** 主管部分：***] 1.4 测试目标 [说明进行项目测试的目标或所要达到的目的] 1.5 参考资料 [列出编写本测试方案时参考的资料和文献]
2 测试配置要求 2.1 网络环境 [在此说明应用系统的网络环境，如果应用系统是网络版的，必须具有本节内容。] 2.1.1 网络硬件 [此处给出网络硬件的拓扑图、名称、规格、数量、配置等信息。] 2.1.2 网络软件 [此处给出网络软件的名称、协议、通讯和连接方式等信息。] 2.2 服务器环境 2.2.1 服务器硬件 [此处给出服务器硬件的名称、规格、数量、配置等信息。] 2.2.2 服务器软件 [此处给出服务器软件名称、协议和版本等信息。] 2.3 工作站环境 2.3.1 工作站硬件 [此处给出工作站硬件的拓扑图、名称、规格、数量、配置等信息。] 2.3.2 工作站软件 [此处给出工作站软件的名称、协议和版本等信息。] 2.4 测试手段 [在此参照《测试计划》说明测试方法和工具，注明执行测试时，必须同时填写《测试记录表》]
2.5 测试数据 [在此简要说明测试数据的形成，如以客户单位具体的业务规则和《***系统需求分析说明书》，参考《***系统概要设计说明书》、《***系统详细设计说明书》和《数据规格说明书》中规定的运行限制，设计测试用例，作为整个**系统的测试数据。] 2.6 测试策略 [在此说明测试策略，可以如下这样说明： 测试过程按三个步骤进行，即单元测试、组装、系统测试，根据不同阶段测试的侧重点不同，分别介绍测试策略： A）单元测试 首先按照系统、子系统和模块进行划分，但最终的单元必须是功能模块，或面向对象过程中的若干个类。单元测试是对功能模块进行正确检验的测试工作，也是后续测试的基础。目的是在于发现各模块内部可能存在的各种差错，因此需要从程序的内部结构出发设计测试用例，着重考虑以下五个方面： 1）模块接口：对所测模块的数据流进行测试。 2）局部数据结构：检查不正确或不一致的数据类型说明、使用尚未附值或尚未初始化的变量、错误的初始值或缺省值。 3）路径：虽然不可能做到穷举测试，但要设计测试用例查找由于不正确的计算（包括算法错、表达式符号表示不正确、运算精度不够等）、不正确的比较或不正常的控制流（包括不同数据类型量的相互比较、不适当地修改了循环变量、错误的或不可能的循环终止条件等）而导致的错误。 4）错误处理：检查模块有没有对预见错误的条件设计比较完善的错误处理功能，保证其逻辑上的正确性。 5）边界：注意设计数据流、控制流中刚好等于、大于或小于确定的比较值的用例。 B）集成测试 集成测试也叫组装测试或联合测试。通常，在单元测试的基础上需要将所有的模块按照设计要求组装成系统，这时需要考虑的问题： 1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失。
JUnit in java单元测试用例实战 单元测试基础 当今软件测试十分盛行时，本人通过项目实践和个人亲身体会浅谈单元测试，本人一直坚持“用代码说话的原则”，同时也希望个人能给出宝贵意见，共同探讨、共同进步，为中国软件事业有更大的发展共同奋斗! 最早我们项目组开发的项目时，写代码都是从底层一直写到表现层到jsp，然后开发人员在web层调试页面，近乎98%都会报一大堆exception,然后再在代码中加断点一步一步查到底哪一层代码出现问题……,比较好点做法就是在各个类中加上main方法测试，但总体很不理想，给web层开发人员的调试和质量控制人员带来繁重的工作压力;使用单元测试后，针对每一个方法都做严格的把关，大大减少调试的时间;同时质量控制人员返回过来的bug 少了近60%，现在对于开发人员写测试用例非常熟练，并且本人根据实际情况对测试用例做了点小小改动(这部分主要在后面代码中详述)，带来很好的效果! 单元测试到底给实际开发带来什么好处那? (1)首先对于开发人员来说大大减少调试工作的时间，同时也规范了对于代码安全管理(我们知道那些方法是可以调用的); (2)对于整个项目来说，有了完整的测试，保证项目最后交付测试有了可靠依据; (3)对于测试人员大大减少bug的反馈; (4)对于项目经理整个项目达到很好的可控; (5)最主要的完整的单元测试给后期维护人员带来很大的便捷! 单元测试好处可能还有很多，但本人只能理解和感悟这么多,希望观者补充! 单元测试配置： 将使用eclipse+myEclopse给大家介绍关于JUNIT的环境的简单配置;右键点击项目选择“属性”，在弹出窗口中到环境变量中添加junit.jar包，这样下一步我们就可以进行单元测试了;
讨论用TestDirector管理测试用例 编制时间:2007-03-16 编制部门:测试组 编制人:郭宏元 “测试用例”虽有国标作蓝本，但实际中，一直以来“测试用例”是所有测试人员有争议的地方，此所谓“仁者见仁，智者见智”。而“法无定法，则无定则”，所有的规范与标准都是围绕更适应人们的工作环境而创建。在此，我就我的一些体会在此与大家分享。 一般来说，“测试用例”的编写主要分三大类，贯彻的原则与基本架构如下： 分类： 1、对验证过程的一个记录； 2、展现一个功能； 3、描述一个场景步骤； 原则： 1、有“对象”属性的描述； 2、阐述了某个“对象”的方法或事件。 3、对属性、方法或事件有详细的定义。 基本架构： 1、目的； 2、前提条件； 3、输入步骤（输入动作或数据，预期结果） 以下总结了一些针对测试用例的“编写要点”作出一些较简单的规范。以方便统一测试用例的编写，并保证使用最用效的测试用例来保证测试质量。我们都知道根据详细设计文档编写测试用例的目的不在于验证软件达到的功能，而在于验证软件应该达到的功能，这样可以去除软件开发过程中的随意性。所以下面就明确测试用例的“目的”、“范围”、“原则”是什么？以及采用的方法做了一点描述。 1、目的： 围绕测试名称或满足实现测试功能而进行。 2、范围：
适用于所要测试的质检项目。 3、功能测试用例编写原则 3.1单元测试功能用例的编写目的 单元测试用例的目的在于验证单个模块是否达到了详细设计说明书中规定的功能，由于是单个模块所以无法检验关联性，可能会牵扯到数据库的操作，例如：删除时，需要查看数据库是否完全删除了数据。 3.2集成测试功能用例的编写目的 集成测试功能用例的目的在于验证软件连接时，模块的连接是否正确（及数据的传递是否正确）。.我们的软件中体现出来的是，是否正确调用界面，界面之间显示的数据是否正确，特别是财务、费用、数据方面的。 集成测试用例的编写过程中，经常将功能用例与业务流程混合编写，因为在集成测试时需验证业务流程中的数据正确性，以及界面之间的数据传递的准确无误。 3.3系统测试业务流程用例的编写目的 系统测试业务流程用例的目的在于验证软件最终数据的准确性，我们的软件体现为，手工数据与报表数据的一直性。用例与用例之间有着一定的关系，目的性十分明确。 4、测试用例设计的原则 4.1全面性 指编写的测试用例应该覆盖所有的“概要设计文档”或“需求文档”以及“测试申请文档”中描述的功能。 4.1.1数据库程序基本的增、删、改功能 增、改测试用例重点在于数据合法性、正确性的检验和提示信息的正确性的检验。输入的数据可能有无限种组合，此时可以采用等价类划分和边界值法，下面有较详细的说明。 删除的测试用例比较简单，只有操作没有数据的输入，但是应该在“备注”中注明，删除的限制条件，以及数据库中应该删除的表的情况，有条件限制时，测试用例应该包含各种删除条件，必要时在添加或修改的测试用例后面或中间紧跟删除的测试用例。 4.1.2对于无输入的操作，应该详细描述其具体的操作步骤和结果
酒店管理系统+单元测试用例 客房预订系统测试用例 测试编号设计者1测试需求项客房预订测试需求标号设计日期001 2008. 9. 4测试目标状态和测完成散客预订、团体预订、客房预订、预订未到处理、预售查询等项功能试数据状态 测试项输入说明（操作）输出说明（预期结果）序号 姓名性别预付押金付款方式入住 1类型证件类型和号码地址联系电话酒店个人押金凭证散客预订 预订入住日期和预离日期 主宾姓名主宾性别预付押金付款方 式入住类型证件类型和号码地址2酒店团体押金凭证团体预订联系电话 预定入住日期和预离日期 主客房间宾客人数 3客房预订根据用户需求预订房间宾客预订信息 预订未到处注销预定信息输出注销成功4理 当前时间酒店预售一览表可售房间数以及某房间的5预售查询预订情况前台接待系统测试用例 测试编号设计者2测试需求项前台接待测试需求标号设计日期002 2008. 9. 4测试LI标状态和测完成散客入住登记、合约入住、团体自动入住和手动入住、补填客单、修改客人信息、试数据状态预订客房查询、可售房间查询等项功能 测试项输入说明（操作）输出说明（预期结果）序号
姓名性别预付押金付款方式入住散客入住登6类型证件类型和号码地址联系电话客人相关信息记入住日期和预离日期 姓名性别证件号预订入住时间期限7客人相关信息合约入住预离时间 姓名性别预付押金付款方式入住类 团体自动入型证件类型和号码地址联系电话8住和手动入团体入住相关信息入住日期和预离日期宾客人数入住住 方式 9填补客单输入用户信息修改后的用户信息 修改客人信10姓名性别证件号所需修改信息显示修改后客户信息息 预订客房查11姓名性别证件号显示预订相关信息或者是无结果询 可售房间查12当前时间空闲房间号询 前台收银系统测试用例 测试编号设计者3测试需求项前台收银测试需求标号设计日期003 2008. 9. 4测试口标状态和测完成记帐查帐转帐个人或团体埋单限制客人消费等项功能试数据状态 序号测试项输入说明（操作）输出说明（预期结果） 记帐查帐13姓名性别证件号当前消费转帐 14酒店消费清单埋单姓名性别证件号 帐务系统测试用例 测试编号设讣者4测试需求项帐务管理测试需求标号设计日期004 2008. 9.4 测试LI标状态和测具备收银功能外，设置纠错报表输出等项功能试数据状态测试项输入说明（操作）输出说明（预期结果）序号
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提醒着。
酒店管理系统 测试用例 姓名：王运飞 学号：08111423 文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改文件标 识： 东华理工大学-酒店管理系统-测试报 告 当前版 本： 2.0 作 者： 王运飞 完成日 期： 2010-10-26 版本/状态作者参与者起止日期备注 1.0 王运 飞 王运飞 2.0 王运 飞王运飞修复了一下bug，程序运 行更加稳定了
目录
0文档介绍 0.1 文档目的 该测试文档实现的目的为，给所有测试用例的说明提供测试方法步骤，同时为进一步开放测试脚本提供依据。 0.2 文档范围 本文档为酒店管理系统，其中包含了酒店订餐，消费方式，现金或刷卡，打折优惠，等基本功能的测试用例。 0.3 读者对象 本文档面向的对象主要有两类，一是测试人员，另一类是开发人员。 0.4 参考文献 《酒店管理系统软件规格需求说明书》 0.5 术语与缩写解释 缩写、术语解释 订餐提前向餐厅预订餐饭，有可能需要交一部分费用 结账就餐后支付就餐费，须向客户开发票 刷卡就餐后使用银行卡支付餐费 包厢顾客单独在一间房子内就餐 1. 接口－路径测试用例 1.1 被测试对象（单元）的介绍 测试对象这里测试对象主要是该软件所实现的几个功能，也可称为接口，这里主要接口有顾客订餐，顾客就餐后刷卡支付餐费，顾客预订包厢，顾
客结账。 1.2 测试范围与目的 测试目的通过测试了解各个接口的正确性，比如顾客能否顺利的订到餐饭，能否联网刷卡，能否订到包厢。 1.3 接口测试用例 接口订餐函数原型 输入/动作期望的输出/相应实际情况 典型值…餐位充足可以订餐成功 边界值…餐位紧张订餐成功或失败成功或失败 异常值…餐位不足订餐失败失败 接口刷卡函数原型 输入/动作期望的输出/相应实际情况 典型值…卡内余额足够刷卡成功成功 边界值…卡内余额不多刷卡成功或失败成功或失败 异常值…卡内余额不够刷卡失败失败 … 接口包厢函数原型 输入/动作期望的输出/相应实际情况 典型值…包厢充足可以预定包厢成功 边界值…包厢较少预订成功或失败成功或失败 异常值…包厢紧张失败失败 … 1.4 路径测试的检查表 检查项结论 数据类型问题 （１）变量的数据类型有错误吗？（２）存在不同数据类型的赋值吗？（３）存在不同数据类型的比较吗？没有不存在不存在 变量值问题 （１）变量的初始化或缺省值有错误吗？没有没有
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;
软件测试中如何编写单元测试用例（白盒测试） 测试用例（T est Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 测试用例（T est Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。 不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。 随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。 要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。 既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。 确定测试用例之所以很重要，原因有以下几方面。 测试用例构成了设计和制定测试过程的基础。测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成95 % 的测试”更有意义。测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。测试设计和开发的类型以及所需的资源主要都受控于测试用例。测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例：·一个测试用例用于证明该需求已经满足，通常称作正面测试用例；·另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。 前段时间公司进行有关测试的培训，集成测试，性能测试，压力测试说了很多。由于本人还处于Coder阶段，只是对单元测试有了些了解。写下来怕以后自己忘记了。都是些自己的看法，不一定准确，欢迎高手指教。 一、单元测试的概念 单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用
一、概述 (1) 二、基本概念 (1) 2.1正面测试（Positive Testing） (1) 2.2负面测试（Negative Testing） (2) 2.3分支测试 (2) 2.4黑盒测试 (2) 2.5白盒测试 (2) 三、单元测试范围 (3) 四、常见测试用例设计方法及举例 (3) 4.1 用于语句覆盖的基路径法 (3) 4.2 用于MC/DC的真值表法 (9) 4.3 边界值法 (11) 4.4 等价类法 (12) 4.5循环测试法 (17) 4.6错误推测法 (18) 五、相关注意事项 (18) 5.1独立性 (18) 5.2尽量脱离被测代码的束缚 (18)
5.3面向对象的语言单元测试特点 (18) 5.4单元测试的命名标准 (19) 1.单元测试的命名标准 (19) 2.单元测试中的变量命名规范 (19) 3.断言和操作分离 (19) 4.避免滥用setup和teardown (19)
一、概述 单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。该文档从测试角度出发，去讨论如何设计单元测试的测试用例。 这里强调，单元测试用例的设计是进入实际编码之前的，测试用例设计在前，更能体现出灵活性，如果已经编码完成再进行测试用例的补充，这样很容易进入一个仅仅是测试了被测代码段功能的怪圈，所以希望所有的单元测试工作，可以放在前面完成。同时单元测试用例是一个不断完善的过程，前期设计好的用例，在代码已经实现完成后，会发现覆盖的并不是很全面，有良好的习惯是需要将对应的测试用例进行补充，而在提交测试后发现的重要的bug，也需要进行单元测试用例的补充，使单元测试和各种测试方法相结合，实现测试质量的充分保证。 二、基本概念 2.1正面测试（Positive Testing） 测试被测对象的正确功能实现无误，即正常流程功能。往往需要根据设计说明进行用例导出，严格按照设计说明编写即可，用例划分注意等价类区分等方法。 例如：接口返回小于等于24个中文字的offer标题（这里标题控制不
单元测试(JUnit)的应用 一．概要 单元测试不仅仅是保证代码在方法级别的正确性，它还能改进设计，易于对代码重构。凡是容易编写单元测试的代码，往往是优秀的设计和松耦合的组件，凡是难于编写单元测试的代码，往往是设计不佳和耦合度高的系统，因此，编写单元测试不仅仅是掌握单元测试柜架的用法，更重要的是在编写单元测试的过程中发现设计缺陷，改进系统结构，从而实现良好的可扩展性。 任何一个项目，单元测试应该在详细设计之后开始进行，首先根据详细设计文档进行单元测试用例的编写，编写完成后进行代码开发，代码完成后运行单元测试，如果通过，则该方法可以发布运行，如果不通过需要进行代码改造，再进行单元测试，直到单元测试运行通过为止。 每新增一个功能时的开发流程如图1所示： 编写测试用例 编写代码 完成 对代码做小的修改 运行测试通过失败 图1 本文首先按照上图所示流程进行一个简单功能的开发，同时使用JUnit 4 提供的
各种功能开展有效的单元测试，接着对JUnit技术进行了简单的介绍。 二．软件支持 Eclipse：最为流行的 IDE，它全面集成了 JUnit，并从版本 3.2 开始支持 JUnit 4。当然 JUnit 并不依赖于任何 IDE。您可以从https://www.doczj.com/doc/ef13565420.html,/上下载最新的 Eclipse 版本。 Ant：基于 Java 的开源构建工具，您可以在https://www.doczj.com/doc/ef13565420.html,/上得到最新的版本和丰富的文档。Eclipse 中已经集成了 Ant。 JUnit：它的官方网站是https://www.doczj.com/doc/ef13565420.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”按钮。
常见的测试用例设计方法都有哪些 常见的测试用例设计方法都有哪些？ 请分别以具体的例子来说明这些方 法在测试用例设计工作中的应用。 1. 等价类划分常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并 合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2. 边界值分析法边界值分析方法是对等价类划 分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入
输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3. 错误推测法基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0 的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例. 4. 因果图方法前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查
学生信息管理系统单元测试报告 [二零一零年十二月二日]
1编写目的 1.1为了保证学生信息管理系统的各项功能可靠的实现，特编写了此测试计划，对所开发软件的各功能模块和事例进行测试。 1.2学会使用简单的单元测试工具，对系统模块进行测试分析，并编写测试用例。 1.3为软件单元的评审验收提供依据. 2．单元模块概述 2.1功能需求分析 本系统由系统用户管理、学生管理、班级信息管理、课程设置和成绩管理几个模块组成。 2.1.1 系统用户管理模块 系统用户管理模块主要是对用户信息的管理，它包括用户登录、添加用户、修改用户密码。 2.1.1.1 用户登录 用户的登录限于已注册的用户，只有已注册的用户才能登录系统。其实现过程： 输入：用户名（用于登录账号）； 输入：密码。 点击：登录按钮。 处理：1）输入信息的合法性。 2）操作成功，登录系统。否则，给出出错提示。 输出：登录成功或者登录失败的提示。 2.1.1.2 添加用户信息 增加一个新的用户。其实现过程如下： 输入：用户名（用于登录帐号），姓名，密码，权限。 处理：1）数据有效性检验。 2）将用户信息保存到数据库对应的数据表中 3）操作成功，给出成功提示，否则给出出错提示。 输出：操作结果。成功给予成功提示，失败给予失败提示，并且给出失败原因。 2.1.1.3 修改用户密码 修改密码用于用户对自己的密码进行修改。 输入：旧密码，新密码，确认密码 处理：1）输入数据有效性的验证，密码长度为6-20。 2）判断新密码与确认密码是否相同，如果不相同，给出出错提示。 3）新密码与确认密码相同，判断旧密码是否正确，如果不正确给出出错提示。 4）新密码与确认密码相同，旧密码正确，用新密码替换原来旧密码。操作成功，给出成功提示，否则给出出错信息。 输出：操作成功，系统提示密码修改成功，反之，系统提示密码修改错误，显示失败的原因
项目名称 测试用例 Radfort Corp. - 深圳市瑞福特信息技术有限公司 - https://www.doczj.com/doc/ef13565420.html, ?1999~2005 - 版权所有 - All Rights Reserved
版本历史
目录 0. 文档介绍 (4) 0.1文档目的 (4) 0.2文档范围 (4) 0.4参考文献 (4) 0.5术语与缩写解释 (4) 1.单元测试用例 (4) 1.1被测试对象的介绍 (4) 1.2测试范围与目的 (5) 1.3测试环境与测试辅助工具的描述 (5) 1.4测试驱动和桩程序的设计 (5) 1.5单元测试用例 (5)
0. 文档介绍 0.1 文档目的 提示：通过制定《××××测试用例》可以令软件测试的实施重点突出、目的明确。同时，在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。 指明读者对象等 0.2 文档范围 提示：阐明本测试用例所涉及到的项目、阶段以及测试类型等 0.4 参考文献 提示：[AAA]作者，《立项建议书》，机构名称，日期 [SPP-PROC-ST] SEPG，系统测试规范，机构名称，日期 0.5 术语与缩写解释 1.单元测试用例 1.1 被测试对象的介绍 提示：本次测试所所包含的内容，要给出以下内容： 被测试的文件列表；类图；类的主要功能简介
1.2 测试范围与目的 提示：根据详细设计说明书，并在开发组内进行充分的交流后对单元测试的目的清晰，与相应的用例联系起来，列出各个单元和测试用例间的关联关系，以方便检视测试用例是否已经覆盖详细设计规格说明书中定义的所有功能。 1.3 测试环境与测试辅助工具的描述 提示：被测项目的关键桩设计（程序和全局变量等）、使用的测试工具等 1.4 测试驱动和桩程序的设计 给出手工写的桩列表，及主要实现功能 1.5单元测试用例
软件单元测试及测试用例设计 [摘要]单元测试是针对各功能模块的进行测试，进行充分的单元测试，是提高软件质量，降低研发成本的必由之路。文章对软件测试和单元测试相关概念做了简要说明，以用户注册模块出生年月日的检验为例，说明了用例设计的过程。 【关键词】软件测试；单元测试；用例；等价类 1.软件测试 软件测试是指利用相关测试工具，按照一定的测试方案和流程对软件系统的功能和性能进行测试，对可能出现的问题进行分析、评估，发现开发错误并跟踪，以确保所开发的软件满足用户需求。软件测试是保证软件质量的主要手段，是根据软件开发各阶段的规则说明和程序内部结构而精心设计的一批测试用例，并利用这些测试用例运行程序以发现软件是否存在错误的过程，软件测试的范围应当包括更广泛些，除了考虑正确性外，还应关心程序的效率、健壮性等因素。 软件测试过程包含单元测试、集成测试、确认测试和系统测试四个步骤： （1）单元测试：对每一个程序单元进行独立测试，检查各程序模块是否正确地实现了预定的功能。 （2）集成测试：把已通过测试的模块组装起来，对软件体系构造的正确性进行测试。 （3）确认测试：检查已完成的软件系统是否已满足了需求规格说明中的各项需求，软件配置是否完全、正确。 （4）系统测试：将经过确认的软件系统置入实际的运行环境中，与其它系统成份结合在一起进行测试。 2.单元测试 单元测试又称模块测试，是以软件系统设计的最小单位——程序模块为对象，进行正确性检验的测试工作。单元测试常被看作编码的附属品，在代码被开发、编译调试、审查后，单元测试用例设计便开始了。进行充分的单元测试，是提高软件质量，降低研发成本的必由之路。几乎所有的开发人员都会对每一段代码做一定程度的单元测试。如果一个模块要完成多项功能，可以将该模块看成由几个小程序组成，对每个小程序分别进行单元测试。如果是关键模块，往往还要做性能测试。 单元测试以详细设计说明书和源程序清单为依据，常采用白盒测试的用例，辅之以黑盒测试的用例，以寻找模块内部可能存在的错误为目的，主要完成模块