单元测试由单元开发人员自己进行。
项目开发实现过程中，每个程序单元（一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。
开发人员根据程序单元的控制流程、内部逻辑结构进行单元测试，争取达到分支覆盖。同时可以结合功能测试的方法进行。
单元测试针对程序模块，从程序的内部结构出发设计测试用例。多个模块可以独立进行单元测试。
单元测试内容：包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等；
单元测试组织原则：根据开发进度安排对已开发完成的单一模块进行测试；
单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的Bug已经得到修改。
1.2 集成测试
集成测试由开发人员进行。
编码完成后，项目组内部应进行集成测试。
集成测试由项目负责人组织策划（必要时需编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常，以及内存泄露等方面的测试。最好采用交叉方法进行测试，即个人开发的部分由其他项目组成员进行测试。
集成测试过程发现的Bug，应提交至缺陷管理工具，并得到修复。测试结果应形成集成测试报告。
系统测试由测试人员进行。
项目开发完成即集成测试完成之后，交付测试团队进行对整个系统的全面测试。
系统测试由测试负责人组织策划（编写测试计划、测试用例）并实施。目前系统测试主要采用黑盒测试方法，对功能（包括性能）、流程、用户界面等方面全面测试。
系统测试过程中发现的Bug，提交至缺陷管理工具，由开发人员进行修复。并最终形成测试报告。
1.3.1系统测试准备与计划
1）理解产品需求（包括需求变更，参与需求阶段的需求分析会议）
2）根据产品Wire
Frame，对产品需求Review
3）理解各模块之间关联及逻辑关系，确定重点测试事项及功能点
4）根据具体App设计测试数据
5）设计编写测试用例
1.3.2系统测试执行
1）产品提交系统测试条件：产品各功能开发完毕并完成集成测试，通过有效性测试
2）测试方法：功能测试为主，黑盒测试
3）测试人员根据测试用例对各模块全面测试
4)发现Bug，提交至缺陷管理工具
5)以版本更新为依据，验证Bug，进行再测试
6)回归测试
1.3.3系统测试完成标准
1）一级缺陷，致命错误，100%得到修改并且复测通过
2）二级缺陷，严重错误，100%得到修改并且复测通过
3）三级缺陷，一般错误，95%得到修改并且复测通过
4）四级缺陷，轻微错误，95%得到修改并且复测通过
当前版本未修复的缺陷应为可接受的缺陷。
1.3.4版本发布准则
各测试阶段全部通过，并符合发布准则，发布产品。
1）所有测试项必须符合以下标准：
致命错误：无
功能错误：无
功能缺陷：相关负责人审核通过
界面缺陷：相关负责人审核通过
建议：相关负责人审核通过
2）以上几项其中之一不满足要求，不予发布。
1.3.5测试总结
各测试阶段全部通过，产品发布。进行测试总结。
1）分析总结已修复的和未修复的Bug，以及Bug的分布
2）总结App存在的缺陷和不足，为修复及预防BUG提供建议
3）总结项目测试的得失和收获
4）进一步完善Test
Case，为下一版本升级测试做准备
2缺陷管理
2.1 缺陷的定义及基本属性
缺陷，即Bug，是指在软件开发过程中的针对软件产品和开发过程中的问题，这些问题已经影响或可能会影响产品的质量。
缺陷应该具备以下属性：
属性 | 描述 |
缺陷标识 | 标记某个缺陷的一组符号，每个缺陷必须有一个唯一的标识 |
缺陷类型 | 根据缺陷的自然属性划分的缺陷种类 |
缺陷等级 | 因缺陷引起的故障对软件产品的影响程度 |
缺陷所处的模块或子系统 | 缺陷分布的模块或子系统 |
缺陷出现几率 | 出现错误的几率 |
缺陷的重现步骤 | 详细的缺陷重现步骤 |
附件 | 与缺陷相关的附件（截图、附件、用例等） |
备注 | 对缺陷的其他描述 |
2.2 缺陷的等级的定义
缺陷等级，即缺陷的严重程度，反映的是对缺陷的发现对象可能造成的影响或后果来定义的。
缺陷等级 | 缺陷性质 | 错误分类 | 描述 |
一级 | 致命错误 | 系统崩溃 系统死锁 | 系统不可行、不可运转；以及对产品的基本功能有致命影响的缺陷。 |
二级 | 严重缺陷 | 严重错误 | 对需求的理解或实现错误，部分的模块或系统不可行或不能运转或部分模块和系统缺失，对整个系统有重大影响；严重影响使用。 |
三级 | 一般缺陷 | 次要错误 布局不合理 文字错误 | 系统中部分单元模块或单个功能描述和实现有错误、有偏差、不一致或有缺失，不影响模块的正常运行，或有影响，但可以有替代的办法或避免办法 |
四级 | 微小缺陷 | 微不足道 | 基本不影响系统的运行和功能的实现。但是与标准、规范和定义不一致 |
五级 | 建议缺陷 | 新特性 | 不在定义、标准、范围的定义和约束之内，但是从提出者来看是需要完善的建议 |
2.3 Bug管理工具
2.3.1
Bug优先级
Bug优先级指缺陷（Bug）必须被修复的紧急程度。
优先级一般分为：Highest、High、Normal、Low、Lowest。
缺陷优先级 | 描述 |
Highest | 需要立刻进行修改 |
High | 需要尽快修改，一天到两天之内必须修改 |
Normal | 正常排队等待修复 |
Low | 可稍后修改 |
Lowest | 留到最后解决，如果项目的进度很紧张可以在产品发布之前不解决 |
2.3.2
Bug状态
Bug的状态，用来跟踪Bug修复过程的进展情况。
Bug的状态一般分为：
In
Progress：New、Accepted、Test；
Closed：Fixed、Invalid。
Bug状态定义：
Bug状态 | 描述 |
New | 1、初始状态。新提交的Bug，等待修改。 2、修改后未验证通过，需要再次修改或说明。 |
Accepted | 开发人员正在修改中 |
Test | 缺陷已修改，等待测试人员验证 |
Fixed | 测试人员验证缺陷已经修复 |
Invalid | 无效的、已经不存在或重复提交的缺陷 |
2.3.3
Bug提交及书写规范
1）Bug的创建：
Bug应包含必要属性。
登录缺陷管理工具，进入Tickets模块，点击NewTicket进行Bug的创建。需要输入：Priority、Assigned
to、Milestone、Estimate、Summary、Description。
2）Description书写及格式：
前置条件：
重现步骤：
问题描述：
期望结果：
2.3.4
Bug处理流程及规范
BUG处理流程：发现BUG->提交BUG（创建Ticket）->开发人员BUG定位与修复->BUG修复之后的验证、再测试，以及确定BUG修复。
Bug处理流程图：
BUG状态处理规范：
| BUG | Assigned To | Status |
|
1 | 测试人员提交BUG | 开发组Team
leader | New |
2 | 开发组Team
Leader分配BUG | 开发人员 | New |
3 | 开发人员定位及修复BUG | 开发人员 | Accepted |
4 | 开发人员确认BUG已修复 | 开发人员 | Test |
5 | 版本更新后，已修复的BUG | 测试组Team
Leader | Test |
6 | 测试组Team
Leader分别BUG | 测试人员 | Test |
7 | 测试人员验证BUG已修复 | 测试组Team
Leader | Fixed |
7 | 测试人员验证BUG未修复 | 开发组Team
Leader | New |
1 | 开发组Team
Leader分配BUG | 开发人员 | New |
3测试版本更新管理
1）测试过程中，版本的建立与更新准则：一个版本/天，或按约定提供测试版本。
2）版本更新按时上传至Testflight和ftp上
3）版本上传信息包含：规范统一的版本号、更新内容。
4处理机制
4.1退回机制
若在测试过程中发生如下情况，暂停测试，将系统退回开发部门：
4.2报告机制
若出现以下情况，需要及时向领导汇报的情况：
测试后期出现重大逻辑错误，修改影响发布时间
测试过程中需求出现重大变更
测试负责人定期汇报测试情况
