编号：  ST-XX-STP               　　        　        　    密级：

公司内部

 

北京中讯润通科技有限公司软件部

20##年11月03日

修改历史

注释：评审号为评审记录表的编号。更改请求号为文档更改控制工具自动生成的编号。

目录

1 概述.... 1

1.1        目标.... 1

1.2        范围.... 1

1.3        参考资料.... 1

术语及缩略词... 1

2     测试对象.... 2

3     测试步骤.... 2

4     测试阶段.... 3

5     回归测试.... 4

6     测试工作成果的交付.... 4

7     测试任务.... 4

8     测试环境要求.... 4

8.1     硬件... 4

8.2     软件... 5

9     职责划分.... 5

10       人员及培训要求.... 6

10.1       人员安排... 6

10.2       培训... 6

11       进度.... 6

12       风险及风险管理.... 6

13       Bug管理系统.... 7

13.1    Bug 管理... 7

13.2    BUG级别的定义... 7

1 概述

本测试计划是针对PS平台的XX手机产品软件功能的测试工作而编写的，主要内容包括测试对象、测试步骤、接受标准、回归测试，同时也是测试组的测试任务、测试职责、人员安排、进度和测试的预期风险及使用BUG管理系统的描述，提供了一个对该软件系统的整体测试计划，用以指导本项目软件测试组的测试人员的工作，同时也为相关项目开发人员提供交流的依据。

XX具有内置摄像头、彩信、移动QQ等功能。XX的单元测试、集成测试由开发组完成，测试组协同开发组进行测试。系统测试由测试组完成，开发人员协同配合。外部测试（现场测试，FTA/TA／SA）由项目软件经理负责，测试组配合。

1.1  目标

本测试计划的目标如下：

l  检验手机软件系统是否满足XX软件需求规格说明书，XX UI Spec，XX产品说明PD，XX MenuTree中的功能/性能的需求。

l  测试组的测试人员在项目启动后开始测试工作的准备，如编写软件系统测试计划，软件系统测试用例（包括手机软件的功能和性能，压力测试等方面），软件测试环境的搭建等。其中根据XX软件需求规格说明定义的功能和性能需求，XX UI Spec，XX MenuTree，XX产品特性说明PD编写XX软件系统测试用例。

l  在实际运行（使用）环境下根据评审通过的软件系统测试计划和软件系统测试用例进行软件系统的测试，并形成软件系统测试记录和测试Log。

l  依据软件系统测试记录和TestLog等相关信息，对测试记录的结果数据进行整理和评价，并形成软件系统测试报告（周报，里程碑报告，总结报告）。

l  外部测试（现场测试，FTA/TA／SA）的测试用例确保涵盖手机行业的标准或公司的标准。

1.2  范围

本文档适用于指导本项目软件测试组的测试工作。其中内置摄像头、彩信、SMS、移动QQ、等为重点的测试模块。

1.3  参考资料

l  < ST_XX_Schedule.mpp>

l  <ST_QCT_XX_MENUTREE>

l  < ST_QCT_XX_SCMP >

l  < ST_QCT_XX_SQAP>

l  <ST_XX_ UI_Spec>

l  <Objective of software implement in every phrase>

术语及缩略词

MMI      Man Machine interface

SMS      Short Message Service

UI       User Interface

FTA      Final Type Approval,是各国GSM手机进入GSM网络必须通过的专业测试,国内开发的手机一般在邮电部传输所和7 layers合资的公司参加测试

TA       即邮电部的移动终端入网测试,一般由各个品牌商出面参加测试

SA   Shipment  assessment

ClearQuest: 软件需求变更，软件缺陷跟踪管理工具

ClearCase : 软件版本配置管理工具

TMT: Test Management Tool

  

2      测试对象

下面为测试对象：

1、  消息(包括MMS、EMS、SMS)

2、  照相机

3、  移动QQ

4、  电话本

5、  我的文档

6、  设置

7、  附件

8、  STK

9、  WAP

10、 游戏

11、 电话拨打和接听

12、 输入法

13、 附加服务

14、 硬件相关

15、 其它

