《学生信息管理系统软件测试计划书.doc》由会员分享，可在线阅读，更多相关《学生信息管理系统软件测试计划书.doc（10页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、文档标识： 学生信息管理系统 软件测试计划书软件测试计划书 编 写 者 校 对 小组成员 数据库 07-3 班 第 01 小组 目录目录 1.引言引言.1 1.1.目的.1 1.2.背景.1 1.3.范围.1 1.4.定义.1 1.5.参考资料.1 2.测试内容测试内容.2 3.测试规则测试规则.2 3.1.进入准则.2 3.2.暂停/退出准则.2 3.3.测试方法.2 3.4.当完成模块测试后进行整个系统的功能测试测试手段 .3 3.5.测试要点.3 3.6.测试工具.3 4.测试环境测试环境.4 4.1.硬件环境.4 4.2.软件环境.4 4.3.安全性环境要求.4 5.项目任务项目任务.
2、4 5.1.测试规划.4 5.2.测试设计.5 5.3.测试执行准备.6 5.4.测试执行.6 5.5.测试总结.6 6.实施计划实施计划.6 6.1.工作量估计.6 6.2.人员需求及安排.7 6.3.进度安排.7 6.4.可交付工件.7 7.风险管理风险管理.7 1 1. 引言引言 1.1. 目的 测试学生信息管理系统中的各个功能模块是否满足用户要求，并测试是否存 bug。预期达到能够使系统 进行快速的改进和系统的提高。为了在软件投入生产性运行之前，尽可能多地发现软件的错误。 1.2. 背景 a 本项目测试的背景；学生信息管理系统是一个教育单位不可缺少的部分,它的内容对于决策者和管 理者来
3、说都至关重要,所以学生信息管理系统应该能够为用户提供充足的信息和快捷的查询手段。但一 直以来人们使用传统人工的方式管理文件档案，这种管理方式存在着许多缺点,如:效率低、保密性差,另 外时间一长,将产生大量的文件和数据,这对于查找、更新和维护都带来了不少的困难。而计算机的应用 便解决了以上问题，它带来更加科学，有效，正规的管理方式，给人们带来了很大的便利。学生信息管 理系统界面简洁，操作简单，满足了学校对学生信息管理的需要。 b 该开发项目的历史，列出用户和执行此项目测试的机构或人群;该项目前后经历了三个阶段，前期 设计阶段，然后是开发阶段，最后是软件的测试阶段。项目的用户针对的是学校的广大学生
4、和管理员， 系统的功能测试主要由专业的软件测试人员进行测试。 1.3. 范围 学生信息管理系统试采用的是黑盒测试的方式来对系统进行测试。主要测试软件的功能是否满足客 户的需要，性能是否优越以及系统所存在的问题。对系统的各个模块进行详细的测试，并记录测试的结 果，对测试的结果进行细致的分析处理。测试时对系统的各个功能模块进行拆分测试，并以每一个模块 都要测试到。对所有可能的结果进行测试，以及测试过程中存在的问题进行分析，然后提交测试的记录。 最后，对软件存在的问题以及性能的测试进行全面分析，并给予记录。 在测试的过程中需要提出各个问题的假设，以及根据需求报告文档中存在的项目功能模块和用户的需求
5、来改善系统。列出可能会影响测试设计、开发、或实施的所有风险或意外事件。列出可能会影响测试设 计、开发或实施的所有约束。 1.4. 定义 信息（Information）：有关学生个人的详细数据，如姓名、性别、家庭住址等 管理（Manage）：对学生信息进行操作，如增删改查等基本功能 统计（Account）：对学生信息的统计，如人数等 1.5. 参考资料 列出编写本计划及测试整个过程中所要参考的文件、资料。 编号编号 资料名称资料名称作者作者日期日期出版单位出版单位 1 软件测试入门与 提高张成明2008.6清华大学出版社 2 软件测试基础教 程刘建宇2007.3邮电大学出版社 软件测试自动化 的
6、引入和应用李刚2004.4机械工业出版社 2 列出编写本计划时需查阅的 Intenet 上杂志、专业著作、技术标准。 查阅内容查阅内容网点地址网点地址简介简介 软件测试工具测试软件性能 软件测试工具ITPUB测试软件的执行效率 2. 测试内容测试内容 下表列出了学生信息管理系统的测试需求，并对其进行了优先级定义： 子系统名称子系统名称模块名称模块名称测试点测试点优先级优先级说明说明 学号 0 0不能自动编号 姓名 1 1长度没有限制 学期 0 0 应该是一个时间段 而不是时间点 点击空白处 0 0 直接出错，然后关 闭系统 增加成绩 添加按钮 0 0 添加完成绩之后不 能及时刷新，就不能很 快
7、的知道是否真的添加 成功 成绩管理 成绩查询界面 2 2 操作起来不够方便， 查询条件不具体。 3. 测试规则测试规则 3.1. 进入准则 首先在系统中配置 ODBC:控制版板-ODBC-选系统 dns-选 access mdb-其中 数据源名信息 ,点 击选择 按钮,选你的程序目录中的 信息.mdb的文件-确定. 另外安装 vb6.0 企业版开发系统。使用账户登录系统来完成各个功能的测试。 3.2. 暂停/退出准则 软件系统在进行单元、集成、确认、系统、安装、验收测试时，发现一级错误（大于等于 1） 、二级错 误（大于等于 2）暂停测试返回开发。软件系统经过单元、集成、确认、系统、安装、验收
8、测试，分别达到 单元、集成、确认、系统、安装、验收测试停止标准。软件系统通过验收测试，并已得出验收测试结论。软 件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。软件项目在其开发生命周期内出现重大 估算，进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据 3.3. 测试方法 本次测试运用黑盒测试方法，对学生管理系统进行测试。首先，进行对功能模块进行划分，明确功能测 试的人员负责情况。其次对各个模块进行测试。黑盒测试也称功能测试或数据驱动测试，它是在已知产品所 应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盒子， 在完全不
9、考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照 需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信 息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等，主 要用于软件确认测试。黑盒测试着力于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行 3 测试。 “黑盒法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所 有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能 的输入进行测试。 3.4.
10、 当完成模块测试后进行整个系统的功能测试测试手段 路径测试(path testing) 。一条路径包含测试员所执行的所有步骤，或程序为了得到正确状态所通过的所 有语句。路径测试包括测试通过程序的很多路径。通过非平凡程序的所有路径是不可能的。因此，有些测试 员进行子路径测试(subpath testing),测试很多部分路径。 、 语句与分支覆盖率(statement and branch coverage)。如果测试执行了程序中的所有语句(或代码行)，则达 到 100%的语句覆盖率。如果执行了所有语句和一个语句到另一个语句之间的所有分支，则达到 100%的语句 和分支覆盖率。设计自己的测试,达
11、到高的语句与分支覆盖率,有时叫做“基于覆盖率的测试(coverage-based testing)” 。(达到覆盖率目标后,可以停止测试，或停止设计更多的测试) 。把它叫做语句与分支覆盖率，是 为了与关注其他类型覆盖率的测试相区别。配置覆盖率就是一个很好例子，这种手段执行同一条语句很多次， 但是潜在产生非常不同的结果。 配置覆盖率(configuration coverage) 。如果必须测试 100 台打印饥的兼容性，并且已经测试了 10 台,就达 到 10%的打印机覆盖率。更一般地，配置覆盖率度量测试员已经运行(并且程序已经通过)的配置测试占计划 运行的配置测试总数的百分比。 基于规格说明
12、的测试(specification-based testing) 。这种测试关注验证在规格说明中所做的有关产品的每 个事实声明。(事实声明是可以用真或假表示的任何语句。)常常包括手册、市场开发文档或广告、技术支持 人员寄给客户的印刷品中的所有声明。 基于需求的测试(requirements-based testing) 。测试关注证明程序满足需求文档中的所有需求(或关注逐个 需求地证明某个需求没有被满足。) 组合测试(combination testing) 。相互组合测试两个或更多变量。本章最后的“测试手段附录”还要讨论这 个问题。组合测试很重要，但是很多测试员对这种测试研究得还很不够。 3
13、.5. 测试要点 主要测试系统的功能是否符合客户要求，各个模块之间的衔接程度是否顺畅，并测试软件是否存在缺 陷和漏洞。 3.6. 测试工具 1.负载压力测试工具 这类测试工具的主要目的是度量应用系统的可扩展性和性能，是一种预测系统行为和性能 的自动化 测试工具。在实施并发负载过程中，通过实时性能监测来确认和查找问题，并针对所 发现问题对系统性 能进行优化，确保应用的成功部署。负载压力测试工具能够对整个企业架构 进行测试，通过这些测试， 企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布 周期。 2.功能测试工具 通过自动录制、检测和回放用户的应用操作，将被测系统的输出记录同预先给定的标
14、准结 果比较，功 能测试工具能够有效地帮助测试人员对复杂的企业级应用的不同发布版本的功能进 行测试，提高测试人员 的工作效率和质量。其主要目的是检测应用程序是否能够达到预期的功 能并正常运行。 3.测试管理工具 一般而言，测试管理工具对测试需求、测试计划、测试用例、测试实施进行管理，并且测 试管理工具 4 还包括对缺陷的跟踪管理。测试管理工具能让测试人员、开发人员或其他的 IT 人员 通过一个中央数据仓库， 在不同地方就能交互信息。 4. 测试环境测试环境 4.1. 硬件环境 1 处理器：Intel Pentium 166 MX 或更高 2 内存：32MB 以上 3 硬盘空间：1GB 以上 4
15、 显卡：SVGA 显示适配器 4.2. 软件环境 vb6.0 企业版开发系统 4.3. 安全性环境要求 操作系统的安全性，测试工具的安全性，测试软件的安全性。 5. 项目任务项目任务 以下是测试学生信息管理系统时与测试有关的任务： 5.1. 测试规划 1. 响应时间 我把“响应时间”的概念确定为“对请求作出响应所需要的时间” ，把响应时间作为用户视角的软件性 能的主要体现。响应时间划分为“呈现时间”和“系统响应时间”两个部分。 2. 并发用户数 我把“并发用户数”与“同时在线数”进行区别对待，我的“并发用户数”的标准是：并发用户数取决 于测试对象的目标业务场景，因此，在确定这个“并发用户数”前
16、，必须（必要）先对用户的业务进行分解、 分析出典型的业务场景（也就是用户最常使用、最关注的业务操作） ，然后基于场景采用某些方法（有多种 计算并发用户数的数学模型与公式）获得“并发用户数” 。 这样做的原因是：假设一个应用系统、最高峰有 500 人同时在线、但这 500 人却不是并发用户数、因为假 设在一个时间点上、有 50%的人在填写复杂的表格（填写表格动作对服务器没有任何负担、只有在“提交” 动作的时候才会对服务器系统构成压力） 、有 40%的人在不停的从一个页面跳转到另外一个页面（不停发出 请求与回应、产生服务器压力） 、还有 10%的人挂在线上，没有任何操作在发呆：） （没有对服务器构
17、成压力 的动作） 。因此只有那 40%的人真正对服务器产生了压力，从这里例子可以看出、并发用户数关心的是不但 是业务并发用户数、还取决于业务逻辑、业务场景。因此我们需要本文第六部分性能测试文档 4、5、6。 3. 吞吐量 我把吞吐量定义为“单位时间内系统处理的客户请求的数量” ，直接体现软件系统的性能承载能力，对 于交互式应用系统来说、吞吐量反映的是服务器承受的压力、在容量规划的测试中、吞吐量是一个重要指标、 它不但反映在中间件、数据库上、更加体现在硬件上。我们在以下方面利用这个指标： （1）用来协助设计性能测试场景，衡量性能测试是否达到了预计的设计目标、比如 J2EE 应用系统的连接池、 数
18、据库事务发生频率、事务发生次数。 （2） 用来协助分析性能瓶颈、参照本文第二部分总的 RBI 方法。 4. 性能计数器 性能计数器式描述服务器或操作系统性能的一些数据指标、例如对 WINDOWS 来说使用内存数、CPU 使 5 用率、进程时间等都是常见的计数器。 对于性能计数器这个指标来说、需要考虑到的不但有硬件计数器、web 服务器计数器、Weblogic 服务器 计数器、Servlet 性能计数器、EJB2 的性能计数器、JSF 性能计数器、JMS 性能计数器。找到这些指标是使 用性能计数器的第一步、关键是找到性能瓶颈、确定系统阀值、提供优化建议才是性能计数器使用的关键。 性能计数器复杂而
19、繁多、与代码上下文环境、系统配置情况、系统架构、开发方式、使用到的规范实现、工 具、类库版本都有紧密的联系、在此不作赘述。 5. 思考时间 我把思考时间确定为“休眠时间” 。从业务系统的角度来说，这个时间指的是用户在惊醒操作时、每个请 求之间的时间间隔、从自动化测试的角度来说、要真实的测试模拟用户操作、就必须在测试脚本中让各个操 作之间等待一段时间、体现在脚本上就是在操作之间放置一个 Think 的函数，体现为脚本中两个请求语句之 间的间隔时间、不同的测试工具提供了不同的函数或方法来实现思考时间、比如 HP LoadRuner 和 IBM Rational Performance Tester
20、 的方式就完全不同。 5.2. 测试设计 用户层： 主要是面向产品最终的使用操作者的测试。这里重点突出的是在操作者角度上，测试系统对用户支持的 情况，用户界面的规范性、友好性、可操作性，以及数据的安全性。主要包括：用户手册、使用帮助、支持 客户的其他产品技术手册是否正确、是否易于理解、是否人性化。 用户界面测试 在确保用户界面能够通过测试对象控件或入口得到相应访问的情况下，测试用户界面的风格是否满足用 户要求，例如：界面是否美观、界面是否直观、操作是否友好、是否人性化、易操作性是否较好。 可维护性测试 可维护性是系统软、硬件实施和维护功能的方便性。目的是降低维护功能对系统正常运行带来的影响。
21、例如：对支持远程维护系统的功能或工具的测试。 安全性测试 这里的安全性主要包括了两部分：数据的安全性和操作的安全性。核实只有规格规定的数据才可以访问 系统，其他不符合规格的数据不能够访问系统;核实只有规格规定的操作权限才可以访问系统，其他不符合 规格的操作权限不能够访问系统; 应用层： 针对产品工程应用或行业应用的测试。重点站在系统应用的角度，模拟实际应用环境，对系统的兼容性、 可靠性、性能等进行的测试。 系统性能测试 针对整个系统的测试，包含并发性能测试、负载测试、压力测试、强度测试、破坏性测试。并发性能测 试是评估系统交易或业务在渐增式并发情况下处理瓶颈以及能够接收业务的性能过程；强度测试
22、是在资源情 况低的情况下，找出因资源不足或资源争用而导致的错误；破坏性测试重点关注超出系统正常负荷 N 倍情况 下，错误出现状态和出现比率以及错误的恢复能力。 系统可靠性、稳定性测试 6 一定负荷的长期使用环境下，系统可靠性、稳定性。 系统兼容性测试 系统中软件与各种硬件设备兼容性，与操作系统兼容性、与支撑软件的兼容性。 系统组网测试 组网环境下，系统软件对接入设备的支持情况。包括功能实现及群集性能。 系统安装升级测试 安装测试的目的是确保该软件在正常和异常的不同情况下进行安装时都能按预期目标来处理。例如，正常 情况下，第一次安装或升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不
23、足、缺少目录 创建权限等。还有一个目的是核实软件在安装后可立即正常运行。另外对安装手册、安装脚本等也需要关注。 5.3. 测试执行准备 故障转移和恢复测试可确保测试对象能成功完成转移，并能从导致意外数据损失或数据完整性破环的各 种硬件、软件、网络故障中恢复数据。故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备 用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。恢复测试是一种对抗性的测 试过程。在这种测试中，将把应用程序或系统至于极端的条件下（或者是模拟的极端条件下） ，以产生故障 （例如设备输入/输出（I/O）故障或无效的数据库指针和关键字） 。然后调用恢复进程
24、并检测和检查应用程序 和系统，核实应用程序或系统和数据已得到了正确的恢复。 5.4. 测试执行 1前提条件确保测试项目的功能正常，如导航，数据输入，处理、检索是否正确，以及业务规则的实施是 否恰当。此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输 出或结果进行分析，以此来核实应用程序及其内部进程,这是目前的测试重点。 执行用例及原始数据记录 2 提交测试问题单和测试报告 3 回归及验收测试 4 输出工件 利用有效的和无效的数据来执行各个用例流，以核实以下内容： a)在使用有效数据时得到预期的结果 b)在使用无效数据时显示相应的错误消息或警告消息。 6. 实
25、施计划实施计划 6.1. 工作量估计 根据工作内容和项目任务对包括测试设计的工作量、测试执行和测试总结的工作量，以人月或人 日计， 并详细注释测试设计、测试执行和测试总结工作所占的比重。软件测试工作量应为开发工作量 的 30%-40%为宜。 7 工作阶段工作阶段所需工作日所需工作日占项目的比例占项目的比例 测试规划阶段1 15% 测试设计阶段1 15% 测试实施阶段1 20% 测试执行阶段1 20% 测试总结阶段1 15% 6.2. 人员需求及安排 下表列出了在此测试活动的人员安排： 角色角色人员人员具体职责具体职责/备注备注 测试经理 负责软件测试的总体安排监督工作 测试设计 负责设计测试方
26、案以及测试用例 测试人员 负责对对项目按照测试方案进行具体测试 记录人员 负责系统测试过程中记录测试信息 6.3. 进度安排 下表列出了测试的时间安排： 项目里程碑项目里程碑开始时间开始时间结束时间结束时间输出要求输出要求/备注备注 测试规划 09:00 10：00 测试设计 10:1011:10 测试设计实施 11:3013:30 测试执行 14:0015:30 测试总结 16:0018:00 6.4. 可交付工件 本节列出了将要创建的各种文档、工具和报告，及其创建人员、交付对象和交付时间。 7. 风险管理风险管理 L=Low(风险与处理的优先级为低) M=Middle(风险与处理的优先级为
27、中) H=High(风险与处理的优先级为高) 功能测试阶段安装测试阶段文档测试 正确性 HHH 文件完整性 HHH 处理的连续性 MMM 访问控制 MMM 符合性 HHH 可靠性 HHH 易操作性 HHH 可维护性 HHH 测 试 阶 段 测 试 因 素 8 可移植性 HHH 2.问题严重度描述 问题严重度描述 致命缺陷1 由于程序所引起的死机,非法退出 2 死循环 3 数据库发生死锁 4 因错误操作导致的程序中断 5主要功能丢失或功能严重错误 6 与数据库连接错误 7 数据通讯错误 严重缺陷1 程序错误 2 程序接口错误 3 数据库的表、业务规则、缺省值未加完整性等约束条件 一般性缺陷1 操作界面错误（包括数据窗口内列名定义、含义是否一致） 2 打印内容、格式错误 3 简单的输入限制未放在前台进行控制 4 删除操作未给出提示 5 数据库表中有过多的空字段