实验五单元测试

一、实验目的

1）掌握单元测试的方法

2) 学习XUnit测试原理及框架；

3）掌握使用测试框架进行单元测试的方法和过程。

二、实验内容

1.了解单元测试的原理与框架

1.1 单元测试原理

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

单元测试的内容包括：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试。

（1）模块接口测试

模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素：

-输入的实际参数与形式参数的个数是否相同

-输入的实际参数与形式参数的属性是否匹配

-输入的实际参数与形式参数的量纲是否一致

-调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；

-调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；

-调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；

-调用预定义函数时所用参数的个数、属性和次序是否正确；

-是否存在与当前入口点无关的参数引用；

-是否修改了只读型参数；

-对全程变量的定义各模块是否一致；

-是否把某些约束作为参数传递。

如果模块功能包括外部输入输出，还应该考虑下列因素：

-文件属性是否正确；

-OPEN/CLOSE语句是否正确；

-格式说明与输入输出语句是否匹配；

-缓冲区大小与记录长度是否匹配；

-文件使用前是否已经打开；

-是否处理了文件尾；

-是否处理了输入/输出错误；

-输出信息中是否有文字性错误。

-局部数据结构测试；

-边界条件测试；

-模块中所有独立执行通路测试。

（2）局部数据结构测试

检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：

-不合适或不相容的类型说明；

-变量无初值；

-变量初始化或省缺值有错；

-不正确的变量名（拼错或不正确地截断）；

-出现上溢、下溢和地址异常。

（3）边界条件测试

边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高程序健壮性。

（4）独立路径测试

在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括：

-误解或用错了算符优先级；

-混合类型运算；

-变量初值错；

-精度不够；

-表达式符号错。

（5）错误处理测试

检查模块的错误处理功能是否包含有错误或缺陷。例如，是否拒绝不合理的输入;出错的描述是否难以理解、是否对错误定位有误、是否出错原因报告有误、是否对错误条件的处理不正确;在对错误处理之前错误条件是否已经引起系统的干预等。

通常单元测试在编码阶段进行。在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。

1.2 测试框架

xUnit是各种代码驱动测试框架的统称,这些框架可以测试软件的不同内容(单元),比如函数和类。xUnit框架的主要优点是,它提供了一个自动化测试的解决方案。可以避免多次编写重复的测试代码。

Unit测试框架包括四个要素：

(1)测试目标（对象）

一组认定被测对象或被测程序单元测试成功的预定条件或预期结果的设定。Fixture就是被测试的目标，可以是一个函数、一组对象或一个对象。测试人员在测试前应了解被测试的对象的功能或行为。

（2）测试集

测试集是一组测试用例，这些测试用例要求有相同的测试Fixture，以保证这些测试不会出现管理上的混乱。

（3）测试执行

单个单元测试的执行可以按下面的方式进行：

第一步编写 setUp() 函数，目的是：建立针对被测试单元的独立测试环境；举个例子，这可能包含创建临时或代理的数据库、目录，再或者启动一个服务器进程。

第二步编写所有测试用例的测试体或者测试程序；

第三步编写tearDown()函数，目的是：无论测试成功还是失败，都将环境进行清理，以免影响后续的测试；

（4）断言

断言实际上就是验证被测程序在测试中的行为或状态的一个函数或者宏。断言的失败会引发异常，终止测试的执行。

1.3 面向特定语言的，基于xUnit框架的自动化测试框架

Junit ：主要测试用Java语言编写的代码

CPPunit：主要测试用C++语言编写的代码

unittest ， PyUnit：主要测试用python语言编写的代码

MiniUnit: 主要用于测试C语言编写的代码

三、实验过程

1.源码

#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <windows.h>
#include <time.h>

#define L 30  // 游戏画面尺寸
#define W 60


// 全局变量
int cells[L][W]; // 所有位置细胞生1或死0


void gotoxy(int x,int y)//类似于清屏函数
{
    HANDLE handle = GetStdHandle(STD_OUTPUT_HANDLE);
    COORD pos;
    pos.X = x;
    pos.Y = y;
    SetConsoleCursorPosition(handle,pos);
}
void startup() // 数据初始化
{
    int i,j;
    for (i=0;i<L;i++) // 初始化
        for (j=0;j<W;j++)
        {
            cells[i][j] = 1;
        }
}

