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

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

同意 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 要经常维护的问题。如果你能预见这个接口它就是因为业务迭代肯定会频繁变动，好像也没更好办法，因为你的被测服务可能也要跟着变动，那时候你也要被叫过来测试。这种情况先和研发探讨一下再做决定

找一份靠谱的工作，还是熟人介绍或者找猎头推荐比较方便

想学，但是每天卷到很晚，下班回到家可能就快 11 点了，很难强迫自己再学点什么了 😭 终究还是欲望不够强烈

昨天刚好看完雷军的《小米创业思考》，深深感慨能力强的人是如何不受任何外力束缚有非常变态的毅力和自控力去做事情，另外从书里也认识到商业化的一些基本考虑（如文中提到的供应商、成本计算、营收预期等）。感觉自己好菜

同意，测试配合协助解决问题，其实也是在解决问题。

如果精力时间允许，可以帮助开发缩小排查范围，这何尝不是在努力解决问题？有些工作，不是测试做就是开发做，它总得需要有人做。而最后找到有 bug 的代码再修复，只是解决问题的环节之一，甚至都不是最后环节（因为你还得复验，上线……）。

不要和开发站在对立面，只能说尽量追求统一的共识为更好的产品交付效率和产品质量去做努力吧

1. 评估这个问题带到线上的严重性，看是否需要阻塞发版先在线下复现修复了
2. 让开发在可能的复现路径上埋更多日志以及监控，以便后续复现出来有更完整的证据链，或者第一时间从线上感知到问题发生尽早接入

其实需要的考虑的问题就是：

1. 是否严重到阻塞上线，不上线的损失是什么？
2. 如果线上问题复现，能否第一时间监控到，能否更高效地定位与修复
3. 最后才是线下测试需要改进的环节

曾经我也像你这么看待过 “架构师”，直至到后来我做抽象的事情多了一些，部分理解开始改变，其实觉得那些听起来天马行空虚无缥缈的建议也没有错，问题是当时的自己并没有跟 ta 同一层次的理解深度，又或者是 ta 的表达没有考虑到我的理解水平，最后相互都觉得水平好低……

还是多从自己身上去找原因吧，一切建议都应该虚心听讲，甭管建议是否恶臭，关键是换位思考、空杯心态。可以保留自己的判断，但不能一听到别人的意见就直接否决。