聊一聊我是如何提高App质量的想法和经验总结！（第二部）
在上一篇文章中，笔者主要讲了把控APP质量的4个大注意点，今天我们来讲剩下的部分。新老SDK
新SDK UT覆盖率90%以上，老SDK基于BDD通过。基于资源有限的情况下，历史遗留的SDK可能无法去梳理并编写单测，那老的SDK可以去给予行为去编写BDD测试用例，这里不展开描述什么是BDD和怎么实践。
针对新的SDK在技术方案阶段就需要思考好测试用例并体现出来，开发阶段UT覆盖率须大于90%。
SDK一定要Lint通过
这里的Lint并不是针对语法、锁进等的OCLint，而是podlint。因为发生过一些情况，就是MR提交后，去打包系统打包阶段，因为podSDK的问题导致的打包失败，所以pod的lint一定要通过，将问题提前解决掉。
SDK Warning清理
SDK内部的warning尽量清理掉，比如UI Web View或者某个使用的API苹果标记为待废弃，假如你不按时修改掉，万一上线后用户使用的某个功能异常，那就GG了。
SDK核心用例梳理
确保接入App集成测试老的SDK梳理核心用例，便于BDD测试。SDK的所有功能需要接入至少2个业务线App去验证功能和性能是否符合预期。
SDK Demo必须体现开发能力
多端Demo对齐SDK的功能设计、类的API多端对齐，能力一致，且在Demo上可以体现出核心功能。
脏乱差治理并优化
年底统计线上问题原因，经常会发现不管是业务线还是中台，都有一些遗留或者接手的线上问题，所以不管何种原因，都需要Owner意识，脏乱差梳理去修复问题。
确保测试用例冒烟通过
QA指派的测试用例一定要冒烟通过，冒烟打回很严重的，这是对质量的不认真，也是对QA工作的不尊重。
关键功能由老司机操刀开发
避免形成卡点（进度）或者影响质量，太忙的情况下至少老带新核心业务功能，新人很难评估到所有影响面和边缘case，所以优先老司机操刀开发，或者新人梳理评估出方案，老司机review把关，避免因为不熟悉造成进度落后或者线上质量问题。
基础SDK交叉测试
业务项目有QA资源，基础SDK不一定有测试资源，需要开发者本身去思考测试用例，包括功能和性能方面，最后可以交叉测试，Android、iOS互测，确保质量。
页:
[1]
