请问有录播吗，蹲了几天了

如果没有，那就先从使用工具开始，因为这是迈出去的第一步。

其实性能测试含金量是整个测试计划的制定、指标设计、数据分析以及问题定位的过程，工具可以随便选，只要达到发压目标，能收集到想要的数据就行。

【用 jmeter5 个线程运行，看到那占用 99% 的 CPU 束手无策😂】比如这种，就是在没有思路的情况下直接去操作，你要想想你去性能测试是为了什么。是为了发现系统的性能瓶颈或性能转折点？还是验证系统能否达到预期的性能？带着这两个问题再去想怎么办。我给两种建议：

1. 如果目标是前者，那应该降低线程数再压，直到 cpu 不再打满，找到那个边界。然后按照这个压力去评估当前系统的表现是否合理，是因为有 bug 或劣化点导致性能问题，还是说这个系统确实就是这样的性能很合理。
2. 如果目标是后者，那原本的性能预期是多少，现在的数据究竟符不符合要求。

不要把思路局限在怎么用好 jmeter 上，也许今天是 jmeter，明天 jmeter 没落没人维护了就换成其他工具，所以花太多时间在上面没意义，把各种报告 ui 性质的东西配满做得花里胡哨也没有意义，因为你或许根本就没在做一个正确的性能测试。

在有经验的同事的指导下，自己完整参与执行一次性能测试

我觉得学框架是最简单的，因为从使用层面来说，你只要记住约定的实现方式或者代码写法就行了，甚至可以不用理解它的运行原理，死记硬背也能用。如果真的觉得连死记硬背都不行，那就找个现成写好的模板，然后把自己的代码往上面替换更改。
对应地，库的使用也不外乎如此，大多数时候我们没充足的时间和精力去理解一个库怎么工作，那就随手拿到它的文档，知道它的接口怎么调能达成什么目标就够了。

好的学习方法，无非就是不停地写、不停地可看，堆实践量，熟能生巧。代码，本质上就是手艺活。

其他代码是怎么写的，以及是怎么运行起来的，可以截图完整一些。

直观例子：

1. 发起了一个业务请求，后端处理有几秒时延，异步等待 ui 页面的相应，期间主动去做一些中间过程数据、日志的检查，发现有问题直接中断，不需要等待完整 ui 响应过程消耗时间

非直观例子：

1. 业务接口是异步接口，想要做接口测试，天然就是写异步测试代码，强掰成同步反而更低效
2. 自研测试框架，要实现同时运行多个测试用例且互相独立，做到测试用例不互相阻塞，可考虑套用异步概念，还能保持比较小的资源消耗（因为大概只需要一个单例类就能完成用例运行、断言，有排队的感觉）

这种问题百度必应谷歌一大把答案吧。

简单来说，我们把代码执行看成是一条时间线（我这样比喻是不贴切计算机底层实际运行的，但是就这个问题入门级可以这么理解），它是有先后顺序的。

按我们最开始学编程时的思维，代码就是一行一行往下执行，它的执行顺序可以通过人眼看代码完全判断出来现在跑到哪里。但是一行一行执行代码，有些工作是阻塞性的，比如执行一行读取磁盘、网络请求的代码，要到秒级的耗时。这时如果没有其他实现方式，代码就会阻塞，我们只能等待其完成，这显然是不合理的。

为什么不合理？想想你在烧水的时候，会傻傻的站在水壶前哪里也不去等着水沸腾吗？肯定不会，你会在这段时间里去做其他事，同时

• 选择一：自己脑海里记着个时间，等到水差不多沸腾你自己跑回来确认 —— 定时轮询；不是异步，是同步非阻塞
• 选择二：水沸腾会自动断电，自己随便找个足够长的时间回来处理 —— 本质上也是定时轮询，只是 “定时” 拉得很长
• 选择三：水沸腾水壶会呼呼叫提醒你赶紧过来处理 —— 异步，水壶响就是事件，你听到水壶响就是接收到事件，你跑过来处理就是异步响应；怎么处理？你爱咋处理就咋处理，你可以关电、倒水、喝水，是你自己定义的处理逻辑

