软件测试测试计划Word格式文档下载.docx

软件测试测试计划Word格式文档下载.docx

《软件测试测试计划Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《软件测试测试计划Word格式文档下载.docx（14页珍藏版）》请在冰点文库上搜索。

确定软件测试目标

准备测试所需的环境

预测测试风险

1.2背景

本系统软件名为SMS学生信息管理平台的B/S结构，由洛阳惠普基地老师进行设计开发。

本软件旨在为惠普基地的老师与学生提供一个信息的收集与交流的平台。

学生信息管理平台的好处是：

一是为老师发布作业与学生下载、提交作业提供好的交流平台；

二是使老师对学生的作业信息和学生的基本信息有更加系统的查询与保存功能。

1.3测试目标

本次测试使用手动测试和自动化测试来完成测试，根据用户需求，找出本系统学生管理、就业管理、档案管理、就业统计、作业管理等五个主要功能模块的缺陷和不足，发现系统隐藏的问题。

功能测试可至少要进行三个轮次的测试，测试用例执行率要达到90%，缺陷修改率要达到95%。

性能测试目标满足用户的要求或者与用户的要求接近度达到99%。

1.4范围

需要测试的目标：

在学生信息管理平台系统功能测试中，需要测试学生管理、就业管理、档案管理、就业统计、作业管理等五个主要功能模块

系统性能指标要求如下：

1、系统支持的在线用户数不低于500

2、登录、学生管理、就业管理、档案管理、就业统计、作业管理等模块，相关操作的平均响应时间不超过3s

软硬件环境需求：

1、CRM系统可运行于Windows平台，支持Apache服务程序

2、系统采用B/S架构，支持IE11、谷歌浏览器对系统的访问

3、系统数据库使用MySQL5.5（或更高版本）

界面需求：

1、系统界面规范，颜色、风格搭配

2、页面布局合理，人性化

3、界面文字信息准确

4、系统界面中的窗体与各种控件可正常显示和使用，易用性好

5、Tab键、enter键、快捷键等可以正常使用

2.测试参考文档和测试提交文档

2.1测试参考文档

文档

（版本/日期）

已创建或可用

作者或来源

测试需求规格说明书

是　

上级分配

软件跟踪矩阵

是

六组成员

软件测试用例

软件测试需求

测试时间表及人员安排

2.2测试提交文档

测试阶段

阶段提交物

测试需求分析

测试需求文档

测试计划设计

测试计划文档

测试用例设计

测试用例文档

手工缺陷报告

手工缺陷报告文档

功能测试报告

功能测试报告文档

性能测试报告

性能测试报告文档

测试报告编写

测试报告文档

3.测试进度

测试活动

计划开始日期

计划结束日期

制定测试计划

2016-5-31

测试要点提取

2016-6-1

2016-6-2

ALM项目管理

测试用例编写

2016-6-3

ALM测试用例导入

手工执行测试用例

2016-6-6

2016-6-7

兼容性测试

功能自动化测试

2016-6-8

2016-6-13

2016-6-14

性能测试

2016-6-20

项目总结

2016-6-21

4.测试资源

4.1人力资源

角色

小组成员

具体职责

负责模块

测试组长

测试计划编写

作业管理

测试跟踪矩阵编写

用例执行

项目总结报告

测试小组成员

就业管理_添加档案

就业管理_添加就业

档案管理

学生管理,就业统计

4.2测试环境

软件环境（相关软件、操作系统等）

IE11浏览器

SMS系统（学生信息管理平台）

中间件服务器Tomcat7.0

硬件环境（网络、设备等）

Windows7平台

208机房小组成员各自电脑

VMware虚拟机

4.3测试工具

用途

工具

生产厂商/自产

功能测试

UFT

HP

LoadRunner

测试流程管理

ALM

选择UFT工具做功能测试的优势:

支持功能测试和回归测试自动化，可用于软件应用环境的测试UFT自动化的基本功能是创建测试、检验数据、增强测试、运行测试脚本、分析测试结果、维护测试。

选择LoadRunner做性能测试的优势:

一种预测系统行为和性能的负载测试工具，可以对整个架构进行测试，能最大限度的缩短测试时间，优化性能和加速应用系统的发布周期。

选择ALM做测试流程管理工具的优势:

利用计算机辅助软件工程的软件工具。

以标准的流程管理方式，协助降低软件开发过程中认为造成的开发瑕疵，特别适用于大型应用的开发。

5.系统风险、优先级

系统在测试阶段的风险主要有：

对质量需求或产品的特性理解不准确，造成测试范围分析的误差。

测试用例没有得到百分之百的执行。

需求的临时变化，导致设计的修改和代码的重写，导致测试时间不够。

测试用例设计不到位，忽视了一些边界条件，深层次的逻辑，用户场景等。

测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差。

有些缺陷的出现频率不是百分之百，不容易被发现。

回归测试一般不运行全部测试用例，是有选择性的运行，必然带来风险。

优先级：

低：

暂时不影响继续测试，可以在方便时解决。

中：

部分功能无法继续测试，需要优先解决。

高：

测试暂停，无法进行，必须立即解决。

6.测试策略

6.1功能测试

对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。

这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。

此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。

以下为各种应用程序列出了推荐使用的测试概要：

测试目标

学生管理、新增作业模块测试用例执行率达到80%，档案管理、就业管理、就业统计测试用例执行率达到90%

就业管理、就业统计模块功能满足用户基本的需求；

学生管理、档案管理、新增作业模块功能严格满足用户基本的需求

