如何编写单元测试用例
一、 单元测试的概念
单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。
测试的覆盖种类
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;
代码：
1 int Test(int i_count, int i_flag)
2 {
3 int i_temp = 0;
4 while (i_count》0)
5 {
6 if (0 == i_flag)
7 {
8 i_temp = i_count + 100;
9 break;
10 }
11 else
12 {
13 if (1 == i_flag)
14 {
15 i_temp = i_temp + 10;
16 }
17 else
18 {
19 i_temp = i_temp + 20;
20 }
21 }
22 i_count--;
23 }
21 }
22 i_count--;
23 }
24 return i_temp;
25 }
1.画出程序控制流程图
圈中的数字代表的是语句的行号，也许有人问为什么选4,6,13,8......作为结点，第2行，第3行为什么不是结点，因为选择结点是有规律的。让我们看程序中；第2行，第3行是按顺序执行下来的。直到第4行才出现了循环操作。而2，3行没有什么判断，选择等分支操作，所以我们把2，3，4全部合并成一个结点。其他的也是照这个规则合并，然后就有了上面的流程图。
2.计算圈复杂度
有了图以后我们要知道到底我们有写多少个测试用例，才能满足基本路径测试。
这里有有了一个新概念——圈复杂度
圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。将该度量用于计算程序的基本独立路径数目。为确保所有语句至少执行一次的测试数量的上界。
公式圈复杂度V（G）=E+N+2，E是流图中边的数量，N是流图中结点的数量。
公式圈复杂度V（G）=P+1 ，P是流图G中判定结点的数量。
通俗的说圈负责度就是判断单元是不是复杂，是不是好测试的标准。一般来说如果圈复杂度如果大于20就表示这个单元的可测试性不好，太复杂（也许有人觉得无所谓，但是如果你们公司实行了CMMI5的话，对这个是有规定的）。
从图中我们可以看到，
V（G）=10条边-8结点+2=4
V（G）=3个判定结点+1=4
上图的圈复杂图是4。这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。
3.导出程序基本路径。
3.导出程序基本路径。
现在我们知道了起码要写4个测试用例，但是怎么设计这4个测试用例？
导出程序基本路径，根据程序基本路径设计测试用例子。
程序基本路径：基本独立路径就是从程序的开始结点到结束可以选择任何的路径遍历，但是每条路径至少应该包含一条已定义路径不曾用到的边。（看起来不好理解，让我们看例子）。
让我们看上面的流程图：从结点4到24有几条路径呢？
1 B（4，24）
2 C，E，J（4，6，8，24）
3 C，D，F，H，A，B（4，6，13，15，22，4，24）
4 C，D，G，I，A，B（4，6，13，19，22，4，24）
还有吗？？
5 C，D，C，I，A，C，E，J（4，6，13，19，22，4，6，8，24）算吗？
不算，为什么？因为上面的4条路径已经包括了所有的边。第5条路径已经不包含没有用过的边了。所有的路径都遍历过了。
好了，现在我们有了4条基本独立路径根据独立路径我们可以设计测试用例。
1 B（4，24）
输入数据：i_flag=0，或者是i_flag《0的某一个值。
预期结果：i_temp=0.
2 C，E，J（4，6，8，24）
输入数据： i_count =1; i_flag=0
预期结果：i_temp=101.
3 C，D，F，H，A，B（4，6，13，15，22，4，24）
输入数据： i_count =1; i_flag=1
预期结果：i_temp=10.
4 C，D，G，I，A，B（4，6，13，19，22，4，24）
输入数据： i_count =1; i_flag=2
预期结果：i_temp=20.
这里的输入数据是有路径和程序推论出来的。而要注意的是预期结果是从函数说明中导出，不能根据程序结构中导出。
为什么这么说？
让我们看程序中的第3行。
int i_temp=0; 假如开发人员一不小心写错了，变成了int i_temp=1; 根据程序导出的预期结果就会是一个错误的值，但是单元测试不出来问题，那单元测试就失去了意义。
有人也许会问这么简单的函数就有4个测试用例，如果还复杂一些的怎么办？上面的测试用例还可以简化吗？答案是可以。
我们来看 路径 1 B（4，24）和 4 C，D，G，I，A，B（4，6，13，19，22，4，24），路径1是路径4的真子集， 所以1是可以不必要的。上图的圈复杂度是4。这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。所以说圈复杂度标示是最多的测试用例个数，不是一定要4个测试用例才可以。不过有一点要申明的是测试用例越简化代表你的测试越少，这样程序的安全性就越低了。
四、完成测试
接下来根据测试用例使用工具测试NUNIT，VS2005都可以。
接下来根据测试结果编写测试报告，测试人，时间，结果，用例，是否通过，格式网上一大把，每个公司的格式也不一样就不说了。
如何使用junit4写单元测试用例
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个测试被忽略，一个测试失败”
测试用例是什么它是由哪些基本元素组成的
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测
测试用例组成元素
(1) 用例ID；
(2) 用例名称；
(3) 测试目的；
(4) 测试级别；
(5) 参考信息；
(6) 测试环境；
(7) 前提条件；
(8) 测试步骤；
(9) 预期结果；
(10) 设计人员。
测试用例（Test Case）是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一，不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不同的趋势。
-单元测试用例模板
要使最终用户对软件感到满意，最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。-测试用例
既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。
(参考信息：百度百科)
