软件总体测试计划

精品文档密 级：内部公开文档编号：1003 版 本 号：V3.0测测（基于安卓平台的测评软件）总体测试计划文件状态： 草稿 正在修改 正式发布文件标识：Company-Project-RD-PRS当前版本：3.0作 者：张放、张钰若、陈国忠完成日期：2014-7-23中国石油大学（华东） 计算机与通信工程学院 天师团开发团队-天师团开发团队对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。文件更改摘要：日期版本号修订说明修订人审核人批准人2014-04-03V1.0初稿陈国忠张钰若陈国忠2014-06-03V2.0修稿陈国忠张钰若陈国忠2014-07-23V3.0定稿陈国忠张钰若陈国忠目录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.测试用例要求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.工作汇报131. 引言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. 测试工具工具名称版本要求备注TestDirector80Bug管理工具VSS6.0配置管理工具QTP8.1性能测试工具3. 测试策略3.1. 测试需求3.1.1. 测试需求编号规则测试需求编号规则包括以下要素： 产品编号 模块编号 功能点和子功能点编号3.1.2. 测试需求的编写规范 测试需求按照测试需求模板编写，包含：任务简介、负责人、变更模块、关联模块的功能特性。3.1.3. 测试需求的管理办法经过用户接受测试需求分析和导出过程后，将得到用户接受测试需求初稿。业务管理部门应组织相关的业务人员、技术人员、环境管理人员、测试人员和其他相关人员进行用户接受测试需求评审，确保达成一致意见。建立用户接受测试需求与业务需求规格、与用户接受测试用例之间的双向跟踪关系；建立系统集成测试需求与软件需求分析规格、与系统集成测试用例之间的双向跟踪关系；建立（系统）连接测试需求与概要设计规格、与（系统）连接测试用例之间的双向跟踪关系；建立单元测试需求与详细设计规格，与单元测试用例之间的双向跟踪关系；建立内部测试需求与软件需求分析规格、与详细设计规格、与内部测试用例之间的双向跟踪关系。3.2. 测试用例要求3.2.1. 测试用例编号规则测试用例编号的编写规则如下：用例编号规则：GH-XXYY-ZZXX为主模块的编号，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-立即解决（Resolve Immediately）导致测试无法继续进行，必须立刻进行修复；对用户产生很大影响，必须优先解决。2-高度关注（Highly Focus）对此缺陷给以高度重视，应优先进行修复。3-正常排队（Normal Queue）缺陷需要正常排队等待修复或列入软件发布清单。4-低优先级（Not Urgent）缺陷可以在方便时被纠正。缺陷状态：缺陷状态描 述提交(Submitted)已提交的缺陷。激活或打开(Active or Open)问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理。拒绝（Rejected）拒绝“提交的缺陷”：不需要修复或不是缺陷或缺陷已经被其他的软件测试人员发现已修正或修复(F