软件总体测试计划.docx
《软件总体测试计划.docx》由会员分享，可在线阅读，更多相关《软件总体测试计划.docx（17页珍藏版）》请在冰豆网上搜索。
软件总体测试计划
密级：
内部公开
文档编号：
1003
版本号：
V3.0
测测（基于安卓平台的测评软件）
总体测试计划
文件状态：
[]草稿
[]正在修改
[√]正式发布
文件标识：
Company-Project-RD-PRS
当前版本：
3.0
作者：
张放、张钰若、陈国忠
完成日期：
2014-7-23
中国石油大学（华东）
计算机与通信工程学院天师团开发团队
---------------------------------------------------------------------
天师团开发团队对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
文件更改摘要：
日期
版本号
修订说明
修订人
审核人
批准人
2014-04-03
V1.0
初稿
陈国忠
张钰若
陈国忠
2014-06-03
V2.0
修稿
陈国忠
张钰若
陈国忠
2014-07-23
V3.0
定稿
陈国忠
张钰若
陈国忠
1.引言
1.1.编写目的
制定总体测试方案的目的是：
使整个测试工作能有序进行，指导测试人员的工作，为测试提供依据。
提供系统化、规范化、工程化、实用化的测试技术规范，尽早发现故障。
在测试时，须按照此计划执行。
1.2.术语
集成测试：
也叫组装测试、联合测试，集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成子系统。
系统测试：
是将经过测试的子系统装配成一个完整系统来测试。
它是检测系统是否确实能提供系统方案说明书中制定功能的有效方法。
确认测试:
又称有效测试，是在模拟的环境下，运用黑盒测试大方法，验证被测软件是否满足需求规格说明书列出的需求，任务是验证软件的功能和性能及其他特性是否与用户需求一致。
1.3.测试标准
测试标准依据软件需求规格说明书。
测试标准参数
测试标准参数值
测试需求覆盖率
>90%
测试用例覆盖率
>90%
测试用例执行通过率
>95%
缺陷率（bug数量/功能点数）
[0.5,3]
遗留缺陷数量
<5%
1.4.参考文档
文档
（版本/日期）
已创建或可用
已被接收或已经被评审
作者或来源
备注
《软件需求规格说明书》
是■ 否□
是■ 否□
陈国忠
《项目迭代冲刺计划》
是■ 否□
是■ 否□
陈国忠
《软件质量保证计划》
是■ 否□
是■ 否□
陈国忠
2.任务概述
2.1.人员安排
角色
姓名
主要工作职责
测试参与度
测试组长
张钰若
组织测试策划，编制测试计划
组织测试案例的编制
提供技术指导，评估测试工作
汇报测试工作
100％
开发组
张汉
在单元测试中进行B角测试
10％
测试员
陈国忠
参与单元测试与集成测试
50％
测试员
张放
参与单元测试、系统测试、验收测试
70%
2.2.测试环境
硬件环境:
PC机（内存2G及以上、win7操作系统）、安卓智能手机。
软件环境：
安卓4.0及以上系统、SQLite数据库、测测app。
2.3.测试工具
工具名称
版本要求
备注
TestDirector
80
Bug管理工具
VSS
6.0
配置管理工具
QTP
8.1
性能测试工具
3.测试策略
3.1.测试需求
3.1.1.测试需求编号规则
测试需求编号规则包括以下要素：
✧产品编号
✧模块编号
✧功能点和子功能点编号
3.1.2.测试需求的编写规范
测试需求按照《测试需求模板》编写，包含：
任务简介、负责人、变更模块、关联模块的功能特性。
3.1.3.测试需求的管理办法
经过用户接受测试需求分析和导出过程后，将得到用户接受测试需求初稿。
业务管理部门应组织相关的业务人员、技术人员、环境管理人员、测试人员和其他相关人员进行用户接受测试需求评审，确保达成一致意见。
建立用户接受测试需求与业务需求规格、与用户接受测试用例之间的双向跟踪关系；
建立系统集成测试需求与软件需求分析规格、与系统集成测试用例之间的双向跟踪关系；
建立（系统）连接测试需求与概要设计规格、与（系统）连接测试用例之间的双向跟踪关系；
建立单元测试需求与详细设计规格，与单元测试用例之间的双向跟踪关系；
建立内部测试需求与软件需求分析规格、与详细设计规格、与内部测试用例之间的双向跟踪关系。
3.2.测试用例要求
3.2.1.测试用例编号规则
测试用例编号的编写规则如下：
用例编号规则：
GH-XXYY-ZZ
XX为主模块的编号，YY为主模块所包含的子模块的编号。
ZZ为子模块中细分的测试条目。
3.2.2.测试用例的编写规范
编写用例规范 ：
a）系统性
对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系
b）连贯性
对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系
统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯。
c）全面性
应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备
d）正确性
输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合
e）符合正常业务规则
测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规
f）可操作性
测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果
编写用例标准 :
a）测试案例编写应该制订统一的模板进行，并约定模板的使用方法；
b）测试案例编写应当根据项目实际情况编写测试案例编写手册，包括案例编号规则、案例编写方法、案例编写内容、案例维护等内容；
c）案例编写应根据手册中约定的编写方法、内容等进行编写；
d）案例编写要步骤明确，输入输出要素清晰，并且与需求和缺陷相对应；
e）案例编写应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能点；
f）注重案例的可复用性，即在以后相似系统的测试过程中可以重复使用，减少测试设计工作量。
测试用例模板：
字段名称
描述
测试用例优先级
标示符
测试项
测试环境要求
输入标准
输出标准
测试用例间的关联
编写人
编写时间
3.2.3.测试用例的管理办法
测试用例根据《测试用例模板》编写，采用EXCEL文档同时保存于项目库及测试库，测试用例的修改于测试需求矩阵同步。
3.3.测试方案
3.3.1.单元测试
测试目标
发现代码和各功能模块的缺陷。
测试程序和三个模块单元（性格测试、智力测试和“每日一签”）的功能，同时检查内部代码设计，测试错误处理能力。
另外包括后台数据库的设计分析。
测试重点与优先级
测试范围：
各个单独模块的功能实现以及代码设计。
重点与优先级：
1、程序内部结构分析；【高优先级】
2、设计测试用例覆盖各函数，测试各函数功能；
【中优先级】
3、设计测试用例覆盖各分支，测试各分支；【中优先级】
4、设计测试用例覆盖各循环，测试各循环条件、功能；
【中优先级】
5、利用合理的输入、输出数据通过黑盒方式测试模块功能；
【中优先级】
6、后台数据库结构分析及功能测试；【中优先级】
7、选择极端条件测试模块功能。
【低优先级】
测试类型
1、白盒测试：
分析程序内部结构，针对条件和循环进行测试；
2、黑盒测试：
通过输入数据和输出结果来检测软件的行为错误。
测试输入
可运行的软件以及软件需求规格说明、待测试程序代码。
测试输出
1、测试日志：
记录测试中发生的事件。
2、测试报告：
记录程序中出现的缺陷。
3、缺陷度量：
以“天”为单位，记录缺陷出现量。
测试结束标准
1、所有测试案例均已运行至少一次；
2、95%的测试案例成功通过；
3、所有测试结果都已被记录。
测试案例覆盖要求
应涵盖函数、分支覆盖。
其中函数覆盖应为100%，即测试过所有函数。
分支覆盖率也应为100%，即代码中涉及的所有分支情况也应全被覆盖，否则会留下未测试代码，引发潜在风险。
BUG记录要求
1、BUG所处位置；
2、引起该缺陷的输入数据；
3、该缺陷得到的输出结果；
测试实施人
张钰若、张汉、张放
3.3.2.集成测试
测试目标
组装各个功能模块（性格测试、智力测试和“每日一签”）后，测试各模块间是否正确的配合工作、传递数据，检查模块间接口工作是否协调。
测试重点与优先级
测试范围：
模块间接口以及模块组装后的整体系统工作情况。
重点与优先级：
1、测试模块间的关键接口（涉及进行大量数据传输、交换）的代码设计；【高优先级】
2、测试模块间的关键接口（涉及进行大量数据传输、交换）的功能实现；【中优先级】
3、测试子系统（各模块组装后的前台系统）功能及后台子系统（主要是数据库）的功能；
【中优先级】
4、选择极端条件测试子系统（各模块组装后的前台系统）功能及后台子系统（主要是数据库）的功能；
【中优先级】
5、测试前后台子系统组装后的功能。
【低优先级】
测试类型
1、静态测试；
2、动态测试（主要）
1）黑盒测试：
通过输入数据和输出结果来检测软件的行为错误；（主要）
2）白盒测试：
分析程序内部结构，针对条件和循环进行测试。
测试输入
1、经过单元测试并改进后的各个单独模块；
2、软件需求规格说明。
测试输出
1、测试日志：
记录测试中发生的事件。
2、测试报告：
记录程序中出现的缺陷。
3、缺陷度量：
以“天”为单位，记录缺陷出现量。
测试结束标准
1、所有测试案例均已运行至少一次；
2、95%的测试案例成功通过；
3、所有测试结果都已被记录。
测试案例覆盖要求
应涵盖函数、分支覆盖。
其中函数覆盖应为100%，即测试过所有函数。
分支覆盖率也应为100%，即代码中涉及的所有分支情况也应全被覆盖，否则会留下未测试代码，引发潜在风险。
BUG记录要求
1、BUG所处位置；
2、引起该缺陷的输入数据；
3、该缺陷得到的输出结果；
测试实施人
张钰若、陈国忠、张汉
3.3.3.确认测试
3.3.3.1.系统测试
测试目标
查找各种系统操作中的错误，保证软件在实际环境中能够稳定、可靠运行。
测试重点与优先级
测试范围：
全面集成的整个系统。
重点与优先级：
1、功能测试；【高优先级】
2、性能测试；【高优先级】
3、恢复性测试；【中优先级】
4、健壮性测试；【低优先级】
测试类型
3、静态测试；
4、动态测试（主要）
3）黑盒测试：
通过输入数据和输出结果来检测软件的行为错误；（主要）
4）白盒测试：
分析程序内部结构，针对条件和循环进行测试。
测试输入
1、经过集成测试并改进后的全面集成的整个系统；
2、软件需求规格说明。
测试输出
1、测试日志：
记录测试中发生的事件。
2、测试报告：
记录程序中出现的缺陷。
3、缺陷度量：
以“天”为单位，记录缺陷出现量。
测试结束标准
1、所有测试案例均已运行至少一次；
2、95%的测试案例成功通过；
3、所有测试结果都已被记录。
测试案例覆盖要求
覆盖所有需求中要求的功能。
BUG记录要求
1、BUG所处位置；
2、引起该缺陷的输入数据；
3、该缺陷得到的输出结果；
测试实施人
张钰若、张放、陈国忠
3.4.测试缺陷管理
3.4.1.缺陷记录
在软件测试的各流程中，发现的软件缺陷统一记录到软件测试缺陷文档中。
缺陷属性：
属性名称
说明
标识（Identifier）
标记某个缺陷的唯一的符号，可以使用数字、字母组合来表示。
类型（Type）
缺陷类型是根据缺陷的自然属性划分的缺陷种类。
描述（Description）
对缺陷进行详细的描述，以便缺陷重现。
严重程度（Severity）
指因缺陷引起的故障对软件产品的影响程度。
优先级（Priority）
缺陷必须被修复的紧急程度。
状态（State）
缺陷通过一个跟踪修复过程的进展情况。
来源（Source）
指引起缺陷的起因。
缺陷类型：
缺陷类型
描述
功能问题
影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。
并且设计文档需要正式的变更。
如指针，循环，递归，功能等缺陷。
接口问题
与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
数据问题
需要修改少量代码，如初始化或控制块。
如声明、重复命名，范围、限定等缺陷。
逻辑问题
需要进行逻辑分析，进行代码修改，如循环条件等
用户界面问题
人机交互特性：
屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。
文档问题
影响发布和维护，包括注释等缺陷。
性能问题
不满足系统可测量的属性值，如：
执行时间，事务处理速率等缺陷。
环境问题
由于设计、编译和运行环境引发的问题。
标准问题
不符合各种标准的要求，如编码标准、设计符号等缺陷。
其他问题
以上问题所不包含的其他问题。
缺陷严重程度：
严重级别
对应缺陷严重等级
描述
1-严重（Critical）
严重缺陷
不能执行正常工作功能或实现重要功能。
2-重要（Major）
较大缺陷
产生错误的结果，导致系统不稳定，运行时好时坏，严重地影响系统要求或基本功能实现的问题。
3-中等（Normal）
一般缺陷
不正确的，但不会影响系统稳定性的缺陷。
4-次要（Minor）
轻微缺陷
不正确的，但有使系统使用起来不太方便的错误，重点指系统的UI问题。
5-其他（Other）
其他缺陷
系统中值得改良的问题。
缺陷优先级：
缺陷优先级
描述
1-立即解决
（ResolveImmediately）
导致测试无法继续进行，必须立刻进行修复；对用户产生很大影响，必须优先解决。
2-高度关注
（HighlyFocus）
对此缺陷给以高度重视，应优先进行修复。
3-正常排队
（NormalQueue）
缺陷需要正常排队等待修复或列入软件发布清单。
4-低优先级
（NotUrgent）
缺陷可以在方便时被纠正。
缺陷状态：
缺陷状态
描述
提交（Submitted）
已提交的缺陷。
激活或打开（ActiveorOpen）
问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理。
拒绝（Rejected）
拒绝“提交的缺陷”：
不需要修复或不是缺陷或缺陷已经被其他的软件测试人员发现
已修正或修复（FixedorResolved）
已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证。
关闭（Closed）
测试人员验证后，确认缺陷不存在之后的状态。
3.4.2.有疑议缺陷的确认
存在争议的缺陷提交项目经理（陈国忠）及测试组长（张钰若）审核，若仍不能决定，则提交项目管理委员会研究决定。
3.4.3.缺陷的统计与分析
测试周期将近1个工作周，缺陷统计分析采用如下方案：
✧发现缺陷随时记入软件测试缺陷文档，并以口头或其它方式通知到开发组人员查看并解决；
✧对于之前遗留的未解决的Bug，与开发组人员确认解决时间；
✧每周五对软件测试缺陷文档中的Bug汇总，进行全面缺陷分析，产生阶段性Bug报告。
4.主要进度安排
阶段
测试工作
输出
时间安排
实施人
备注
需求阶段
参与项目计划制定
编制测试计划
组织编制部分功能测试案例
测试总体计划、功能测试案例
在4月3号前完成
测试组长
张钰若
设计阶段
编制功能测试案例
编制集成测试案例
测试案例
在4月10号前完成
测试组所有成员
编码阶段
单元测试
经过测试的程序、单元测试BUG记录
开发组
使用测试缺陷文档管理BUG
集成测试
集成测试报告、集成测试BUG记录
测试组，开发组
张放
张汉
使用测试缺陷文档管理BUG
发行测试
……
……
……
……
5.工作汇报
汇报方式
频度
汇报对象
周报
每周一次
项目经理
测试报告
阶段测试完成后
项目经理、QA
测试工作阶段汇报
里程碑阶段完成前
项目经理、QA
升级会员 