客户端测试 可测性改进-学习记录

客户端测试面临的挑战

难点：

业务复杂，产品多，技术栈多样

测试过程的痛点：

配置-》执行-〉检查-》结果

手工测试前置配置操作极其繁琐：安装测试包-〉进入debug页面-》设置h-〉设置AB test-》锁定rn包-〉进入业务页面-》选择城市-〉登录-》开始测试

执行时应用属于黑盒状态，很多东西是测不到的，也感知不到有问题；场景难以构造；真机UI自动化因为链路长，耗时长，不稳定。

解决方案：

业务复杂，产品多，技术栈多样-》需要通用，可扩展

迭代快-》需要高效

缺陷不规范-〉需要标准化

配置工作繁琐、场景难以构造、深度与广度不足-》需要可测性改造

客户端可测性改进的概念

一个被测应用，能不能被感知，能不能观测到它的状态，能否控制它的状态。

客户端测试像一座冰山，我们能看到的就是表面的ui，实际上在下方还有网络与数据、存储、应用内部状态、系统与设备等很多层。做可测性改进就是希望能感知到下层的这些东西。

可测性改进的原理：把app的数据和状态通过http协议上报，以达到“可观”的目的，通过http协议，控制app的状态，达到“可控”的目的。

基于可测性改进的短链路测试

客户端业务复杂，链路较长，利用深度链接剪断长链路，通过scheme直接跳转到指定的页面，结合可测性改进实现短链路测试，控制接口数据的发出与返回，控制应用内状态（登录态、页面、AB test、rn包、定位等），上报应用数据（页面链接、js错误、性能数据等）。

优点：

流程短、维护成本低、运行效率快，去掉中间环节，降低case维护成本，提高运行效率。

可控性高，case稳定性高，过多的输入不确定性会影响执行结果。

可测性高，校验力度高。