1）掌握单元测试的方法
2) 学习XUnit测试原理及框架；
3）掌握使用测试框架进行单元测试的方法和过程。
单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
单元测试的内容包括
模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素：
-输入的实际参数与形式参数的个数是否相同
-输入的实际参数与形式参数的属性是否匹配
-输入的实际参数与形式参数的量纲是否一致
-调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
-调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
-调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
-调用预定义函数时所用参数的个数、属性和次序是否正确；
-是否存在与当前入口点无关的参数引用；
-是否修改了只读型参数；
-对全程变量的定义各模块是否一致；
-是否把某些约束作为参数传递。
如果模块功能包括外部输入输出，还应该考虑下列因素：
-文件属性是否正确；
-OPEN/CLOSE语句是否正确；
-格式说明与输入输出语句是否匹配；
-缓冲区大小与记录长度是否匹配；
-文件使用前是否已经打开；
-是否处理了文件尾；
-是否处理了输入/输出错误；
-输出信息中是否有文字性错误。
-局部数据结构测试；
-边界条件测试；
-模块中所有独立执行通路测试；
检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
-不合适或不相容的类型说明；
-变量无初值；
-变量初始化或省缺值有错；
-不正确的变量名（拼错或不正确地截断）；
-出现上溢、下溢和地址异常。
边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高程序健壮性。
（4）独立路径测试
在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括：
-误解或用错了算符优先级；
-混合类型运算；
-变量初值错；
-精度不够；
-表达式符号错。
（5）错误处理测试
检查模块的错误处理功能是否包含有错误或缺陷。例如，是否拒绝不合理的输入;出错的描述是否难以理解、是否对错误定位有误、是否出错原因报告有误、是否对错误条件的处理不正确;在对错误处理之前错误条件是否已经引起系统的干预等。
通常单元测试在编码阶段进行。在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。
xUnit是各种代码驱动测试框架的统称,这些框架可以测试 软件的不同内容(单元),比如函数和类。xUnit框架的主要优点是,它提供了一个自动化测试的解决方案。可以避免多次编写重复的测试代码。底层是xUnit的framwork，xUnit的类库，提供了对外的功能方法、工具类、api等
TestCase(具体的测试用例)去使用framwork
TestCase执行后会有TestResult
使用TestSuite控制TestCase的组合
TestRunner执行器，负责执行case
TestListener过程监听，监听case成功失败以及数据结果，输出到结果报告中
Junit ： 主要测试用Java语言编写的代码
CPPunit：主要测试用C++语言编写的代码
unittest ， PyUnit：主要测试用python语言编写的代码
MiniUnit: 主要用于测试C语言编写的代码
使用Visual studio2019软件内的CppUnitTest不需要借助别的插件
#pragma warning(disable : 4996) #include <stdio.h> #include <stdlib.h> #include <time.h> int main() { int a, b, d, t; //定义两个操作数a,b，结果d，输入结果t char c; //运算符c可取“＋、－、×、÷” int i, sum = 0; //题目数量i,答对数目sum srand(time(0)); //初始化随机数发生器 for (i = 0; i < 10; i++) { a = rand() % 100 + 1; b = rand() % 100 + 1; c = rand() % 4; //0表加，1表减，2表乘，3表除 /**< 数据合格判断及算式显示 */ printf("第%d题：", i + 1); switch (c) { case 0: while ((d = a + b) > 100) //保证和在100内 { a = rand() % 100 + 1; b = rand() % 100 + 1; } printf("%d + %d = ", a, b); break; case 1: while (a > 100 || b > 100) //被减数小于100 { a = rand() % 100 + 1; b = rand() % 100 + 1; } if (a < b) //被减数大于减数 { d = a; a = b; b = d; } d = a - b; printf("%d - %d = ", a, b); break; case 2: while ((d = a * b) > 100) //保证积小于100 { a = rand() % 100 + 1; b = rand() % 100 + 1; } printf("%d × %d = ", a, b); break; case 3: while (a > 100 || b > 100 || (a * b == 0)) //保证被除数小于100且除数不为0 { a = rand() % 100 + 1; b = rand() % 100 + 1; } if (a < b) //被除数必须大于除数 { d = a; a = b; b = d; } a = (a / b) * b; //保证整除 d = a / b; printf("%d ÷ %d = ", a, b); break; } /**< 输入你的计算结果 */ scanf("%d", &t); if (d == t) { sum++; printf("正确\n"); } else printf("错误\n"); } /**< 输出答对题数和得分 */ printf("答对 %d 题，得分：%d\n", sum, sum * 10); return 0; }
产生和为100内的加法设计正常测试用例
乘积小于等于100,测试用例
3*3=9
0乘用例
0*3=0
边界测试用例
10*10=100
11*10=110
100以内除法，除数不可为0且必须整除
测试用例
24/8=3
不可整除用例
5/3=1
被除数为0用例
0/3=0
由于除数生成有0值判断，会提示异常，且代码内已避免此情况，此处不做处理
首先创建新项目
右键点击“解决方案”->"添加"->“新建项目”继续选择“本机单元测试项目
然后选择属性选择“链接器”->"输入"->"选择依赖项"
右键选中引用，点击“添加引用”勾选需要引用的项目.
开始编写程序
#include "pch.h"
#include "CppUnitTest.h"
#include "..\Project5\源.cpp"
using namespace Microsoft::VisualStudio::CppUnitTestFramework;
namespace UnitTest1
{
TEST_CLASS(UnitTest1)
{
public:
TEST_METHOD(add)
{
Assert::AreEqual(add(82, 13), 95);
Assert::AreEqual(add(63, 23), 86);
Assert::AreEqual(add(63, 83), -1);
}
TEST_METHOD(Sub)
{
Assert::AreEqual(sub(15, 3), 12);
Assert::AreEqual(sub(70, 29), 41);
Assert::AreEqual(sub(65, 79), -1);
}
TEST_METHOD(Multiply)
{
Assert::AreEqual(multiply(1, 65), 65);
Assert::AreEqual(multiply(3, 9), 27);
Assert::AreEqual(multiply(13, 9), -1);
}
TEST_METHOD(Divide)
{
Assert::AreEqual(divide(99, 11), 9);
Assert::AreEqual(divide(50, 2), 25);
Assert::AreEqual(divide(70, 8), -1);
}
};
}
测试结果:
测试均通过
比较以下二个工匠的做法，你认为哪种好？结合编码和单元测试，谈谈你的认识。
我觉得工匠一的做法好,在问题出现之前，分析、预见可能出现的问题。将整个设计思路、大致方向、以及细致的模块划分做好，有条有理的去一步步完成，这样最后编码结束的时候，也会给后续的测试，优化以及扩展提供很大的帮助，节省成本。
本次实验主要是做了单元测试的工作，使用了一些单元测试的办法来查找程序可能出现的bug，经过了这次测试，我明白了模块化设计的作用，不仅仅是方便维护检查，也方便测试，更有利于程序的稳定。
原文：https://www.cnblogs.com/lv000/p/13032711.html