02 2021 档案

摘要:VI.测试用例模块case.py TestCase也是个神奇的类, 或者说是个蝙蝠类.既是哺乳动物又是鸟类 5.1 长得就是一只鸟 class TestCase(object): def __init__(self, methodName="runTest"): pass def addCleanu 阅读全文
posted @ 2021-02-10 12:22 O万山 阅读(138) 评论(0) 推荐(0)
摘要:V.测试套模块suite.py 测试套模设计的比较尴尬, 按照名称应该是测试套件的组织,应该只有一个协议或者范式声明. 然鹅, 他和 用例模块case.py也身兼用例组织和用例驱动执行的功能. 甚至, suite范式声明的码量很少. 大部分工作是测试 执行. 基类BaseTestSuite功能很单一 阅读全文
posted @ 2021-02-10 10:51 O万山 阅读(138) 评论(0) 推荐(0)
摘要:III.测试驱动模块runner.py runner模块主要功能是: *.初始化result将测试结果记录和处理转交给result模块;(详参后续result模块lifecycle) *.启动测试套运行, 将run动作传递给TestSuit模块的__call__函数; *.统计result结果, 向 阅读全文
posted @ 2021-02-09 17:44 O万山 阅读(139) 评论(0) 推荐(0)
摘要:I.unitest源码 unittest .. | __init__.py | __main__.py | case.py # 用例组织模块 | loader.py # 测试用例嗅探模块 | main.py # 脚本主入口 | result.py # 测试结果维护 | runner.py # 测试运 阅读全文
posted @ 2021-02-09 16:41 O万山 阅读(206) 评论(0) 推荐(0)
摘要:【引子】 项目从自研(造轮子)的测试框架切到nosetests, 起初的感觉只是解决了自制轮子基类全局变量管理和状态切换问题. 直到被fixture的抽象惊艳到了. 自制的轮子是假设所有用例之间独立, 用例内部负责测试场景构造,测试点,战场打扫和异常处理,如下. 1 class TestCase(o 阅读全文
posted @ 2021-02-09 14:51 O万山 阅读(103) 评论(0) 推荐(0)
摘要:【问题背景】: Jenkins job过多导致pipline过多无法维护, 考虑实现归一化版本控制. 分离job配置数据和jenkins流程, 把pipline主逻辑流程代码化, 使得修改维护简单&同时避免误修改导致的无意义工作. 具体方案: 1.抽离数据, 将配置数据集中存放在$JENKINS_H 阅读全文
posted @ 2021-02-01 11:54 O万山 阅读(1469) 评论(0) 推荐(0)