为什么会出现异步？应该解释清楚了，没有异步就只能各种同步或阻塞，效率低下，CPU 大量空转。

使用场景：你调用一个接口，这个接口要处理 10s 之后才会返回，怎么应用异步？

1. 实现定义好接口返回之后你的处理逻辑
2. 调用接口，把这个异步处理逻辑绑定上去，告诉它只要你接口返回，就运行这个处理逻辑

检测工具分静态和动态，多数按具体的编程语言区分（动态的如 C++ malloc 等监控、java 的虚拟机运行时监控等，各有各的实现也对应不用专用工具），所以建议补充具体做什么语言的内存泄露检测，否则就很难回答。

【作为 QA 技术能力强，方法论强真的有用吗？一定程度上肯定是有用的，但是在管理 QAteam 后，就有发现有的同学技术能力很强，但是项目质量不怎么样】

这一块我有点个人体会。每个人都有他的特长，让每个人去发挥他的特长，可能要比要求每个人在短板上有所提高达到不错的水平，要来得更简单也更舒服。

我之前待过的团队就属于后者，比如有一个同学不善言辞沟通，对事情的整体把控力也相对弱，当时的 QA 负责人就把 ta 推出去做交接人 own 一个专项，最后结果也是比较差，弄得大家都不太开心。有时候为了锻炼人 push 一把也是可以的，说不定就超越自我了呢，不过要看不同人的素质，可能这个人的性格和行为方式就注定了 ta 的短板改正起来成本非常大，那作为管理者就得考虑怎么去用好这个人，其次才是怎么帮 ta 成长帮他克服自己的弱点。

建议帖主尝试为这种类型的同学去创造更合适他们的工作内容，说不定有新的效果。

其他的不多说，就楼主的问题，城市首选一线北上广深，因为城市大机会多同行密集，更容易遇见好的团队好的同事好的老板；其次是二线城市，同理；再往下除非公司岗位特别好，或自己有特殊需求，不然不需要考虑。

不要被 测开、测试 title 所束缚。

是什么人，要做什么，取决于岗位的工作内容而不是 title，而工作内容是在你面试进去的时候就应该聊清楚的。title 可以是一个业务测试，但是实际工作可能参与很大部分的测试平台开发，那还能叫测试么？其实也不合适。

那为什么有人会顶着测试 title 做开发工作呢？人的能力有差异，不同的事情适合不同的人，可能当时团队里就这个测试同学开发能力最强，刚好又需要做一些事情，就理所当然选中 ta。同理，测开 title 也有时候需要做测试，业务缺人就要补位顶上扛迭代压力。换一种情况，如果 leader 判断长期质量非常重要，短期业务迭代压力可以放一放缓一缓，那定位测开的同学可能就不需要加入业务测试，继续做对应的提效开发工作。

虽然很多时候 title 会限制工作内容和范围，但去到最后的能力栈还是取决于你呆在这家公司里所做过的事情总和。至于测开到底是测试还是开发，这个就看在入职的时候是怎么聊定位的，应该是先有定位，再有 title。而 title 是死的，定位活的，定位可能会变，但是 title 大概率不变。是工作内容塑造一个人，而不是 title 塑造一个人。

故，狭义地说测开是测试还是开发，要不要干测试，能不能干测试，我觉得是看情况去讨论，下不了结论。

其实也还好，vim 进去不按 i 或者 a 或者什么编辑键，即使编辑了不保存一样不造成影响。
甲方其实可以选择教育你，没必要批评你，说白了可能就是甲方看你不顺眼而已 。

为什么这种问题还会一直有人问 ，选哪个自己有信心能赚更多就选择哪个得了。不需要这么多顾虑，敢想敢做才是关键

不太正常，它不像是前端展示的问题，重复关注算成了两个人关注我，所以应该是数据库已经有问题了

怀疑是脏数据，可能某些重试逻辑没做好前置检查就出现重复入库？

同意 11 楼的看法，就像我们做质量保障工作分优先级一样，测试用例也应该分优先级再定投入。

