只要能自动化的就自动化， 除非是太难自动化了，或者就算自动化了稳定性也太差的。

在一定程度遗漏是可以的，看你们的测试策略。 没有一个方案是效率和质量都能到 100 分的。 效率和质量是要取舍的。 我们能接受这种页面样式的 bug 遗漏。 说白了就是我们如果人肉的挨个页面检查， 这样的效率损耗我们接受不了， 所以我们就不检查了， 我们也愿意承担这种风险，如果生产出了这样页面样式的 bug，那就认命。 我从来就没追求 100% 的没 bug 状态。 而且其实新需求你怎么地都得人肉测，测新需求的时候好多页面其实能覆盖的到。 所以出这种 bug 的概率在我们这也很低。 所以直接放弃人肉测试

凡是自动化了的，我们就不再人肉跑了， 完全信任自动化的结果。 否则我们也不堆这么多的自动化了。 当然这也跟我们做 TO B 产品有关系， 商业模式上决定了我们业务流程不会变的那么疯狂。 比较少出现那种比如直接颠覆了现有业务形态和流程的那种事。所以极少出现直接废弃的情况。 都是页面变动， 功能变动，就跟着改就行了。 只要代码设计好了，某个功能变动了或者页面元素更改了， 那我们也只需要改一个地方就行了。 所以其实都还好。

搞兼职其实对普通人来说挺难的， 尤其踏出第一步很难。 一般搞技术的， 兼职无非就两种。 第一是接私活。 这事我以前还真干过， 不过资源是我同学的， 他手里有客户， 但他也是一个人所以那段时间忙的时候他就拉我们几个老同学一块挣钱。 我接过一个 PHP 的项目。 这个东西的门槛其实挺低的， 你有能写 web 的能力就成， 难在了你怎么能有资源接到活。 第二个是知识变现， 比如你看极客时间上那么多课， 你要是能成为大牛， 或者有路子让极客时间的运营认可你，那也挣钱，搞个课程然后坐着收钱，这个我觉得更难， 你去教别人技术，那得先让业界认可你。

非技术的就天南海北什么都有了， 比如我们家女王大人搞直销， 在一个平台上卖衣服什么的。 每卖一件都有提成。 她也没好好干， 一边看孩子一边干这个， 挣的很少。 但是弄的好的人一个月万八千的没啥问题。 也有那种副业变主业专职搞直销的，说是一年百万年薪的也有。

确实是越早越好， 因为当你积累了 10 年测试经验的时候，你会发现你在这个圈子里的名气，人脉还有技能都可以让你在测试领域里干的不错。 但你转去研发后， 你会发现你要人脉没人脉，要名气没名气，连技能也是垫底的那个。 这时候你会发现转去研发可能还不如做测试混的好。

所以他们是大佬~~ 我是小兵赖子~~

我本身不懂投资， 就是靠劳动换钱。 但我看好多大佬都在炒股抄币搞量化。

怎么说呢，我是这么认为的啊。 普通的测试管理岗位要过 40k 也很难,管理岗和管理岗也是有差别的。 非技术型的管理岗在中小厂得做到总监级别才有到 40k 的可能性。 而大厂的管理岗位不管是不是技术型的都相对比较容易拿到 40k。 而技术管理岗不管在哪都相对容易到 40k，不过技术管理岗的坑位比较少。

然后薪资上看， 测试比不让研发是正常的， 从天花板上看也是研发路线的天花板高， 这个就算我再怎么鼓吹测试开发也得承认的。从比例上看研发比 QA 更容易成为高 T/P。 测开岗的出现一定程度上弥补了这个问题吧， 测开做好了 40k 没问题。 楼主说的 6 年 43k 的研发，其实也算优秀了。 6 年还在 20， 30 来 k 晃荡的研发大把大把的。 如果是做测开岗位，基本上在中位数上可以跟研发岗位在薪资上持平。 但是往上走，测开也会有天花板的限制导致一流的测开比一流的研发还是要差一些的。

