软件总体测试计划.doc

1、密 级：内部公开文档编号：1003 版 本 号：V3.0测测（基于安卓平台的测评软件）总体测试计划文件标识： Company-Project-RD-PRS当前版本： 3.0作 者： 张放、张钰若、陈国忠文件状态： 草稿 正在修改 正式发布完成日期： 2014-7-23测测总体测试计划天师团开发团队 第 2 页 共 13 页中国石油大学（华东） 计算机与通信工程学院 天师团开发团队-天师团开发团队对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。文 件 更 改 摘 要 ：日期 版本号 修订说明 修订人 审核人 批准人20

2、14-04-03 V1.0 初稿 陈国忠 张钰若 陈国忠2014-06-03 V2.0 修稿 陈国忠 张钰若 陈国忠2014-07-23 V3.0 定稿 陈国忠 张钰若 陈国忠测测总体测试计划天师团开发团队 第 3 页 共 13 页目录1. 引言 .41.1. 编写目的 41.2. 术语 41.3. 测试标准 41.4. 参考文档 42. 任务概述 .42.1. 人员安排 42.2. 测试环境 52.3. 测试工具 53. 测试策略 .53.1. 测试需求 53.1.1. 测试需求编号规则 .53.1.2. 测试需求的编写规范 .53.1.3. 测试需求的管理办法 .53.2. 测试用例要求

3、63.2.1. 测试用例编号规则 .63.2.2. 测试用例的编写规范 .63.2.3. 测试用例的管理办法 .73.3. 测试方案 73.3.1. 单元测试 .73.3.2. 集成测试 .83.3.3. 确认测试 .93.4. 测试缺陷管理 103.4.1. 缺陷记录 .103.4.2. 有疑议缺陷的确认 .123.4.3. 缺陷的统计与分析 .124. 主要进度安排 .125. 工作汇报 .13测测总体测试计划天师团开发团队 第 4 页 共 13 页1. 引 言1.1. 编 写 目 的制定总体测试方案的目的是：使整个测试工作能有序进行，指导测试人员的工作，为测试提供依据。提供系统化、规范化

4、、工程化、实用化的测试技术规范，尽早发现故障。在测试时，须按照此计划执行。1.2. 术 语集成测试：也叫组装测试、联合测试，集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成子系统。系统测试：是将经过测试的子系统装配成一个完整系统来测试。它是检测系统是否确实能提供系统方案说明书中制定功能的有效方法。确认测试:又称有效测试，是在模拟的环境下，运用黑盒测试大方法，验证被测软件是否满足需求规格说明书列出的需求，任务是验证软件的功能和性能及其他特性是否与用户需求一致。1.3. 测 试 标 准测试标准依据软件需求规格说明书。测试标准参数 测试标准参数值测试需求覆盖率 90%测试用例覆盖率 9

5、0%测试用例执行通过率 95%缺陷率（bug 数量/功能点数） 0.5, 3遗留缺陷数量 5%1.4. 参 考 文 档文档（版本/日期） 已创建或可用已被接收或已经被评审 作者或来源备注软件需求规格说明书 是 否 是 否 陈国忠项目迭代冲刺计划 是 否 是 否 陈国忠软件质量保证计划 是 否 是 否 陈国忠2. 任 务 概 述2.1. 人 员 安 排角色 姓名 主要工作职责 测试参与度测试组长 张钰若组织测试策划，编制测试计划组织测试案例的编制提供技术指导，评估测试工作汇报测试工作100测测总体测试计划天师团开发团队 第 5 页 共 13 页开发组 张汉 在单元测试中进行 B 角测试 10测试

6、员 陈国忠 参与单元测试与集成测试 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. 测试需求的编写规范 测

