摘要：原则具体包括自动化独立性可重复简单的解释一下三个原则单元测试应该是全自动执行的。为了保证单元测试稳定可靠且便于维护，需要保证其独立性。原则编写单元测试用例时为了保证被测模块的交付质量需要符合原则。与设计文档相结合来编写单元测试。
本文首发于泊浮目的专栏：https://segmentfault.com/blog...背景
最近项目在测试阶段陆陆续续的测出了一些bug.这个情况刚出现的时候,让笔者很困惑——平时我们的每个feature代码都是跟随着大量看起来考虑很周全的case进入代码仓库的,然而事实还是打了我们的脸.故在本文,笔者将会从最近的所学所想来谈谈编写测试的时候我们应该注意什么.
AIR原则与BCDE原则前阵子看了一本书,里面提到了单元测试的一些原则:
宏观上,单元测试要符合AIR原则
微观上,单元测试的代码层面要符合BCDE原则
AIR原则AIR即空气,单元测试亦是如此。当业务代码在线上运行时,可能感觉不到测试用例的存在和价值,但在代码质量的保障上,却是非常关键的。新增代码应该同步增加测试用例,修改代码逻辑时也应该同步保证测试用例成功执行。AIR原则具体包括:
A: Automatic (自动化)
I: Independent (独立性)
R: Repeatable (可重复)
简单的解释一下三个原则:
单元测试应该是全自动执行的。测试用例通常会被频繁地触发执行,执行过程必须完全自动化才有意义。
如果单元测试的输出结果需要人工介入检查,那么它一定是不合格的。单元测试中不允许使用System.out等方法来进行人工验证,而必须使用断言来验证。
为了保证单元测试稳定可靠且便于维护，需要保证其独立性。用例之间不允许互相调用,也不允许出现执行次序的先后依赖。
BCDE原则编写单元测试用例时,为了保证被测模块的交付质量,需要符合BCDE原则。
B: Border,边界值测试,包括循环边界、特殊取值、特殊时间点、数据顺序等。
C: Correct,正确的输入,并得到预期的结果。
D: Design,与设计文档相结合,来编写单元测试。
E: Error,单元测试的目标是证明程序有错,而不是程序无错。为了发现代码中潜在的错误,我们需要在编写测试用例时有一些强制的错误输入(如非法数据、异常流程、非业务允许输入等)来得到预期的错误结果。
在ZStack白盒集成测试中实践原则之前提到的原则是基于单元测试的,但在ZStack的白盒测试中也可以作为有价值的参考.
戳此了解ZStack的白盒集成测试:https://segmentfault.com/a/11...
由于ZStack的整套测试框架也是基于Junit扩展而来,因此也是一定程度上遵循了上面提到的AIR原则.除了A原则,I和R原则在一定程度上打了折扣:
I: 如果上一个测试没有清理干净状态,则会影响下一个测试
R: 基于上面提到的I,很有可能导致可重复性大打折扣
当然,出现这些问题时则表示当前的代码中有bug.但单元测试则不会受到这样的影响——它能测出bug,AIR原则也得以保证.
在本次示例中,我们将以VmInstance的创建API即——APICreateVmInstacneMsg作为测试对象.如果读者不是很了解上下文,也可以简单的看一下这个Case:OneVmBasicLifeCycleCase
Border Test && Error Test边界测试是用来探测和验证代码在处理极端的情况下会发生什么.而错误测试为了保证ZStack在一些错误的状态下做出我们所期待的行为.
那么我们该如何编写这样的测试呢?我们先来简单的理一下创建Vm的流程:
VmImageSelectBackupStorageFlow
VmAllocateHostFlow
VmAllocatePrimaryStorageFlow
VmAllocateVolumeFlow
VmAllocateNicFlow
VmInstantiateResourcePreFlow
VmCreateOnHypervisorFlow
VmInstantiateResourcePostFlow
而其中每一个步骤可以分成好几个小步骤,以VmAllocateHostFlow为例:
我们可以看到,根据不同的策略,allocateHost里还会有好几个flow.而由于松耦合架构,我们可以在测试中轻易的模拟极端问题的出现,如:
找不到合适的BackupStorage
HostCapacity的不够
Agent返回的回复在某一个时刻与管理节点的状态不同
.......
以此类推,以上创建vm的8个flow都可以轻易模拟各种边界条件及错误情况.
Correct Test && Design Test正确性测试听起来应该会很简单,(比如调用一个API,然后看结果返回是否正确)但如果放到集成测试中,我们还是可以拓展出一些额外的关注点的.还是以上面提到的createVm为例子,我们看到了8个flow,然后里面可能还嵌套着好几个子flow.如图所示:
在编写正确性测试时,我们可以考虑额外关注以下几点:
APIParam在各个Flow间中转时是否如预期
关注管理节点内的服务:
Flow之间调用的时序是否符合预期
Flow之间流转时,业务目标状态是否符合预期
关注管理节点外的服务:
对于agent的请求是否符合预期
在API调用完后,相关资源的目标状态是否符合预期
而与文档结合的测试用例,则应当由团队的测试人员来定义.可以确定的是,这类的测试更加关注于API(即输入输出),而不是内部的状态.
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/77462.html
摘要：再谈移动端适配百分比解决方案的缺点在我们的项目中大量的使用百分比来解决页面在宽度上的自适应，其实在高度上并没有很好的自适应。 前言 这篇文章的内容如题目一样，主要分为两个部分， 谈谈业内主流的移动端适配解决方案 点5像素的由来和实现方法 建议在读这篇文章的时候先读下这篇文章《高清屏概念解析与检测设备像素比的方法_20161005》，因为这些文章涉及的很多概念在这篇文章中都会提到。 ...
摘要：阿里云效平台基于理念的私有平台实践本文将系统的从个方面，分享互娱运维团队对于运维平台实践经验及未来展望，希望对大家有一些参考意义。 CI Weekly 围绕『 软件工程效率提升』 进行一系列技术内容分享，包括国内外持续集成、持续交付，持续部署、自动化测试、 DevOps 等实践教程、工具与资源，以及一些工程师文化相关的程序员 Tips 。同步于 flow.ci Blog、微信公众号、官...
摘要：注意这种只能发生在单参数构造函数中举个例子创建一个类，类该类如下，有个单参数的构造函数。默认构造函数当构造函数不带参数时，我们就把这个构造函数叫做默认构造函数。 前...
阅读 568·2021-11-19 11:29
阅读 3201·2021-09-26 10:15
阅读 2711·2021-09-22 10:02
阅读 1758·2021-09-02 15:15
阅读 1802·2019-08-30 15:56
阅读 2084·2019-08-30 15:54
阅读 2741·2019-08-29 16:59
阅读 526·2019-08-29 16:20