测试范围

学生管理、就业管理、档案管理、就业统计、新增作业模块和兼容性测试（IE11、360、谷歌浏览器）

技术

进行手工测试,分析需求,制定测试计划,然后编写测试用例,用例包括（编号,测试名称,前置条件,操作步骤,预期结果,优先级,状态等）编写完成后开始执行用例,在操作的过程中发现缺陷,发现的缺陷以缺陷报告的方式进行提交,最后提交总结报告

开始标准

到测试合同（或项目计划）约定的时间

软件测试所需的各种文档已经准备完毕

所提交的被测软件受控

软件源代码正确通过编译或汇编

完成标准

按要求完成了合同（或项目计划）所规定的软件测试任务

实际测试过程遵循了原定的软件测试计划和软件测试说明

客观、详细地记录了软件测试过程和软件测试中发现的所有问题

软件测试中的问题或异常有合理解释或正确有效的处理

测试重点和优先级

测试重点：

学生管理、就业管理、档案管理、就业统计、新增作业模块

中

需考虑的特殊事项

模块与模块之间的关联

用户要求的特殊功能

6.2用户界面测试

用户界面（UI）测试用于核实用户与软件之间的交互。

UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。

另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。

通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动、和快捷键）的使用

窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准

学生管理、就业管理、档案管理、就业统计、新增作业模块和兼容性测试（IE7.0、360、谷歌浏览器）

测试小组配置好软硬件测试环境，并能正常访问以及测试用例的编写完成

6.3性能评测

性能评测是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。

性能评测的目标是核实性能需求是否都已满足。

实施和执行性能评测的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评测和微调。

测试SMS系统处于压力情况下，应用的表现

测试SMS系统找到特性环境下系统处理能力的极限

测试SMS系统程序对异常情况的抵抗能力

压力测试：

通过对软件系统不断施加压力，识别系统性能拐点，来获得系统提供的最大服务级别的测试活动

负载测试：

通过在被测系统上不断施加压力，直到达到性能指标极限要求

强度测试:

检查程序对异常情况的抵抗能力

大流量数据与多用户操作时系统响应时间,事务处理速率等

负载测试

压力测试

强度测试

完成了合同规定的软件测试任务

发现了缺陷并得到了解决

测试工作通过了测试评审

客观详细记录了软件测试过程中发现的问题

达到并且满足的用户的需求

测试重点:

对系统进行负载测试压力测试强度测试测试工作

优先级:

高

负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测

应该暂时减少用于系统的DASD，以限制数据库可用空间的增长

使多个客户机对相同的记录或数据帐户同时进行的访问达到同步

7.测试标准

7.1测试接收标准

到测试合同（或项目计划）约定的时间；

软件测试所需的各种文档已经准备完毕；

所提交的被测软件受控；

软件源代码正确通过编译或汇编；

最好从一开始就介入到被测软件的开发周期。

7.2测试停止标准

按要求完成了合同（或项目计划）所规定的软件测试任务；

实际测试过程遵循了原定的软件测试计划和软件测试说明；

客观、详细地记录了软件测试过程和软件测试中发现的所有问题；

软件测试的全过程自始至终在控制下进行；

软件测试中的问题或异常有合理解释或正确有效的处理；

软件测试工作通过了测试评审；

全部测试软件、被测软件、测试支持软件和评审结果已纳入配置管理。

7.3非正常停止标准

项目需要暂停进行调整，测试应暂停并备份暂停点的数据；

软件在开发过程中出现重大偏差；

本轮提交的缺陷未得到开发反馈；

项目和需求中有2处不一致的情况出现；

项目经理有特殊情况，需发文档说明并停止测试。

8.风险管理

8.1项目进度风险

料：

需求变更、测试用例数据设计不充分、质量标准不统一；

人：

疲态、同化效应、定位效应、业务不熟、测试人员变动；

时：

测试时间不足、测试时间延长；

环：

被测试软件版本不统一、被测试环境不一致、被测试硬件环境不一致、测试硬件未及时到位；

法：

错误或缺失测试方法、场景缺失或部分缺失、测试用例实施不充分；

其他：

沟通不良、开发提交测试时间比计划延时。

8.2需求变更风险

针对需求变更过快问题，测试人员与开发人员应及时保持联系取得最新需求，并且测试人员必须和开发人员高度一致，保证测试人员所掌握需求是第一手资料。

一旦发生需求改动而测试人员不知情的情况，首先确认需求变动。

必要情况下可增加测试人员，同时，测试相关文档可以稍后修改，完成预定目标。

针对需求不清晰问题，找相应的需求人员和开发人员进行需求评审，一定要和需求人员和开发人员意见达到一致。

8.3沟通不良风险

预防这种风险应该是项目建设之初测试人员就和此项目的相关人员进行交流和沟通，注意培养和锻炼自身的沟通技巧。

8.4功能和需求不一致风险

测试结束时，应用功能和需求不一致：

告知项目经理，并留下文档进行说明。

9.附录：

项目任务

以下是一些与测试有关的任务：

✧　　制定测试计划

⏹确定测试需求

⏹制定测试策略

⏹创建时间表

⏹生成测试计划

✧设计测试

⏹准备工作量分析文档

⏹确定并说明测试用例

✧执行测试

✧执行测试过程

✧评估测试的执行情况

✧核实结果

✧记录缺陷

✧对测试进行评估

✧评估测试用例覆盖

✧分析缺陷

✧确定是否达到了测试完成标准与成功标准