SWD System Test Management
修订记录
序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 文件编号： 文件类型： 受控状态： 文件版本： 发布日期： 总 页 数： 编制： 审核： 批准： 日期: 日期： 日期： 版本 修订更改描述 编制 审核 批准 更改日期 1 目的
控制和管理软件测试流程
确保手机软件功能满足软件相关需求
2 编制依据
软件工程通用要求
部分ISO9001,CMM标准的原则 原有项目的宝贵经验
3 执行原则
1. 2. 3. 4. 标准化作业，尊重事实
严格执行测试计划和测试用例，排除测试的随意性
测试人员需主动与项目相关人员保持有效的沟通，以便更好地完成测试任务 尽早发现问题，及时解决问题；减少、预防后序过程中发生同样问题
4 适用范围
设计研发的手机软件的单元测试，集成测试及系统测试
5 术语、定义
CR : Change Requests,通常作为一项待实现的新功能的索引 PR : Problem Reports,通常作为一个需要改正的Bug的索引
DR : Document Request,通常作为一个需要维护的一个文档变更索引 Clear Case : 软件版本配置管理工具
Clear Quest: 软件需求变更，软件缺陷跟踪管理工具
FTA : Final Type Approval,是各国GSM手机进入GSM网络必须通过的专业测试,国内开发的手机一般在邮电部传输所和7 layers合资的公司参加测试
TA : 即邮电部的移动终端入网测试,一般由各个品牌商出面参加测试
PD : Product Description,从市场前景,软硬件,外观,结构,产品开发里程碑(Milestone)等方面对一个新产品进行描述的文档
SCM: Software Configuration Management SQA: Software Quality Assurement SRS: Software Requirement Specification SDS: Software Design Specification SIS: Software Interface Specification UI_Spec: User Interface Spec
Menu Tree: Menu Tree，菜单树 SDP: Software Development Plan
SCMP: Software Configuration Management Plan STP: Software Test Plan STR: Software Test Report SA: Shipment assessment
6 岗位职责
6．1 执行职责
6．1．1 软件测试经理
规划，建立，维护软件测试管理流程 制定,改进和维护软件测试流程 监控并协调各项目的软件测试工作
创建，维护测试用例，评审新增测试用例 评审，批准软件项目测试计划 与其它部门的协调、合作
6．1．2 软件测试项目负责人
编写软件测试计划
编写并维护测试用例，并依据测试计划及测试用例进行测试
编写软件测试记录和测试报告，并提交给相关人员， 对Bug 和测试报告进行评审 组织软件测试计划，软件测试用例的评审，参与软件需求及软件需求变更的评审
6．1．3 软件测试工程师
执行软件测试计划
编写并维护测试用例，并依据测试计划及测试用例进行测试 填写测试记录和测试报告 验证关闭Bug
6．1．4 软件开发工程师
按照开发计划，依据制定的质量标准进行软件开发 负责具体模块的需求分析，设计，编码和维护
进行单元测试，对相关模块的文档和代码进行评审验证关闭Bug 对软件Bug及时进行分析，改进和解决
6．1．5 软件质量保证工程师
编写并严格执行项目软件质量保证计划
确保所负责项目的软件过程文档和记录符合软件质量要求
确保所负责软件项目的各种评审按照软件评审流程执行，并跟踪评审问题的状态 监督软件项目的开发管理过程，及时发现软件质量问题并跟踪解决
6．2 编制、修改、评审、审批、更新职责
本流程由软件测试组编制、修改；由相关部门共同评审，并经管理层签字认可方可生效。 测试组应根据项目具体情况对本流程进行适时更新，组织评审，并经管理层审批。
7 作业流程、管理办法
7.1 作业流程
NO 1项目启动 2 需 求 阶 段
作业过程名
了解软件要求 作业内容 / 管理方法
了解《产品定义(Product Description)》中规定的软件相关的主要功能（如：彩信、电子邮件、手写输入等）要求。搜集、分析软件测试输入内容。
职责 测试经理； 测试项目负责人
输出结果
识别测试要求 测试人员参加《软件开发计划(Software Development Plan)》，《软件开发时间进度表(Schedule)》，《软件需求规格说明》，《软件功能菜单树(Menu Tree)》，模块的《软件需求规格说明(SRS)》，《人机界面规格说明(UI Spec)》评审会议；软件测试项目负责人依据《软件开发计划(Project Software Development Plan)》，《软件开发时间表(Schedule)》编写《软件测试计划》
软件项目经理；软件测试项目负责人；软件测试经理
《软件测试计划》
测试计划 测试用例 测试项目负责人依据《软件需求规格说明》，《软件功能菜软件测试单树》，模块的《软件需求规格说明(SRS)》，《人机界面规项目负责格说明(UI Spec)》编写《软件测试用例》包括（版本发布人 预测试测试用例和软件系统测试测试用例），并组织评审。 完成模块的软件测试用例 软件测试软件需求变更时，根据更新的软件开发计划和需求文档相项目负责应变更和修改《软件测试用例》和《软件测试计划》。 人 软件需求发生变更时，及时维护测试用例。
完善测试用例
软件需求发生变更时，及时维护测试用例。
《软件测试测试用例》
《软件测试计划》；《软件测试用例》
3设 计 阶 段 4编码和单元测试阶段
测试计划、测试用例评审、完成 单元测试 测试记录 Bug修改 回归测试 测试记录 ClearQuest上软件项目的Bug记录； 经理,开发 工程师,软件测试工程师、SCM, SQA.
5 集成测试 阶段 软件模块 集成 预测试 测试记录 Bug确定 Bug报告 Bug修改 版本发布 集成测试 Bug关闭 6 系统测试 阶段
Bug修改 新版本发布 预测试 测试组依据项目测试用例对已集成的软件模块进行系统测试，测试周期一般为期5天。
当SCM发布新版本后第二天起，测试人员对该版本进行全面的集成测试，确保软件所有功能的正确性，性能达到要求。
软件测试项目负责人总结汇总相关测试人员提交的测试结果，填写《软件测试记录》，提交给软件项目经理，软件测试组成员，SQA。
当软件需求发生变更时或根据本项目和其它项目的Bug发现情况，及时增加修改有关测试用例。
测试组依据测试用例对已集成的软件模块进行系统测试，测试周期一般为期5天。
当SCM发布新版本后第二天，测试人员对该版本进行全面的系统测试，确保软件所有功能的正确性，性能达到要求，压力测试和冲突测试达到预期结果。
软件整个生命周期内进行function test 3－4 circle；stress test 2 cycle；call test 6－7 cycle；regression Test 2 cycle。 软件测试项目负责人汇总测试人员提交的测试结果，填写《软件测试记录》，提交给软件项目经理，测试组成员和SQA。
当软件需求发生变更时或根据本项目和其它项的Bug发现情况，及时更新测试用例。
测试组在测试时，对以前修改的PR/CR进行有针对性的回归测试。
软件项目经理组织对Bug管理系统中提交的各个Bug讨论和分析,确定每个Bug是否是真正的软件问题,Bug所属的模块,严重程度和修改紧急度等,同时把每个Bug分配给相应的开发人员，并由开发人员进行修改。
软件项目经理, 开发工程师, 软件测试工程师, SCM, SQA.
ClearQuest上的Bug记录
《软件测试记录》
《客户测试计划变更书面申请》
测试记录 软件项目经理
开发工程师,
软件测试工程师, SCM, SQA. ClearQuest上的Bug记录
《软件测试记录》
《客户测试计划变更书面申请》
Bug确定 Bug报告 版本发布 软件项目ClearQuest上经理 的Bug记录 开发人员、 SCM
ClearQuest上的Bug记录
系统测试 测试记录 开发人员修改Bug后，及时更新Clear Quest上的bug记软件测试录（变为Resolved）。在软件版本更新后由测试人员验证工程师, 修改过的Bug是否可以close，在描述中记录验证结果，SQA. 拒绝或关闭Bug。
Bug报告 Bug关闭 软件测试项目负责人编制每个版本《软件系统测试报告》，软件测试发给软件开发项目组成员、软件测试组全体、软件部总监、项目负责PM、SQA。 人
《软件系统
测试报告》
7 （FTA / TA） FT
外部测试 A /
前的确认 TA
SA check 8 SA 参与 SA check SQA根据软件版本外发认证评审 (OQR)（根据软件项目阶段开发目标及验收标准），判断可否送出做FTA/TA测试。
SQA
ClearQuest上的Bug记录
《软件系统测试报告》
SA check
判断可以送出进行外部测试时由软件项目经理通知PM。 SPM；软件
测试经理 软件测试项目负责人参与SA check 。 软件测试依据软件测试用例进行检查，判定整体软件设计开发输出项目负责是否满足设计输入要求 人 根据《用户手册》中编写的功能介绍和功能使用方法进行SQA 测试。发现异常以后通知市场部进行用户手册修改。 开发项目结束后, 软件测试组应进行软件测试总结，对软件测试管理过程，活动进行分析，为将来的项目和持续改进积累经验数据.
9 量产和维护测试阶段
手机上市 客户反馈 确认问题 Bug报告 Bug修改 测试 软件升级 当手机上市后，对手机产品的软件进行维护和售后服务，在此期间，由AM接受客户的反馈，通知软件项目经理、SQA、PM等。软件项目经理将用户反映的一些问题（确认是BUG后）通知软件测试项目负责人，进行核实问题 软件测试负责人确认问题Bug后，提交Bug管理系统，并通知软件项目经理。
软件项目经理组织对Bug管理系统中提交的各个Bug讨论和分析,确定每个Bug是否是真正的软件问题,Bug所属的模块,严重程度和修改紧急度等,同时把每个Bug分配给相应的开发人员，开发人员申请PR后进行相应的修改工作。 同时，项目经理把每个Bug分配给相应的开发人员，开发人员申请PR后进行相应的修改工作。
当SCM发布外部running change版本前，测试人员首先对集成的所有模块进行全面合法的版本发布预测试，确保产品基本功能的正确性；
开发人员修改Bug后，及时通知软件测试人员，SCM和SQA。测试人员及时验证开发人员修改的Bug是否确实可以close。
当SCM发布外部running change版本后，测试项目人员对该版本进行全面的系统测试，确保软件所有功能的正确性，性能达到要求，压力测试和冲突测试达到预期结果。 量产和维护测试阶段的测试、完善工作进行到软件成熟为止。
当软件需求发生变更时或根据其它和本项目Bug发现情况，及时修改有关测试用例。
如果客户提出测试加速的申请，SQA及测试负责人负责风险分析，当客户确认承担风险的责任时，按照客户要求去做，否则，按照经客户确认过的测试计划和测试流程去做。
AM
软件项目经理；
客户代表
软件测试经理
SCM SQA
ClearQuest上的Bug记录
《软件系统测试报告》
《客户测试计划变更书面申请》
7．2 管理办法
1. 软件测试人员必须熟悉测试用例要求及操作
2. 软件测试项目负责人需监督软件测试人员是否有效按照测试用例进行测试和并检验测试结果的有效
性，发现异常时及时进行分析，并实施改进措施
3. 对新版本软件发布时的《release note》中注明的变更、修改、增删内容，软件测试项目人员要仔细阅
读、了解变更、修改、增删的内容
8．软件Bug 管理系统
8．1 SW Bug 提交方法
1. 测试组采用Clear Quest提交Bug 2. Bug标题采用英文填写，描述采用中文 3. 提交Bug用语需规范，基本操作步骤及手机状态采用专有词汇描述 4. 提交Bug描述要详细，采用固定格式填写，问题定位要准确 8．2 软件 Bug 级别定义 BugLevel Description A 致命故障，正常操作下导致系统无法工作、危害严重的故障。 A类故障事例： 1.可重现的死机、掉电、自动重启现象 2.无法开机 3.不能通话、找不到网络 4. 客户logo、IMIE号出错 5.可重复的花屏、黑屏、蓝屏等现象；待机电流大 6. 其它同等故障 B 严重故障，正常操作下常用菜单功能的不可恢复错误，或严重影响用户使用的故障。以及用户容易发现的显示错误。 或者非正常操作下导致的错误，严重影响用户使用并且用户容易重现的故障。 B类故障事例： 1. 常用功能模块中功能失常 2. 常用功能模块中按键失灵 3. 常用功能模块中MMI界面显示错误。 4. 常用功能模块中有关文字信息（短信、帮助等）出现乱码、显示紊乱 5. 其它同等故障 C 一般故障，功能表现不正确，影响用户正常使用的故障，以及其他非常用界面的显示错误。 如：日期时间显示出错等一些功能性或逻辑上的处理错误。 或者非正常操作下导致的错误，影响用户使用但用户不易重现的故障。 C类故障事例： 1. 次要功能模块中功能失常 2. 极端情况下的功能失常、死机、掉电、自动重启现象 3. 次要功能模块中MMI界面显示错误 4. 其它同等故障 D 轻微故障，不影响用户正常使用的故障，或仅偶尔影响个别非常用功能的故
障。 以及其他普通用户不能察觉，但又不影响用户使用的设计错误。 D类故障事例： 1．用户界面（MMI）轻微故障错误，如菜单中图片、滚动条、选中条规格不一致等 2. 文字内容有误。 3. 各级菜单、MMI界面及左右soft key的中英文是否一致 4. 其它同等故障 E 1.某个故障曾经出现，但不能重现或难以重现的。 2.对某个故障，软件部已经进行了修改，但难以确认解决得是否彻底，验证比较困难，或验证需要的时间比较长。
8．3 软件 Bug 关闭方法: Bug 级别 Once 3 Versions Less then 30% 1 Version Between 31% and 69% 1 Version More than 70% 1 Version 100% 1 Version A 100 次 3 Versions 100次 1 Version 50次 1 Version 30次 1 Version 20次 1 Version B 100次 3 Versions 100次 1 Version 50次 1 Version 30次 1 Version 20次 1 Version C 100次 3 Versions 100次 1 Version 50次 1 Version 30次 1 Version 20次 1 Version D 100次 100次 50次 30次 20次
8．4 “Not Bug” 确认方法:
由软件项目组长及测试经理统一认可后置为“not bug”
8．5 软件测试组输出文档:
软件测试项目负责人每日发出当天测试进度及Daily bug list
软件测试经理每个测试周期发出该项目bug分析报告及统计误测漏测数据
9．软件测试用例管理系统
1. 测试组采用Clear Case, Test Director管理日常测试用例 2. 软件测试用例需依据《软件需求规格说明》，《软件功能菜单树》《软件需求规格说明(SRS)》《人机
界面规格说明(UI Spec)》从软件测试用例库中选取或重新编写
3. 软件测试用例编写完毕后，由软件项目经理，SQA,相关模块开发人员及相关模块用例编写人员共同评审，评审完毕后在Clear Case, Test Director中归档
4. 系统测试开始后如遇到测试用例未能涵盖的bug，需增加，修改测试用例，并在该轮测试周期完成后将所有增加、修改的测试用例在Clear Case, Test Director中更新
10．加强测试管理，最终降低误测漏测比率
1. 通过培训提高软件测试人员的测试技能和测试理论知识，加强测试人员对软件需求文档的理解能力 2. 完善测试用例库,提高测试用例覆盖面，将每个测试周期新增加的用例及时更新
3. 加强测试用例，bug等管理工具的使用效果（ClearQuest，ClearCase及TestDirector） 4. 改善测试流程，确保功能测试，压力测试及回归测试都得到充分运用 5. 尽早开始测试，确保单元测试，集成测试与系统测试的时间不被压缩 6. 增加自动测试的涵盖范围，降低测试人员的劳动强度
7. 加强单元测试与集成测试，降低本应在单元测试阶段发现而实际在系统测试阶段发现的bug的比率 8. 建立测试效果的评估体系，并将结果与测试人员的业绩挂钩 9. 不同测试周期采用不同测试人员对同一模块进行测试
10. 及时吸取经验教训，及时总结，将旧项目的经验应用到新项目中
因篇幅问题不能全部显示，请点此查看更多更全内容