Exp5 单元测试

一、实验目的

1)掌握单元测试的方法

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

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

二、实验要求

2.1 单元测试原理

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

单元测试的内容包括

  模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

(1)模块接口测试

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

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

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

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

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

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

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

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

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

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

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

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

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

-文件属性是否正确; 

-OPEN/CLOSE语句是否正确; 

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

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

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

-是否处理了文件尾; 

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

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

-局部数据结构测试; 

-边界条件测试; 

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

(2)局部数据结构测试

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

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

-变量无初值; 

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

-不正确的变量名(拼错或不正确地截断); 

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

(3)边界条件测试

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

(4)独立路径测试

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

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

-混合类型运算; 

-变量初值错; 

-精度不够; 

-表达式符号错。

(5)错误处理测试

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

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

2.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)断言  

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

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

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

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

  unittest , PyUnit:主要测试用python语言编写的代码

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

三、实验内容

3.1  源码

import random


# 四则运算

def szys():
    sym = ['', '', '×', '÷']

    f = random.randint(0, 3)

    n1 = random.randint(0, 100)

    n2 = random.randint(0, 100)

    result = 0

    if f == 0:  # 加法

        result = n1 + n2
        
        if result >= 100:
        
            result = szys()
            
            return result

    elif f == 1:  # 减法,要先比较大小,防止输出负数

        n1, n2 = max(n1, n2), min(n1, n2)

        result = n1 - n2
        
        if result >= 100:
        
            result = szys()
            
            return result

    elif f == 2:  # 乘法

        result = n1 * n2
        
        if result >= 100:
        
            result=szys()
            
            return result

    elif f == 3:  # 除法,要比较大小,并循环取整除

        n1, n2 = max(n1, n2), min(n1, n2)

        while n1 % n2 != 0:
        
            n1 = random.randint(1, 10)

            n2 = random.randint(1, 10)

            n1, n2 = max(n1, n2), min(n1, n2)

        result = int(n1 / n2)
        
        if result >= 100:
        
            result = szys()
            
            return result
            
    if result <= 100:
    
        print(n1, sym[f], n2, '= ')

    return result


# 制作题库

def test():
    sym = ['', '', '×', '÷']

    print('输入所需要的题目数量')

    n = int(input())

    result = []

    m = 0

    while m <= (n - 1):
        print(m + 1)

        result.append(szys())

        print(' ')

        m = m + 1

    m = 0

    print('对应的答案:')

    while m <= (n - 1):
        print(m + 1, '', result[m])

        m = m + 1

print('欢迎使用在线四则运算系统')

print('选择想要的模式')

print('1、进行四则运算')

print('2、制作题库')

n = int(input())

# 当输入1时,进行四则运算,调用函数syzs()

if n == 1:

    a = 0
    
    x = 1
    
    print('输入题目数量')
    
    b = int(input())
    
    while x <= b:
    
        print('',x,'')
        
        result = szys()

        j = input()

        s = int(j)
        
        if s == result:

            print('right')
            
            a = a+1
        else:

            print('error.,the answer is', result)
            
        print('一共答对',a,'')
        
        x = x+1
        
    print('-------------再见-------------')
# 当输入2时,进行制作题库

if n == 2:
    test()

3.2 测试用例设计

程序有两个函数,一个是生成四则运算结果的函数,一个是生成题库的函数。生成四则运算结果的函数主要测试运算值在不在0~100之间,是否为空,是否为整数,生成题库的函数主要测试能不能生成有效的题库及运算结果正不正确。

用例描述 用例参数 期望结果
正常用例 0<t<100 测试通过
边界用例 t=-1 测试不通过
错误用例 t>100 测试不通过
用例描述 用例参数 期望结果
正常用例 断言不为空 测试通过
正常用例 断言为整数 测试通过
正常用例   测试通过

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

unittest是python自带的一个单元测试框架,类似于java的junit,基本结构是类似的。基本用法如下:

1.用import unittest导入unittest模块

2.定义一个继承自unittest.TestCase的测试用例类,如class xxx(unittest.TestCase):