void show()  // 显示画面
{
    gotoxy(0,0);  // 清屏
    int i,j;
    for (i=1;i<=L-1;i++)
    {
        for (j=1;j<=W-1;j++)
        {
            if (cells[i][j]==1)
                printf("●");  //   输出活的细胞
            else
                printf("○");  //   输出空格            
        }
        printf("\n");
    }
    Sleep(500);
}

void updateWithoutInput()  // 与用户输入无关的更新
{    
    int NewCells[L][W]; // 下一帧的细胞情况
    int NeibourNumber; //统计邻居的个数
    int i,j;
    for (i=1;i<=L-1;i++)
    {
        for (j=1;j<=W-1;j++)
        {
            NeibourNumber = cells[i-1][j-1] + cells[i-1][j] + cells[i-1][j+1]
                + cells[i][j-1] + cells[i][j+1] + cells[i+1][j-1] + cells[i+1][j] + cells[i+1][j+1];
            if (NeibourNumber==3)
                NewCells[i][j] = 1;  
            else if (NeibourNumber==2)
                NewCells[i][j] = cells[i][j];
            else
                NewCells[i][j] = 0; 
        }
    }
    
    for (i=1;i<=L-1;i++)
        for (j=1;j<=W-1;j++)
            cells[i][j] = NewCells[i][j];
        
}

void updateWithInput()  // 与用户输入有关的更新
{
    
}

void main()
{
    startup();  // 数据初始化    
    while (1) //  游戏循环执行
    {
        show();  // 显示画面
        updateWithoutInput();  // 与用户输入无关的更新
        updateWithInput();  // 与用户输入有关的更新
    }
}

2.测试用例设计（结合单元测试的内容和模块功能设计测试用例）

设计用例使得一次迭代得到下一代结果，多次迭代可以得到稳定结果。定义大小，提供原始图和大小，update能够演进到下一代，并且可以输出。通过while循环，能够自行迭代。可以总结为以下设计：

当前状态	邻居数量	下一个状态
生存	2-3	生存
生存	0-1,4-8	死亡
死亡	3	生存
死亡	0-2,4-8	死亡

只提供状态迁移窗口，根据给定的邻居情况，跃迁到下一个状态。cell只保存当前自身的状态。

3.选择的测试框架介绍、安装过程

这次的生命游戏使用的是C++语言，因此用Cppunit进行单元测试。下载CPPUnit并解压。

解压后用VC6.0打开CPPUnit/src/中的工程文件CppUnitL ibraries.dsw.选择Build菜单下Batch Build子菜单，将会有-对话框(如下图)，去掉所有以Unicode 结尾的Project选项目，然后按“全部重建”按钮，将生成cppunit的库文件，其位置在CPPUnit/lib目录下。

选择Tools->Options菜单,选择Directories TAB页，在show directories for下拉框中选择Include files,增加路径CPPUnit/include，以及CPPUnit/lib路径要写完整。

选择菜单“Project-> Setting‘’进入Project Settings对话框，切换到'C/C+ + '标签页，分页选择‘’Code‘’，generation'项，对于release版,选择'Multithreaded DLL',对于Debug版,选择’DebugMultithreaded DLL'。同样是在'C/C+ +'这个标签页，分类选择'C+ + langage'项，选择AllConfigurations,选择'Enable Run-Time Type Information (RTTI)'。

切换到'Link'标签页，选择配置项“Win32 Release"，在'Object/library modules'中添入需要的lib文件,即把“cppunit.ib testrunner.lib”加到后面，前面要有- - 个空格。选择配置项“Win32 Debug"，在'Object/library modules'中添入“cppunitd.libtestrunnerd.lib"。(Debug 模式为‘cppunitd.lib和testrunnerd.lib, Release 模式为cppunit.lib和testrunner.lib )。

4.测试代码

//声明一个TestSuite

