理论总结的不错~

针对偶发性问题，希望提前挖掘出来一般 2 种做法：遍历测试、探索测试。这些测试，都可以引入各种故障异常的条件，比如磁盘打满、弱网等。

那假设确实无法提前挖掘，想后置复现出来怎么做：流量回放（服务端流量 + 移动端操作的录制与回放）、埋点跟踪、日志回捞…… 利用这些手段去缩小排查范围，最后还是要人肉找出问题。

不要想着有什么神仙方案能全自动化，太不切实际，更多是经验导向，可能这个问题一出现，基于经验和对系统的熟悉就能猜出大概是哪几方面的排查思路。

固定机型，不过是少了一维变量，转化一下就是固定机型下的偶发性问题罢了，同样的思路。

有开源的话希望拜读一下

打卡~

字节的全球真机房好像只是内部使用，定位上确实是用来做评测和本地化验证

应该要在研发内部推广一下 git rebase，把无效的 commit 合并在一起，这样提交记录才干净且可 review
参考：http://jartto.wang/2018/12/11/git-rebase/

这篇之前发过的老文，把它搬过来当专栏~ 后面把 testerhome 当成一个自己沉淀的主要阵地了

本质就是 持续且高质的输出。

途径可以是：

1. 图文输出 - 个人博客、各类论坛社区、公众号、专栏
2. 音视频输出 - 各类视频社区
3. 代码输出 - 参与开源项目，或其他形式分享自己的代码
4. 行业大会

输出类型可以是：

1. 技术输出 - 最纯粹的技术，单点技术、技术体系等
2. 观点输出 - 趋势、新技术评论？
3. 领域知识输出 - 质量保障各方面
4. 经历输出 - 工作经历、自己的实践

当然，如果在业界本身做出很好的成绩，带出很好的团队，自然也会有名气。

看来我提了不少 bug

这么说也确实有道理

已阅

请问这次三个分享有公开的 PPT 可以下载么？

具体看 app 是怎么实现的，WiFi 和 移动网络很多时候会有细分的网络策略，这些策略可能会具体到底层网络协议等在网络传输性能方面的影响，大厂会有相关专门团队做网络策略优化，具体就很深了我也没什么了解。

如果 app 本身的实现没考虑这些，那本质上我理解就是弱网区别而已，WiFi 也可以去构造弱网。

看了一下没太理解是啥，不全知道你怎么用多线程。可能要贴一下代码才比较好判断，可以把代码中的敏感信息打码掉

可能他都没看完全文，只看了前面一点点就直接拉到下面评论了

都是典型问题，老板估计也是想看看你线下线上全流程有没有相关经验，我自己的理解

问题 1：测试的既定流程已经测完，仍然会导致一些 BUG 流入到线上，如何规避？
答：回答思路上，可以先完善线下测试的评估标准，就是楼主说的覆盖率、研发效能度量一类的。
不过，线下内部测试不可能解决全部问题，之所以这么说，一方面是问题挖掘有局限性，体现在场景很深、环境碎片化、数据复杂等特性上；另一方面问题修复同样有局限性，不是所有的 Bug 研发都会修，都修复到位。所以线下测试本身是不可能发现所有问题的，整个质量保障体系应该是线下测试延伸到线上。
那回到实际逃逸的 Bug ，首先在思路上，先分析逃逸的原因是什么，有多少问题在线下是可以拦截，多少是无法拦截，其中能拦截但逃逸的是为什么，能力不够成熟？能力没用好？流程有问题？评估不准确？最后总结归纳找出痛点（标准、流程、能力），这样就知道下一步的建设是什么。
上面说的是虚的思路，实际在做的时候就有很多细节，准入准出标准、发布测试能力方案，灰度发布流程，线上验证流程，线上监控建设，用户反馈舆情分析等等……

问题 2：一个产品已经由某测试工程师测试了两三年以上，但是还是会有一些体验/友好上的问题，如何规避此类问题？
答：体验/友好上的问题，看起来很模糊需要被定义，比如是端上的交互体验问题还是性能问题（卡顿、耗电），还是服务端性能机或时延问题，因为每个领域都有很多细拆的东西去探讨。
“规避” 这个词也非常模糊，应该要澄清面试官到是想问如何去挖掘暴露问题，还是如何去解决修复问题，抑或是两个都想问。
挖掘问题，白盒黑盒的形式都可以，移动端和服务端的形式又不一样，移动端一般有埋点统计、竞品评测、用户问卷、用户反馈 NPS 分析等。服务端可以日志数据打点、压测、拨测等。
修复解决问题，这个话题更偏向于研发，就不展开了。

请问白盒分析、路径规划是怎么理解呢，有公开的关于 X-Monkey 的资料可以学习么？（比如大会 PPT、录屏等）

谢谢~

我给楼主一下可实施的建议，这个问题很典型，研发团队质疑测试团队，不知道你们在干嘛，看不到专业产出，这时作为测试 leader，应该要有一点危机感了。

首先澄清观念：产出 ≠ 苦劳，结果是最终大家看的，过程辛苦和中间难度可以说，但要主次分明，否则听起来就不太专业，给人一种你很虚你在打感情牌的感觉。

回到上面的问题，一些实际有效的改进点：

现象 1：研发不知道测试在干什么，觉得测试人多价值低

• 原因：中间过程黑盒，做的事情没清楚外漏，说人话就是平时没给研发刷脸刷得够多，接入研发流程的地方不够多，计划对齐不够清楚，没有度量数据来说问题
• 解法：需求变更多——测试卡口，规范提测流程；测试很苦逼，自动化维护工作量大——数据说话，需求提测，缺陷数量，缺陷解决时长，测试执行周期等，网上一搜一大把。

现象 2：自动化掰不清

• 原因：没理清楚自动化的价值
• 解法：自动化能不能发现问题，有没有用——数据；自动化维护成本如何——数据；哪些用例要做自动化，自动化整体如何持续运营——机制、流程、运营计划

现象 3：研发觉得测试的人一直在 “学习”，其实就是含蓄的说在划水

• 原因：人员的工作规划不清晰，大家的目标不够明确
• 解法：1v1 沟通，明确每个人的职和责，每个人有固定的 Topic，定期 review 产出，而不能永远以储备知识为借口来说没产出

可以考虑找大厂外包岗位提升一波见识，看看别人是怎么做的，再利用下班的空闲时间去吸收。不过大厂外包也有一些是很忙的，下班非常晚，需要自己甄别一下。

15 楼提到的基于覆盖率的精准测试建设，网上有很多来自大厂的成熟经验，搜一下就有了，甚至很多具体的技术思路也有一些呈现。

搜着去看一看，应该就能对 “覆盖率” 这个东西新的理解，当然技术归技术，其实后续的运营会更重要（个人感觉）。

不错不错

• 从成本的角度看：编程语言永远都学不完，浅表的语言学习，就相当于学习 “回字的一百种写法”，核心技术思想学不通，本末倒置；正确的策略是，先掌握一门，通过这个语言去掌握工作需要的开发技能，如果工作要求切换语言，大多数情况是临时学习过来再翻译一下就可以了
• 从技术的角度看：技术本源并不是哪门语言更好，语言只是一种工具，去实现人的想法，如果有最好语言一说，那是不是其他语言就不应该存在了？

emmmmmm，这个帖子是楼主想浅谈下这个项目自己的心得，还是说想问别人怎么做虚拟主播的直播测试？
标题和描述互相冲突了