仓库管理系统项目软件测试方案说明书

仓库管理系统测试计划第1章引言6

1.1编写目的6

1.2背景6

1.3参考资料6

第2章任务概述7

2.1系统概述7

2.2目标7

2.3文档概述7

2.4软件测试环境8

2.4.1 设备8

2.4.2 软件环境9

2.5条件与限制9

第3章计划10

3.1测试方案10

3.1.1 单元测试10

3.1.2 集成测试10

3.1.3 确认测试10

3.1.4 测试工具11

3.2测试项目11

3.2.1 测试要求11

3.2.2 测试类型12

3.2.3 测试定义12

3.2.4 暂停准则12

3.3测试准备13

3.4主要进度13

3.5风险管理13

第4章测试设计说明14

4.1测试用例设计说明14

4.1.1 用例选取原则14

(1>输入<输入的数据和输入命令）15

(2>输出<预期的输出数据）15

(3>步骤及操作15

(4>允许偏差15

4.2测试执行16

4.3回归测试16

第5章评价准则16

5.1软件错误的严重性等级16

5.2测试通过标准18

5.3数据记录、整理和问题分析18

5.3.1 数据记录和整理18

5.3.2 问题确认及处理18

第1章引言

1.1 编写目的

本文档是系统初步验收过程中进行三方测试的测试方案，其主要描述了测试方案、测试项目和各项目的测试用例设计说明等。测试人员可通过文档的测试方案结合测试用例，对系统进行测试。

本文档的读者范围是：

承建商超市仓库管理员和技术人员；

软件项目监理；

测试组技术人员；

1.2 背景

在计算机飞速发展的今天，将计算机这一信息处理利器应用于超市仓库的日常管理已是势必所然，而且这也将为超市仓库管理带来前所未有的改变，它可以带来意想不到的效益，同时也会为企业的飞速发展提供无限潜力。采用计算机管理信息系统已成为超市仓库管理科学化和现代化的重要标志，它给企业管理来了明显的经济效益和社会效益。主要体现在：极大提高了超市仓库工作人员的工作效率，大大减少了以往入出存流程繁琐，杂乱，周期长的弊端。

基于超市超市仓库管理的全面自动化，可以减少入库管理、出库管理及库存管理中的漏洞，可以节约不少管理开支，增加企业收入。

超市仓库的管理的操作自动化和信息的电子化，全面提高了超市仓库的管理水平

1.3 参考资料

1> 系统项目需求说明书

2> 项目总体设计说明书

3> 项目数据库设计说明书

第2章任务概述

2.1 系统概述

超市仓库管理系统主要实现对物品和操作人员还有供应商等信息的进行同样有效的管理，从而实现物品查询的和人员管理的现代化，实现信息共享超市仓库管理系统主要包括：物品进销存和人员管理与系统维护这几个方面。测试主要针对系统功能性、安全性、可靠性方面的测试。测试的执行人员为本项目的业主方、监理方和承建方。本次测试计划所描述的测试工作为超市仓库管理系统系统的整体测试及性能测试。

2.2 目标

通过系统测试检查数据流是否符合《总体设计说明书》的要求，程序是否具备《总体设计说明书》、《需求说明书》要求的功能，系统中各模块的连接是否正确，模块之间的数据流是否有中断的情况，数据流是否达到末端等。同时针对监理方在测试过程中发现的问题进行相应的回归测试，保证已发现问题已解决。

2.3 文档概述

本文档按IEEE std 829-1998《软件测试文档》要求编写，为适应本次验收测试的要求，作了适当调整。

本文档主要描述测试组计划、组织和管理测试的方法和步骤，不描述测试用例的执行细节，也不描

述产品特征运行的技术细节。

本文档说明了准备和进超市仓库管理系统项目三方测试所应做的各项工作，并作为指导整个测试工作的依据。

本测试计划的主要用途如下：

●定义软件的三方测试；

●定义软件测试环境；

●确定测试风险；

●测试通过准则；

本测试计划各章节包括以下内容：

●在任务概述中，描述了本测试计划的被测试应用的简况、背景、本文档的简介；

●描述了构成测试环境所需的硬件和软件配置，以及这些硬件和软件的安装、测试和管

理的计划；

●在测试项目中，描述各项被测软件的总体测试要求、测试类型、测试级别、测试定

义；

●在测试方法和基本原理中，描述执行测试的方法和基本原理；

在数据记录、整理和问题分析中，描述按本测试计划所作测试的数据整理和分析过程,

并说明问题的判定、分级和处理；

2.4 软件测试环境

本次测试环境定于学生自己在宿舍的测试环境。测试所使用到的硬件设备、系统软件、应用支撑软件由学生自己安排。

2.4.1 设备

表1-1测试设备环境

2.4.2 软件环境

操作系统:Windows XP

软件: 、浏览器、LoadRunner

客户端支持软件：

具有MS IE6.0或以上版本浏览器

2.5 条件与限制

本次测试的限制包括：

(1>因为本次测试对象只是一个文档，所以没有测试实例，可能跟实际情况有出入，只能作为一个参考测试方案。

(2>本次测试将不考虑关系数据库的安装和功能。测试前数据库已安装并处于可操作的状态。

(3>本次测试将不直接测试Web服务器。

(4>整个测试主要进行系统测试，不准备进行单元测试和集成测试。

本测试计划和日程安排是在下述前提下完成的：

(1>需求和功能规格说明是完全的、正确的和稳定的。

(2>系统实现了需求和功能规格说明所定义的功能。

(3>测试提示明确的描述了对本次测试的要求。

第3章计划

3.1 测试方案

本次测试主要任务是对超市仓库管理系统进行初步验收的测试。测试的主要内容为：系统重要功能测试、监理方测试发现问题的回归测试以及系统的性能测试。

3.1.1 单元测试

在需求规格说明书中描述的所有功能，都将在选定的客户端/服务器配置组合上进行测试。测试中需要考虑正常的功能实现和恶意测试，即使用设计者不期望的数据进行操作。

3.1.2 集成测试

集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。使用黑盒测试方法测试集成的功能。集成测试中没完成的功能进行回归测试。

3.1.3 确认测试

确认测试又称为有效性测试。其任务是检查软件的功能和性能是否与需求说明书中确定的指标相符。确认测试阶段有进行确认测试与软件配置审查两项工作。

确认测试一般是在模拟环境下运用黑盒测试方法，由专门测试人员和用户参加的测试。确认测试需要需求说明书、用户手册等文档，要制定测试计划，确定测试的项目，说明测试的内容描述具体的测试用例。集成测试中没完成的功能进行回归测试。

软件配置审查的任务是检查软件的所有文档资料的完整性、正确性。如发现遗漏和错误，应补充和改正。同时要编排好目录，为以后的软件维护工作奠定基础。

3.1.4 测试工具

Mercury LoadRunner 8.1

LoadRunner是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。目前企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢，系统崩溃等问题。这些都不可避免地导致公司收益的损失。Mercury Interactive 的LoadRunner 能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT 资源，并确保终端用户在应用系统的各个环节中对其测试应用的质量，可靠性和可扩展性都有良好的评价。LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，能更快的查找和发现问题。此外，LoadRunner 能支持广范的协议和技术，提供特殊的解决方案。

3.2 测试项目

3.2.1 测试要求

对超市仓库管理系统项目内部测试需要满足下列要求：

●对软件需求报告描述的软件功能进行测试，以验证其是否满足规定的要求。

●对软件的安全性进行测试。

●对软件可靠性进行测试，包括容错性的测试。

●对软件易用性进行测试，包括易理解性、易学性、易操作性的测试。

●使用等价类划分、随机测试、猜错法、因果图法、状态图法进行测试。

●完成对软件需求的完全覆盖。

●对系统的性能进行测试，包括系统响应、并发测试。

3.2.2 测试类型

表3-1 测试类型

测试定义

表3-2 测试定义

3.2.4 暂停准则

被测软件无法正常安装将导致暂停测试执行活动。

被测软件在测试过程中发现重大缺陷，影响后续测试工作，将导致暂停测试执行活动。

3.3 测试准备

建立测试项目表，测试项目表是指按照用户需求说明书并结合本次测试的特点抽取重要的业务系统功能划分为小的项目并建立列表。

●根据测试范围和测试目标，设计各模块的数据用例。

测试各模块数据是否符合系统《总体设计说明书》要求的数据流，检查程序的来源是否正确，数据的存储及计算过程是否正确。并检查系统是否达到《用户需求说明书》所要求的功能3.4 主要进度

表3-3 测试进度

3.5 风险管理

因为不可预料的原因导致测试时间压缩，此外因受网络环境的限制，性能测试时间也将有所变动。通过增加延长测试时间，并采取加班方法解决。通过软件测试组来负责测试项目的总体管理工作，统一组织、监控测试工作，协调测试与开发工作。

因为测试人员是非系统开发人员，对系统的熟悉、功能的理解会存在不明确的地方，导致测试工作效率降低，甚至导致测试方向偏移。可通过加强与承建方测试人员的沟通，相互间形成共识，并由承建方人员对功能进行解说并提供技术支持。

第4章测试设计说明

本次测试共设计测试用例40个，用例覆盖功能测试、安全性测试、易用性测试等测试类型，用例具体分布如下表所示：

表3-4 测试具体类型

4.1 测试用例设计说明

4.1.1 用例选取原则

用例设计策略具体描述为：

●功能测试

?根据软件需求规格说明的功能描述，对软件的各项功能逐一进行验证；

在对软件的各项子功能逐一进行测试时，对被测试软件的可选择项目和输入数据进行

分类，每一个类数据分别设计测试用例；

?使用等价类划分、随机测试、猜错法进行测试设计。

●安全性测试

?从授权用户方面查看是否有足够权限使用系统和数据来进行测试；

?从非授权用户方面查看是否能访问系统和和数据来进行测试。

●容错性测试

?通过用户误操作的几种模式设计测试用例。

?使用错误的操作序列对软件进行测试。

?使用超过输入范围的数据对软件进行输入的测试。

●易用性测试

?从软件的易操作性、易学习性等方面对软件进行逐项测试。

●性能测试

?根据系统用户需求及总体设计的性能规定对系统的并发、响应速度方面进行测试。

(1>输入<输入的数据和输入命令）

各用例的输入数据和输入命令，详见各用例表格。

(2>输出<预期的输出数据）

各用例的输出<包括预期界面输出和数据输出），详见各用例表格。

(3>步骤及操作

各用例的测试步骤及操作顺序，详见各用例表格。

(4>允许偏差

用例中所描述的操作提示<包括操作前提示、操作结果提示），可能与实际测试界面提示文字存在差异。在不影响用户对该提示的理解的情况下，该差异属于系统允许偏差。

用例中所描述的界面操作控件的名称、标题，可能与实际测试界面的操作控件存在差异。在不产生歧义的情况下<例如，“添加”与“增加”），该差异属于系统允许偏差。

4.2 测试执行

测试执行应严格按照测试计划中的进度安排进行，执行过程中，应做好详尽的测试记录，这些记录包括：

●记录每个用例的执行结果；

●记录用例执行过程中相关的细节；

●记录执行测试过程中出现的不寻常的结果；

●记录测试过程中新增的测试用例。

4.3 回归测试

回归测试将重新测试发现缺陷的测试用例，以确认软件缺陷得到修复。

第5章评价准则

5.1 软件错误的严重性等级

表5-1 测试错误等级

表5-2 测试特性

5.2 测试通过标准

●错误等级为1的错误不存在；

●错误等级为2的错误数量<=5；

●错误等级为3的错误数量<=8；

●所有提交的错误都已更正。

5.3 数据记录、整理和问题分析

5.3.1 数据记录和整理

在测试过程中，由测试组记录测试用例的基本执行情况，填写《测试用例记录表》。

软件测试过程中发现错误或故障时，测试人员应将错误现象、故障产生的详细步骤、测试条件等进行详细记录，并填写《软件问题报告》。

根据错误原因分析结果和掌握的其他信息对错误进行评审，提出错误分类和定级意见，为判决测试工作结果提供依据。

软件问题等级定义为：

●严重：会影响到任务成败的软件问题；

●一般：会对任务的功能产生影响，但不影响到整个任务的成败；

●轻微：给操作员带来不方便或麻烦，但不影响所要求的功能实现的软件问题。

5.3.2 问题确认及处理

软件测试开始前应建立软件问题报告数据库，对软件测试过程中发现的问题应详细的记录在《软件问题报告表》中，并按规定的程序传递。

若系统软件存在重大缺陷导致系统无法进行，则应立即停止测试，直到受测软件被修改更正。

软件测试过程中发现错误或故障时，测试人员应将错误现象、故障产生的详细步骤、测试条件等详细记录。若错误或故障会危及系统、分系统的安全或系统、分系统已无法继续正常工作，则应立即停止测试，直到受测软件被修改更正。否则，一般应让测试工作继续进行以便获得更多的错误或故障信息。根据错误原因分析结果和掌握的其他信息对错误进行评审，提出错误分类和定级意见，为判决测试工作结果提供依据