3      测试步骤

1、 项目启动后，项目软件测试负责人负责完成《XX软件系统测试计划》，并进行评审和更新维护。

2、 在项目启动后，依据XX软件系统测试计划、XX的软件需求文档SRS,UI Spec,MenuTree,PD（Feature List）等，项目软件测试负责人编写软件系统测试用例，并进行评审和更新维护。其中包括PreTest的软件系统测试用例。将来用TMT工具管理测试用例。

3、 在项目开发组提交第一阶段测试程序（System Test Cycle 1）之后，软件项目测试组依据《XX软件系统测试计划》和《XX软件系统测试用例》来进行软件测试工作。同时用Bug管理工具ClearQuest的缺陷跟踪进行软件测试Bug的提交，跟踪管理。

4、 每次对内Release之前，需要根据《XX PreTest软件系统测试用例》进行1～2天的PreTest，并用Excel记录测试记录，并将发现的Bug及时提交给开发组进行Fix。

5、 每次对外Release之前，除了进行PreTest之外，还要根据《XX软件系统测试用例》进行完整的软件系统测试，并形成测试记录和TestLog，并将Bug提交到ClearQuest上。

6、 每个对外正式的release版本完成了完整的系统测试（一般为5个工作日）后，项目软件测试负责人在软件部WEB上的项目页面上及时提交软件测试报告（周报、里程碑报告，总结报告），如有可能提交软件测试记录和有关的TestLog。

7、 对于对内的中间版本或者预测试的版本的测试，要求使用excel表格记录测试结果（将来用TMT工具自动记录）。

8、 项目组的测试工程师将测试记录结果（如执行的pretest Testcase及对应的测试结果）提交给测试负责人，由测试负责人整理、汇总后形成软件系统测试记录报告和软件系统测试报告放置到软件部WEB的XX项目页面上，并用邮件通知XX人员（包括软件项目经理，软件开发人员，SCM，SQA，测试组全体人员）和PM／QA／SSM人员。只有XX项目的软件测试工程师和软件测试负责人有权往ClearQuest Open Bug和将Bug状态进行关闭.对于开发人员Fix的Bug进行回归测试验证,决定将该Bug Close或者ReOpen.

9、 在测试过程中发生软件需求变更时，XX软件测试人员根据ClearQuest发布的邮件通知,PRM发布的PR/CR/DR通知和评审通知,以及测试组其它项目软件测试工程师发布的软件测试记录和软件测试报告,以及SQA提供的SQA报告信息,以及软件项目经理/QA转发的市场和用户以及其他部门反馈的软件问题,以及试用手机发现BUG,更新XX系统软件测试计划和XX系统软件测试用例。

10、        在每次软件内部Release,外部Release(FTA,CTA,Factory Poilot Run,量产,维护)时,及时提交XX软件系统测试记录报告和XX软件系统测试报告.

11、        每次现场测试时,软件测试负责人负责软件现场测试计划,软件现场测试用例,软件现场测试报告的协调,检查,提交。

12、        《XX软件系统测试计划》和《XX软件系统测试用例》要放置在ClearCase 的Doc_Vob／XX目录下，并及时进行更新，同时更新软件部WEB的相关文档的链接。

4      测试阶段

测试阶段的接收标准依据《软件阶段实现目标》执行，参考该文件的相关部分。

接收标准分四阶段：

System Test Cycle 1：

        

软件系统大部分功能集成完成，并针对已经实现的功能进行系统的软件测试以及内部发布的PreTest。该阶段结束的接受标准是拨打和接听电话、短信息、电话簿和其它与网络相关的功能全部实现。

FTA &Field Test Cycle 2：

对经过软件系统测试和现场测试和修改过Bug和增加新Features的软件送交FTA之前进行的系统性软件测试和内部发布的PreTest测试，为FTA提供软件系统测试报告。，将经过软件系统测试的软件按照软件现场测试计划进行现场测试，以及配合现场测试所需要的软件系统测试和内部发布的PreTest。将经过软件系统测试的软件按照软件现场测试计划进行现场测试。该阶段结束的接受标准是大部分的软件（（如除了游戏和WAP功能外））关键功能实现正确。

