网瘾少年,野路子学的测试,擅长服务端

  • 理解下测试左移和右移,能在提测前提前介入到测试工作或者说在线上提高 “缺陷发现时间”、“问题定位时间”、“问题解决时间”

  • 如何让测试用例更有价值 at 2023年07月07日

    那你的测试过程不具备可靠性

  • 你这感悟没到位,接口测试想对于功能测试的价值是可以测到更细粒度,能更快发现底层交互问题,你去玩玩代码覆盖率看看哪些是覆盖到的 哪些没覆盖到的,再重新理解下接口层用例设计策略,为保障服务的高可用、高并发、稳定性、安全性、伸缩性等,细分来看包括:对外接口、内部交互接口、交互服务异常(三方、微服务或者中间件)、安全测试、故障演练、启动配置项等。

  • 不是向服务器 是向某个服务应用或者某个应用实例,先理解心跳原理,是通过什么协议传输,长连接还是无状态的 http,5s 一次和 1s 一次本质上除了频率是没啥区别。还有个点要确定下,你对并发的理解,1 个并发就是 1 个用户,1w 个就是 1w 用户噢,并发和 tps 不对等。

    要考虑 1w 并发的情况如果是长连接,那就是要满足 1w 个线程,1w 个长连接通道,能不能支撑 1w 消息通道同时传递处理,一台机子一般处理不了这么大的量,得换算成单机场景,单机能跑多少 考虑稳定性、可靠性,压测完后提供较有力得参考数据。脚本实现就是先建立好通道,服务端再短时间内一块发送消息包。

    如果是无状态的 http 请求,就是省略了建立通道的环节,直接发起请求,原理都差不多。

  • 仅楼主可见
  • 深一点的话,可以针对数据存储、服务依赖、服务异常做些故障演练,数据存储可以了解缓存穿透、击穿、雪崩,比方说在读取数据时数据正在删除中,会不会抛出捕捉不到的异常。服务相关的可以参考 panic 服务的场景考虑,比方说依赖的应用程序崩溃,在测试环境 kill -9 模拟,服务请求超时,依赖服务 connect fail 等。

  • 在 testCase 层定义个变量就好,没必要搞全量的数据驱动

  • 可以帮忙写单测

  • 感觉看到了曾经的自己,哈哈😂

    一开始我用的 unittest 框架写自动化脚本,跳槽以后心血来潮,想试试 jmeter,看看投入成本和产出是否成正比,也用 jmeter 整过接口自动化测试,写完第一版就发现维护成本很大,各种检索不便利,也没啥全局替换的功能。

    接着继续研究数据驱动,能否有效的提升测试脚本编写效率,如果是简单的 http 接口做点数据驱动效果确实明显,但如果遇到组合场景,不同协议的比方说 socket tcp udp,又或者说需要做参数转换参数加密,实现一些数据驱动反而新增很多框架 bug,投入的时间成本反而增加。

    之前也有搭过一整套自动化生成测试脚本的,只需要编写 excel,把所有服务交互的信息列出来,把所有输入输出分类好,base 概念,精准校验哪部分内容,还衍生出 AVU 的概念。那个 excel 是真的复杂,找个 985 高材生也要熟悉一个星期,才能介入进来,理解成本很大,框架搭建时也发现很多 bug。

    后来跳槽到这家厂,经常要做各种服务交接工作,有交接过 rf 的脚本、pytest 的脚本、unittest 的脚本或者没框架的脚本,现在编写脚本更多的是考虑快速定位、报告可读性、源码阅读成本。还是用回 unittest 的框架,引入比较基础的数据驱动,定义好团队编码规范,编码量虽然比之前数据驱动那些多,但时间成本反而更低,复制粘贴 2s,改个描述参数 30s,一条 case 就出来。

    接口自动化除了脚本框架外,核心其实还是用例设计,怎么设计用例才能保证代码覆盖率,更细粒度的场景能不能自动化,比方说服务与三方服务的异常交互,这样就衍变出单服务的自动化测试及测试思维,从单服务入手也能模拟各种故障演练,有时间的话可以研究研究这部分,比研究框架更有价值,框架够用就行。

  • 有研发经验转研发 不算测试转研,这种按正常的市场行情算就可以。如果是纯测试转研发,能平薪转拿到 offer 就已经很好了。

网瘾少年,野路子学的测试,擅长服务端