不知道~~ 我打从实习的时候简历就花了，在外包混了 5 年， 迄今没进过大厂。。。。。

这个怎么说呢，我觉得这个取决于你们的产品是否真的做到了前后端分离。 如果你们测试的工作没有前后端分离， 接口测试依然是压在功能测试人员， 那我个人认为大面积铺开接口测试确实不值得。 都不如写主流程的 UI 自动化来的好。

前后端分离就是前端和后端各自有自己的迭代周期和提测时间， 各自分开的。 这时候的接口测试也是会加入到持续集成中来的，可以做到尽早的发现 bug。 而不是等前后端都联调完了， 交给前端测试人员的时候才跑的。 这样才会更有效果。

那个啥，我说一句你别不高兴。。。。 你们这个薪资太低了。。。 符合你 JD 描述的人不会答应只给这么点钱就来的。。。

淡定淡定， 文字比较冰冷。 感受不到语气，比较容易误解

面试，要学会装逼

你从另一个角度看，就是专精某一个领域。 这年头不都说要成为领域专家不要做杂而不精么。

而且我好像写过挺多其他的类似自动化测试啊， 持续集成啊，大数据啊之类的东西。 我也不是除了 k8s 什么都不会。 只不过我最擅长 k8s 那我就总拿 k8s 来说事呗

我是最擅长 k8s， 不过这有错么

我没太弄清楚面试官想得到什么答案，他的意思是你没起到多少作用，但是你不是说把问题原因定位到了么。 难道他想你直接改 bug 么哈哈哈。 可能你这个问题比较简单吧，所以面试官不以为然。 一般回答这种问题都是往高逼格上回答。 就找你印象里最有技术含量的 bug 说就行了。 回答方向上主要经清楚测试过程，排查过程和验证过程，中间多讲讲怎么帮助研发排查问题的。 如果能知名的开源软件的 bug 就更好，比如我一般会说 k8s 的 bug。 因为这个显逼格哈哈哈。 比如：

我们在测试环境中发现服务不稳定，总是很卡。甚至请求失败。通过监控 k8s 集群上发现有 2 个节点的 cpu load 高达 200，但是在这两个点上启动的服务其实很少，而且 CPU 使用率也很低。通过 ps 命令发现当前节点的进程数量有好几千个，所以初步判断是由于进程过多导致的进程上下文切换造成的 cpu load 变高。 找到若干个进程查看其 stack 发现都是 fork from xxx 的进程，怀疑都是由某个进程 fork 出来执行 shell 命令的。 查看 kubelet 的日志发现有很多的报错信息显示 du 命令运行出错。 不知道跟这个有没有关系，所以到 github 上查找是否有相关问题。 最终找个有人提过相关的 issue。原因是 k8s 1.8 版本中 kubelet 对外暴露的 metric 接口是给普罗米修斯对接监控用的。他会周期的执行收集监控数据的命令。 其中会执行 du 命令来收集磁盘信息数据， kublet 1.8 使用的是老版本的收集功能，有一个偶发的缺陷是调用 du 命令会出错。所以 kubelet 中会一直抛出这个异常，而因为一直出错所以一直重试，所以才会有那么多 fork 出来的进程执行 du 命令导致 CPU load 变高。 所以按照 github 上提供的 workaournd 我们把 du 命令直接删除。 这样找不到 du 命令只会抛一次错但是不会导致不停的重试。 后面我们找到了不少这样的低版本 k8s 的 bug 导致的产品不稳定问题，甚至直接影响到了生产环境。所以在 19 年的时候升级到 k8s 1.16 版本后就彻底解决了这个问题。

这个 bug 是不是听起来就很有逼格了。 引申下去可以跟面试官探讨一下这种开源产品的 bug 你们怎么处理的问题。

ps：面试这玩意都是吹着唠的， 有些 bug 可能不是你处理的，但是只要你知道细节，不怕面试官深问，你就拿来说是自己处理的就成

