- 01.概述说明
- 02.兼容性覆盖
- 03.多端覆盖
- 04.异常覆盖
- 05.关联覆盖
- 06.核心流程覆盖
- 07.集成覆盖
- 08.新老版本覆盖
- 09.CI覆盖
- App质量问题是个很大的Topic，为了最终达成优秀的线上质量，需要在全流程各个环节都通过流程与技术相结合的方式做好约束，QA只是质量保证的一个环节，且较为后置，研发更应该对自己的交付质量做好前置性的保障，自测是个很重要的环节。
- 业务场景复杂，自测要关注的维度很多，在尽可能保证效率的情况下要提高自测质量，需要一套可行且全面的自测规范来引导思路，梳理了一套规范，主要包括8个方面：
- 兼容性覆盖；多端覆盖；异常覆盖；关联覆盖；核心流程覆盖；集成覆盖；新老版本覆盖；CI覆盖
- 说明：App开发受限于Android/iOS系统变更和一些机型碎片化问题，兼容性问题是经常被提及的重要方面，但不是所有代码都涉及到兼容性问题。
- 准则：一般认为与系统/机型的差异化密切相关的高危点需要做兼容性测试。（Android推荐云测平台：http://mcloud.intra.xiaojukeji.com/remote/#!/devices）
- 使用高版本系统API，低版本直接不支持造成Crash
- 使用低频、不常见、项目中没用过的API，虽然API不存在高低版本区分问题，但很可能会因为不熟悉，导致一些兼容性表现被忽视
- 引入新的SDK，包括集团内SDK与开源SDK，引用量大的SDK一般在兼容性方面表现较好，但仍需做好回归验证，比如引入Lottie
- 复杂UI开发/动效开发/自定义View等，复杂UI/动效/自定义View容易在特殊机型/小屏等出现与预期不一致的表现，比如换行异常、截断、动效轨迹错误等
- 功能命中Android/iOS官方明确提出的系统特性差异，比如典型的权限适配、存储适配等，需要重视兼容性覆盖
- 大规模的功能改版/重构，无需原因，必须做兼容性覆盖
- 说明：既要保证功能在多个产物的稳定性，又要尽可能提高效率。
- 准则：一般认为在时间充足的情况下应该做全端测试，在时间有限的情况下应该对一些多端敏感型场景做好覆盖测试。
- 说明：大部分情况下，产研都只关注到了正常的业务主流程，但对于很多异常分支（包括业务异常分支、代码异常分支）关注不够，导致后期花大量时间对异常情况做处理，时刻保持异常覆盖意识才能避免后期的被动。
- 准则：一般认为代码中涉及到if-else、onFailure、onException、null、empty、nil 等场景，需要做异常覆盖测试。
- 网络数据请求，只关注data != null，error_code = 0的情况，忽略可能出现的网络/服务异常/时序问题
- try-catch代码中，只处理try不处理catch，上线后出现严重的异常状态或执行流程
- 只对异常分支逻辑提供了 Assert 断言，便于在 DEBUG 模式下发现问题，而未对异常分支逻辑进行降级处理，易造成线上逻辑错误
- 对List类型数据做remove、insert等操作时，不考虑列表长度可能为空、为1时的range异常，导致严重Crash
- 说明：在大部分规模较大的应用系统中，代码之间都会存在千丝万缕的关联，尽管可以通过一些工程化手段尽量提高内聚降低耦合，但合理的代码关联与引用还是很常见，现代IDE都会提供代码关联查看功能。
- 准则：代码常见操作（M-修改，A-新增，D-删除），每种操作都可能直接/间接的导致与之关联的模块出现问题，都需要小心测试。
- A-新增，该操作大部分情况下不会影响其他模块，但需要关注新增的代码是否包含一些间接的关联因素，例如新增了个SPI实现类，会被SPI Loader运行时动态加载，编译期无任何引用
- D-删除，该操作大部分情况下不会影响其他模块，因为相关联模块在编译期会直接报错，但需要关注删除的代码可能包含一些间接的关联因素，例如包含被反射调用的代码、SPI实现类等
- M-修改，该操作出现问题的场景要多很多，一般需要通过IDE检查所有关联，并确认每处引用是否受影响：
- 说明：核心流程覆盖一般在发版前QA都会做重点关注验证，正常feature级别开发一般不会涉及到核心流程验证，但如果修改面涉及到底层代码、通用业务能力等，是需要做核心流程覆盖的。
- 准则：一般当修改超出单一业务模块边界，且影响主流程环节>1个时，需要做核心流程覆盖测试。
- 说明：这里说到的【集成】概念，并不泛指QA后期的集成测试，由于业务场景的特殊性，项目某一模块需要集成到其他应用，此环节容易出现被忽视的问题。
- 准则：一般当修改涉及到与乘客端相关联的部分，非外卖内部自闭环的部分，需要做集成覆盖测试。
- 说明：大部分开发测试阶段，都是以当前最新版本为基准，但容易忽略对老版本的覆盖测试，导致上线后老版本出现严重问题。
- 准则：一般当API修改涉及到版本控制，新老版本差异化处理，或端上修改涉及到对老版本缓存数据依赖时，需要做老版本覆盖测试和老版本升级测试。
- 端上新版本需要依赖老版本在设备中存入的老数据时，例如给某个序列化结构新增/删除/修改字段，且该序列化结构已经被老版本写入本地缓存，需要覆盖两个场景：
- 在不清理应用数据的情况下，用老版本做直接覆盖升级并测试
- 完全清理应用数据，模拟新用户安装后无缓存场景做测试（例如首页启动逻辑，有无缓存是两个分支）
- 说明：CI覆盖是指在前期已完成各类自测后，最终提交代码时，做的最后一步check，之前曾出现不止一起线上问题，与最后一步check不足有关。
- 准则：开发阶段一定要打开Lint检查，并对增量代码做编译前扫描，修改Error问题，最终提交CR前，需要Check自己的所有改动文件。
- 常见场景：
- 开发阶段打开Lint检查，并对编译前报错Error做修复，不要在本地强制关闭Lint
- 提交CR前，通过自己常用的Git diff工具，对每一个文件的每一处改动都要做认真审视，必须避免一些测试代码、忘记修改的代码被提上去
