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

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

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

问题 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 的团队配置都不一样，就不能一概这样要求（也不实际，因为执行不下去），所以在宿主上还是有挺大的痛点解决不了（质量 与 效率）。

确实是这么个理，但是在质量视角，该兜底的还是得有自动手段去兜底，总不能一直归因到人的质量意识层面，因为这个很难去把控和改变。所以也挺没办法的，只能穷极各种不一定高效的手段去做质量守门员

老哥目前测试方式是怎样的，不妨交流交流，真的是好难找到对口的同学

5 楼说得挺好，我补充一下我的看法。

工作前两三年应该是迅速生长的时光，迷茫周期不宜超过两个月，如果有那代表问题已经出现了，那就这问题应该怎么调整呢？需要先弄明白两个问题：

1. 你自己想要在职场中成为一个什么样的人？
2. 成为你心目中理想的人，你现在还缺什么？

好，即使第 2 个问题你想不明白，至少第 1 个问题你还是能很快给出答案的吧。那承接第 1 个问题其实也是很确定的做法，你需要找到对应的 RoadMap（发展地图，技能地图）来参考。

上面已经明确了你接下来要做什么（计划），你可以从下面几个方面去发展：

1. 工作中是否有符合你计划的内容，如果有，那尝试直接在工作中实践成长 —— 日复一日的用例设计、执行，这些重复工作中真的没有可以提效的部分吗？如果有，那怎么用技术、流程去提效；如果没有，那尝试着找上级反馈自己的想法，可以尝试发起一些类似的小专项，找人和自己一起做（或者找人带着自己做）；如果也不可行，就看第 2 点。
2. 工作中找不到直接能切合计划的内容让自己发展，那就业余时间，靠自驱靠卷了，这里没必要多说，self discipline

其实这个问题转化一下，就是我们在简历和面试应该如何合理加料。

我的感觉是：

1. 在实际工作中，要主动去拓展上下游让自己摸得到更多东西，这样自合作伙伴做过的事情，自己如果了解得比较清楚，可以在面试里一并说出来（不建议说成是自己的东西，但也可以不提及是别人做的事情，就当成给面试官完整地呈现出来整个事情，除非被确切问到）。
2. 一些自己完全没参与过的东西，但是通过各种形式学习沉淀下来（比如公司内部分享和培训），也可以当成是自己对某种事情开展的想法 or 思路，但要明确说自己还没实践过，免得误会。

至于背调，职场里做个好人，不要和别人撕破脸皮，不要留下黑历史，其实没什么特别难度，让大家对自己有个正常的评价。

我作为面试官，如果看到有人简历里写 “精通功能测试用例设计”，不会觉得有啥特别的甚至有点想笑。
一来用例设计是测试的基本功吧，二来但凡你写了精通我问个问题你答不出来或者回答得一般般就可以当场寄了。

吸引技术同学最好的作用就是技术公关，这一次 B 站很成功，看得上头

一般下面几种做法。

SDK 本身的接口测试

先给定义：

• 接口：SDK 的一个 API
• 功能：SDK 的一个或者多个 API 组合在一起成为有实际意义的功能

SDK 接口测试，一般就是基于 SDK 接口去写调用代码测试，本质上就是写接口自动化，也经常会基于 SDK 实现一个可视化的宿主 Demo（这个 Demo 就调用 SDK 各种功能接口），后面点一下 Demo 的按钮就能在背后跑接口自动化。

SDK 服务端接口测试

SDK 可能也会有服务端交互，如 RTC SDK（推流、连麦），这时可以针对和 SDK 涉及的服务端做接口测试，不过这个范畴更多是服务端的测试，和 SDK 关系没那么大。

SDK 宿主上的黑盒测试

这个没什么好说的，就是谁集成使用了你的 SDK，你就去谁上面搞测试。

上面提到的是具体测试实施的手段，而说到测试范畴，其实还是我们常说的那些维度，不外乎

• 功能测试、异常测试、性能测试、兼容测试、安全测试 而具体要做哪些测试，要基于 SDK 本身的业务属性去评估，不一定都要做。