TA ＆ Field Test Cycle 3：

对经过FTA和修改过Bug和增加新Features的软件送交CTA之前进行的系统性软件测试测试和PreTest测试，为CTA提供软件系统测试报告。将经过软件系统测试的软件按照软件现场测试计划进行现场测试，以及配合现场测试所需要的软件系统测试和内部发布的PreTest。将经过软件系统测试的软件按照软件现场测试计划进行现场测试。该阶段结束的接受标准是所有的软件功能实现正确。

SA Test Cycle 4：

对经过TA的软件进行试生产，以及修改Bug和增加新Features的软件再进行量产前的完整性系统测试和每次内部发布的PreTest测试，为SA提供软件系统测试报告。该阶段结束的接受标准是所有的软件功能完善和性能稳定。

Mass Manafuture ＆ Maintance Test Cycle 5：

对量产阶段反映的问题和市场用户反馈的问题进行BugFix，增加必要的新Features后，每次出厂前需要进行完整性系统测试和每次内部发布的PreTest测试，提供软件系统测试报告。该阶段结束的接受标准是所有的反映的软件Bug被Close，并经过充分的回归性测试验证，并且整个软件系统功能完善并且性能稳定。

5      回归测试

在每次Release之后（对内和对外），在新的正式release版本基础上，根据PR/CR/DR和ClearQuest需求变更情况，以及其它项目组的软件测试记录报告，本项目的SQA报告，本项目的Bug历史记录，以及通过软件项目经理反馈的来自其他渠道的（来自QA/客户／PM/试用手机的Bug）Bug Fix后，进行有重点针对性的运行软件测试用例，验证是否实现新增加功能和修改存在的Bug――即回归测试，并形成软件测试记录。然后对测试记录中的Bug通过Clearquest提交。

6      测试工作成果的交付

按照软件测试计划及时交付如下的测试文档：

l  《XX软件系统测试计划》

l  《XX软件系统测试用例》

l  《XX软件系统Release测试记录报告》（包括《XX软件发布预测试记录报告》）

l  《XX软件系统测试报告》(周报,月报,总结报告)

7      测试任务

l  参考《XX软件项目开发计划》文档制定《XX软件系统测试计划>,并进行评审,评审后放入ClearCase Doc—Vob库的XX目录下,并根据SDP计划的改变进行及时更新和维护。并及时将有关信息通知项目组的人员（软件开发人员，SCM,SQA，SPM，SSM，测试组全体人员）及相关的QA、PM人员。

l  根据《TF_CNXT_XX_PD.doc》,《TF_CNXT_XX_SRS》,《TF_CNXT_XX_UISPEC》,《TF_CNXT_XX_MenuTree》编写《TF_CNXT_XX_SoftwareTestTestCase》,并进行评审,,评审后放入ClearCase Doc_Vob库的XX目录下,并根据《TF_CNXT_XX_SRS》,《TF_CNXT_XX_UISPEC》,《TF_CNXT_XX_MenuTree》的改变进行及时更新和维护。并及时将有关信息通知项目组的人员（软件开发人员，SCM,SQA，SPM，SSM）及相关的QA、PM人员。

l  每次Release测试分为PreTest测试和系统测试.其中PreTest测试时,将《XX预测试软件测试记录报告》报送给SPM／SQA确认和修改.系统测试时, 将《XX系统软件测试记录报告》和《XX软件系统测试报告》报送给SPM／SQA确认和修改，同时将《XX软件系统测试报告》中的测试Bug提交给CLEARQUEST,并及时更新Clearquest上的Bug状态，,并将SPM/SQA确认后的《XX系统软件测试记录报告》和《XX软件系统测试报告》放置在软件部WEB的XX项目的页面上,并用Email及时通知项目组人员和SQA,SCM，软件测试组全体人员，SPM和SSM.

l  XX项目组的测试人员在接到其它项目组的测试报告邮件通知后,及时验证其它项目的Bug是否在XX存在,如果存在,填写《XX软件测试记录报告》并将Bug提交到Clearquest。

