测试用例命名测试方法结果(测试用例名称命名规范)
目录导读：
测试用例设计方法
为某个业务目标，而编制的一组由测试输入，执行条件以及预期结果组成的案例
在开始实施测试之前规划好测试用例，可以避开盲目测试并提高测试效率。
测试用例的使用令软件测试的实施重点突出、目的明确。
在软件版本更新后仅需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。
检验软件是否满足顾客需求、展现一个测试人员的工作量、体现测试用例的设计思路。
必须掌握：用例编号(怎样命名)、所属模块、用例标题（验证谁在怎么回事下，去做什么，最终结果是什么）、优先级、前置条件、方法步骤、测试数据、预期结果、实际结果
了解内容：通过否、bugID、编写人员、编写时间、测试人员、测试时间、备注
测试用例覆盖所有的用户需求
测试用例要简单并且明了
各类型的测试用例要齐全
用最少的用例覆盖最多的需求
等价类划分 是把所有可能输入的数据分为若干个区域，紧接着从每个区域中取少量有表现性的数据进行测试即可。
等价类 ：何为等价类，某个输入域的集合，在这个集合中每个输入条件都是等效的。
一般可分为有效等价类和无效等价类。
有效等价类：指符合《需求规格说明书》，输入合理的数据集合
无效等价类：指不符合《需求规格说明书》，输入不合理的数据集合
取值范围型： 输入学生成绩 0-100
恒等类型 ： 仅有一个结果是正确的，其他都是错误的 例如 彩票的特等奖
布尔值型： 通过是否来进行选择，如同意协议
枚举类型： 给出选项内容，只要符合其中任意一个就能够 例如选择学历
规则类型： 给定要求，满足要求的就能够，打比方说邮箱
在任意文本输入框中可以填写的字符类型： 中文、英文、特殊符号、空格、数字。
定义：边界值剖析 是取稍高于或稍低于边界的一些数据进行测试。
原因： 流程开发循环体时的取数也许会由于<，<=搞错。
上点： 是指边界上的点，不管此时的域是开区间还是闭区间，开区间的话，上点就是在域外，闭区间的话，上点就是在域内。
离点： 是指离上点近日的点，这里就跟是闭区间还是开区间就有关系了，假如是开区间，那么离点就在域内，假如是闭区间，那么离点就在域外。(开内闭外)
遵循的原则：开内闭外 开区间往中间找，闭区间往外找
内点： 域内的任意点都是内点。
0<=x<=10 左上点 0 左离点 -1 右离点 11 右上点 10 内点 5
0<x<10 左上点 0 左离点 1 右离点 9 右上点 10 内点 5
0<=x<10 左上点 0 左离点 -1 右离点 9 右上点 10 内点 5
因果图法可能适合输入条件比较多的情形，测试所有的输入条件的排列组合。经常提到的原因在于输入，经常提到的结果就是输出。
1。确定原因、结果、中间过程
2。连接因果图
3。标明管束条件
4。输出测试用例
错误猜测法是测试经验富饶的人喜欢使用的一种测试用例设计方法。
一般这一个方法是基于经验和直觉推测流程中可能发送的各式错误，有针对性地设计。只能代表一种补充。
输入一串数字，流程可自动从小到大排序
邮箱格式@符合的全角以及半角情况
测试手机终端的通话功能，可以设计各式通话失败的情形来补充测试用 例：
无SIM 卡插入时进行呼出（非紧急呼叫）
插入已欠费SIM卡进行呼出
射频器件损坏或无信号区域插入有效SIM卡呼出
互联网正常，插入有效SIM卡，呼出无效号码（如1。888。333333。不输入任何号码等）
互联网正常，插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字
最要紧的是要思考和剖析测试对象的各个方面，多参考以前发现的bug的相关数据，汇总的经验，个人多考虑异常的情形、反面的情形、特殊的输入，以一个攻击者的态度对待流程，就能设计出比较完善的测试用例来。
设计测试用例时，剖析和表达多输入条件下执行不同操作的黑盒测试方法。
注意和提防： 该方法和因果图法相似。
1。确定原因和动作
2。排列组合
3。标明结果关系
4。输出测试用例
日本人提出
使用工具：正交表
正交实验法就是利用排列整齐的表 -正交表来对试验进行整体设计、综合比较、统计剖析，实现通过少数的实验次数找到较好的生产条件，以达到最高生产工艺效果。
这种试验设计法是从大量的试验点中挑选适量的具有表现性的点，利用已经造好的表格—正交表来安排试验并进行数据剖析的方式方法。
正交表能够在因素变化范围内均衡抽样，使每次试验都具有较强的表现性，因为正交表具备均衡分散的特征，保证了全面实验的某些要求，这几个试验常常能够较好或更好的达到实验的意图。
正交实验设计包括两部分内容：第1，是如何安排实验；第2，是如何剖析实验结果。
在一个界面中有多个控件，每个控件有多个取值，控件之间可以互相组合，没有可能（也没很有必要）为每一种组合编写一条用例，怎样使用最少最优的组合进行测试。——正交排列法
在项目中如何用junit写单元测试用例
first of all大家需要先下载对应的 JUnit 相关的 JAR 包，下载的过程可以去 JUnit 的官方网站，也可以直接通过 Maven 资源仓库来完成。
利用简单的 @Test 注解解读实现我们的测试方法的编写和执行
准备工作做好之后，接着下面我们就能够开始try编写壹个简单容易的测试代码了。first of all，我们编写了壹个 Calculator 类，并提供五个方法分别完成加减乘除以及求平方的运算。代码如下：
package net。oschina。bairrfhoinn。main;
public class Calculator {
public void add(int n){
result += n;
}
public void substract(int n){
result -= n;
}
public void multiply(int n){
result *= n;
}
public void pide(int n){
result /= n;
}
public void square(int n){
result = n * n;
}
public int getReuslt(){
return result;
}
public void clear(){
result = 0;
}
private static int result;
}
在测试类中用到了JUnit4框架，自然要把相应地Package蕴含进来。最主要地一个Package就是org。junit。*。把它蕴含进来之后，绝多数功能就有了。还有一句话也非常地重要“import static org。junit。Assert。*;”，我们在测试的时刻使用的壹系列assertEquals()方法就来自这个包。核心提示壹下，这是壹个静态蕴含（static），是JDK5中新增加的壹个功能。总之，assertEquals是Assert类中的壹系列的静态方法，壹般的使用方式是Assert。 assertEquals()，不过使用了静态蕴含后，前面的类名就能够省略了，使用起来更加加倍的方便。
另外须留意的是，我们的测试类是壹个单独的类，没有任何父类。测试类之名字也可以任意命名，没有任何有限性。因此我们不能通过类的声明来推测断定它是还是不是一个测试类，它与普通类的不同在于它内部的方式方法的声明，我们接着会说到。在测试类中，并不是每壹个方法都是用于测试的，因此我们必须使用“注解解读”来明确表明哪些是测试方法。“注解解读”也是JDK5的壹个新特性，用在此处非常恰当。俺们是可以看见，在某些方法的前有@Before、@Test、@Ignore等字样，这几个就是注解解读，以壹个“@”作为开头。这几个注解解读都是JUnit4自定义的，熟练掌握这几个注解解读之寓意，对于编写恰当的测试类十分重要。
接着下面我们创建壹个测试类 CalculatorTest。java，代码如下：
package net。oschina。bairrfhoinn。test;
import static org。junit。Assert。*;
import org。junit。Test;
import net。oschina。bairrfhoinn。main。Calculator;
public class CalculatorTest {
private static Calculator calculator = new Calculator();
@Test
public void testAdd(){
calculator。add(7);
calculator。add(8);
assertEquals(15， calculator。getReuslt());
}
}
first of all，我们要在方法的前面使用@Test标注，以表明这是壹个测试方法。对于方法的声明亦有如下要求：名字可以随便取，没有任何限制，不过返回值必须为void，并且不能有任何参数。假如违反这几个规定，会在运行时抛出壹个异常。至于方法内该写些什么，那么这样就要看你需要测试些什么了。打比方说上述代码中，我们想测试壹下add()方法的功能是否正确，就在测试方法中调用几次add函数，初始值为0，先加7，再加8，我们期待的结果或许应该是1五、假如最终实际结果也是15，则说明add()方法是正确的，反之说明它是错的。assertEquals(15， calculator。getResult());就是用以判断期待结果和实际结果是否相等，其中第壹个参数填写期待最终，第2个参数填写实际最终，即通过计算得到的结果。这样写好之后，JUnit 会自动进行测试并把测试结果反馈给用户。
假如想运行它，能在 eclipse 的资源管理器中选择该类文件，紧接着点击右键，选择 Run As->JUnit Test 即可看见运行结果。
使用@Test 的属性 Ignore 指定测试时跳过这一个办法
假如在写流程前做了非常好的规划，那么哪些方法是什么功能都应该实现并且确定下来。于是，即便该方法尚未完成，他的具体功能也是确定的，这也就象征着你能够为他编写测试用例。不过，假如你已经把该方法的测试用例写完，但该方法尚未完成，那么测试的时刻无疑是“失败”。这种失败和名符其实的失败是有区别的，因此 JUnit 提供了壹种方法来区别他们，那么这样就是在这种测试函数的前面加上 @Ignore 标注，这个标注之寓意就是“某些方法尚未完成，暂不参与此次测试”。如此的话测试结果就会提醒你有多少个测试被忽视，而不是失败。壹旦你完成了相应函数，仅需要把@Ignore标注删去，就能够进行正常的测试。
打比方说说上面的测试类 Calculator。java 中，假设我们的 Calculator 类的 multiply() 方法没有实现，俺们是可以在测试类 CalculatorTest 中先写如下测试代码：
package net。oschina。bairrfhoinn。test;
import static org。junit。Assert。*;
import org。junit。Ignore;
import org。junit。Test;
import net。oschina。bairrfhoinn。main。Calculator;
public class CalculatorTest {
private static Calculator calculator = new Calculator();
。。。 //此处代码省略
@Ignore("mod square() not implemented， please test this later。。。")
@Test
public void testSquare(){
calculator。square(3);
assertEquals(9， calculator。getReuslt());
}
}
我们再运行壹次测试，会看见如下最终，从图中可以很明显的看出，方法testSquare() 上的 @Ignore 注解解读已经生效了，运行时直接跳过了它，而方法testAdd()仍然正常的运行并通过了测试。
使用注解解读 @Before 和 @After 来完成前置工作和后置工作
前置工作一般是指我们的测试方法在运行之前需要做的壹些准备工作，如数据库的连接、文件的加载、输入数据的准备等需要在运行测试方法之前做的事情，都属于前置工作；类似的，后置工作其实指的是测试方法在运行后来的壹些要做的事情，如释放数据库连接、输入输出流的关闭等；打比方说我们上面的测试，因为只声明了壹个 Calculator 对象，他的初始值是0，不过测试完加法操作后，他的值就不是0了；接着下面测试减法操作，就必然要慎重考虑上次加法操作的结果。这百分百是壹个很糟糕的设计！！！我们非常希望每壹个测试方法都是单独的，互相之间没有任何耦合度。于是，我们就有必要在实施每壹个测试方法之前，对Calculator对象进行壹个“复原”操作，以消除其他测试造成的作用与影响。于是，“在任何壹个测试方法执行之前必须执行的代码”就是壹个前置工作，我们用注解解读 @Before 来标注它，如下例子所示：
package net。oschina。bairrfhoinn。test;
。。。
import org。junit。After;
import org。junit。Before;
import org。junit。Ignore;
import org。junit。Test;
public class CalculatorTest {
。。。//这里省略部分代码
@Before
public void setUp() throws Exception {
calculator。clear();
}
@After
public void tearDown() throws Exception {
System。out。println("will do sth here。。。");
}
。。。//这里省略部分代码
}
另外要说的是，注解解读 @Before 是定义在 org。junit。Before 这个类中的，因此使用时需要将其引入我们的代码中。这样做了之后，每次我们运行测试方法时，JUnit 都会先运行 setUp() 方法将 result 的值清零。但是要注意和提防的是，这里不再需要 @Test 注解解读，由于这并不是壹个 test，只是壹个前置工作。同理，假如“在任何测试执行之后需要进行的收尾工作，我们可以使用 @After 来标注，方法与它类似。因为本例比较简单，不需要用到此功能，因此我们只是简单了给它添加了壹个 tearDown() 方法并在收尾时打印壹句话到控制台，并且使用 @After 来注解解读这一个办法。
使用@BeforeClass 和 @AfterClass 来完成仅需要执行壹次的前置工作和后置工作
上面我们提到了两个注解解读 @Before 和 @After ，我们来看看他们是否适合完成如下功能：有壹个类负责对大文件（超过500 MB）进行读写，他的每壹个方法都是对文件进行操作。换句话说，在调用每壹个方法之前，我们都要打开壹个大文件并读入文件内容，这百分百是壹个非常耗费时的操作。假如我们使用 @Before 和 @After ，那么每次测试都要读取壹次文件，效率及其低下。因此我们希望的是，在所有测试壹开始读壹次文件，所有测试结束之后释放文件，而不是每次测试都读文件。JUnit的作者显然也考虑到了此问题，它给出了@BeforeClass 和 @AfterClass 两个注解解读来帮我们实现这个功能。从名字上就能够看出，用这两个注解解读标注的函数，只在测试用例初始化时执行 @BeforeClass 方法，当所有测试执行完毕之后，执行 @AfterClass 进行收尾工作。在这儿须留意壹下，每个测试类只能有壹个方法被标注为 @BeforeClass 或 @AfterClass，而且该方法必须是 public static 类型的。
使用@Test 的属性 timeout 来完成限时测试，以检测代码中的死循环
此刻假设我们的 Calculator 类中的 square() 方法是个死循环，那应该如何办呢，打比方说说像下面这样：
public void square(int n){
for(;;){}
}
假如测试的时刻遇见死循环，你的脸上根本不会露出笑容的。于是，对于那些逻辑很复杂，循环嵌套比较深的、有可能出现死循环的流程，因此壹定要采取壹些预防措施。限时测试是壹个非常好的处理方案。我们给这几个测试函数设定壹个预期的执行时间，超过此壹时间，他们就会被系统强行终止，并且系统还会向你汇报该函数结束的缘故是由于超时，这样你就能够发现这几个 Bug 了。要实现这壹功能，仅需要给 @Test 标注加壹个参数timeout即可，代码如下：
@Test(timeout=2000L)
public void testSquare() {
calculator。square(3);
assertEquals(9， calculator。getReuslt());
}
timeout参数表明了你预计该方法运行的时长，单位为毫秒，因此2000就代表2秒。此刻我们让这个测试方法运行壹下，看看失败时是什么效果。
使用@Test 的属性expected来监控测试方法中也许会抛出的某些异常
JAVA中的异常处理也是壹个重点，所以你经常会编写壹些需要抛出异常的函数。假如你觉得壹个函数应该抛出异常，可是它没抛出，这算不算 Bug 呢？这肯定是Bug，JUnit 也考虑到了这壹点，并且可以帮助我们找到这种 Bug。例如，我们写的计算器类有除法功能，假如除数是壹个0，那么必然要抛出“除0异常”。于是，我们有必要对这几个进行测试。代码如下：
@Test(expected=java。lang。ArithmeticException。class)
public void testDivide(){
calculator。pide(0);
}
如上述代码所示，大家需要使用@Test注解解读中的expected属性，将我们要检验的异常（这里是 java。lang。ArithmeticException）传递给他，这样 JUnit 框架就能自动帮我们检测是否抛出了我们指定的异常。
指定 JUnit 运行测试用例时的 Runner
大家有还是没有想过此问题，当你把测试代码提交给JUnit框架后，框架是怎样来运行你的代码的呢？答案就是Runner。在JUnit中有许多个Runner，他们负责调用你的测试代码，每壹个Runner皆有其各自的特殊功能，你要依据需要选择不同的Runner来运行你的测试代码。可能你会觉得奇怪，前面我们写了那样多测试，其实没有明确指定壹个Runner啊？这是由于JUnit中有壹个默认的Runner，假如你没有指定，那么系统会自动使用默认Runner来运行你的代码。换句话说，下面两段代码意思为完全壹样的：
import org。junit。runner。RunWith;
import org。junit。runners。JUnit4;
@RunWith(JUnit4、class)
public class CalculatorTest {
。。。//省略此处代码
}
//用了系统默认的JUnit4、class，运行效果完全壹样
public class CalculatorTest {
。。。//省略此处代码
}
测试用例的设计通常来讲包括哪些内容?
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、方法步骤、预期最终，下面逐一介绍。
用例编号
测试用例的编号有一定的规则，打比方说系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规那么是项目名称+测试阶段类型（系统测试阶段）+编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题
对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。打比方说 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。
重要级别
定义测试用例的优先级别，可以笼统的分为 四个不同的等级
输入限制
提供测试执行中的各式输入条件。依据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求之中的输入有很大的依靠性，假如软件需求中没有非常好的定义需求的输入，那么测试用例设计中会遇见很大的障碍。
方法步骤
提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在方法步骤中详细列出。
预期结果
提供测试执行的预期最终，预期结果应该依据软件需求中的输出总结出。假如在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
怎样写出完美的测试用例
*用例编号
命名规范：模块英文名_001 ，首字母大写
*用例名称
一个完整的句子；
可以直观表达本条用例的目的；
用条件描述用例标题，而不是参数描述用例标题；
假如一个用例中蕴含多个参数，用例中或许应该是每个参数的取值；
不要超过30个汉字；
所属模块
归属的功能模块，可以再细分为子模块
前置条件
用例执行的前置条件
测试数据
用例执行的用的测试数据
*用例步骤
测试步骤不要多于7步；
不要在测试用例中引用别的测试用例，假如测试用例2需要测试用例1执行后才能执行：
1、将用例1和用例2合并成一个大的用例；----适合用例简单容易的情况
2、将用例1简述后作为用例2的前置条件；
避开蕴含过多的用户细节与关键；
在测试步骤后和预期结果前加标签，明确操作后执行的最终，示例：
方法步骤：1、同时按住绘本键+音乐键3s；[chek1]
2、在APP上输入正确的WiFi名称和密码进行连接；[chek2]
预期结果：[chek1]进入配网模式，播放进入配网模式提示音，黄灯呼吸；
[chek2]联网成功，退出配网模式，播放联网成功提示音，灯光关闭；
避开在测试步骤中使用笼统的词汇：将笼统的词汇量化，如反复---100次，长久：二十四小时，大量：1000个；
*预期结果
预期结果一定是明确的，没有不确定性；
预期结果不要多余5个，不要少于1个；
优先级
用例执行的优先级
用例等级
将用例划分为不同等级，依据不同的质量等级执行不同等级的用例
注：
①单条必须是可单独执行的
②带*号为常规用例必须，其他依据实际情况选择添加
③此规范适合使用于编写完整测试用例时，简化的测试用例可以只蕴含用例标题、预期结果；
测试用例的逻辑规范是什么?
1、
多条用例是在某个前提条件下完成的，是属于控制和被控制的关系，则这几个用例能够放在该。。。
2、
用例之间执行有顺序要求，则标记序号1，2，三、
3、
保证同级的用例是互相平行的，互不作用与影响，假如有互相间的作用与影响，则标记层级关系。
测试用例的设计通常来讲包括哪些内容?
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、方法步骤、预期最终，下面逐一介绍。
用例编号
测试用例的编号有一定的规则，打比方说系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规那么是项目名称+测试阶段类型（系统测试阶段）+编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题
对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。打比方说 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。
重要级别
定义测试用例的优先级别，可以笼统的分为 四个不同的等级
输入限制
提供测试执行中的各式输入条件。依据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求之中的输入有很大的依靠性，假如软件需求中没有非常好的定义需求的输入，那么测试用例设计中会遇见很大的障碍。
方法步骤
提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在方法步骤中详细列出。
预期结果
提供测试执行的预期最终，预期结果应该依据软件需求中的输出总结出。假如在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。