CPPUNIT_TEST_SUITE(CellTest);
//添加测试用例到TestSuite,定义新的测试用例需要在这里声明一下
CPPUNIT_TEST(testgotoxy);
//TestSuite声明完成
CPPUNIT_TEST_SUITE_END();
Main.cpp
#include<iostream>
using namespace std;
#include "cppunit/extensions/TestFactoryRegistry.h"
#include "cppunit/ui/text/TestRunner.h"
#pragma comment (lib, "cppunitd_dll.lib")
//如果不更改TestSuite,则本文件后期不需要更改
int main()
{
CppUnit::TextUi::TestRunnerrunner;
//从注册的TestSuite中获取待定的TestSuite,没有参数获取未命名的TestSuite
CppUnit::TestFactoryRegistry&registry = CppUnit::TestFactoryRegistry::getRegistry("alltest");
//添加这个TestSuite到TestRunner
runner.gotoxyTest(registry.makeTest());
//允许测试
runner.run();
return 0;
}
CellTest.h
/*使用宏的CPPUNIT*/
#include "cppunit/extensions/HelperMacros.h"
class CellTest:public CppUnit::TestFixture
{
//声明一个TestSuite
CPPUNIT_TEST_SUITE(MathTest);
//添加测试用例到TestSuite,定义新的测试用例需要在这里声明一下
CPPUNIT_TEST(testgotoxy);
//TestSuite声明完成
CPPUNIT_TEST_SUITE_END();
public:
//初始化函数
void setUp();
//清理函数
voidtearDown();
//测试生命游戏的测试函数
void testRelive();
protected:
intm_value1,m_value2;
};
CellTest.cpp
#define CELLTEST_H
#ifdef CELLTEST_H
#include "cellTest.h"
#include "cppunit/TestAssert.h"
#endif
//把这个TestSuite注册到名为"alltest"的TestSuite中，如果未定义，则会自动定义
//也可以CPPUNIT_TEST_SUITE_REGISTRATION(CellTest)；注册到全局的一个未命名的TestSuite中
CPPUNIT_TEST_SUITE_NAMED_REGISTRATION(CellTest,"alltest");
void CellTest::setUp()
{
  init(int[][] shape) ;      // 初始化游戏 board 
　　    void tick();                    // 行进到在一个回合
　　    int[][] get();    
}
void CellTest::tearDown()
{
}
void CellTest::testRelive()
{
　　  int[][] shape = {{0, 0, 1}, {0, 0, 0}, {1, 0, 1}};
　　    Game g = new GameImplSample(shape);
　　    g.tick();
　　    // 自己死亡，周围3个存活状态，复活
　　    assertEquals(1, g.get()[1][1]);

}

5.测试结果分析

把point类的头文件和源程序加进去后，结果如下：（加了system("pause");）

“class”类型重定义；由于Point.h文件在一开始没有使用宏定义，导致运行测试类时显示Point.h重编译；解决办法将Point.h文件中加上宏定义#ifndef POINT_H #define POINT_H #endif即可。

思考题

比较以下二个工匠的做法，你认为哪种好？结合编码和单元测试，谈谈你的认识。

答：第一个工匠的方法更好，我们平时编写程序的时候都是按照工匠二的方式，整面墙都砌完了直接进行集成开发，经常让整面墙坍倒。单元测试长期以来被人们忽视，要测试一个类，最简单的方法是直接在调试器中使用表达式观察对象的值与状态，也可以在程序中加上一-些断言、打印中间值等，当然还可以编写专门]的测试程序。但是这些方法都有一个很大的局限性，都需要加入人工的判断和分析。由此，自动化测试的引入才是解决之道。正是因为如此，提倡"测试驱动开发"的人群，开发出一系列的自动化单元测试框架xUnit，现在已经有针对Java、Pyhton、C++、 PHP等各种常用语言的测试框架。可以很快的发现错误的测试。

实验小结

因为测试的案例本身就是一个exe工程，编译之后可以直接运行，非常的方便。编写测试案例变的非常简单(使用- 些简单的宏如TEST)，让我们将更多精力花在案例的设计和编写上。提供了强大丰富的断言的宏，用于对各种不同检查点的检查。提高了丰富的命令行参数对案例运行进行一系列的设置。

posted @ 2020-06-01 17:25 纪超超阅读(247) 评论(0) 收藏举报

刷新页面返回顶部

纪超超

实验五 单元测试