软件测试计划书两篇

软件测试计划书两篇(总31页)

--本页仅作为文档封面，使用时请直接删除即可--

--内页可以根据需求调整合适字体及大小-- 软件测试计划书两篇

篇一：学生信息管理系统软件测试计划书

1. 引言

1.1. 目的

测试学生信息管理系统中的各个功能模块是否满足用户要求，并测试是否存bug。预期达到能够使系统进行快速的改进和系统的提高。为了在软件投入生产性运行之前，尽可能多地发现软件的错误。

1.2. 背景

本项目测试的背景；学生信息管理系统是一个教育单位不可缺少的部分,它的内容对于决策者和管理者来说都至关重要,所以学生信息管理系统应该能够为用户提供充足的信息和快捷的查询手段。但一直以来人们使用传统人工的方式管理文件档案，这种管理方式存在着许多缺点,如:效率低、保密性差,另外时间一长,将产生大量的文件和数据,这对于查找、更新和维护都带来了不少的困难。而计算机的应用便解决了以上问题，它带来更加科学，有效，正规的管理方式，给人们带来了很大的便利。学生信息管理系统界面简洁，操作简单，满足了学校对学生信息管理的需要。

b．该开发项目的历史，列出用户和执行此项目测试的机构或人群;该项目前后经历了三个阶段，前期设计阶段，然后是开发阶段，最后是软件的测试阶段。项目的用户针对的是学校的广大学生和管理员，系统的功能测试主要由专业的软件测试人员进行测试。

1.3. 范围

学生信息管理系统试采用的是黑盒测试的方式来对系统进行测试。主要测试软件的功能是否满足客户的需要，性能是否优越以及系统所存在的问题。对系统的各个模块进行详细的测试，并记录测试的结果，对测试的结果进行细致的分析处理。测试时对系统的各个功能模块进行拆分测试，并以每一个模块都要测试到。对所有可能的结果进行测试，以及测试过程中存在的问题进行分析，然后提交测试的记录。最后，对软件存在的问题以及性能的测试进行全面分析，并给予记录。

在测试的过程中需要提出各个问题的假设，以及根据需求报告文档中存在的项目功能模块和用户的需求来改善系统。列出可能会影响测试设计、开发、或实施的所有风险或意外事件。列出可能会影响测试设计、开发或实施的所有约束。

1.4. 定义

信息（Information）：有关学生个人的详细数据，如姓名、性别、家庭住址等

管理（Manage）：对学生信息进行操作，如增删改查等基本功能

统计（Account）：对学生信息的统计，如人数等

1.5. 参考资料

列出编写本计划及测试整个过程中所要参考的文件、资料。

编号 资料名称 作者 日期 出版单位

1 《软件测试入门与提高》 清华大学出版社

2 《软件测试基础教程》 邮电大学出版社

《软件测试自动化的引入和应用》 机械工业出版社

列出编写本计划时需查阅的Intenet上杂志、专业着作、技术标准。

查阅内容 网点地址 简介

软件测试工具 测试软件性能

软件测试工具 ITPUB 测试软件的执行效率

2. 测试内容

下表列出了学生信息管理系统的测试需求，并对其进行了优先级定义：

子系统名称 模块名称 测试点 优先级 说明

成绩管理

增加成绩 学号 0 不能自动编号

姓名 1 长度没有限制

学期

0 应该是一个时间段而不是时间点 点击空白处

0 直接出错，然后关闭系统

添加按钮

0 添加完成绩之后不能及时刷新，就不能很快的知道是否真的添加成功

成绩查询 界面

2 操作起来不够方便，查询条件不具体。

3. 测试规则

3.1. 进入准则

首先在系统中配置ODBC:控制版板-->ODBC--->选系统dns--->选accessmdb--->其中数据源名"信息",点击"选择"按钮,选你的程序目录中的"信息.mdb"的文件--->确定.

3.2. 另外安装企业版开发系统。使用账户登录系统来完成各个功能的测试。

3.3. 暂停/退出准则

3.4. 软件系统在进行单元、集成、确认、系统、安装、验收测试时，发现一级错误（大于等于1）、二级错误（大于等于2）暂停测试返回开发。软件系统经过单元、集成、确认、系统、安装、验收测试，分别达到单元、集成、确认、系统、安装、验收测试停止标准。软件系统通过验收测试，并已得出验收测试结论。软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据

3.5. 测试方法

3.6. 本次测试运用黑盒测试方法，对学生管理系统进行测试。首先，进行对功能模块进行划分，明确功能测试的人员负责情况。其次对各个模块进行测试。黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。黑盒测试着力于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

3.7. 当完成模块测试后进行整个系统的功能测试测试手段