7、试需求按照测试需求模板编写，包含：任务简介、负责人、变更模块、关联模块的功能特性。3.1.3. 测试需求的管理办法经过用户接受测试需求分析和导出过程后，将得到用户接受测试需求初稿。业务管理部门应组织相关的业务人员、技术人员、环境管理人员、测试人员和其他相关人员进行用户接受测试需求评审，确保达成一致意见。建立用户接受测试需求与业务需求规格、与用户接受测试用例之间的双向跟踪关系； 测测总体测试计划天师团开发团队 第 6 页 共 13 页建立系统集成测试需求与软件需求分析规格、与系统集成测试用例之间的双向跟踪关系； 建立（系统）连接测试需求与概要设计规格、与（系统）连接测试用例之间的双向跟踪关系；

8、建立单元测试需求与详细设计规格，与单元测试用例之间的双向跟踪关系； 建立内部测试需求与软件需求分析规格、与详细设计规格、与内部测试用例之间的双向跟踪关系。3.2. 测 试 用 例 要 求3.2.1. 测试用例编号规则测试用例编号的编写规则如下：用例编号规则：GH-XXYY-ZZXX 为主模块的编号，YY 为主模块所包含的子模块的编号。ZZ 为子模块中细分的测试条目。 3.2.2. 测试用例的编写规范编写用例规范 ：a） 系统性对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系 b） 连贯性对系统业务

9、流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯。 c） 全面性应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备 d） 正确性输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合 e） 符合正常业务规则测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规 f） 可操作性测测总体测试计划天师团开发团队 第 7 页 共

10、 13 页测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果 编写用例标准 :a) 测试案例编写应该制订统一的模板进行，并约定模板的使用方法； b) 测试案例编写应当根据项目实际情况编写测试案例编写手册，包括案例编号规则、案例编写方法、案例编写内容、案例维护等内容； c) 案例编写应根据手册中约定的编写方法、内容等进行编写； d) 案例编写要步骤明确，输入输出要素清晰，并且与需求和缺陷相对应；e) 案例编写应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能点； f) 注重案例的可复用性，即在以后相似系统的测试过程中可以重复使用，减少测试设计工作量。测试用例

11、模板：字段名称 描述测试用例优先级标示符测试项测试环境要求输入标准输出标准测试用例间的关联编写人 编写时间3.2.3. 测试用例的管理办法测试用例根据测试用例模板编写，采用 EXCEL 文档同时保存于项目库及测试库，测试用例的修改于测试需求矩阵同步。3.3. 测 试 方 案3.3.1. 单元测试测试目标 发现代码和各功能模块的缺陷。测试程序和三个模块单元（性格测试、智力测试和“每日一签” ）的功能，同时检查内部代码设计，测试错误处理能力。另外包括后台数据库的设计分析。测试重点与优先级 测试范围：各个单独模块的功能实现以及代码设计。重点与优先级：1、 程序内部结构分析； 【高优先测测总体测试计划

12、天师团开发团队 第 8 页 共 13 页级】2、 设计测试用例覆盖各函数，测试各函数功能；【中优先级】3、 设计测试用例覆盖各分支，测试各分支；【中优先级】4、 设计测试用例覆盖各循环，测试各循环条件、功能；【中优先级】5、 利用合理的输入、输出数据通过黑盒方式测试模块功能；【中优先级】6、 后台数据库结构分析及功能测试； 【中优先级】7、 选择极端条件测试模块功能。 【低优先级】测试类型 1、 白盒测试：分析程序内部结构，针对条件和循环进行测试；2、 黑盒测试：通过输入数据和输出结果来检测软件的行为错误。测试输入 可运行的软件以及软件需求规格说明、待测试程序代码。测试输出 1、 测试日志：记

13、录测试中发生的事件。2、 测试报告：记录程序中出现的缺陷。3、 缺陷度量：以“天”为单位，记录缺陷出现量。测试结束标准 1、 所有测试案例均已运行至少一次；2、 95%的测试案例成功通过；3、 所有测试结果都已被记录。测试案例覆盖要求 应涵盖函数、分支覆盖。其中函数覆盖应为 100%，即测试过所有函数。分支覆盖率也应为 100%，即代码中涉及的所有分支情况也应全被覆盖，否则会留下未测试代码，引发潜在风险。BUG 记录要求 1、 BUG 所处位置；2、 引起该缺陷的输入数据；3、 该缺陷得到的输出结果；测试实施人 张钰若、张汉、张放3.3.2. 集成测试测试目标 组装各个功能模块（性格测试、智力

