检测工具分静态和动态，多数按具体的编程语言区分（动态的如 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 可以是数据线也可以是网络协议。

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

做平台和用平台不是一波人，从来都是这样，习惯就好。
就看做平台这波人会不会尽快去找用平台的人拿到反馈然后赶紧迭代了

需要开发的专项测试工具一般是指什么：

1. 特定业务场景才适用的工具 —— 比如基于这些工具在特定网络协议上再做一层封装才能在业务上使用
2. 需要针对某些指标项钻研得更深 —— 比如工具中有些指标项欠缺，而业务中刚好需要
3. 需要和公司平台打通的工具 —— 把工具能力集成到公司内部的体系，打通数据收集存储展示 ……

如果想自己真的算有能力开发这样的工具，应该如何学起：
我的方法可能比较低效，找别人的源码就是一顿看，一切从抄袭开始，抄着抄着随着知识储备提升你就会意识到当前方案的问题，然后找到更好或者更适合自己需求的实现方案，然后再做一遍（在别人看来你就是在搞轮子，大家一样质疑你，就像这个帖子一样 ）

我的老板一句话概括：对内不同业务方向，把控线下到线上全流程质量风险对应的质量建设；对外沟通研发产品运营，及时获取各种产运研动向以不停给大家输入。

活挺抽象，时间也比较碎片，老板更多是务虚而不是务实，但是务虚也有务虚的价值，不是每个人都有务虚的毅力和能力（想想你一天到晚都在开会，你开会得保证有意义，会后零散时间还要沟通、想规划、把关下属工作）。这些都依赖有前期大量务实的沉淀和思考。

从目标触发去考虑你要做什么事情。

• 如果公司对 app 安全性要求并不高，而且历史上也没出过什么太严重的安全问题，那可能：
  1. 公司 app 的安全性也许还挺高，找安全问题的空间不大
  2. 公司根本不太在意 app 的安全，在现阶段不会有多大投入

这种情况总结起来就是，你也没必要把这个东西研究得多深，有个结果交付给上司就行了。

• 如果公司对 app 要求很高，我建议还是直接找乙方做安全测试，安全领域真的很深，我以前在外围简单涉猎过，这些东西如果不花大量时间实践是没结果的

按匹配度排序，如不匹配则逐级下降：

1. 完全一样业务的业界测试团队的质量工作
2. 业务不完全一样但是依然处于同一个大领域的业界质量工作
3. 业务不一样，领域也不一样，但是要做的事情和你们想做的事情接近的质量工作（比如都是要做覆盖率、都是要做接口/UI 自动化）

第 1 和第 2 点基本上到手就能直接参考；第 3 点需要你们已经有建设目标才能找，结合楼主说的【不知道应该关注哪些内容】，我理解就是没有明确的建设目标。如果楼主所在业务内部交流本身也没提什么特殊的建设，那就先当做是常规业务去建设就好了。至于常规业务一般建设什么，这个网上很容易搜索到。

个人观点：

1. 211 的优势更大，一本和二本在面试筛选时虽然有区别，都其实也都是本科。而 985、211 这些显然是第一批被筛选出来的
2. 进 211 如果专业不理想，前一到两年要刻苦学习随时准备转专业，越早转过去理想专业越好
3. 电气不清楚，电子信息、计算机方向我理解就是出来做程序员，写代码是门手艺，在校写得越多能力越强，所以老师并不重要，最好能混进去学校的 xxx 计算机实验室跟着老师做项目，不行就自学（我自己也算是半个自学），还是讲究实践

综合楼上观点，分情况讨论可能是这个样子：

1. 如果你能确保上游服务稳定，如上游服务变更少，逻辑简单等，可以偷懒省去 mock 的环节直接测，我们默认上游没问题，在测试的时候一并观察上游返回是否符合预期即可 —— 相对来说，省了 mock 成本，但是在校验时有额外的心智负担
2. 如果你无法确保上游服务稳定，如上有服务变更频繁，逻辑复杂，可能有更复杂的依赖，这种为了测试效率考虑还是走 mock，如果直接测，一旦出问题要排查半天是哪里的问题，长期来看效率可能是负向 —— 相对来说，有 mock 成本，mock 了之后就可以尽量去转化为接口自动化测试

大多数情况下，大家可能都是按照 1 去操作，有些业务形态真的复杂，那就只能 2，这些工作省不了。

一般系统设计接口是稳定的，如果频繁变动接口（mock 轻易就 break），我觉得可以质疑研发的接口设计水平。所以不太需要考虑 mock 要经常维护的问题。如果你能预见这个接口它就是因为业务迭代肯定会频繁变动，好像也没更好办法，因为你的被测服务可能也要跟着变动，那时候你也要被叫过来测试。这种情况先和研发探讨一下再做决定