标签:tca 复位 dcl 组织 子类 维护 cleanup sts image
【引子】 项目从自研(造轮子)的测试框架切到nosetests, 起初的感觉只是解决了自制轮子基类全局变量管理和状态切换问题. 直到被fixture的抽象惊艳到了.
自制的轮子是假设所有用例之间独立, 用例内部负责测试场景构造,测试点,战场打扫和异常处理,如下.
1 class TestCase(object): 2 def prepare_scenario(self): 3 print("Prepare resources and scenarios") 4 5 def do_test(self): 6 print("Execute test point and assertions") 7 8 def clear_scenario(self): 9 print("Clear resource and restore test env as testcase never happen") 10 11 def handler_fail_and_exeception(self): 12 print("Clear resource and restore test env, even if happen" 13 "to failure and execptions")
用例结构需要解决的问题: a.测试用例场景准备;b.测试结果管理(如计时器,统计结果,记录测试用例结果);c.失败和异常场景处理.
显而易见, 这个粗糙的结构需要花大量精力解决这三个问题. b问题还好, 无非是多抽一层, 将结果管理随测试用例的lifecyle的过程关联起来.
ac两个问题存在致命缺陷:
1.资源和时间开销巨大: 用例之间独立每个用例自己处理好资源准备和清理会造成大量前置后置动作消耗测试时间, 并发执行也会消耗大量被测资源.
2.准备和恢复环境代码不可维护: 异常处理与过程强耦合, 在不同的阶段失败或者异常, 需要做不同的处理.
【unittest】python标准包unittest优雅的解决了(借鉴JUnit&Smalltalk testing framework)以上问题.他做了以下假设和抽象:
* fixture: 测试用例是以测试用例族的形式组织的. 用例族是一个迭代概念, 对标模块包. 包的层级是可迭代的, 包的父子祖孙关系巧妙的解决了共享资源问题.
* testsuite&testcase: 测试套件和测试用例的概念如上图. 测试用例为unittest.case.TestCase的子类, TestCase内部以test*开头的函数(可以通过load_tests协议自定义)
是单个测试用例, 一组相关联系的测试用例通过TestCase类组合在一起. 在实际测试场景中可以解决大部分的测试测试场景.
如: 裸金属的测试.一个裸机的创删各需要半小时以上,按照之前的组织形式, 要创建4台裸机, 测试完成后删除还有开销.
TestCase类有setUp tearDown setUpClass tearDownClass两对fixture. 在用例类执行开始setUpClass 准备创建裸机, 类执行完毕tearDownClass销毁裸机.
用例函数之间: 用例结束后清理掉函数作用域的资源, 用例开始的时候做些复位动作.
* addSetupCleanup & addCleanup: 临时资源栈记录类&函数作用域的局部资源栈, 在失败或者异常后知道需要如何清理哪些资源.
* modue * package: 包和模块间也是同族关系, 也可以通过setup & teardwon管理公共资源.
class TestCase(object): def addCleanup(self, function,, *args, **kwargs): print("将清理动作入局部作用域资源栈") def doCleanups(self): print("将局部作用域资源栈释放") def setUp(self): print("用例函数执行的前置动作") def tearDown(self): print("用例函数执行的后置动作") @classmethod def setUpClass(cls): print("用例类的准备动作") @classmethod def setTearDown(cls): print("用例类的后置清理动作")
标签:tca 复位 dcl 组织 子类 维护 cleanup sts image
原文地址:https://www.cnblogs.com/woruo/p/14392954.html