App质量
最近一次周会，PM提出App的质量不高，研发的小伙伴被吐槽了一番，而且最近几个版本确实都有发小版本修复bug的现象
# 如何确定一个App质量高低？
测试人员认为： 提交测试的版本问题多，明显的展示问题、逻辑问题等，冒烟不过，bug率较高，回归会耗更多时间。
产品经理认为： 线上反馈问题较多，比如页面展示的不对、H5页面出现白屏或者样式不对，交互不对、网络加载慢或者访问失败、Crash等。
运营人员认为： 某某某版本线上反馈问题较多，导致用户流失。
而做为开发人员的我们是怎么认为呢？
高质量的App可以从以下两个方面去衡量：
性能
- 卡顿率
- 启动时长
- 页面秒开率
- 帧率
- ANR率
- 流量
- 耗电
稳定性
- Crash率
所以站在不同的角度，看App的质量如何也是不一样的。
# 如何提高产测试、品经理和运营人员眼中的质量？
如何提高产测试、品经理和运营人员眼中的质量？
保证提交到测试的版本质量：改善研发流程，需求评审后确定设计排期，设计交互评审后再确定研发排期和测试排期，测试用例在开发阶段要评审，开发完成后需要用测试用例进行自测，从而保证提交到测试的版本质量。
展示问题：属于最低级的错误，需要开发人员细心，自己模块尽量多关注，自测各种情况的展示，而不能过度依赖测试人员发现问题。
H5页面白屏或者样式交互：随着WebViewLoader组件的发布，此类问题越来越少，一般都是H5 JS兼容问题，需要使用Safari联调（大家也要学会如何使用Safari和H5端进行联调），Web组件有修改需要邮件通知Web的业务方，衡量评估对各个web业务方是否会造成影响（这块主要我来做）。
网络加载：用户复杂的网络环境会导致网络加载慢或者失败从。
- 慢：弱网络或者接口背后逻辑复杂，可以通过听云平台（慢请求）看到接口慢在哪个阶段 DNS、TCP、首包或者响应时间，可以确定是弱网还是接口背后逻辑复杂，若是背后逻辑复杂则需要和接口开发人员协商接口拆分或者优化。
- 失败：网络请求失败或者业务逻辑失败，从CAT平台监控看到在网关到服务内部的错误占比还是比较少的，基本上属于网络请求失败或者逻辑有问题。
- 网络请求失败：从听云来看主要是超时
- 逻辑：400（token，保证需要token的接口必须有token）和服务端接口内部出现错误（比如出现散标投标失败）
Crash：目前已经做了部分Crash防护和自动修复
- APM组件实现了Crash上报、连续Cash监控及沙盒清空修复
- Utils组件对数组、字典做安全操作防护
TestFlight包要经过Instrument工具测试，保证没有内存泄露等问题
# 如何提高研发人员眼中App的质量？
# 稳定性方面：
严苛模式
增加下列防护：
（1）unrecognized selector crash
（2）KVO crash
（3）NSNotification crash
（4）NSTimer crash
（5）Container crash（数组越界，插nil等，已经实现）
（6）NSString crash （字符串操作的crash）
（7）Bad Access crash （野指针）
（8）UI not on Main Thread Crash (非主线程刷UI)静态分析：组件发布阶段已经增加infer，可以检测资源泄露、内存泄露、循环引用、空引用、参数不能为空检查，本地变量不能为空检查，业务组件不允许设置忽略检查
Debug面板：页面（是否释放）、帧率、内存。
容灾能力
目前只做了连续crash防护。还可以做的包括：
- 页面降级（降级到H5、或者RN界面）
- 图片降级（几乎不存在）
# 性能方面：
增强APM组件的收集能力，并做好蜂巢平台展示分析能力
- 启动时长
- 流畅度/帧率
- 内存
- 用户操作轨迹
- 耗电情况
# 其他方面：
灰度
外部用户正式环境灰度一周，统计Crash和性能指标，再正式对外发布。
远程能力
需要借助长连接收集下面信息
- 用户操作轨迹
- 远程日志
- Memory Dump
- 修复（待思考）