前段时间，在项目组里做了一点java的测试用例，虽然没有全自动化，也完成了半自动化的测试。比如：针对接口的测试，提供服务的测试等，都不需要启动服务，也不需要接口准备好。我们只需要知道输入输出，便可以进行testcase的编写，这样很方便。我们这边这次完成的针对某一块业务。
看一下一部分的完成情况
这次的主要目的还是来讲TestCase
那什么是TestCase？
是为了系统地测试一个功能而由测试工程师写下的文档或脚本；
具体到junit.framework. TestCase这个抽象类
其实网上有很多关于这方面的帖子，博客之类的，大家也可以找找，学习学习。毕竟我这里的理解还是很肤浅的
那第二点，为什么需要编写测试用例？
通俗易懂一点：写的目的就是为了记录，并加以完善，因为测试一个功能往往不是走一遍就OK的，需要反复的改，反复的测，直到功能可以提交给客户。
深度提炼一点：
1） 测试用例被认为是要交付给顾客的产品的一部分。测试用例在这里充当了提高可信度的作用。典型的是UAT（可接受）级别。
2） 测试用例只作为内部使用。典型的是系统级别的测试。在这里测试效率是目的。在代码尚未完成时，我们基于设计编写测试用例，以便一旦代码准备好了，我们就可以很快地测试产品。
具体的参考：http://www.51testing.com/html/41/n-44641.html
深入的也不多说，网上这种东西很多。
正题：
使用JUnit时，主要都是通过继承TestCase类别来撰写测试用例，使用testXXX()名称来撰写单元测试。
用JUnit写测试真正所需要的就三件事：
1． 一个import语句引入所有junit.framework.*下的类。
2． 一个extends语句让你的类从TestCase继承。
3． 一个调用super(string)的构造函数。
下面可以看一下TestCase的文档介绍里的Example
1.构建一个测试类
public class MathTest extends TestCase {
protected double fValue1;
protected double fValue2;
protected void setUp() {
fValue1= 2.0;
fValue2= 3.0;
}
}
2.一个Test方法以及断言使用
public void testAdd() {
double result= fValue1 + fValue2;
assertTrue(result == 5.0);
}
3.运行单个方法的使用
TestCase test= new MathTest("add") {
public void runTest() {
testAdd();
}
};
test.run();
或者
TestCase test= new MathTest("testAdd");
test.run();
4.运行一组测试用例
public static Test suite() {
suite.addTest(new MathTest("testAdd"));
suite.addTest(new MathTest("testDividByZero"));
return suite;
}
还有下面这种方式
public static Test suite() {
TestSuite suite = new TestSuite("Running all tests.");
/*10000*/
suite.addTestSuite(TestAgentApi.class);
/*10001*/
suite.addTestSuite(TestAgentUxxApi.class);
}
运行6个，5个没有通过，一目了然。
setUp和tearDown
|
/** * Sets up the fixture, for example, open a network connection. * This method is called before a test is executed. */ protected void setUp() throws Exception { } /** * Tears down the fixture, for example, close a network connection. * This method is called after a test is executed. */ protected void tearDown() throws Exception { } |
对于重复出现在各个单元测试中的运行环境，可以集中加以管理，可以在继承TestCase之后，重新定义setUp()与tearDown()方法，将数个单元测试所需要的运行环境在setUp()中创建，并在tearDown()中销毁。
Junit提供的种种断言
JUnit提供了一些辅助函数，用于帮助你确定某个被测试函数是否工作正常。通常而言，我们把所有这些函数统称为断言。断言是单元测试最基本的组成部分。
方法：
assertEquals-期望值与实际值是否相等
assertFalse-布尔值判断
assertTrue-布尔值判断
assertNull-对象空判断
assertNotNull-对象不为空判断
assertSame-对象同一实例判断
assertNotSame-检查两个对象是否不为同一实例
fail-使测试立即失败
Junit和异常
1．从测试代码抛出的可预测异常。
2．由于某个模块（或代码）发生严重错误，而抛出的不可预测异常。
这两点的异常是我们比较关心的。下面展示一种情况：对于方法中每个被期望的异常，都应写一个专门的测试来确认该方法在应该抛出异常的时候确实会抛出异常。图展示的是抛出异常才通过，不抛出异常，case不通过。
如图
异常情况如下：
对于处于出乎意料的异常，我们最好简单的改变我们的测试方法的声明让它能抛出可能的异常。JUnit框架可以捕获任何异常，并且把它报告为一个错误，这些都不需要你的参与。
回顾一下如何使用Junit
JUnit的使用非常简单，共有3步：
第一步、编写测试类，使其继承TestCase；
第二步、编写测试方法，使用testXXX的方式来命名测试方法；
第三步、编写断言。
如果测试方法有公用的变量等需要初始化和销毁，则可以使用setUp,tearDown方法。
最新内容请见作者的GitHub页：http://qaseven.github.io/