软件总体测试计划

上传人:hs****ma 文档编号:487640898 上传时间:2023-06-05 格式:DOC 页数:18 大小:169.50KB
返回 下载 相关 举报
软件总体测试计划_第1页
第1页 / 共18页
软件总体测试计划_第2页
第2页 / 共18页
软件总体测试计划_第3页
第3页 / 共18页
软件总体测试计划_第4页
第4页 / 共18页
软件总体测试计划_第5页
第5页 / 共18页
点击查看更多>>
资源描述

《软件总体测试计划》由会员分享,可在线阅读,更多相关《软件总体测试计划(18页珍藏版)》请在金锄头文库上搜索。

1、-:部公开文档1003版本号:V3.0测测基于安卓平台的测评软件总体测试方案文件状态: 草稿 正在修改 正式发布文件标识:pany-Project-RD-PRS当前版本:3.0 放、钰假设、国忠完成日期:2021-7-23中国石油大学华东计算机与通信工程学院天师团开发团队-天师团开发团队对本文件资料享受著作权及其它专属权利,未经书面许可,不得将该等文件资料其全部或任何局部披露予任何第三方,或进展修改后使用。文件更改摘要:日期版本号修订说明修订人审核人批准人2021-04-03V1.0初稿国忠钰假设国忠2021-06-03V2.0修稿国忠钰假设国忠2021-07-23V3.0定稿国忠钰假设国忠目

2、录1.引言21.1.编写目的21.2.术语21.3.测试标准21.4.参考文档22.任务概述22.1.人员安排22.2.测试环境22.3.测试工具23.测试策略23.1.测试需求23.1.1.测试需求编号规则23.1.2.测试需求的编写规23.1.3.测试需求的管理方法23.2.测试用例要求23.2.1.测试用例编号规则23.2.2.测试用例的编写规23.2.3.测试用例的管理方法23.3.测试方案23.3.1.单元测试23.3.2.集成测试23.3.3.确认测试23.4.测试缺陷管理23.4.1.缺陷记录23.4.2.有疑议缺陷确实认23.4.3.缺陷的统计与分析24.主要进度安排25.工作

3、汇报21. 引言1.1. 编写目的制定总体测试方案的目的是:使整个测试工作能有序进展,指导测试人员的工作,为测试提供依据。提供系统化、规化、工程化、实用化的测试技术规,尽早发现故障。在测试时,须按照此方案执行。1.2. 术语集成测试:也叫组装测试、联合测试,集成测试是在单元测试的根底上,将所有模块按照概要设计要求组装成子系统。系统测试:是将经过测试的子系统装配成一个完整系统来测试。它是检测系统是否确实能提供系统方案说明书中制定功能的有效方法。确认测试:又称有效测试,是在模拟的环境下,运用黑盒测试大方法,验证被测软件是否满足需求规格说明书列出的需求,任务是验证软件的功能和性能及其他特性是否与用户

4、需求一致。1.3. 测试标准测试标准依据软件需求规格说明书。测试标准参数测试标准参数值测试需求覆盖率90%测试用例覆盖率90%测试用例执行通过率95%缺陷率bug数量/功能点数0.5, 3遗留缺陷数量5%1.4. 参考文档文档版本/日期已创立或可用已被接收或已经被评审作者或来源备注软件需求规格说明书是否是否国忠工程迭代冲刺方案是否是否国忠软件质量保证方案是否是否国忠2. 任务概述2.1. 人员安排角色主要工作职责测试参与度测试组长钰假设组织测试筹划,编制测试方案组织测试案例的编制提供技术指导,评估测试工作汇报测试工作100开发组汉在单元测试中进展B角测试10测试员国忠参与单元测试与集成测试50

5、测试员放参与单元测试、系统测试、验收测试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. 测试需求的管理方

6、法经过用户承受测试需求分析和导出过程后,将得到用户承受测试需求初稿。业务管理部门应组织相关的业务人员、技术人员、环境管理人员、测试人员和其他相关人员进展用户承受测试需求评审,确保达成一致意见。建立用户承受测试需求与业务需求规格、与用户承受测试用例之间的双向跟踪关系;建立系统集成测试需求与软件需求分析规格、与系统集成测试用例之间的双向跟踪关系;建立系统连接测试需求与概要设计规格、与系统连接测试用例之间的双向跟踪关系;建立单元测试需求与详细设计规格,与单元测试用例之间的双向跟踪关系;建立部测试需求与软件需求分析规格、与详细设计规格、与部测试用例之间的双向跟踪关系。3.2. 测试用例要求3.2.1.

