asp网站做视频,鹿城网络公司,打开网站弹出广告代码,前端与移动开发如何设计单元测试#xff1f;
单元测试设计方法
单元测试用例#xff0c;和普通测试用例的设计#xff0c;没有太多不同#xff0c;常见的就是等价类划分、边界值分析等。而测试用例的设计其实也是开发者应该掌握的基本技能。
等价类划分
把所有输入划分为若干分类
单元测试设计方法
单元测试用例和普通测试用例的设计没有太多不同常见的就是等价类划分、边界值分析等。而测试用例的设计其实也是开发者应该掌握的基本技能。
等价类划分
把所有输入划分为若干分类从每个分类中选取少数有代表性的数据做为测试用例。
例如一个方法计算输入参数的绝对值的倒数如果是输入是 0则抛异常。那么对这个方法写测试的话就应该有三个等价类输入是负数、0 以及正数。所以我可以选取一个负数、一个正数以及 0 来设计三个测试用例。
再举个例子某个方法是根据医生的认证状态发送不同的消息。那么等价类可能有三种未认证、普通认证但无权威认证、普通认证且权威认证某些情况下可能还会包括无普通认证但有威认证。
边界值分析
边界值是指划分等价类后在边界附近的一些输入数据这些输入往往是最容易出错的。
例如对于上面计算绝对值的倒数的例子那么边界值就包括 Integer.min、-1、0、1、Integer.max 等。再举个例子文本框输入范围为 1 - 255 个字符那么等价类按输入长度划分有三类 0、1 到 255、大于 255而边界值则包括 0、1、2、254、255、256 等。
其他类似于空数组、数组的第一个和最后一个、报表的第一行和最后一行等等也是属于边界值需要特别关注。
其他方法
除了上面提到的几种测试设计方法还有几种常用的
场景法。场景法是根据模块实际使用的场景例如 API 的实际调用方法、系统的实际需求场景和处理逻辑创建的用例。这种方法比较直观并且用例贴近实际需求的不可忽视。
错误推测。错误推测其实就是凭直觉考虑最容易出错的情况来设计用例。例如我们直到新用户、重复请求、并发、弱网、大数据量等情况都是非常容易出错的那么可以针对性的设计用例。错误推测需要测试设计者比较熟悉业务逻辑并且经验丰富。
其他还有因果图、正交法等方法这里就不说了。
覆盖率
如果按照前面的用例设计方法可能会设计出很多用例。我们不可能也没有必要把每一个用例都写成单元测试。
怎么确认用例是否足够呢一个很重要的参考指标就是代码覆盖率。
覆盖率指标
常用的覆盖率指标有四种
语句覆盖每条语句至少执行一次。
分支覆盖每个分支至少有一次为真、一次为假。
条件覆盖每个分支的每个条件至少有一次为真、一次为假。
路径覆盖对所有的分支、循环等可能的路径至少都要覆盖一次。
我们以这个简单的代码为例看看这四种覆盖率到底是什么意思。
if (a b) {
// X
}
// Y
if (c || d) {
// X
}
语句覆盖。只需要一个测试用例让 a b 和 c || d 都为真系统会依次执行 X、Y、Z 三个的代码段就能做到语句覆盖。
分支覆盖。至少需要两个测试用例让 a b 和 c || d 都各为真假例如用例1 a b 为真和 c || d 为假用例2 则反过来既可让两个条件分支都各为真一次为假一次。
条件覆盖。至少需要四个测试用例条件 a 和 b 的四种组合都要执行一次条件 c 和 d 的四种组合也都要执行一次。
路径覆盖。至少需要八个测试用例条件 a、b、c 和 d 的所有组合都要执行一次。
可以看到要做到条件覆盖甚至路径覆盖会需要非常多的测试用例。一般情况对于复杂的逻辑单元测试做到分支覆盖就不错了必要的话再做更多完全的覆盖。
Jacoco 覆盖
Jacoco 的覆盖率略有不同这里简单说一下。
指令覆盖Instructions覆盖所有的 Java 代码指令。
分支覆盖Branches和上面的分支覆盖基本是一样的。
圈复杂度覆盖Cyclomatic Complexity可以认为就是路径覆盖率。
语句覆盖Lines和上面的语句覆盖基本是一样的。
方法覆盖Methods覆盖所有的方法。
类覆盖Classes覆盖所有的类。
怎么写有效的单元测试
到现在相信大家对怎么写单元测试应该有一定概念了。但是很多人也会有疑问
单元测试耗费太多时间会不会降低生产效率
单元测试会不会很难维护比如修改代码时还总是需要修改单元测试。
关于第一个问题相信大家应该都能理解如果我们在开发时发现 BUG那么解决它是很容易的但是一旦到了集成、验收甚至上线之后那么要解决它就要花费比较大的代价了。业界很早就有共识并且有不少数据可以证明有效的单元测试虽然要花费更多编码时间但是可以很大的减少项目的集成、测试和维护成本。
注意上面提到很重要一点是单元测试必须是有效的如果我们发现单元测试很难维护那往往是因为我们没有写出有效的单元测试。
不是所有的代码都需要单元测试
写单元测试我们也需要考虑投入产出比例如下面这些情况写单元测试的投入产出比可能会较差。
短期的或者一次性的项目例如 Demo、数据更新脚本。
业务简单的不含太多逻辑的模块。例如获取或者查找一个数据或者没有分支条件的业务逻辑等。
UI 层相对而言比较难做单元测试除非 UI 本身就有比较复杂的逻辑其实某些 UI 框架也提供了单元测试工具。
那么那些情况下要写单元测试呢简单来说就是两类。
逻辑复杂、不容易理解、容易出错的模块。例如计算闰年的方法、订单下单等。
公共模块或者核心的业务模块。
即使对于需要写单元测试的模块我们也应该关注最核心最重要的测试用例而没必要单纯的追求覆盖率或者追求条件覆盖甚至路径覆盖一般做到分支覆盖就可以了。另外一个有效的方法是对于出现的每一个 BUG添加一个单元测试。
单元测试应该是稳定的
这里稳定的第一个含义是单元测试不应该经常需要修改。如果单元测试经常因为底层实现逻辑的变动而需要修改那一定不是好的单元测试。也就是说被测单元的接口应该是稳定的、设计良好的、易于扩展的。
稳定的第二个含义是单元测试的结果应该是稳定的。如果在不同的环境、不同的情况运行单元测试会返回不同的结果那就不是好的单元测试。如果测试需要依赖特定的数据、文件等那需要有前置的初始化脚本确保依赖的数据、文件在所有环境都存在并且是一致的。
单元测试应该是灰盒测试
单元测试应该覆盖核心逻辑的各种分支、边界及异常但是避免涉及易变的实现逻辑。也就是说我们不应该把单元测试当成完全的白盒测试但也不是黑盒测试而应该把它当成介于白盒和黑盒之间的灰盒测试。
被测代码应该是抽象良好的
如果我们发现一段代码很难编写单元测试常常是因为这段代码没有符合良好的抽象规范比如没有使用 DI、不符合单一职责原则、或者依赖了全局的公共变量和方法等等。我们可以考虑优化这段代码再来尝试单元单元测试。
谈谈到底什么是抽象以及软件设计的抽象原则 介绍了软件抽象的原则这里就不再重复了。
编码时就应该同时写好单元测试
这样我们才能在调试时就发挥单元测试的优势对代码的任何修改都能得到即时反馈。如果是后面再补充单元测试一方面对实现可能已经不太熟悉了编写测试的代价更大了另一方面单元测试能发挥的作用也变小了。不过即使这样对那些需要长远维护的项目编写单元测试也还是很有用的。
单元测试的代码质量也很重要
单元测试也是代码也是需要不断维护的。所以我们不应该随随便便的去写单元测试而是要把他们也当成普通代码一样要做到高质量、模块化、可维护。
为什么要写单元测试之终极原因
终极原因是作为一名优秀的工程师如果被 QA 和产品经理 Challenge 有 BUG能忍吗而我们工程师当然要用工程师 Style 的测试方法那就是自动化的单元测试了不是吗
文章来源网络 版权归原作者所有
上文内容不用于商业目的如涉及知识产权问题请权利人联系小编我们将立即处理