路径测试(pathtesting)。一条路径包含测试员所执行的所有步骤，或程序为了得到正确状态所通过的所有语句。路径测试包括测试通过程序的很多路径。通过非平凡程序的所有路径是不可能的。因此，有些测试员进行子路径测试(subpathtesting),测试很多部分路径。、

语句与分支覆盖率(statementandbranchcoverage)。如果测试执行了程序中的所有语句(或代码行)，则达到100%的语句覆盖率。如果执行了所有语句和一个语句到另一个语句之间的所有分支，则达到100%的语句和分支覆盖率。设计自己的测试,达到高的语句与分支覆盖率,有时叫做“基于覆盖率的测试(coverage-basedtesting)”。(达到覆盖率目标后,可以停止测试，或停止设计更多的测试)。把它叫做语句与分支覆盖率，是为了与关注其他类型覆盖率的测试相区别。配置覆盖率就是一个很好例子，这种手段执行同一条语句很多次，但是潜在产生非常不同的结果。

配置覆盖率(configurationcoverage)。如果必须测试100台打印饥的兼容性，并且已经测试了10台,就达到10%的打印机覆盖率。更一般地，配置覆盖率度量测试员已经运行(并且程序已经通过)的配置测试占计划运行的配置测试总数的百分比。

基于规格说明的测试(specification-basedtesting)。这种测试关注验证在规格说明中所做的有关产品的每个事实声明。(事实声明是可以用真或假表示的任何语句。)常常包括手册、市场开发文档或广告、技术支持人员寄给客户的印刷品中的所有声明。

基于需求的测试(requirements-basedtesting)。测试关注证明程序满足需求文档中的所有需求(或关注逐个需求地证明某个需求没有被满足。)

3.8. 组合测试(combinationtesting)。相互组合测试两个或更多变量。本章最后的“测试手段附录”还要讨论这个问题。组合测试很重要，但是很多测试员对这种测试研究得还很不够。

3.9. 测试要点

主要测试系统的功能是否符合客户要求，各个模块之间的衔接程度是否顺畅，并测试软件是否存在缺陷和漏洞。

3.10.测试工具

1. 负载压力测试工具

这类测试工具的主要目的是度量应用系统的可扩展性和性能，是一种预测系统行为和性能的自动化测试工具。在实施并发负载过程中，通过实时性能监测来确认和查找问题，并针对所发现问题对系统性能进行优化，确保应用的成功部署。负载压力测试工具能够对整个企业架构进行测试，通过这些测试，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

2. 功能测试工具

通过自动录制、检测和回放用户的应用操作，将被测系统的输出记录同预先给定的标准结果比较，功能测试工具能够有效地帮助测试人员对复杂的企业级应用的不同发布版本的功能进行测试，提高测试人员的工作效率和质量。其主要目的是检测应用程序是否能够达到预期的功能并正常运行。

3. 测试管理工具

一般而言，测试管理工具对测试需求、测试计划、测试用例、测试实施进行管理，并且测试管理工具还包括对缺陷的跟踪管理。测试管理工具能让测试人员、开发人员或其他的IT人员通过一个中央数据仓库，在不同地方就能交互信息。

4. 测试环境

4.1. 硬件环境

1>处理器：IntelPentium166MX或更高

2>内存：32MB以上

3>硬盘空间：1GB以上

4.2. 4>显卡：SVGA显示适配器

4.3. 软件环境

4.4. 企业版开发系统

4.5. 安全性环境要求

操作系统的安全性，测试工具的安全性，测试软件的安全性。

5. 项目任务

以下是测试学生信息管理系统时与测试有关的任务：

5.1. 测试规划

1.响应时间 我把“响应时间”的概念确定为“对请求作出响应所需要的时间”，把响应时间作`为用户视角的软件性能的主要体现。响应时间划分为“呈现时间”和“系统响应时间”两个部分。

2.并发用户数

我把“并发用户数”与“同时在线数”进行区别对待，我的“并发用户数”的标准是：并发用户数取决于测试对象的目标业务场景，因此，在确定这个“并发用户数”前，必须（必要）先对用户的业务进行分解、分析出典型的业务场景（也就是用户最常使用、最关注的业务操作），然后基于场景采用某些方法（有多种计算并发用户数的数学模型与公式）获得“并发用户数”。

这样做的原因是：假设一个应用系统、最高峰有500人同时在线、但这500人却不是并发用户数、因为假设在一个时间点上、有50%的人在填写复杂的表格（填写表格动作对服务器没有任何负担、只有在“提交”动作的时候才会对服务器系统构成压力）、有40%的人在不停的从一个页面跳转到另外一个页面（不停发出请求与回应、产生服务器压力）、还有10%的人挂在线上，没有任何操作在发呆：）（没有对服务器构成压力的动作）。因此只有那40%的人真正对服务器产生了压力，从这里例子可以看出、并发用户数关心的