java测试用例怎么写( 二 ) _测试

4、熟悉系统，对编写测试用例很有帮助。
5、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。
4. 怎么给javaWeb项目写测试用例文件名：Calutor.java
package com.sc.zy;
public class Calutor {
public int add(int num1,int num2){
return num1+num2;
}
public int sub(int num1,int num2){
return num1-num2;
}
public int mul(int num1,int num2){
return num1*num2;
}
public int div(int num1,int num2){
if(num2==0){
throw new MyException();
}
return num1/num2;
}
}
文件名：MyException.Java
package com.sc.zy;
public class MyException extends RuntimeException {
}
文件名：CalutorTest.java
package com.sc.zy;
import junit.framework.Assert;
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Ignore;
import org.junit.Test;
public class CalutorTest {
private Calutor c;
@BeforeClass
public static void setUpBeforeClass(){
System.out.println("=====static init=======");
}
@AfterClass
public static void tearDownAfterClass(){
System.out.println("=====static destory=======");
}
@Before
public void setUp(){
System.out.println("[email protected]=======");
c=new Calutor();
}
@After
public void tearDown(){
System.out.println("[email protected]=======");
}
@Test
public void testAdd(){
int sum=c.add(1, 2);
Assert.assertEquals(3, sum);
}
@Test(expected=com.sc.zy.MyException.class)
public void testDiv(){
c.div(1, 0);
}
@Ignore
public void testDiv1(){
int d=c.div(1, 5);
Assert.assertEquals(0, d);
}
}
5. 如何编写一个好的测试用例我一直在想，作为测试人员应该用脑袋去测试，也就是说应该在工作中不断的总结经验，把自己的发现应用到测试中去，这样你才能有真正的提高，你所具备的理论和能力才有竞争力。
回到测试用例中来，我觉得做好以下三点就是一个好的用例。第一：依据分明众所周知，一个项目首先立项，然后经过一系列的动作到了需求分析，昨晚需求分析后，测试就可以做测试需求，然后就可以写测试用例了。
所以32313133353236313431303231363533e4b893e5b19e31333332636334写测试用例的依据就是需求。这么说太笼统，举一个例子。
一个系统经过前期的需求分析，详细设计，模块设计等一系列的动作，最后生成了详细的需求说明和详细设计文档等等，在这些文档中，已经很详细的描述了所有的需求点和功能点，也有较详细的技术说明，接下来的工作就是怎么把这些功能点和需求点变成测试点，这就需要做好测试需求分析和测试方案工作，生成一个个可测试的测试点。这也是需求必须可测的一个体现。
假设经过上一步工作，分析出这个系统有5个模块，50个大的功能点，500个具体需求点，最后生成了5000个测试点。那么 ok，我们就要写5000个测试用例。
还是那句话，一个测试用例只能对应一个测试点，测试点和用例是1对1的关系；一个需求点可以对应多个用例，需求点和用例是1对多的关系。这样做的目的在统计中讲。
第二：目的明确用例都有个测试目的，这就是要目的明确，并且也只能有一个目的。前面无论多少步骤，都是为了找到这个目的途径。
功能从大到小有层次的划分，我们做测试用例也是有层次的，不然你怎么定义用例的优先级呢？等到测试最小的功能点是，支持这个功能点的其他上层功能点，我们都默认正确就可以了，这就是我们的预期，所以在测试步骤中不用对上层的功能专门考虑测试数据，只把他当成一个正确的找到目前的功能点的途径就行。换句话说，你要测试的功能点需要点10个连接才能找到，那么前9个连接我们再以前就应该设计了用例，在第10个连接中默认他们正确就ok，这个用例的前9步，只是告诉你如何找到第10步。