实验五:单元测试

一、实验目的
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.测试代码。考虑到这次实验主要是进行代码测试,因此选择了比较简单的代码来进行测试。

源码:#include "stdafx.h"
#include "CppUnittest.h"
#include "../Calculator/Calculator.h"
 
using namespace Microsoft::VisualStudio::CppUnitTestFramework;
 
namespace UnitTest1
{
TEST_CLASS(UnitTest1)
{
public:

TEST_METHOD(TestMethod1)
{
// TODO: 在此输入测试代码
Cal test;
int x = 4, y = 7;
Assert::AreEqual(11, test.add(x,y));
Assert::AreEqual(-3, test.sub(x, y));
Assert::AreEqual(28, test.mul(x, y));
Assert::AreEqual(0, test.div(x, y));
}
 
};
}

2.安装测试及过程

(1)下载cppunit后,将其解压,,然后进入解压后的文件夹下的src文件夹里,打开CppUnitLibraries.dsw文件。vs会询问是否转换,选择yes.

 

 (2)修改目标文件名

右键cppunit,选择属性,在弹出窗口将目标文件名由$(ProjectName)改成$(ProjectName)d,如下图所示

 

 

 按照同样的方式,将剩余的文件进行改名,如下图:

 

 

 

 

 

 

 

 (3)修改DSPlugIn,右击DSPlugin->属性->配置属性->链接器->高级->无入口点,由“否”改成“是”。如图。


(4)修改TestRunner
在vs中打开TestRunner\UserInterface\ MsDevCallerListCtrl.cpp,在67行中将version由7.0改成8.0,如下

 

 (5)编译lib库

在vs中选择生成-->批生成,全选后点击生成,如下

 

 (6)查看cppunit-1.12.1\lib文件夹,是否有编译后的文件:

 

 有,则说明安装成功。

(8)头文件代码:

class Cal
{
public:
int add(int x, int y);
int sub(int x, int y);
int mul(int x, int y);
int div(int x, int y);
}

 

 

(9)主文件代码:

#include "pch.h"
#include "Calculator.h"
#include <iostream>
 
int Cal::add(int x, int y)
{
return x + y;
}
int Cal::sub(int x, int y)
{
return x - y;
}
int Cal::mul(int x, int y)
{
return x * y;
}
int Cal::div(int x, int y)
{
return x / y;
}
int main()
{
return 0;
}
3.生成单元测试程序

1)右击解决方案”Calculator“(1个项目),选择添加-新建项目,添加头文件和源文件

 

 

 

 

 (2)在新打开的窗口中选择测试-测试项目,修改名称和位置

 

 

 (3)此时,可以看到解决方案中变成了2个项目,一个是我们本来的Calculator程序,一个就是刚才新生成的名为“Unittest1”的用于单元测试的程序。

 

(4)右击UnitTest1下的引用,选择添加引用,在新打开窗口中将 Calculator 程序添加进去。

 

(5)右击解决方案栏中的 Calculator ,选择属性,将常规-项目默认值-配置类型修改为 静态库(.lib)

 

 

 4.代码测试

 

 对该程序进行测试,结果如下:

 

发现有错,修改后,错误删除,可以正常运行

 5.代码存放

思考题

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

 

 

 答:根据不同场景有不同的选择。工匠一适用于时间充裕需要对场景有高需求的情况,工匠一在现实情况中适用于科研,开发等场地的建造。而

工匠二适用于时间急迫且不需要高需求的情况,实际上在现实生活中,我们更趋向于工匠二。因为对于我们大部分人来说,不能看做到的每一步

都十分精准,因此我觉得二更好。

 

实验小结:通过这次单元测试的实验,我发现难度超出了前几次的实验,不仅是对前面知识能力的巩固,更是对新的

开发软件的掌握。难的不仅是新软件的应用,代码也是考验程序员编程能力的重要指标,因此在这最后一次的实验上,

我更加的认识到了自己的不足。

 

posted @ 2020-06-01 18:09  迷路的橘子  阅读(187)  评论(0编辑  收藏  举报