14、测试和“每日一签”）后，测试各模块间是否正确的配合工作、传递数据，测测总体测试计划天师团开发团队 第 9 页 共 13 页检查模块间接口工作是否协调。测试重点与优先级测试范围：模块间接口以及模块组装后的整体系统工作情况。重点与优先级：1、 测试模块间的关键接口（涉及进行大量数据传输、交换）的代码设计； 【高优先级】2、 测试模块间的关键接口（涉及进行大量数据传输、交换）的功能实现； 【中优先级】3、 测试子系统（各模块组装后的前台系统）功能及后台子系统（主要是数据库）的功能； 【中优先级】4、 选择极端条件测试子系统（各模块组装后的前台系统）功能及后台子系统（主要是数据库）的功能；【中优先级】

15、5、 测试前后台子系统组装后的功能。 【低优先级】测试类型 1、 静态测试；2、 动态测试（主要）1） 黑盒测试：通过输入数据和输出结果来检测软件的行为错误；（主要）2） 白盒测试：分析程序内部结构，针对条件和循环进行测试。测试输入 1、 经过单元测试并改进后的各个单独模块；2、 软件需求规格说明。测试输出 1、 测试日志：记录测试中发生的事件。2、 测试报告：记录程序中出现的缺陷。3、缺陷度量：以“天”为单位，记录缺陷出现量。测试结束标准 1、 所有测试案例均已运行至少一次；2、 95%的测试案例成功通过；3、所有测试结果都已被记录。测试案例覆盖要求 应涵盖函数、分支覆盖。其中函数覆盖应为

16、100%，即测试过所有函数。分支覆盖率也应为 100%，即代码中涉及的所有分支情况也应全被覆盖，否则会留下未测试代码，引发潜在风险。BUG 记录要求 1、 BUG 所处位置；2、 引起该缺陷的输入数据；3、该缺陷得到的输出结果；测试实施人 张钰若、陈国忠、张汉测测总体测试计划天师团开发团队 第 10 页 共 13 页3.3.3. 确认测试3.3.3.1.系 统 测 试测试目标 查找各种系统操作中的错误，保证软件在实际环境中能够稳定、可靠运行。测试重点与优先级 测试范围：全面集成的整个系统。重点与优先级：1、 功能测试； 【高优先级】2、 性能测试； 【高优先级】3、 恢复性测试； 【 中优先级

17、】4、 健壮性测试； 【 低优先级】测试类型 3、 静态测试；4、 动态测试（主要）3） 黑盒测试：通过输入数据和输出结果来检测软件的行为错误；（主要）4） 白盒测试：分析程序内部结构，针对条件和循环进行测试。测试输入 1、 经过集成测试并改进后的全面集成的整个系统；2、 软件需求规格说明。测试输出 1、 测试日志：记录测试中发生的事件。2、测试报告：记录程序中出现的缺陷。3、缺陷度量：以“天”为单位，记录缺陷出现量。测试结束标准 1、 所有测试案例均已运行至少一次；2、95% 的测试案例成功通过；3、所有测试结果都已被记录。测试案例覆盖要求 覆盖所有需求中要求的功能。BUG 记录要求 1、

18、BUG 所处位置；2、 引起该缺陷的输入数据；3、该缺陷得到的输出结果；测试实施人 张钰若、张放、陈国忠3.4. 测 试 缺 陷 管 理3.4.1. 缺陷记录在软件测试的各流程中，发现的软件缺陷统一记录到软件测试缺陷文档中。缺陷属性：属性名称 说 明标识（Identifier ） 标记某个缺陷的唯一的符号，可以使用数字、字母测测总体测试计划天师团开发团队 第 11 页 共 13 页组合来表示。类型（Type） 缺陷类型是根据缺陷的自然属性划分的缺陷种类。描述（Description） 对缺陷进行详细的描述，以便缺陷重现。严重程度（Severity ） 指因缺陷引起的故障对软件产品的影响程度。优