其实我已经连续喝了 5 个月的中药了， 今年身体出了问题，先是连续拉肚子一个月，后面又是失眠，又是心慌。去看中医说湿热，脾胃虚，而且长期熬夜导致肾阴阳两虚。现在没特殊原因每天固定 10 点半睡觉，不敢再熬夜了。 好在技术，职位，人脉上都已经积累到了一定阶段了，所以不需要像以前那么拼命。

我是这么想的，拼多多其实说的是实话， 大多数人其实现在还是拿命去换钱。 因为我们这种普通人不拼命的话，以后就看不起病，买不起房，生不起孩子，养不起老。

所以在这个大环境没改变之前， 我们也没什么办法。 年轻的时候尽量多积累一些东西， 包括技术，人脉，金钱， 以及在一个公司中的地位。 这样起码 30 多岁以后就可以不用像以前那么拼了， 就好像我现在的职位就不用像以前那么拼了。

有一说一，我也觉得直接写代码是最好的

收到~~ 以后我会继续分享的

现在做大数据的测试的人群还是比较少一些，属于较小众的职位。 主要是因为之前测试人员都不具备相应的技术能力，并且大数据的测试场景确实不好测。 所以一般公司都是主要由研发自己来保证这部分的质量， 测试人员就在 UI 上测个皮儿的现状。 但是现在行业里对测试人员看法的转变，以及大家的技术能力越来越高的趋势 已经开始改变这个现状了。 我看不少公司的 JD 里已经要求 QA 有大数据技术栈的能力了， 同行们也都开始在讨论怎么测试大数据的场景了。 尤其是近些年软件架构的变化和互联网数据量的暴增，AI 火了也是变相的带动了大数据的发展（AI 离不开大数据）， 所以我相信会有越来越多的大数据测试岗位的， 而且待遇都不错， 从现在看我沟通的一些要求大数据技术栈的职位，薪资都不低。

你要是想学习的话， 自己搭个 hadoop， 用 spark 或者 flink 去写一些大数据的任务， 先学会大数据的一些基本开发的技能， 了解大数据生态是怎么运作的。 后面要针对这个生态里各个环节的点进行开发上的学习。 包括批处理场景，流计算场景， 流计算场景中还设计到了各个中间件， 比如 kafka。 再然后就是要学习这些东西的一些底层原理。 比如什么是数据倾斜， checkpoint 是怎么回事， 窗口是用来处理什么场景的， 数据一致性要怎么保证，精准一次性语义又是什么等等。 大数据测试的特点就是没有大数据开发能力的话就基本上没办法测， 因为它大部分的业务逻辑都在底层， 这也是为什么以前都是研发自己来保证的原因， 毕竟测试人员很少有具备这种能力的人出现。

真是巧了， 我们的 cdh 集群的命名跟你截图的一样。。。。 还有 kafka 不是有 java，python，golang 的客户端么，你需要的不是这个么？

你这个语气，观点还有行文习惯， 我差不多能猜到你是谁了。你还是这么狂妄的认为天下你最强其他人都是小白。 而既然你已经开始人身攻击直接说大家都是小白了， 那我也就不打算回应你了。 只盼你这个唯一不是 “小白” 的大高手有空能开始写点干货文章， 别在我帖子下刷存在感了 ， 88.

就 postman 最友好了吧

虽然吧我没觉得我做的东西有多高大上，我说受众小不代表高大上， 只是做这个领域的人少。 但你要说这些东西只是对小白来说是故弄玄虚，随便做过几年测试就很 接地气。 你这不是骂人呢么， 合着你觉得社区里这么多人都是没几年经验的小白， 只有你是 做过几年测试的。 你想贬低我 + 抬高自己，我能理解，但能别捎带着别人么。

我是不是该考虑考虑写点接地气的了， 老写大数据，k8s，混沌工程的是不是受众太小了，毕竟搞的人不多。