单元测试的测试用例

单元测试的测试用例设计主要依据是详细设计说明吗~

单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试的测试用例设计主要根据接口规格说明。

单元测试验证的是详细设计。有自顶而下和自下向上两位方式，需要编写桩模块或驱动模块。单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来！

　　首先我们需要先下载相应的 JUnit 相关的 JAR 包，下载的过程可以去 JUnit 的官方网站，也可以直接通过 Maven 资源仓库来完成。

　　使用简单的 @Test 注解实现我们的测试方法的编写和执行
　　准备工作做好之后，接下来我们就可以开始尝试编写壹个简单的测试代码了。首先，我们编写了壹个 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 divide(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;
　　}
　　

下面说说测试用例、输入数据及预期输出。输入数据是测试用例的核心，对输入数据的定义是：被测试函数所读取的外部数据及这些数据的初始值。外部数据是对于被测试函数来说的，实际上就是除了局部变量以外的其他数据，老纳把这些数据分为几类：参数、成员变量、全局变量、IO媒体。IO媒体是指文件、数据库或其他储存或传输数据的媒体，例如，被测试函数要从文件或数据库读取数据，那么，文件或数据库中的原始数据也属于输入数据。一个函数无论多复杂，都无非是对这几类数据的读取、计算和写入。预期输出是指：返回值及被测试函数所写入的外部数据的结果值。返回值就不用说了，被测试函数进行了写操作的参数（输出参数）、成员变量、全局变量、IO媒体，它们的预期的结果值都是预期输出。一个测试用例，就是设定输入数据，运行被测试函数，然后判断实际输出是否符合预期。下面举一个与成员变量有关的例子： void CMyClass::Grow(int years)
{
mAge += years;
if(mAge < 10)
mPhase = 儿童;
else if(mAge <20)
mPhase = 少年;
else if(mAge <45)
mPhase = 青年;
else if(mAge <60)
mPhase = 中年;
else
mPhase = 老年;
}
测试函数中的一个测试用例：
CaseBegin();{
int years = 1;
pObj->mAge = 8;
pObj->Grow(years);
ASSERT( pObj->mAge == 9 );
ASSERT( pObj->mPhase == 儿童 );
}CaseEnd();
在输入数据中对被测试类的成员变量mAge进行赋值，在预期输出中断言成员变量的值。现在可以看到老纳所推荐的格式的好处了吧，这种格式可以适应很复杂的测试。在输入数据部分还可以调用其他成员函数，例如：执行被测试函数前可能需要读取文件中的数据保存到成员变量，或需要连接数据库，老纳把这些操作称为初始化操作。例如，上例中 ASSERT( ...)之前可以加pObj->OpenFile();。为了访问私有成员，可以将测试类定义为产品类的友元类。例如，定义一个宏：
#define UNIT_TEST(cls) friend class cls##Tester;
然后在产品类声明中加一行代码：UNIT_TEST(ClassName)。 下面谈谈测试用例设计。前面已经说了，测试用例的核心是输入数据。预期输出是依据输入数据和程序功能来确定的，也就是说，对于某一程序，输入数据确定了，预期输出也就可以确定了，至于生成/销毁被测试对象和运行测试的语句，是所有测试用例都大同小异的，因此，我们讨论测试用例时，只讨论输入数据。
前面说过，输入数据包括四类：参数、成员变量、全局变量、IO媒体，这四类数据中，只要所测试的程序需要执行读操作的，就要设定其初始值，其中，前两类比较常用，后两类较少用。显然，把输入数据的所有可能取值都进行测试，是不可能也是无意义的，我们应该用一定的规则选择有代表性的数据作为输入数据，主要有三种：正常输入，边界输入，非法输入，每种输入还可以分类，也就是平常说的等价类法，每类取一个数据作为输入数据，如果测试通过，可以肯定同类的其他输入也是可以通过的。下面举例说明：
正常输入
例如字符串的Trim函数，功能是将字符串前后的空格去除，那么正常的输入可以有四类：前面有空格；后面有空格；前后均有空格；前后均无空格。
边界输入
上例中空字符串可以看作是边界输入。
再如一个表示年龄的参数，它的有效范围是0-100，那么边界输入有两个：0和100。
非法输入
非法输入是正常取值范围以外的数据，或使代码不能完成正常功能的输入，如上例中表示年龄的参数，小于0或大于100都是非法输入，再如一个进行文件操作的函数，非法输入有这么几类：文件不存在；目录不存在；文件正在被其他程序打开；权限错误。
如果函数使用了外部数据，则正常输入是肯定会有的，而边界输入和非法输入不是所有函数都有。一般情况下，即使没有设计文档，考虑以上三种输入也可以找出函数的基本功能点。实际上，单元测试与代码编写是“一体两面”的关系，编码时对上述三种输入都是必须考虑的，否则代码的健壮性就会成问题。
白盒覆盖
上面所说的测试数据都是针对程序的功能来设计的，就是所谓的黑盒测试。单元测试还需要从另一个角度来设计测试数据，即针对程序的逻辑结构来设计测试用例，就是所谓的白盒测试。在老纳看来，如果黑盒测试是足够充分的，那么白盒测试就没有必要，可惜“足够充分”只是一种理想状态，例如：真的是所有功能点都测试了吗？程序的功能点是人为的定义，常常是不全面的；各个输入数据之间，有些组合可能会产生问题，怎样保证这些组合都经过了测试？难于衡量测试的完整性是黑盒测试的主要缺陷，而白盒测试恰恰具有易于衡量测试完整性的优点，两者之间具有极好的互补性，例如：完成功能测试后统计语句覆盖率，如果语句覆盖未完成，很可能是未覆盖的语句所对应的功能点未测试。
白盒测试针对程序的逻辑结构设计测试用例，用逻辑覆盖率来衡量测试的完整性。逻辑单位主要有：语句、分支、条件、条件值、条件值组合，路径。语句覆盖就是覆盖所有的语句，其他类推。另外还有一种判定条件覆盖，其实是分支覆盖与条件覆盖的组合，在此不作讨论。跟条件有关的覆盖就有三种，解释一下：条件覆盖是指覆盖所有的条件表达式，即所有的条件表达式都至少计算一次，不考虑计算结果；条件值覆盖是指覆盖条件的所有可能取值，即每个条件的取真值和取假值都要至少计算一次；条件值组合覆盖是指覆盖所有条件取值的所有可能组合。老纳做过一些粗浅的研究，发现与条件直接有关的错误主要是逻辑操作符错误，例如：||写成&&，漏了写！什么的，采用分支覆盖与条件覆盖的组合，基本上可以发现这些错误，另一方面，条件值覆盖与条件值组合覆盖往往需要大量的测试用例，因此，在老纳看来，条件值覆盖和条件值组合覆盖的效费比偏低。效费比较高且完整性也足够的测试要求是这样的：完成功能测试，完成语句覆盖、条件覆盖、分支覆盖、路径覆盖。做过单元测试的朋友恐怕会对老纳提出的测试要求给予一个字的评价：晕！或者两个字的评价：狂晕！因为这似乎是不可能的要求，要达到这种测试完整性，其测试成本是不可想象的，不过，出家人不打逛语，老纳之所以提出这种测试要求，是因为利用一些工具，可以在较低的成本下达到这种测试要求，后面将会作进一步介绍。
关于白盒测试用例的设计，程序测试领域的书籍一般都有讲述，普通方法是画出程序的逻辑结构图如程序流程图或控制流图，根据逻辑结构图设计测试用例，这些是纯粹的白盒测试，不是老纳想推荐的方式。老纳所推荐的方法是：先完成黑盒测试，然后统计白盒覆盖率，针对未覆盖的逻辑单位设计测试用例覆盖它，例如，先检查是否有语句未覆盖，有的话设计测试用例覆盖它，然后用同样方法完成条件覆盖、分支覆盖和路径覆盖，这样的话，既检验了黑盒测试的完整性，又避免了重复的工作，用较少的时间成本达到非常高的测试完整性。不过，这些工作可不是手工能完成的，必须借助于工具，后面会介绍可以完成这些工作的测试工具。

