目录
1.概述 ………………………………………………………………………………….…………………..2 1.1目的 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„2 1.2适用范围 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„2 1.3执行原则 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„2 1.4角色和职责 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„2 2.软件测试流程„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„3 2.1软件测试流程图 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„3 2. 2 流程图解析„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„3 3 软件测试周期人员活动图„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„5 3.1 活动图 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„5 3.2 活动图描述 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„7 3.2.1软件测试准备（S0~S2 …...................................................................................................................7 3.2.2 测试执行阶段（S3） „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„8 3.2.2.1软件执行阶段流程图 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„8 3.2.2.2软件测试执行阶段人员活动图………..…………………………………………………………….9 3.2.3测试扫尾工作（S4~S6）„„..„„„„„„„„„„„„„„„„„„„„„„„„„„11 4.缺陷管理..........................................................................11 4.1 BUG级别定义.....................................................................11 4.2 BUG处理规范 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„13 4.3 量产BUG标准„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„13
1.概述
1.1目的
有效的制定不同测试类型（软件系统测试、Field Trial、专项测试、自动化测试）的软件测试计划； 按照计划进行测试，发现软件中存在的问题； 对软件中已经解决的问题进行有效的验证; 判定测试过程和问题验证的有效性。
1.2适用范围
适用范围是参与手机产品软件测试的各测试工程师、测试模块组长、测试PM。
1.3执行原则.
标准化作业，尊重事实；
测试工程师需要对手机各项功能提出疑问的态度来思考软件；
测试工程师需要主动与项目组的所有成员保持有效的沟通，以便更好地完成测试任务； 尽早发现问题，及时跟踪问题；减少、预防后序过程中发生问题；
1.4角色和职责
1.4.1 测试部门经理
1. 负责审核测试计划,监督计划的实施过程，确保按计划进行实施和按计划完成测试任务； 2. 制定、更新和维护软件测试流程；
3. 对发现的部门需要改进的问题提供解决方案； 4. 制定短期、长期的改进措施；进行评审和监督； 5. 监督新员工培训实施情况，对培训结果进行考核 6. 参与项目风险评估 1.4.2 测试PM
1. 参与软件需求与UI评审
2. 编制STP（软件测试计划）
3. 根据软件测试申请单的要求判定是否接受软件测试版本；达到软件测试标准安排系统测试；对测试需求进行组内培训。
4.测试任务的分配；测试过程进行跟踪；处理异常情况；发送定期测试报告（每一个软件升级版本）到测试部门经理、开发、各管理人员
5.跟进BUG的修改情况，组织BUG评审（项目晚期进行）
6.参与项目风险评估 1.4.3 测试功能模块组长
1.参与软件需求评审
2.组织测试工程师编写测试用例以及测试用例的维护，并与测试PM、开发一起进行用例评审 3.组内成员工作技能的培养与培训，组内成员的业绩考核 4.协助测试PM做好人员调配 5.协助测试PM进行BUG评审 1.4.4 测试工程师
1. 按照系统测试计划进行系统测试用例的执行， 2. 测试记录的整理，
3. Bug的跟踪【包括：提交、验证、关闭Bug】。
2.软件测试流程
2.1软件测试流程图
2. 2 流程图解析 需求分析
一般而言，需求分析包括软件需求文档、软件规格书以及开发人员的设计文档等。测一款软件首先要知道软件能实现哪些功能，如果是手机常规运用与手机平台原生态的东西可以不提供需求分析文档，这个需求分析对于手机软件而言主要针对新的定制、新的应用等。
测试计划
测试计划由测试PM负责制定，测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测
试计划一般包括以下一些方面：
1. 测试背景 a, 项目介绍
b, 项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等 2. 测试依据 a, 软件需求文档 b, 软件规格书 c, 软件设计文档 d, 其他，如参考产品等 3. 测试资源 a, 测试人员需求 b, 测试样机需求 4. 测试策略 a, 采取测试方法
b, 采取哪些测试工具以及测试管理工具
c, 对测试人员进行培训等
5. 测试日程 a., 测试需求分析
b, 测试用例编写
c, 测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，外场测试、α、β测试阶段等），每个阶段的工作重点以及投入资源等。
计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在
软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控了。在变化面前能够做到应对自如、处乱不惊那是最好不过了。
测试设计
对于手机而言，测试设计主要包括测试用例的编写。由于常规的测试点的用例都已经具备，这里主要
针对新的需求与应用。 测试执行
测试执行阶段一般分为以下阶段：
确认测试→系统测试→验收测试→产品说明书check，其中每个阶段还有回归测试验证问题。单元测试、集成测试目前暂无需求，后期项目可根据实际情况添加。
从测试的角度而言，测试执行过程是要考虑量和度的问题，就是指测试的范围与测试的程度的问
题。
从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地
利用资源来开展测试。当然如下几个问题也需要考虑：
a, 当测试人员测试的执行不到位、敷衍了事时该如何解决？ b, 测试效率问题，怎样提高测试效率?
c, 根据版本的不同采取怎么样的测试策略，是全面测试、自由测试还是针对模块的测试 d, 达到量产的标准，是否需要项目延时等标准。
软件评估
这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发布量产的软件进行评估，以确定是否能够投放市场。软件评估小组一般由项目负责人、营销人员、部门经理等组成。 测试总结
项目已经发布量产，测试项目组可以通过各种方式对整个测试过程进行总结，可以是做的好的方面的经验，也可以是不足之处以便后续项目避免。
测试维护
由于测试的不完全性，当软件正式release后，用户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，修改后需要再次对软件进行测试、评估、发行。
3 软件测试周期人员活动图
3.1 活动图
3.2 活动图描述
3.2.1软件测试准备（S0~S2） 目的
1. 有效的制定软件测试用例的编写计划和评审计划； 2. 按照用例编写计划进行测试用例的编写和评审。
3. 对评审的问题进行记录，并根据评审意见和需求变更进行更新测试用例 4. 判定测试用例编写、评审过程的有效性； 进入条件
1. 项目正式启动 2. 需求文档已经进行归档 输入
软件开发计划、软件开发时间表、菜单树、功能列表、人机界面规格说明书、冲突说明、内存使用分配表、按键定义、最大/最小值、默认值、需求的变更信息等相关需求文档。 作业流程及其管理方法
输出
软件测试计划（STP）、测试用例
3.2.2 测试执行阶段（S3） 3.2.2.1软件执行阶段流程图
软件执行阶段流程图解析
1．根据整个软件测试执行过程，按时间分成三等分，分别为T1：测试初期、T2：测试中期、T3：
测试晚期与验收测
2. T1：测试初期这个阶段，主要执行确认测试、基本功能的测试。确认测试的目标需要确保软
件完全符合设计文档。基本功能的测试的重点是执行测试用例，尽可能多的去暴露基本功能的问题，测试的执行方式以执行测试用例为主。
3. T2：测试中期采用自由测试为主，除了测试基本功能外，还需要重点测试性能、兼容性测试、
音频主观性测试。其中性能测试可借助于自动化测试工具进行测试。另外这个时期需要外场测试的进入，测试目的是模拟动态环境下用户的使用过程下手机是否稳定。
4. T3：测试晚期阶段，这个阶段仍然需要执行多遍测试用例以确保基本功能的实现完全没有问
题。同时根据项目进度，库里面遗漏的问题太多，需要与开发组织BUG评审，确认哪些问题是可以带上市，可以不做修改，以此来降低开发对BUG的修改时间，确保产品量产能按照计划时间顺利进行。另外，晚期的验收阶段，最好进行三个版本的验收测试。
5. 系统测试分为三个阶段，并不是单纯的时间三等分，而是每个时间段都需要达到测试目标。
若没有达到测试目标，测试PM需要及时调节计划，并组织分析问题，避免因为测试不到位的原因导致项目延期。
3.2.2.2软件测试执行阶段人员活动图 活动图
活动图描述 目的
1. 有效的制定系统测试的软件测试计划；
2. 按照计划进行测试，发现软件中的存在的问题（包括：界面、需求、功能、兼容性、性能等方
面问题）。
3. 对软件中已经解决的问题进行有效的验证; 4. 判定测试过程和问题验证的有效性； 进入条件
1. 完成系统测试计划和系统测试用例;
2. 测试工程师领用了测试样机和相关的测试资源。 3. 已确认软件测试申请、软件版本和Release Note。 输入
1. 软件测试计划和软件测试用例。 2. 软件测试申请； 作业流程及其管理方法
输出
软件测试计划（Cycle）、系统测试报告（Cycle）、场测计划、场测报告
3.2.3测试扫尾工作（S4~S6） 目的
1. 根据测试结果，做好软件风险评估，评断软件是否符合量产标准 2. 做好测试总结，积累好的经验，去除不好的东西 进入条件
1. 完成了测试执行阶段，产品申请量产
11
4.缺陷管理
12
4.2 BUG处理规范
1. 测试工程师在测试过程中发现Bug后，提交到bugfree上，并在后续版本上进行Bug的验证和关闭。对于现场测试出现的BUG，可在测试完成回来后将BUG提交到bugfree上；
2. 开发人员修改完BUG后，应及时将BUG状态置为“已修复”同时备注好测试需要验证的版本号。测试工程师在每次更新版本时，首先验证“已修复”的BUG，确认修改成功及时关闭BUG，若确认未修改打回到对应的开发工程师。 3.对于设计如此的BUG，需要开发、测试双方进行评估之后，双方都确认是设计如此才可以正常关闭。 4.对应项目晚期，若库里BUG太多影响项目量产日期，可进行BUG评审，确认哪些BUG是必改项，哪些事可以带上市的，可带上市的BUG置成延期处理。 ...........未完待续.........
4.3 量产BUG标准
13
1. S、A级BUG必须完全解决
2. 其他级别的BUG可根据评审结果而定
14
目录
1.概述 ………………………………………………………………………………….…………………..2 1.1目的 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„2 1.2适用范围 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„2 1.3执行原则 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„2 1.4角色和职责 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„2 2.软件测试流程„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„3 2.1软件测试流程图 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„3 2. 2 流程图解析„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„3 3 软件测试周期人员活动图„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„5 3.1 活动图 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„5 3.2 活动图描述 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„7 3.2.1软件测试准备（S0~S2 …...................................................................................................................7 3.2.2 测试执行阶段（S3） „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„8 3.2.2.1软件执行阶段流程图 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„8 3.2.2.2软件测试执行阶段人员活动图………..…………………………………………………………….9 3.2.3测试扫尾工作（S4~S6）„„..„„„„„„„„„„„„„„„„„„„„„„„„„„11 4.缺陷管理..........................................................................11 4.1 BUG级别定义.....................................................................11 4.2 BUG处理规范 „„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„13 4.3 量产BUG标准„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„„13
1.概述
1.1目的
有效的制定不同测试类型（软件系统测试、Field Trial、专项测试、自动化测试）的软件测试计划； 按照计划进行测试，发现软件中存在的问题； 对软件中已经解决的问题进行有效的验证; 判定测试过程和问题验证的有效性。
1.2适用范围
适用范围是参与手机产品软件测试的各测试工程师、测试模块组长、测试PM。
1.3执行原则.
标准化作业，尊重事实；
测试工程师需要对手机各项功能提出疑问的态度来思考软件；
测试工程师需要主动与项目组的所有成员保持有效的沟通，以便更好地完成测试任务； 尽早发现问题，及时跟踪问题；减少、预防后序过程中发生问题；
1.4角色和职责
1.4.1 测试部门经理
1. 负责审核测试计划,监督计划的实施过程，确保按计划进行实施和按计划完成测试任务； 2. 制定、更新和维护软件测试流程；
3. 对发现的部门需要改进的问题提供解决方案； 4. 制定短期、长期的改进措施；进行评审和监督； 5. 监督新员工培训实施情况，对培训结果进行考核 6. 参与项目风险评估 1.4.2 测试PM
1. 参与软件需求与UI评审
2. 编制STP（软件测试计划）
3. 根据软件测试申请单的要求判定是否接受软件测试版本；达到软件测试标准安排系统测试；对测试需求进行组内培训。
4.测试任务的分配；测试过程进行跟踪；处理异常情况；发送定期测试报告（每一个软件升级版本）到测试部门经理、开发、各管理人员
5.跟进BUG的修改情况，组织BUG评审（项目晚期进行）
6.参与项目风险评估 1.4.3 测试功能模块组长
1.参与软件需求评审
2.组织测试工程师编写测试用例以及测试用例的维护，并与测试PM、开发一起进行用例评审 3.组内成员工作技能的培养与培训，组内成员的业绩考核 4.协助测试PM做好人员调配 5.协助测试PM进行BUG评审 1.4.4 测试工程师
1. 按照系统测试计划进行系统测试用例的执行， 2. 测试记录的整理，
3. Bug的跟踪【包括：提交、验证、关闭Bug】。
2.软件测试流程
2.1软件测试流程图
2. 2 流程图解析 需求分析
一般而言，需求分析包括软件需求文档、软件规格书以及开发人员的设计文档等。测一款软件首先要知道软件能实现哪些功能，如果是手机常规运用与手机平台原生态的东西可以不提供需求分析文档，这个需求分析对于手机软件而言主要针对新的定制、新的应用等。
测试计划
测试计划由测试PM负责制定，测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测
试计划一般包括以下一些方面：
1. 测试背景 a, 项目介绍
b, 项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等 2. 测试依据 a, 软件需求文档 b, 软件规格书 c, 软件设计文档 d, 其他，如参考产品等 3. 测试资源 a, 测试人员需求 b, 测试样机需求 4. 测试策略 a, 采取测试方法
b, 采取哪些测试工具以及测试管理工具
c, 对测试人员进行培训等
5. 测试日程 a., 测试需求分析
b, 测试用例编写
c, 测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，外场测试、α、β测试阶段等），每个阶段的工作重点以及投入资源等。
计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在
软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控了。在变化面前能够做到应对自如、处乱不惊那是最好不过了。
测试设计
对于手机而言，测试设计主要包括测试用例的编写。由于常规的测试点的用例都已经具备，这里主要
针对新的需求与应用。 测试执行
测试执行阶段一般分为以下阶段：
确认测试→系统测试→验收测试→产品说明书check，其中每个阶段还有回归测试验证问题。单元测试、集成测试目前暂无需求，后期项目可根据实际情况添加。
从测试的角度而言，测试执行过程是要考虑量和度的问题，就是指测试的范围与测试的程度的问
题。
从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地
利用资源来开展测试。当然如下几个问题也需要考虑：
a, 当测试人员测试的执行不到位、敷衍了事时该如何解决？ b, 测试效率问题，怎样提高测试效率?
c, 根据版本的不同采取怎么样的测试策略，是全面测试、自由测试还是针对模块的测试 d, 达到量产的标准，是否需要项目延时等标准。
软件评估
这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发布量产的软件进行评估，以确定是否能够投放市场。软件评估小组一般由项目负责人、营销人员、部门经理等组成。 测试总结
项目已经发布量产，测试项目组可以通过各种方式对整个测试过程进行总结，可以是做的好的方面的经验，也可以是不足之处以便后续项目避免。
测试维护
由于测试的不完全性，当软件正式release后，用户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，修改后需要再次对软件进行测试、评估、发行。
3 软件测试周期人员活动图
3.1 活动图
3.2 活动图描述
3.2.1软件测试准备（S0~S2） 目的
1. 有效的制定软件测试用例的编写计划和评审计划； 2. 按照用例编写计划进行测试用例的编写和评审。
3. 对评审的问题进行记录，并根据评审意见和需求变更进行更新测试用例 4. 判定测试用例编写、评审过程的有效性； 进入条件
1. 项目正式启动 2. 需求文档已经进行归档 输入
软件开发计划、软件开发时间表、菜单树、功能列表、人机界面规格说明书、冲突说明、内存使用分配表、按键定义、最大/最小值、默认值、需求的变更信息等相关需求文档。 作业流程及其管理方法
输出
软件测试计划（STP）、测试用例
3.2.2 测试执行阶段（S3） 3.2.2.1软件执行阶段流程图
软件执行阶段流程图解析
1．根据整个软件测试执行过程，按时间分成三等分，分别为T1：测试初期、T2：测试中期、T3：
测试晚期与验收测
2. T1：测试初期这个阶段，主要执行确认测试、基本功能的测试。确认测试的目标需要确保软
件完全符合设计文档。基本功能的测试的重点是执行测试用例，尽可能多的去暴露基本功能的问题，测试的执行方式以执行测试用例为主。
3. T2：测试中期采用自由测试为主，除了测试基本功能外，还需要重点测试性能、兼容性测试、
音频主观性测试。其中性能测试可借助于自动化测试工具进行测试。另外这个时期需要外场测试的进入，测试目的是模拟动态环境下用户的使用过程下手机是否稳定。
4. T3：测试晚期阶段，这个阶段仍然需要执行多遍测试用例以确保基本功能的实现完全没有问
题。同时根据项目进度，库里面遗漏的问题太多，需要与开发组织BUG评审，确认哪些问题是可以带上市，可以不做修改，以此来降低开发对BUG的修改时间，确保产品量产能按照计划时间顺利进行。另外，晚期的验收阶段，最好进行三个版本的验收测试。
5. 系统测试分为三个阶段，并不是单纯的时间三等分，而是每个时间段都需要达到测试目标。
若没有达到测试目标，测试PM需要及时调节计划，并组织分析问题，避免因为测试不到位的原因导致项目延期。
3.2.2.2软件测试执行阶段人员活动图 活动图
活动图描述 目的
1. 有效的制定系统测试的软件测试计划；
2. 按照计划进行测试，发现软件中的存在的问题（包括：界面、需求、功能、兼容性、性能等方
面问题）。
3. 对软件中已经解决的问题进行有效的验证; 4. 判定测试过程和问题验证的有效性； 进入条件
1. 完成系统测试计划和系统测试用例;
2. 测试工程师领用了测试样机和相关的测试资源。 3. 已确认软件测试申请、软件版本和Release Note。 输入
1. 软件测试计划和软件测试用例。 2. 软件测试申请； 作业流程及其管理方法
输出
软件测试计划（Cycle）、系统测试报告（Cycle）、场测计划、场测报告
3.2.3测试扫尾工作（S4~S6） 目的
1. 根据测试结果，做好软件风险评估，评断软件是否符合量产标准 2. 做好测试总结，积累好的经验，去除不好的东西 进入条件
1. 完成了测试执行阶段，产品申请量产
11
4.缺陷管理
12
4.2 BUG处理规范
1. 测试工程师在测试过程中发现Bug后，提交到bugfree上，并在后续版本上进行Bug的验证和关闭。对于现场测试出现的BUG，可在测试完成回来后将BUG提交到bugfree上；
2. 开发人员修改完BUG后，应及时将BUG状态置为“已修复”同时备注好测试需要验证的版本号。测试工程师在每次更新版本时，首先验证“已修复”的BUG，确认修改成功及时关闭BUG，若确认未修改打回到对应的开发工程师。 3.对于设计如此的BUG，需要开发、测试双方进行评估之后，双方都确认是设计如此才可以正常关闭。 4.对应项目晚期，若库里BUG太多影响项目量产日期，可进行BUG评审，确认哪些BUG是必改项，哪些事可以带上市的，可带上市的BUG置成延期处理。 ...........未完待续.........
4.3 量产BUG标准
13
1. S、A级BUG必须完全解决
2. 其他级别的BUG可根据评审结果而定
14