为什么需要这些测试
1. 不同维度的,基本功能正确性的验证
用自动化方式测试基本功能,
2. 防止代码过快腐化
为什么会产生腐化: 缺乏维护、长期技术债堆积、缺乏文档、缺少代码敬畏感、技术方案变更
3. 防护网:重构、新功能迭代
重构:技术更新、方案更新、非技术原因组件替换等
主要用户回归测试
4. 特殊场景的记事本
产品开发、测试、上线、使用过成中,都会有为了fix某种异常场景的code, 为了防止后续迭代中遗漏这些逻辑,可以通过UT、IT、ST来保证,尤其是IT和ST
5. 一个比喻: 多层防护
UT: 绿色防护网,颗粒度最小,能防护细节,但不能撑起整个框架,通常只用于函数级别的测试
IT/ST 黄色框架防护,支撑整个框架, 但无法防护一些扳手等小物件的跌落, 同样用于系统级别或者场景级别测试
(IT/ST: 一般区别一个模块间和模块内,具体叫法,不同公司不同业务线不同叫法。也有不区分ST IT的)
测试用例的代价
开发过程中,测试用例代码量 >> 产品代码(一般1:5 - 1:10)
代码重构过程中,涉及到大量测试用例的重构
开发过程中的测试,一般都会集成到CI流水线,增加CI维护成本、机器成本、以及代码提交成本
UT&ST一般做法
UT: 采用gtest框架直接测试;函数中依赖的其他模块, 一般采用gmock方式,来mock掉接口
2. ST/IT: 采用stub的方式来模拟
2.1 mock和stub区别,哪些场景下mock满足不了
2.1.1 mock方需要主动做一些业务逻辑,一些动作: pub、定时任务等
2.2.2 mock方需要根据请求方的参数或场景,返回不同值(这里当然可以使用手动算出来mock值, 代码复用程度低、case难度大)
2.2 stub测试框架中组成:
1. stub: 用于模拟被测方所依赖的外围模块,每一个所依赖的模块都是一个stub,stub为scenario提供一些配置接口,通过接口调用配置不同业务逻辑
2. scenario: 用于测试不同场景,每一个scenario相当于一个测试的case, scenario中调用stub接口来配置该case下stub行为, 来模拟N多场景(比如说在case1中 stub pub消息5次/S, 在case2中不pub消息, case3中收到某个消息后才pub消息)
3. stub和scenario通道: 直接调用还是RPC, 这个主要依赖于测试粒度,一般intra module内都采用直接调用, inter modlue采用RPC
3. TTCN:大型产品会采用TTCN专门用于场景测试的语言来编写case, 特别是通信协议栈
关于CI(sanity测试、冒烟测试,会涉及CD)
1. UT ST IT这些测试都属于研发侧的测试,都会部署在CI流程中,设置为代码提交的门禁
2. 在大量版本迭代后,包括产品代码和测试代码的迭代。 经常会产生unstable case,这些case只有在特定的环境下才会复现,对于这种case一般无法立即修复,可能N天或者一周之内修复
关于压力测试
1. 压力测试分为两个目的:对业务逻辑的压力测试, 和对系统平台的压力测试
2. 业务逻辑的压力测试: 采用多次方式, 乱序方式(对于测试用例编写要求较高), 跑完后统计失败case、内存占用、过程中处理延迟变化等
3. 系统平台压力测试: 采用极大值方式:文件size巨大、任务量巨大、QPS巨大、CPS巨大等方式模拟
关于稳定性测试
1. 在业务逻辑压力测试的场景下,也会对业务的稳定性做一定测试
2. 通过mock或者stub来模拟所依赖模块, 设置模块的极限值来测试系统的稳定性, 比如: 请求超时场景下, 产品代码侧超时的同时stub发出响应、 stub侧的响应秒回等场景
其他测试:
sanity测试、冒烟测试、TTCN# 欢迎使用Markdown编辑器
你好! 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章,了解一下Markdown的基本语法知识。