标签:缺陷 ifd tox 单元 live 系统测试 相同 lte 测试环境
一、实验目的
1、掌握单元测试的方法
2、学习XUnit测试原理及框架
3、学习使用测试框架进行单元测试的方法和过程
二、实验内容与要求
1、了解单元测试的原理与框架
1.1单元测试原理
单元测试,是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如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语言编写的代码
2、结对编程的小组采用测试框架对自己“结对编程”实验的程序模块(类)进行单元测试,提交单元测试报告。
测试报告包括以下内容:
1)源码
2)测试用例设计 (结合单元测试的内容和模块功能设计测试用例)
3)选择的测试框架介绍、安装过程
4 )测试代码
5)测试结果与分析
3、push测试报告和测试代码到各自的github仓库
三、实验过程
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.测试用例设计 (结合单元测试的内容和模块功能设计测试用例)
3.选择的测试框架介绍、安装过程
(1)下载、解压cppunit
(2)进入cppunit目录下src文件夹,用vs2010打开CppUnitLibaries文件。
(3)修改目标文件名
右键cppunit,选择属性,在弹出窗口将目标文件名由$(ProjectName)改成$(ProjectName)d
将cppunit_dll的目标文件名改成cppunitd_dll
同样的将DllPlugInTester改成$(ProjectName)d_dll;将TestPlugInRunner的改成$(ProjectName)d;将TestRunner的改成$(ProjectName)d。
(4)修改DSPlugin
右键属性/配置属性/链接器/高级/无入口点,由“否”改成“是(/NOENTRY)”。
(5)修改TestRunner
打开TestRunner\UserInterface\ MsDevCallerListCtrl.cpp,在67行中将version由7.0改成8.0。
(6)编译生成lib库
选择生成/批生成,选择全选点击生成。
打开cppunit目录下lib文件夹。
4 .测试代码
(1)在vs2010中新建一个项目unit。
(2)在工程中添加被测试的头文件和cpp文件。
(3)在解决方案中添加一个测试项目。
(4)配置测试项目的属性
右击测试项目,选择属性,添加cppunit库文件和lib路径。
(5)添加cppunit.lib链接库。
(6)编写测试代码
//UnitTest.h #pragma once /*使用宏的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 startUp(); //清理函数 void tearDown(); //测试生命游戏的测试函数 void testRelive(); protected: intm_value1,m_value2; };
//UnitTest.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::startUp() { 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]); }
// Main.cpp #include "stdafx.h" #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®istry = CppUnit::TestFactoryRegistry::getRegistry("alltest"); //添加这个TestSuite到TestRunner runner.gotoxyTest(registry.makeTest()); //允许测试 runner.run(); return 0; }
5.测试结果与分析
6.push测试报告和测试代码到各自的github仓库
四、思考题
比较以下二个工匠的做法,你认为哪种好?结合编码和单元测试,谈谈你的认识。
答:我认为第一种做法比较好,开发时比较耗费时间但是节省了二次检查的时间,并且能确保代码成功运行;
第二种做法看起来节省时间,但是后期检查修改可能需要耗费大量时间,还有可能需要重新来过。
五、实验小结
同步本次实验,我了解了XUnit测试原理及框架,学习了使用测试框架进行单元测试的方法和过程。
但是还未完全掌握单元测试的方法,尤其是编写测试代码(好难),还需要继续学习相关知识。
标签:缺陷 ifd tox 单元 live 系统测试 相同 lte 测试环境
原文地址:https://www.cnblogs.com/lldkla/p/13022061.html