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

途径可以是：

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

一方面首先是：关于测试时间评估这块最好能有个标准搞出来大家可以参考，不然很容易变成一个人说了算（比如测试负责人），其实风险挺大的。

1. 按照用例的数量和执行难度评估：100 个用例跟 10 个用例的执行时长自然不一样，一个用例要查缓存查数据库查日志跟一个用例只看响应的执行时长也不一样，所以需要做明确的区分。
2. 明确测试时间有效评估的前提：测试肯定不是一帆风顺的，所以要明确说清楚，评估出来的时间是指正常顺利测试的时间，如果别人非要你给一个准确时间，就不要把因提测质量不佳、功能不可测等承诺进去，这块说清楚就好。再给到 修 bug 的一些 buffer 时间，基本 ok。

如果这里说的是手机系统通知栏里的那种推送（不是 App 自定义的站内推送），这些推送必然要经过手机厂商的服务器（华米 OV、Apple 都要），这似乎意味着无法从本地真机上 mock 出来的。

在我司，推送中台将推送服务封装了一个简单的 Web 平台供大家手工测试使用或者自动化调用，要做成自动化那就是去调用这个推送中台的 Api。如果楼主的公司不存在这种推送中台，那就需要自行去和推送服务端的研发沟通，能否开一个内部测试接口给你调用。

假设推送可以了，那接下来就是看手机是否能接受到推送，推送是一定有折损率的，它不会 100% 成功，同时也会存在时延，所以整体上失败率非常高。这个步骤可使用常规的移动端自动化框架去做校验，或者从 App 日志上去做校验也可以，看测试目标自行选择不同方式。

最后备注，推送测试有安全风险，比如一不小心给线上用户批量推送了一个测试消息，那就是一个测试事故了。

精彩的回答：公开可参考的制度 -> 落实制度的组织 -> 来源于组织的标准 -> 从标准中转化的技术能力和技术运营 -> 承载能力和运营事项的平台

这个命题定得太大了，既然公司规模不是很大，就没必要追求面面俱到，要先看做这个事情的目的是什么，再来确定要做出什么结果。
如果只是想保证不出现安全维度的质量问题，我觉得最快的方式就是直接找乙方安全公司做全面的渗透测试。如果不想出这块费用，也可以拿市面上开源的现成工具扫一扫找问题解决。可以去 OWASP 上看看有没有你需要的安全标准（甚至是 Top 10 安全问题也可以当成是你们的安全标准），再找一些网上的安全编码规范给到研发，结合一些信息安全意识的条理和培训，我觉得就差不多了。

是的，老哥很有经验，这个是我们在做的一个事情，不过感觉这个事情在不久后就会遇到瓶颈。核心问题可能会转化为：

1. 宿主 App 视角：我怎么把合到我身上来的 SDK 的质量把关兜底好，有无比较通用的测试方案
2. SDK 视角：如何解决 SDK 发版多宿主测试的效率问题，如何有利用有限的人力来支撑不停增加的待测宿主

表达一下我的观点：
1、理论上，确实这么做是正确的，但是 SDK 团队有质量保障上的局限性和客观困难 —— 一方面 SDK 自身质量好，不等于集成在复杂的宿主上呈现出来的质量一定好；另一方面 SDK 客观不一定有测试团队，SDK 研发自己测试在宿主业务视角看来局限很大。
2、这么说理论上合理，但是当宿主集成的 SDK 越来越多，SDK 寄宿的宿主也越来越多，双方都无法顾得来。
3、在实际场景下可能更多的是这样：App 和 SDK 是一同升级的，经常是 SDK 的研发给 App 提接入代码，需要 SDK 的研发熟悉 App 的业务和技术框架，这个就很硬性要求了（尤其是平台型的 App，上面会集成很多集团的其他业务，如 淘宝）

其实有一个死结很难解（或者解不了，只能去缓和）：SDK 变更升级，宿主和 SDK 都有质量风险，在复杂的合作中，各自的边界划分好没问题，但是暂时找不到合适的手段将测试成本降低，以及提升效率。

同意，我们的思路有一部分就是打算提供一些标准给 SDK 方，告诉他们在什么环节应该要具备什么能力完成很么事情，会包含 imath60 所提及的这些内容~
不过标准归标准，当 SDK 越来越多，不同 SDK 的团队配置都不一样，就不能一概这样要求（也不实际，因为执行不下去），所以在宿主上还是有挺大的痛点解决不了（质量 与 效率）。