---

延安市19763448130： 单元测试用例该怎么写 - ？
亓贵灯盏： 写单元测试用例?好像有些理想化.在实际工作中,能有个基本的详细设计文档就不错了,只要有了详细设计文档,就可以直接建立可执行的测试用例.先写个文字的单元测试用例,费时费力,还要维护,项目不会给那么多时间吧?从我们的客户反馈来看,实际工作中,很多项目是没有规范的详细设计的,这时最容易范的错误就是:测试人员阅读代码来了解代码功能,以便设计用例,结果,测试几乎没有效果.所以,除非有规范的文档,否则单元测试要由开人员为主.如果连详细设计文档都没有,那依据什么来写文字版的单元测试用例?如果有,那就用不着写一个文字版的.

延安市19763448130： 单元测试的测试用例主要根据( )的结果来设计. - ？
亓贵灯盏： D.详细设计

延安市19763448130： 什么是单元测试 - ？
亓贵灯盏： 单元测试:单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等.它是软件动态测试的最基本的部分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性.一个软件单元的正确性是相对于该单元的规约而言的.

延安市19763448130： 白盒测试的单元测试用例怎么编写 - ？
亓贵灯盏： 白盒测试用例设计技术可分为逻辑覆盖和路径覆盖,逻辑覆盖又可分为以下几种,从弱到强:语句覆盖(SC):设计足够多的测试用例,确保每条语句都被执行过.判定覆盖(DC):设计足够多的测试用例,确保每个判定都分别取真值与假值...

延安市19763448130： 如何编写干净的单元测试用例 - ？
亓贵灯盏： 读者最好对Spring框架及Spring框架提供的单元测试支持有所了解,因为本文案例基于Spring技术编写.但对Spring不了解并不影响本文所讲述的单元测试用例编写及回调模式、模板方法的应用. 单元测试是编写高质量代码的前提,通过编写有...

延安市19763448130： 测试面向对象软件时,主要有哪些设计单元测试用例的方法 - ？
亓贵灯盏： 面向对象只是程序设计的一种方法、思想,对于测试而言,基本还是 黑盒、白盒、灰盒这三种,是否面向对象对测试影响不会很大,不过很多时候看要基于UML的测试模型来定的

延安市19763448130： 常见的测试用例设计方法都有哪些 - ？
亓贵灯盏： 主要的测试用例方法有:等价类、边界值、因果图、错误猜测、正交试验等等,用到最多的肯定是等价类和边界值,基本上任何用例都会用到这两种方法,当然,错误猜测也是比较常用的.

延安市19763448130： 我该如何写单元测试? - ？
亓贵灯盏： ?? 在我的团队中,单元测试是较难推行的敏捷实践之一,我思考后觉得有以下原因:1、主观上觉得会加大工作量,影响进度2、从未接触junit等单元测试框架,害怕接触新事物3、团队形式上要求、形式上开展,但是未能结合培训、Code ...

延安市19763448130： 没有参数的函数怎么写单元测试用例? - ？
亓贵灯盏： 对于函数测试来说,一个用例,就是设定输入,执行程序,判断输出是否符合预期.可能输入包括:参数、需读的成员变量、需读的全局变量、内部输入(调用子函数获得的输入);可能输出包括:返回值、输出参数、被写的成员变量、被写的...