边缘的系统不需要花太多时间做太多保障，因为它本身即使出问题也不会带来足够大的影响；对等的，测试用例如果是面向不怎么重要的地方，其实也可以分开来追求效率或者质量。

没必要以一个过高的标准统一要求所有测试用例，因为时间是非常有限，尤其是互联网两周发版是常态，不太允许全部用例都是高质量的要求。

个人感觉，测试用例的灵魂不在于字字斟酌明确，而是在于用例本身的结构（脑图结构）能否体现出一个有逻辑可理解的测试思路，让读者跟上这个思路并且能独立判断思路遍历是否完整可靠。至于繁文缛节方面的事情，一定程度上可以忽略。

好书 +1，书上有个微信号还可以加作者的微信入群，和一帮大佬吹水

我最近也做了类似 B 的事情，出于让外包同学多方面成长的初衷，我让外包同学尝试去做一做自动化，还做了好一些专门的辅导工作，最后结果是……

1. 为什么自动化要我做，而不是别人做？为什么别人能更早下班，我就要呆在这搞自动化？
2. 本周自动化进度还是 0，原因是业务测试任务太重了搞不过来……
3. 同一个问题，说了三四遍还是搞不懂，只会死记硬背，不会理解问题……
4. 稍稍变式不一样的问题就没能力独立解决，即使他手头有着联通世界的互联网搜索工具……
5. 个人工作和生活分得比较开，下班之后就不再想碰工作了，所以上班的时候尽量多学一些（然后下班很早【摊手】，又不愿意比别人付出额外多的时间）

只能说，成长真的是个人的问题，作为外人不要想着自己能去改变什么，也没义务去帮任何人成长。尤其是每个人的 “个人强度” 还不一样，有些人很脆弱无法逼迫自己往前多走一步，但有些人却能越战越勇。并不是让大家去学，给大家空间学，大家就真的能成长起来，这一套理论在人的惰性前是完全无法经受考验的。
当然，除非你是他们的管理者，对他们的成长有一定责任，否则还是不要浪费时间（+ 浪费感情）了……

PDF Github 链接，有贴在文章开端部分。

请问有无线上直播和录播渠道？

有几个疑点：

1. 正如 10 楼所说，提效部分是否当前效率最大痛点，还是说为了让工作中体现提效而找个简单轻松的地方去落地
2. 提效工作做得够不够好，还是说勉强 60 分的形象工作，大家对提效工作根本没信心还是要人肉兜底
3. 提效有了但是人的理念有没有转变过来，还是说依然选择人肉兜底保心安

实际中比较多的是第 2 和第 3 种情况

成都机会就多很多了，如果没有 base 限制倒是可以过去成都碰碰运气

fastmonkey 和 fastbot 都是同一个作者，前者更多是个人项目（完全不维护），后者是团队项目（作者在字节跳动）。

1. iOS 有必要做 monkey 测试，大厂一定都会做，100%
2. 目前市面上 iOS，应该就是 fastbot 最好了（指国内免费使用的，国外或收费的不了解）

这么说确实是，不过考虑到 appium 本身的初衷，它留着一层中间层也无可厚非，因为完全没必要因为 windows 和 mac 而去掉它再维护一套；毕竟你也不能排除它用这台 windows，通过远程通信去 dump 另一台 windows 的控件嘛。

不过文章确实精彩

移动端框架搞中间层是为了屏蔽不同平台之间的差异，让 client 端使用同一套协议实现不同的平台自动化，相当于降低 client 端的复杂度，固定的 DSL 可以让项目会更好维护。中间抽象层的损耗个人感觉不大，就是 pc 端发请求到移动端的 server，server 调用平台接口实现。这里逃不掉一次通信，除了通信外其他的本地工作只要没 bug 都不会带来损耗。

楼主的想法是通过 adb 命令去 dump 控件，有没有想过 adb 命令一样会出现通信拥挤导致不可接受的卡顿延迟问题？因为这里本质上还是需要手机和外部通信，只是说 appium 走网络协议（http），adb 可以是数据线也可以是网络协议。

思来想去，好像本质问题依然还在？