3.定义setUp和tearDown,这两个方法与junit相同,即如果定义了则会在每个测试case执行前先执行setUp方法,执行完毕后执行tearDown方法。

4.定义测试用例,名字以test开头,unittest会自动将test开头的方法放入测试用例集中。

5.一个测试用例应该只测试一个方面,测试目的和测试内容应很明确。主要是调用assertEqual、assertRaises等断言方法判断程序执行结果和预期值是否相符。

6.调用unittest.main()启动测试

7.如果测试未通过,则会显示e,并给出具体的错误(此处为程序问题导致)。如果测试失败则显示为f,测试通过为.,如有多个testcase,则结果依次显示。

官方给的HTMLTestRunner库运行有问题,所以在网上重新下载了HTMLTestRunner库。

然后在设置里面把库来源改成Sources,这样就可以import自己写的模块

 

3.4 测试代码

#_*_coding:utf-8_*_
#author     :lenovo
#time       :2020/5/29 9:22
#file       :static.py
#IDE        :PyCharm
# static.py
import unittest
import HTMLTestRunner
import yunsuan

class Test(unittest.TestCase):

    @classmethod
    def setUpClass(self):
        print("execute setUpClass")

    @classmethod
    def tearDownClass(self):
        print("execute tearDownClass")

    def setUp(self):
        print("execute setUp")

    def tearDown(self):
        print("execute tearDown")

    def test_limit(self):
        print('execute test_limit')
        t = yunsuan.szys()
        assert 0 < t < 100

    def test_negative(self):
        print('execute test_negative')
        t = yunsuan.szys()
        t = -1

    def test_than(self):
        print('execute test_than')
        t = yunsuan.szys()
        assert t > 100

    def test_empty(self):
        print('execute test_empty')
        t = yunsuan.szys()
        self.assertIsNotNone(t)

    def test_integer(self):
        print('execute test_integer')
        t = yunsuan.szys()
        self.assertIsInstance(t, int)

    def test_test(self):
        print('execute test_test')
        m = yunsuan.test()


if __name__ == '__main__':
        suite = unittest.TestSuite()
        # Test是要测试的类名,test_one是要执行的测试方法
        suite.addTest(Test("test_limit"))
        suite.addTest(Test("test_negative"))
        suite.addTest(Test("test_than"))
        suite.addTest(Test("test_empty"))
        suite.addTest(Test("test_integer"))
        suite.addTest(Test("test_test"))
        # 实践中发现执行时的当前路径,不一定是此文件所在的文件夹,所以使用绝对路径
        # print(f"{os.getcwd()}")
        filename = 'D:\apptestresult.html'
        fb = open(filename, 'wb')
        runner = HTMLTestRunner.HTMLTestRunner(stream=fb, title="测试HTMLTestRunner", description="测试HTMLTestRunner")
        runner.run(suite)
        fb.close()

3.5 测试结果与分析

 可以看到测试结果在0到100内和不为负数通过,大于100不通

 测试结果不为空和为整数通过测试

 

3.6 push测试报告和测试代码到github仓库

思考题

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

答:我认为工匠一的做法好,因为在问题出现之前,分析、预见可能出现的问题。工匠一、二都知道砖有对不齐的可能,做为测试人员我们都知道,软件或多或少会有问题,如果能在开发之前预见开发过程中会出什么样的问题,测试将会有质的改变。开发人员根据测试人员所预见的问题开发,防止这些问题的发生。这是测试过程质的改变,测试不再是去找bug,而是引导开发避免问题的发生。测试的流程和作用也发生了改变,测试不是再等墙砌完了,推了再砌,而是和开发 一起努力,争许一次把墙砌好,要以最小返工率为目标。

实验小结

本次实验做了单元测试,通过测试认识到了在开发过程中经常做单元测试的重要性。也是第一次使用python测试工具库unittest,使用起来比较方便,只需要import工具包就行。由于代码比较少,函数模块也比较少,所以测试内容比较简单。

原文地址:https://www.cnblogs.com/cshgh/p/12995302.html