BeansKingdom

​ 记录下 Shell 中常见的几种 判断字符串A是否包含字符串B的方法。

背景

​ 在大部分的编程语言中都支持 “键值对” 的这种数据结构，比如：Python中的dict、Java中的HashMap等等。对于Shell中实际也是存在类似的这种用法，也就是 “Shell关联数组“。

​ 刚好最近在写Shell脚本的时候使用了该功能，便进行相关使用方法以及注意点的记录。

背景

​ 在使用Jmeter进行一些高并发的压测时候，请求参数重需要构造唯一的订单ID。

​ 开始时使用了 ${__Random(100000,999999,)} 以及 __time() 的组合来生成唯一订单ID，但由于TPS较大的情况下，最终导致了出现重复订单ID😂。。。

于是梳理了下后续可能压测的场景，根据此方案制定了最终的解决方案。后续可能压测的场景如下：

• 场景一：一个线程组中存在多个线程并发生成唯一ID；
• 场景二：多个线程组 + 每个线程组中是多个线程并发生成唯一ID；
• 场景三：多个Jmeter脚本 + 多个线程组 + 每个线程组中是多个线程并发生成唯一ID；

背景

​ 最近在搭建混沌工程所需要的专项测试环境，原来一般都是直接通过 nohup + & 的方式，但该方式存在一个问题，如果由于服务器重启或者进程被kill掉了，那这个时候就需要再手动的去启动相应的进程。 这样对于只有一两个进程来说还好，但对于需要维护很多台虚拟机或者很多进程的时候则会比较繁琐。所以便牵扯到守护进程一一Supervisor。

背景

​ 公司开始推荐相关阅读书籍，其中有一本书的要求是：“针对该行业的入门级必读书籍”，回头一看自己看过很多相关测试的书籍（囫囵吞枣模式┑(￣。。￣)┍ ），但确实没法一下说出来哪本书属于入门级必读书籍（毕竟自己刚进入测试行业的时候，完全是来靠自己摸爬滚打，在整个工作经验中慢慢的阅读相关书籍😂，当时也没有想到要针对性的指导自己去学习测试这门技术）。

入门级人群的定义

​ 入门级必读书籍面对的人群我个人认为大概画像是：从未接触过测试或刚进入测试行业的人群（不一定工作年限为0，可能存在其他领域转到测试行业）。

背景

​ 最近比较频繁的在虚拟机上搭建环境，由于默认虚拟机上都是部署的 Python2，所以涉及到了 Python3.7 的安装，此处进行一个过程的记录，方便后续的查看。

系统环境

1
2
3
4
5

[root@41c0abcd92d8 tools]# cat /etc/centos-release
CentOS Linux release 7.9.2009 (Core)

[root@41c0abcd92d8 tools]# uname -a
Linux 41c0abcd92d8 5.10.47-linuxkit #1 SMP Sat Jul 3 21:51:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

背景

​ 在一次处理Python中List长度为5W+的特殊场景中，发现函数执行时间很长，大概花费了8秒，明显与平时的执行时间存在较大差距（几乎是毫秒级别）。通过Debug后发现具体耗时较多的代码如下：

1
2
3
4

while len(nums) > 0:
	first_num = nums.pop(0)		# 最终定位到原因在该行代码
  # 对 first_num 进行一系列的处理
  ...

通常情况下，调用pop()与pop(-1)的时间复杂度都为1，但pop(N) （0<=N<len(list)-1）的时间复杂度却是 N。所以硬生生的把一个原本时间复杂度只有O(n)的变成了O(n²)。

背景

​ 最近正在风风火火的弄混沌工程😂，在弄到网络延迟、丢包的故障注入时，需要进行故障验证。如果仅仅是网卡层面的话，直接通过 ping 的方式即可，但现在需要的是知道具体某个 IP + PORT 的延迟。

​ 还好在这百试不厌的GOOGLE下，找到了一个小众工具 一一 paping，比较好的解决了我的问题，下面先配一个效果图。

背景

​ 公司的测试工具平台开发也快一年了，积累的功能也越来越多，最近刚好需要对测试用例平台模块的相关功能进行修改。 修改的过程真的是痛苦。。。虽然原来已经看过一遍clean code了，但时间久了又回到了老样子。。。

我们趟过代码的水域。我们穿过灌木密布、瀑布暗藏的沼泽地。我们拼命想找到出路，期望有点什么线索能启发我们到底发生了什么事；但目光所及，只是越来越多死气沉沉的代码。 一一 代码整洁之道

​ 整本书看完后，并不觉得所有的东西都一定要按照书中的来做，但有以下的一些经验还是可以参考和采纳的。

背景

​ 作为一名测试，对自己写的代码就更加需要保障质量了😂。。。但又不可能每次和业务一样，每次改动后都通过手工测试去覆盖，此时便想到了单测/接口来保障测试自己开发的功能。

​ 但现在互联网公司，不管是开发还是测试的代码的单测覆盖率普遍不高，或者说编写单测不是一个普遍的现象。 具体原因可以先来查看一段代码，实现的功能是：在指定的 Jenkins server 上根据用户自定义的参数来构建指定的Job任务，代码的格式如下：

1
2
3
4
5
6
7
8
9

def start_job(cls, job_name, server=None, params=None):
  server = server or cls.server
  params = params or dict()
  status = cls.get_job_status(job_name, server)
  if not status and cls.check_task_status(job_name, server):
    server.build_job(job_name, parameters=params)
    return "开始执行"
  else:
    raise ValueError("已存在正在执行中的任务, 请勿重复执行")