19、先级（Priority） 缺陷必须被修复的紧急程度。状态(State) 缺陷通过一个跟踪修复过程的进展情况。来源（Source） 指引起缺陷的起因。缺陷类型：缺陷类型 描述功能问题影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如指针，循环，递归，功能等缺陷。接口问题 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。数据问题 需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。逻辑问题 需要进行逻辑分析，进行代码修改，如循环条件等用户界面问题 人机交互特性：屏幕格式， 确认用户输入，功能有效性，页面排版

20、等方面的缺陷。文档问题 影响发布和维护，包括注释等缺陷。性能问题 不满足系统可测量的属性值，如：执行时间，事务处理速率等缺陷。环境问题 由于设计、编译和运行环境引发的问题。标准问题 不符合各种标准的要求， 如编码标准、设计符号等缺陷。其他问题 以上问题所不包含的其他问题。缺陷严重程度：严重级别 对应缺陷严重等级描 述1-严重（Critical） 严重缺陷不能执行正常工作功能或实现重要功能。2-重要（Major） 较大缺陷产生错误的结果，导致系统不稳定，运行时好时坏，严重地影响系统要求或基本功能实现的问题。3-中等（Normal） 一般缺陷不正确的，但不会影响系统稳定性的缺陷。4-次要（Mino

21、r） 轻微缺陷 不正确的，但有使系统使用起来不太方便的错误，重点指系统的 UI 问题。测测总体测试计划天师团开发团队 第 12 页 共 13 页5-其他（Other） 其他缺陷系统中值得改良的问题。缺陷优先级：缺陷优先级 描 述1-立即解决（Resolve Immediately）导致测试无法继续进行，必须立刻进行修复；对用户产生很大影响，必须优先解决。2-高度关注（Highly Focus） 对此缺陷给以高度重视，应优先进行修复。3-正常排队（Normal Queue） 缺陷需要正常排队等待修复或列入软件发布清单。4-低优先级（Not Urgent） 缺陷可以在方便时被纠正。缺陷状态：缺陷状

22、态 描 述提交(Submitted) 已提交的缺陷。激活或打开(Active or Open)问题还没有解决，存在源代码中，确认“提交的缺陷” ，等待处理。拒绝（Rejected） 拒绝“提交的缺陷”：不需要修复或不是缺陷或缺陷已经被其他的软件测试人员发现已修正或修复(Fixed or Resolved)已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证 。关闭(Closed） 测试人员验证后，确认缺陷不存在之后的状态。3.4.2. 有疑议缺陷的确认存在争议的缺陷提交项目经理（陈国忠）及测试组长（张钰若）审核，若仍不能决定，则提交项目管理委员会研究决定。3.4.3.

23、 缺陷的统计与分析测试周期将近 1 个工作周，缺陷统计分析采用如下方案： 发现缺陷随时记入软件测试缺陷文档，并以口头或其它方式通知到开发组人员查看并解决； 对于之前遗留的未解决的 Bug，与开发组人员确认解决时间； 每周五对软件测试缺陷文档中的 Bug 汇总，进行全面缺陷分析，产生阶段性 Bug 报告。测测总体测试计划天师团开发团队 第 13 页 共 13 页4. 主 要 进 度 安 排阶段 测试工作 输出 时间安排 实施人 备注需求阶段参与项目计划制定编制测试计划组织编制部分功能测试案例测试总体计划、功能测试案例在 4 月 3号前完成测试组长张钰若设计阶段编制功能测试案例编制集成测试案例测试案例 在 4 月 10号前完成 测试组所有 成员单元测试经过测试的程序、单元测试 BUG记录开发组 使用测试缺陷文档管理 BUG集成测试集成测试报告、集成测试 BUG 记录测试组，开发组张放张汉使用测试缺陷文档管理 BUG编码阶段发行测试 5. 工 作 汇 报汇报方式 频度 汇报对象周报 每周一次 项目经理测试报告 阶段测试完成后 项目经理、QA测试工作阶段汇报 里程碑阶段完成前 项目经理、QA