实验五 单元测试
一、实验目的
1）掌握单元测试的方法
2) 学习XUnit测试原理及框架；
3）掌握使用测试框架进行单元测试的方法和过程。
二、实验内容与要求
1、了解单元测试的原理与框架
1.1 单元测试原理
单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
单元测试的内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试。
（1）模块接口测试
模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素：
-输入的实际参数与形式参数的个数是否相同
-输入的实际参数与形式参数的属性是否匹配
-输入的实际参数与形式参数的量纲是否一致
-调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
-调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
-调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
-调用预定义函数时所用参数的个数、属性和次序是否正确；
-是否存在与当前入口点无关的参数引用；
-是否修改了只读型参数；
-对全程变量的定义各模块是否一致；
-是否把某些约束作为参数传递。
如果模块功能包括外部输入输出，还应该考虑下列因素：
-文件属性是否正确；
-OPEN/CLOSE语句是否正确；
-格式说明与输入输出语句是否匹配；
-缓冲区大小与记录长度是否匹配；
-文件使用前是否已经打开；
-是否处理了文件尾；
-是否处理了输入/输出错误；
-输出信息中是否有文字性错误。
-局部数据结构测试；
-边界条件测试；
-模块中所有独立执行通路测试；
（2）局部数据结构测试
检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
-不合适或不相容的类型说明；
-变量无初值；
-变量初始化或省缺值有错；
-不正确的变量名（拼错或不正确地截断）；
-出现上溢、下溢和地址异常。
（3）边界条件测试
边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高程序健壮性。
（4）独立路径测试
在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括：
-误解或用错了算符优先级；
-混合类型运算；
-变量初值错；
-精度不够；
-表达式符号错。
（5）错误处理测试
检查模块的错误处理功能是否包含有错误或缺陷。例如，是否拒绝不合理的输入;出错的描述是否难以理解、是否对错误定位有误、是否出错原因报告有误、是否对错误条件的处理不正确;在对错误处理之前错误条件是否已经引起系统的干预等。
通常单元测试在编码阶段进行。在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。
1.2 测试框架
xUnit是各种代码驱动测试框架的统称,这些框架可以测试 软件的不同内容(单元),比如函数和类。xUnit框架的主要优点是,它提供了一个自动化测试的解决方案。可以避免多次编写重复的测试代码。
底层是xUnit的framwork，xUnit的类库，提供了对外的功能方法、工具类、api等
TestCase(具体的测试用例)去使用framwork
TestCase执行后会有TestResult
使用TestSuite控制TestCase的组合
TestRunner执行器，负责执行case
TestListener过程监听，监听case成功失败以及数据结果，输出到结果报告中。
Unit测试框架包括四个要素：
(1)测试目标（对象）
一组认定被测对象或被测程序单元测试成功的预定条件或预期结果的设定。Fixture就是被测试的目标，可以是一个函数、一组对象或一个对象。 测试人员在测试前应了解被测试的对象的功能或行为。
（2）测试集
测试集是一组测试用例，这些测试用例要求有相同的测试Fixture，以保证这些测试不会出现管理上的混乱。
（3）测试执行
单个单元测试的执行可以按下面的方式进行：
第一步 编写 setUp() 函数，目的是：建立针对被测试单元的独立测试环境；举个例子，这可能包含创建临时或代理的数据库、目录，再或者启动一个服务器进程。
第二步 编写所有测试用例的测试体或者测试程序；
第三步 编写tearDown()函数，目的是：无论测试成功还是失败，都将环境进行清理，以免影响后续的测试；
（4）断言
断言实际上就是验证被测程序在测试中的行为或状态的一个函数或者宏。断言的失败会引发异常，终止测试的执行。
1.3 面向特定语言的，基于xUnit框架的自动化测试框架
Junit ： 主要测试用Java语言编写的代码
CPPunit：主要测试用C++语言编写的代码
unittest ， PyUnit：主要测试用python语言编写的代码
MiniUnit: 主要用于测试C语言编写的代码
三、实验内容
1、CPPunit的下载和安装
在https://sourceforge.net/projects/cppunit/files/cppunit/官网中寻找最新版本的CPPunit下载。
下载cppunit-1.12.1压缩包后解压，在D:\cppunit-1.12.1\src中寻找CppUnitLibraries.dsw打开，选择组建/批组建，选择创建后，可在D:\cppunit-1.12.1\lib寻找到生成的库文件，可以根据需要选择所需的项目进行编译，其中项目cppunit为静态库，cppunit_dll为动态库。
2、测试用例设计 （结合单元测试的内容和模块功能设计测试用例）
用例设计如下：
| 用例编号 | 用例描述 | 输入参数 | 预期结果 |
| 1 | 正常用例 | - | 随着时间细胞图不断变化，游戏正常进行 |
| 2 | 地图中无细胞 | - | 细胞图无变化，游戏卡住无法进行 |
| 3 | 地图中满细胞 | - | 细胞图无变化。游戏卡住无法进行 |
3、测试过程
(1)源码
#include "stdio.h" #include "string.h" #include "windows.h" #include "time.h" #define N 49//1表示棋子，只有黑色棋子 int chess[N+2][N+2];//定义棋盘大小 int chess0[N+2][N+2];//辅助棋盘 void Initialize();//初始化一个对局函数 void RunGame();//进行游戏 int count_cellsNumber(int i,int j);//计算生命周围的生命数量 void Data();//调用已存的游戏数据 void main() { system("mode con cols=99 lines=50");//设置窗口大小 system("color 70");//设置颜色 Initialize();//初始化一个对局函数 RunGame();//进行游戏 } void Initialize()//初始化一个对局函数 { Data();//调用已存的游戏数据 } void Data()//调用已存的游戏数据 { int i,j; srand((unsigned)time(NULL)); for(i=0;i<N;i++){ for(j=0;j<N;j++) chess[i][j]=rand()%2; } /* int p=12; int l; for(l=-16;l<=16;l++) //if(l!=-8&&l!=0&&l!=4) chess[N/2+1][N/2+1+l]=1; */ /* //滑翔机 chess[1][3]=1;chess[2][1]=1;chess[2][3]=1;chess[3][2]=1;chess[3][3]=1; */ /* //高斯帕滑翔机 chess[1][p+11]=1;chess[1][p+13]=1; chess[2][p+10]=1;chess[2][p+13]=1; chess[3][p+9]=1;chess[3][p+10]=1;chess[3][p+21]=1;chess[3][p+28]=1; chess[4][p+1]=1;chess[4][p+2]=1;chess[4][p+7]=1;chess[4][p+8]=1;chess[4][p+12]=1;chess[4][p+21]=1;chess[4][p+27]=1;chess[4][p+29]=1; chess[5][p+1]=1;chess[5][p+2]=1;chess[5][p+9]=1;chess[5][p+10]=1;chess[5][p+20]=1;chess[5][p+27]=1;chess[5][p+28]=1;chess[5][p+30]=1; chess[6][p+10]=1;chess[6][p+13]=1;chess[6][p+16]=1;chess[6][p+17]=1;chess[6][p+27]=1;chess[6][p+28]=1;chess[6][p+30]=1;chess[6][p+31]=1;chess[6][p+35]=1;chess[6][p+36]=1; chess[7][p+11]=1;chess[7][p+13]=1;chess[7][p+16]=1;chess[7][p+19]=1;chess[7][p+20]=1;chess[7][p+21]=1;chess[7][p+22]=1;chess[7][p+27]=1;chess[7][p+28]=1;chess[7][p+30]=1;chess[7][p+35]=1;chess[7][p+36]=1; chess[8][p+16]=1;chess[8][p+17]=1;chess[8][p+18]=1;chess[8][p+19]=1;chess[8][p+27]=1;chess[8][p+29]=1; chess[9][p+17]=1;chess[9][p+18]=1;chess[9][p+28]=1; */ } void cells_state(int i,int j) { int living_cellsnumber=0; living_cellsnumber=count_cellsNumber(i,j); if(chess[i][j]==1){ if(living_cellsnumber<2) chess0[i][j]=0;//如果一个生命周围的生命少于2个，它在回合结束后死亡。 else if(living_cellsnumber>3) chess0[i][j]=0;//如果一个生命周围的生命超过3个，它在回合结束后死亡。 else if(living_cellsnumber==2||living_cellsnumber==3) chess0[i][j]=1;//如果一个生命周围有2或3个生命，它在回合结束时保持原样。 } else if(chess[i][j]==0){ if(living_cellsnumber==3) chess0[i][j]=1;//如果一个死格周围有3个生命，它在回合结束时获得生命。 } } void RunGame()//进行游戏 { int i,j,s=0; int flag=0; while(1) { system("cls");//清理屏幕，准备写入 for(i=1;i<N+1;i++) { for(j=1;j<N+1;j++) if(chess[i][j]==1) printf("█");//printf("■"); else if(chess[i][j]==0) printf(" "); printf("\n"); } for(i=1;i<N+1;i++) for(j=1;j<N+1;j++) { cells_state(i,j); } for(i=1;i<N+1;i++) for(j=1;j<N+1;j++) chess[i][j]=chess0[i][j]; Sleep(10); if(flag==0) { getchar(); flag=1; } } } int count_cellsNumber(int xline,int yline)//计算生命周围的生命数量 { int living_cellsnumber=0,i,j; for(i=-1;i<=1;i++){ for(j=-1;j<=1;j++){ if(!(i==0&&j==0)&&chess[xline+i][yline+j]==1) living_cellsnumber++; } }return living_cellsnumber; }
(2)测试代码
ExampleTestCase.c
#include <cppunit/config/SourcePrefix.h> #include "ExampleTestCase.h" CPPUNIT_TEST_SUITE_REGISTRATION(ExampleTestCase ); void ExampleTestCase::setup() { m_value1 = 0; m_value2 = 0; } void ExampleTestCase::Data() { srand((unsigned)time(NULL)); for(;m_value1<49;m_value1++){ for(;m_value2<49;m_value2++) chess[m_value1][m_value2]=rand()%2; } for(m_value1=0;m_value1<49;m_value1++){ for(m_value2=0;m_value2<49;m_value2++) CPPUNIT_ASSERT( chess[m_value1][m_value2] == 0 ); } }
4、测试结果
思考题：
比较以下二个工匠的做法，你认为哪种好？结合编码和单元测试，谈谈你的认识。
解：我认为工匠一的做法比较好。我们平时在编写程序时总是先编写程序再进行检查，这种做法总会导致在最后检查时出现很多错误要求重新编码，有时甚至在编写代码的过程中都会出现bug，而如果在编码之前便“拉上水平线”，可以提升编码的质量，减少bug，还可以提升反馈速度，减少重复工作。除此之外，我们现在编写的程序还很简陋，但是我们日常生活中实际使用的软件代码很多，每次更新都要考虑会不会影响旧的功能，而在编码之前“拉上水平线”可以有效解决这个问题。
实验小结
本次单元测试实验中，我们组测试的代码为C语言编写，所以在本次实验中，我对C++的测试工具CppUnit有了更深入的了解，学习了CppUnit的测试原理及框架。
