坠入互联网N年，这个行业什么都好就是掉头发 ，经历大大小小的企业，各企业的开发规范、流程各不同，包含了国/内外团队同时在同一个Project中协同开发，大大小小总会存在各种代码冲突和commit丢失等等，故设计了一套开发流程规范来解决痛点。

首先就是要解决的多项目，跨地域，跨国家的开发人员的冲突，先来一套git 规范再说：

从主干开发分支develop git checkout -b xxx 出新分支，开发完成后进行code rebase、commit合并等，

开发完成后进行自测及单元测试，要对已开发的代码进行如下场景测试：

UI测试

1）界面（菜单、窗口、按钮）布局、风格是否满足产品要求，文字和图片组合是否美观，操作是否友好。

2）清晰、简洁、美观、响应、一致，需保证与PRD与效果图一致。

3）不同分辨率下是否自动适配。

4）UE交互、触摸点是否友好。

5）界面动画是否符合PRD，画面是否卡顿。

6）当数据异常无网络时，界面是否正常。

功能测试

1）开发的代码，各逻辑模块编写测试代码，模拟真实数据、边界数据、异常数据、假数据进行代码测试，检查逻辑是否正常。

2）代码模块自动调用压力测试，检查输出结果是否正常。

3）串联APP整体流程，其他页面相关业务是否影响和正常。

边界测试

1）无网络，API无数据，是否有数组越界、string index、空指针保护。

2）不同手机品牌，不同操作系统的兼容性测试。

3）同一账号跨平台Android和iOS登录后，检查业务逻辑是否正确与同步。

4）音视频模块需要测试最大化/最小化。

5）低电量、断网、3G、4G、Wifi测试。

全新安装、卸载、覆盖安装、升级测试

1）检查全新安装业务、功能、流程是否与PRD一致

2）卸载后安装，app上有部分缓存情况下，业务功能是否与PRD一致。

3）安装一个线上正在运营的app版本后，在用IDE覆盖安装最新的APP，业务功能呢是否与PRD一致。

性能测试

1）检查开发的代码模块是否触发离屏渲染。

2）cell、View是否重用

3）开发的VC检查是否delloc,是否导致内存泄漏，观察进入与退出该页面的内存消耗

4）页面卡顿，UI刷新是否小于16.67ms。

3. 可读性，代码注释量过少，尤其是缺少对重要函数和代码语句的注释。

a.提高代码Review的效率及代码回顾时逻辑梳理；

b.函数和变量命名规范

c.驼峰是命名；类、变量使用英文描述

4. 准确性，函数逻辑方案不合理，存在很多冗余的逻辑或代码

必须使用最优解决方案，不能为了节省时间赶进度使用临时方案。

5. 可靠性，写代码过程中IDE 显示的警告或者标记必须修改；函数入参非空判断，野指针；参数生命周期；自我模块测试代码，功能测试。

6. 安全性，一些秘钥，数据存储需要考虑是否有缺陷

7. 第三方依赖库，是否必须依赖，否则不要引入，增加包体大小和类的数量

8. 性能，数据计算，业务处理，数据模型设计模式MVVM。For循环时要考虑性能。线程的使用。

9. 大型需求及复杂需求，必须写Wiki方案及流程图评审，保证方案正确性及iOS、Android方案一致性

单元测试

*概述：单元测试是检查程序模块正确性的测试工作，是软件设计的最小单元。其目的是发现每个程序模块中可能存在的错误。

1. 检查算法的逻辑正确性；确定编写的代码算法和数据结构定义(如队列、堆栈等。)实现了模块或方法所需的功能。

2.检查模块接口的正确性；确定形参的个数、数据类型和顺序是否正确；确定返回值的类型和返回值的正确性。

3.是否检查输入参数的正确性；如果没有正确性检查，确定是否不需要检查参数的正确性；否则，请添加参数的正确性检查。经验表明，缺少检查参数正确性的代码是软件系统不稳定的主要原因之一。

4.调用其他方法解决接口的正确性；检查参数的类型是否正确，传入的参数值是否正确，数量是否正确，尤其是多态方法。返回值是否正确，是否有意义。最好用显示代码检查每个被调用方法返回值的正确性。如果被调用的方法异常或错误，程序应该给出反馈并添加适当的错误处理代码。

5.错误处理；要求模块预见错误条件，设置适当的错误处理，这样一旦程序出错，出错的程序可以重新安排。其逻辑的正确性，而这种错误处理应该是模块功能的一部分。下列情况之一表明模块的错误处理函数包含错误或缺陷：对错误的描述难以理解；对错误的描述不足以定位错误和确定错误的原因；显示的错误信息与实际错误原因不一致；错误条件的不正确处理；在错误被处理之前，错误状况已经引起了系统干预等。

6.检查常量或全局变量的正确性；确定所使用的常量或全局变量的值、数值和数据类型；常数的每个引用与其值、值和类型之间的一致性。

7.表达式符合定义的规范。变量命名能够见名知意，并且简洁但不宜过长或过短、规范、容易记忆、最好能够拼读。并尽量用相同的表示符代表相同功能，不要将不同的功能用相同的表示符表示;更不要用相同的表示符代表不同的功能意义。

8.程序风格的一致性、规范性;代码必须能符合企业规范，所有的代码风格一致、规范、工整。

9.检查代码是否可以优化、算法效率是否最高。不必要的循环。逻辑线程等。

10.检查方法内部注释是否完整;是否清晰简洁;是否正确的反映了代码的功能，错误的注释比没有注释更糟;是否做了多余的注释;对于简单的一看就懂的代码没有必要注释。

11.检查注释文档是否完整;对包、类、属性、方能、参数、返回值的注释是否正确且容易理解;是否会落了或多了某个参数的注释，参数类型是否正确，参数的限定值是否正确。特别是对于形式参数与返回值中关于神秘数值的注释。

12.在单元测试栏里增加自动单测的case用于每次提测前自动运行其它单测。

提测描述

完成自测及单测后，需在ticket中增加测试内容、测试范围、建议的测试方案，如：

*技术修改范围：修改Voip库的连接方式，与Android pppp_connect参数保持一致，修改xxx接口

*测试WIFI环境：4G、同网段WIFI、不同网段外网WIFI、AP连接、电池机链接，弱网情况

*验收标准：直播功能正常，从曹智辉那查看p2p server的日志，是否是p2p连接优先

*测试机型：长供电、电池机

*测试用例P0级Case：通过

一些专业性的技术测试如需要造数据，造环境等等都写上去，可以让测试人员case覆盖的更加全面。