7、 测试用例编号规则测试用例编号的编写规则如下:用例编号规则:GH-*YY-ZZ*为主模块的编号,YY为主模块所包含的子模块的编号。ZZ为子模块中细分的测试条目。3.2.2. 测试用例的编写规编写用例规:a) 系统性对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系;对模块业务流程要说明子系统部功能、重点功能以及它们之间的关系b) 连贯性对系统业务流程要说明各个子系统之间是如何连接在一起,假设需要接口,各子系统之间是否有正确的接口,假设是依靠页面,则页面的是否正确;对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统,其部功能接口是否连贯。c) 全面性应

8、尽可能覆盖各种路径、尽可能覆盖各个业务点,并要考虑跨年、跨月的数据以及大数据量并发测试的准备d) 正确性输入界面后的数据应与测试文档所记录的数据一致,而预期结果也应与测试数据发生的业务吻合e) 符合正常业务规则测试数据要符合用户实际工作中的业务流程,同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规f) 可操作性测试用例中要写清楚测试的操作步骤,以及不同的操作步骤相对应的测试结果编写用例标准:a) 测试案例编写应该制订统一的模板进展,并约定模板的使用方法;b) 测试案例编写应当根据工程实际情况编写测试案例编写手册,包括案例编号规则、案例编写方法、案例编写容、案例维护等容;c) 案例编写应

9、根据手册中约定的编写方法、容等进展编写;d) 案例编写要步骤明确,输入输出要素清晰,并且与需求和缺陷相对应;e) 案例编写应严格根据需求规格说明书及测试需求功能分析点进展,要求覆盖全部需求功能点;f) 注重案例的可复用性,即在以后相似系统的测试过程中可以重复使用,减少测试设计工作量。测试用例模板:字段名称描述测试用例优先级标示符测试项测试环境要求输入标准输出标准测试用例间的关联编写人编写时间3.2.3. 测试用例的管理方法测试用例根据测试用例模板编写,采用E*CEL文档同时保存于工程库及测试库,测试用例的修改于测试需求矩阵同步。3.3. 测试方案3.3.1. 单元测试测试目标发现代码和各功能模

10、块的缺陷。测试程序和三个模块单元性格测试、智力测试和每日一签的功能,同时检查部代码设计,测试错误处理能力。另外包括后台数据库的设计分析。测试重点与优先级测试围:各个单独模块的功能实现以及代码设计。重点与优先级:1、 程序部构造分析;【高优先级】2、 设计测试用例覆盖各函数,测试各函数功能;【中优先级】3、 设计测试用例覆盖各分支,测试各分支;【中优先级】4、 设计测试用例覆盖各循环,测试各循环条件、功能;【中优先级】5、 利用合理的输入、输出数据通过黑盒方式测试模块功能;【中优先级】6、 后台数据库构造分析及功能测试;【中优先级】7、 选择极端条件测试模块功能。【低优先级】测试类型1、 白盒测

11、试:分析程序部构造,针对条件和循环进展测试;2、 黑盒测试:通过输入数据和输出结果来检测软件的行为错误。测试输入可运行的软件以及软件需求规格说明、待测试程序代码。测试输出1、 测试日志:记录测试中发生的事件。2、 测试报告:记录程序中出现的缺陷。3、 缺陷度量:以天为单位,记录缺陷出现量。测试完毕标准1、 所有测试案例均已运行至少一次;2、 95%的测试案例成功通过;3、 所有测试结果都已被记录。测试案例覆盖要求应涵盖函数、分支覆盖。其中函数覆盖应为100%,即测试过所有函数。分支覆盖率也应为100%,即代码中涉及的所有分支情况也应全被覆盖,否则会留下未测试代码,引发潜在风险。BUG记录要求1

12、、 BUG所处位置;2、 引起该缺陷的输入数据;3、 该缺陷得到的输出结果;测试实施人钰假设、汉、放3.3.2. 集成测试测试目标组装各个功能模块性格测试、智力测试和每日一签后,测试各模块间是否正确的配合工作、传递数据,检查模块间接口工作是否协调。测试重点与优先级测试围:模块间接口以及模块组装后的整体系统工作情况。重点与优先级:1、 测试模块间的关键接口涉及进展大量数据传输、交换的代码设计;【高优先级】2、 测试模块间的关键接口涉及进展大量数据传输、交换的功能实现;【中优先级】3、 测试子系统各模块组装后的前台系统功能及后台子系统主要是数据库的功能;【中优先级】4、 选择极端条件测试子系统各模

13、块组装后的前台系统功能及后台子系统主要是数据库的功能;【中优先级】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. 系统测试测试目标查找各种系统操作中的错误,保证软件在实际环境中能够稳定、可靠运行。测试重点与优

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 建筑/环境 > 施工组织

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号