单元测试一般以白盒为主,测试的依据是单元测试

什么是单元测试？单元测试是什么
单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确，通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为
单元测试的好处
1，单元测试不但会使你的工作完成得更轻松。而且会令你的设计会变得更好，甚至大大减少你花在调试上面的时间 2，提高代码质量 3，减少bug，快速定位bug 4，放心地修改、重构
写单元测试要注意什么
1，不能只测试一条正确执行路径，要考虑到所有可能的情况
2，要确保所有测试都能够通过，避免间接损害
3，如果一个函数复杂到无法单测，那就说明模块的抽象有问题
4，配置不是单元测试的难点，难点是mock（后文讲），做单元测试需要伪造被测函数用到的大部分函数
为什么写单元测试
编写单元测试太花时间了？考虑下面问题：
1，对于所编写的代码，你在调试上面画了多少时间？
2，对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你画了多少时间在重新确认这些代码上面？
3，对于一个别人报告的bug，你花了多少时间才找出导致这个bug的源码位置？
对于那些没有使用单元测试的程序员而言，上面这些问题所耗费的时间的递增速度是很快的，而且随着项目深入，递增速度会变得更快；而另一方面，适当的单元测试却可以很大程度地减少这些时间，从而为你腾出足够的时间来编写所有的单元测试——甚至可能还有剩余的空闲时间。
单元测试到底是什么?应该怎么做？单元测试一般是有开发人员或测试人员来做。谁来做并没有一个绝对的标准，要根据公司的实际情况来决定。
单元测试的实现方式包括：人工静态检查、动态执行跟踪。
人工静态检查：就是通常所说的“代码走读”，主要是保证代码逻辑的正确性。
动态执行跟踪：就是把程序代码运行起来，检查实际的运行结果和预期结果是否一致。
开发人员做单元测试：
优点：开发人员对代码最熟悉，而且开发人员编程技能相对比较强，所以开发人员自己写单元测试效率上和覆盖率上都比较高。
缺点：开发人员平时写业务代码就要花费很多时间，有时候确实没有时间写单元测试；而且大部分开发人员没有太好的测试思想，单元测试可能只是写个最简单的用例就完了；自己写的代码自己测，往往都是不靠谱。
测试人员做单元测试：
优点：测试人员有比较系统的测试思想，可以更好地保证用例的覆盖。而且通过写单测测试能更好地了解具体代码结构、流程，对于后续的业务测试也非常有利。
缺点：测试人员的编程技能相对比较弱，如果不同编程是无法开展单元测试的。并且测试人员对代码没有开发人员熟悉，效率会比较低。

文章插图
单元测试的策略有哪些逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
单元测试是对软件基本组成单元进行测试，
这里的基本单元不一定是指一个具体的函数
（
Function
或
Procedure
）
或一个类的方法，
“
单元
”
具有一些基本属性，
如：
明确的功能、
规格定义，明确的接口定义，可清晰地与同一程序的其它单元划分开来。
在纯
C
语言的代码中，为了操作方便期间，我们一般认为一个函数就是一个单元。
1.2.2
单元测试的主要目的：
1.
验证代码是与设计符合的
2.
跟踪需求和设计的实现
3.
发现设计和需求中存在的错误
4.
发现在编码过程中引入的错误
1.2.3
何时开展单元测试
一般地，
在编码阶段就应开展单元测试，
边写程序边测试是一个好习惯。
一个组织不要
孤立的划分出编码和单元测试两个阶段，也不要等代码都写完了才开始单元测试。
有时候需要将单元测试时间推后到集成阶段，甚至系统完成阶段。
单元测试可以分为计划、设计、实现、执行几个阶段。
“
计划
”
是作好人和时间的安排。
“
设计
”
确定采用什么样的测试方法，
达到一个什么样的覆盖率标准等。
“
实现
”

单元测试一般以白盒为主,测试的依据是 单元测试

秒懂生活扩展阅读

单元测试一般以白盒为主,测试的依据是单元测试