我是Java程序员出身,后来因为工作原因转到到了测试开发岗位。测试开发工作很多年后。针对标题的两个问题,我还有些发言权,特来说下:
1、什么是单元测试
2、该怎么做单元测试
单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。至于“单元”的大小或范围,并没有一个明确的标准,“单元”可以是一个函数、方法、类、功能模块或者子系统。单元测试通常和白盒测试联系到一起,如果单从概念上来讲两者是有区别的,不过我们通常所说的“单元测试”和“白盒测试”都认为是和代码有关系的,所以在某些语境下也通常认为这两者是同一个东西。还有一种理解方式,单元测试和白盒测试就是对开发人员所编写的代码进行测试。
提示:概念这个东西大概理解是什么意思即可~
想一想:前面我们介绍了,单元测试简单理解就是对开发人员所编写的代码进行测试,既然和代码相关我们第一感觉那应该是“开发人员来做”;再一看单元测试包含“测试”两个字,那么“测试人员来做”也应该是合理的吧。
单元测试一般是有开发人员或测试人员来做。谁来做并没有一个绝对的标准,要根据公司的实际情况来决定。接下来我们分析一下开发人员或测试人员做单元测试的优缺点:
- 现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
- 如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
- 可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
- 分享他们的经验,还会分享很多直播讲座和技术沙龙
- 可以免费学习!划重点!开源的!!!
- qq群号:110685036
单元测试的实现方式包括:人工静态检查、动态执行跟踪
人工静态检查包含的主要内容:
动态执行跟踪需要编写测试脚本调用业务代码进行测试,为了更好的管理维护测试脚本,一般会采用单元测试框架来管理,不同的语言有不同的单元测试框架:
单元测试的一个重要的衡量标准就是代码覆盖率,尽量做到代码的全覆盖。常见单元测试覆盖标准:
入门示例:针对开发人员编写的实现计算操作的方法进行单元测试
- # 开发人员编写的业务代码
- class CalUtil:
- """计算器"""
-
- @staticmethod
- def add(x, y):
- """加法"""
- return x + y
-
- @staticmethod
- def sub(x, y):
- """减法"""
- return x - y
-
- @staticmethod
- def mul(x, y):
- """乘法"""
- return x * y
-
- @staticmethod
- def div(x, y):
- """除法"""
- return x / y
-
- # 单元测试脚本
- import unittest
- from test_ut.cal import CalUtil
-
- class TestCal(unittest.TestCase):
- def test_add_01(self):
- # 测试数据
- x = 1
- y = 2
- expect = 3
-
- # 调用被测方法
- result = CalUtil.add(x, y)
- print(f"result={result}")
-
- # 断言
- self.assertEqual(expect, result)
-
- def test_add_02(self):
- # 测试数据
- x = 1
- y = -1
- expect = 0
-
- # 调用被测方法
- result = CalUtil.add(x, y)
- print(f"result={result}")
-
- # 断言
- self.assertEqual(expect, result)
-
- # ...
单元测试基本等同于白盒测试
敲字不易,如果此文章对你有帮助的话,点个赞收个藏,给作者一个鼓励。也方便你下次能够快速查找。