一种基于动态插件系统的移动测试黑科技

移动端线上问题定位的几个场景：

 

场景一： 云端用户反馈某功能不可用，RD猜测几种可能触发原因，线上收集的客户端打点日志信息不全，无法完全确认问题。陷入死循环，线上用户持续暴露问题，线下无法稳定复现，不能及时定位问题。如何破？

场景二：通过客户端预埋方式打点用户行为，往往会出现打点不全的问题，而往往线上问题的定位需要这些行为日志为问题定位提供良好的复现步骤。 如何无需编码，通过技术手段获取全量用户与客户端交互日志？

场景三：线下很多好工具可以SDK化，给线上问题发现和定位带来大量正向收益，但因为测试能力本身会影响集成app的性能，或开发团队排期等原因，无法集成，大量线上问题无法充分暴露。如何优美的解决这种问题？

场景四：百度的线上客户端小流量实验表明，线上问题实际是一种正态分布的随机事件，TOP问题，往往只需抽样很少量用户即可召回，而不需要影响全量用户

移动端线下测试的几个场景：

 

场景一： 客户端测试简单却又复杂，一个客户端测试人员的简单技能树可能包括这些问题的分析能力: ANR、crash、卡顿、内存泄露、内存、CPU占用、电量分析、启动速度分析等等一系列的技能。而往往，部分QA人员并不是全栈。并且这些工具的使用本身，就是一个工具大集合。如何让客户端测试人员，或非专业测试人员，无需任何背景，只需要点一点就可以具备全部客户端问题分析能力

场景二：同刚才说的线上问题定位，线下大量的优秀功能，并不能适用于全量用户，因为他们本身就是伤敌八百，自伤一千的能力。如何在尽量小用户体验损耗的前提下，让问题尽量的全部召回？