l  及时将每次Release的PreTest和系统软件测试记录报告和测试报告放置到软件部WEB上，并通知项目组的人员及相关的QA、PM人员。

8      测试环境要求

8.1 硬件

下面表格是软件系统测试所要求的硬件环境：

8.2 软件

9      职责划分

项目测试负责人:

负责跟踪、管理本项目的测试工作，并确保该项目的产品质量无严重错误。负责编写XX系统测试计划,XX系统测试用例,编写XX PreTest测试用例,PreTest测试记录,软件测试报告,捕获软件测试Log（根据需要），在每个正式发布的release版本上验证Clearquest上的Bug，确认后close。对于执行中间版本或者预测试（准备打lable时）版本时，将测试的结果与测试工程师的提交的结果进行整理、合并，确认后提交给项目经理。与项目经理、测试经理、测试工程师进行有效沟通，同时与相关工作人员进行协调。积极主动负责测试本项目，应项目经理要求加班时，应尽量配合。

测试工程师:

负责实施、执行测试，并记录测试结果。配合项目测试负责人的测试工作，对于执行中间版本或者预测试（准备打lable时）版本时，依据XX系统测试计划、XX系统测试用例、XX PreTest测试用例执行测试，将测试记录的结果和测试报告直接提交给项目测试负责人即可。对于正式发布的release版本的测试，同样依据XX系统测试用例执行，测试的具体部分由项目测试负责人安排。发现的Bug经项目测试负责人确认后，提交到Clearquest上，同时，直接提交测试记录结果给项目测试负责人。应项目经理要求加班时，应尽量配合。

10   人员及培训要求

10.1 人员安排

测试活动及人员安排安排如下：

10.2 培训

11   进度

                       

12   风险及风险管理

1、 测试人员未能正确的理解该项目的软件功能需求。措施：可以通过参加软件需求评审。

2、 测试人员与相关的开发人员交流不够充分。措施：通过建立软件测试记录报告和软件测试报告制度，以及个人周报制度，充分使用ClearCase，ClearQuest，PRM，PCD等管理软件系统和软件测试经理的考核。

3、 软件测试时间不能充分保证和预留（Release PreTest需要一个工作日，软件系统测试需要5个工作日）。措施：软件项目经理尽量将Release时间提前通知软件测试人员（最好提前5个工作日）。

4、 由于开发人员release版本的延时造成测试工作不能按计划进行，造成测试不能充分。措施：配合开发进度进行相应的加班。

13   Bug管理系统

13.1    Bug 管理

Bug的管理系统使用的是Clearquest。Clearquest的 Bug提交和关闭仅限本项目组内的测试人员（包括项目软件测试负责人），如果Bug的来源不是本项目的测试人员发现的，要求软件项目经理及时通知到本项目的测试负责人，由项目测试负责人确认后，提交Bug。对于预测试版本（pretest）的发现Bug,不能提交到Clearquest上，要求及时填写并提交软件测试记录报告和软件测试报告，必要时可以组织有关人员（软件项目经理，软件测试经理，SQA经理，软件测试负责人，核心模块软件开发工程师，软件部总／副总经理）进行软件测试记录报告和软件测试报告的评审，对测试报告中的Bug进行确认。

13.2    BUG级别的定义

一级 Bug(AA)：导致系统无法实现功能目标，使用无法继续进行。主要包括：程序非正常终止、程序死机、关键需求未实现、软件功能与需求严重不符。并且重现率为50%上的，为一级BUG。

二级 Bug(A)：导致系统无法正常实现功能目标，但知道如何通过其它途径来避免错误发生。主要包括：程序非正常终止但可避免、非关键需求理解错误。并且重现率为50%以下，或者使用频率不高，为二级BUG。

三级 Bug(B)：系统功能目标基本实现，软件功能与需求基本相符，但部分功能有错误或者界面显示有错误。例如：单个字符串显示错误，图片位置与文字重叠，无法辨认等。

四级 Bug(C)：界面显示与需求相符，但用户使用不方便，如用户界面不很友好。