软件测试大作业.docx

软件测试大作业.docx

《软件测试大作业.docx》由会员分享，可在线阅读，更多相关《软件测试大作业.docx（56页珍藏版）》请在冰豆网上搜索。

软件测试大作业

《软件测试技术》

课程考核作业

一、测试计划

1引言

1.1编写目的

软件测试计划是指导测试过程的纲领性文件，借助软件测试计划，参与测试的项目成员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

由于本网站从需求到开发从编码到最终的实现，都是自行研制开发的，在其中有许多的不规范和相应的程序BUG，需要在最后的测试阶段得以修正。

以满足用户的需求。

1.2项目背景

随着科技的发展，网络一体化已经席卷了全球，现代网络生活已经遍布每个家庭乃至个人。

互联网技术的不断革新与发展为全球经济带来了新的变化。

学校作为培养高科技，高素质人才的平台，学校网络的发展是这一平台不可或缺的因素。

学校已经深深地意识到信息时代对学校的发展意味着什么，在师资培养、学术交流、教学改革、科研协作等方面都离不开网络，网络为各大高校之间的交流提供的便捷的途径。

1.3定义

单元测试：

集中检测软件设计的最小单元－模块。

集成测试：

是测试和组装软件的系统化技术。

自底向上集成：

从“原子”模块（即在软件结构最低层的模块）开始组装和测试。

白盒测试：

已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

黑盒测试：

已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合求。

2任务概述

2.1目标

在测试过程中找出并修改相应的BUG，使网站正常的运行。

2.2运行环境

a）硬件条件：

PC机

b）运行环境：

Windows7

2.3需求概述

2.4条件与限制

测试的机器上必须安装能够运行JSP的JDK和Tomcat，以及有SQLSERVER2000的支持。

3计划

3.1测试方案

结合时间、分组、经验等多方面因素，测试方案步骤如下：

1、进行单元测试，对相关模块进行分部测试。

2、每个模块的单元测试成功后，再对各个模块结合起来的整体程序进行测试。

3.2测试项目

一、单元测试

1、学校概况模块

2、教务信息模块

3、科学研究模块

4、研究生教育模块

5、招生模块

6、就业模块

7、图书馆模块

二、集成测试

在单元测试都完全通过后，对模块进行整合，对整合后的模块进行测试，在分块开发过程中可能有不同的模块共同调用相同的数据表，可能存在冲突，因此，在集成测试的过程中主要对共用的数据表进行字段sort值的分配，以便消除相互冲突，从而达到系统的完整性。

3.3测试准备

1、将自己负责的模块进行测试。

4测试项目说明

4.1测试项目名称及测试内容

测试项目：

1、学校概况模块

2、教务信息模块

3、科学研究模块

4、研究生教育模块

5、招生模块

6、就业模块

7、图书馆模块

测试内容：

1、对各个模块的添加、修改、删除功能实现的测试。

2、对页面总体规划的测试。

3、对数据安全性、准确性的测试。

4.2测试用例

4.2.1输入

见测试用例

4.2.2输出

　　4.2.3步骤及操作

　　通过是用不同的什么在界面出现不同的内容：

以学生身份登陆：

通过对信息的录入和修改，从而管理学生自身基本信息的内容。

以教师身份登陆：

通过对信息的录入和修改，从而管理老师自身基本信息的内容，以及对教学答疑的管理。

以管理员身份登陆：

通过对信息的录入和修改，管理和分配教师和学生的权限。

4.2.4允许偏差

输入于显示的结果正确率控制在百分之九十以上正确。

允许偏差控制在百分之十以内。

4.3进度

将测试进度分成两部分：

1、单元测试

2、集成测试

4.4条件

对设备的要求：

PC机上必须安装JDK和Tomcat引擎

对软件的要求：

安装Eclipse

人员要求：

对网站的结构和功能有一定的了解。

５评价

5.1　范围

本网站在功能实现上已经很完备，结合测试中出现的问题，主要是在界面的的设计以及对功能细节方面的处理还有欠缺，应更多的站在用户角度来完善网站的约束条件，此外，数据库应适当的加入触发器等进一步约束所添加、修改、删除相应信息的能力。

5.2准则

以用户的需求为准则，不断修改模块，完善最终的软件。

二、测试方案

1．测试需求

下面列出了那些已被确定为测试对象的项目（用例、功能性需求和非功能性需求）。

此列表说明了测试的对象。

2．测试方案

[测试方案提供了推荐用于测试对象的方法。

上一节“测试需求”中说明了将要测试哪些对象，而本节则要说明如何对测试对象进行测试。

对于每种测试，都应提供测试说明并解释其实施和执行的原因。

如果不实施和执行某种测试，则应该用一句话加以说明，并陈述这样做的理由。

例如，“将不实施和执行该测试。

。

该测试不合适。

”制定测试策略时所考虑的主要事项有：

将要使用的方法以及判断测试何时完成的标准。

下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、受控的数据库来执行，可按实际需要进行删减。

]

测试类型

数据和数据库完整性测试

[数据库和数据库进程应作为<项目名称>中的子系统来进行测试。

在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。

对于数据库管理系统（DBMS），还需要进行深入的研究，以确定可以支持以下测试的工具和方法。

]

测试目标：

[确保数据库访问方法和进程正常运行，数据不会遭到损坏。

]

方法：

[调用各个数据库访问方法和进程，并在其中填充有效的和无效的数据或对数据的请求。

检查数据库，确保数据已按预期的方式填充，并且所有数据库事件都按正常方式出现；或者检查所返回的数据，确保为正当的理由检索到了正确的数据]

完成标准：

[所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。

]

需考虑的特殊事项：

[测试可能需要DBMS开发环境或驱动程序以便在数据库中直接输入或修改数据。

进程应该以手工方式调用。

应使用小型或最小的数据库（其中的记录数很有限）来使所有无法接受的事件具有更大的可见性。

]

功能测试

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

这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。

这种类型的测试基于黑盒方法，即通过图形用户界面（GUI）与应用程序交互并分析输出结果来验证应用程序及其内部进程。

以下列出的是每个应用程序推荐的测试方法概要：

]

测试目标：

[确保测试对象的功能正常，其中包括导航、数据输入、处理和检索等。

]

方法：

[利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：

在使用有效数据时得到预期的结果。

在使用无效数据时显示相应的错误消息或警告消息。

各业务规则都得到了正确的应用。

]

完成标准：

[所计划的测试已全部执行。

所发现的缺陷已全部解决。

]

需考虑的特殊事项：

[确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）]

用户界面测试

　　　［用户界面（UI）测试来核实用户与软件的交互。

UI测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。

除此之外，UI测试还要确保UI功能内部的对象符合预期要求，并遵循公司或行业的标准。

]

测试目标：

[核实以下内容：

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

窗口的对象和特征（例如：

菜单、大小、位置、状态和中心）都符合标准。

]

方法：

[为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。

]

完成标准：

[证实各个窗口都与基准版本保持一致，或符合可接受标准]

需考虑的特殊事项：

[并不是所有定制或第三方对象的特征都可访问。

]

性能评价

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

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

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

注：

以下事务均指“逻辑业务事务”。

这种事务被定义为将由系统的某个主角通过使用测试对象来执行的特定用例，例如，添加或修改某个合同。

]

测试目标：

[核实所指定的事务或业务功能在以下情况下的性能行为：

正常的预期工作量

预期的最繁重工作量]

方法：

[使用为功能或业务周期测试制定的测试过程。

通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代次数。

脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多台客户机（虚拟的或实际的客户机，请参见下面的“需考虑的特殊事项”）上重复。

]

完成标准：

[单个事务或单个用户：

在每个事务所预期或要求的时间范围内成功地完成测试脚本，没有发生任何故障。

]

[多个事务或多个用户：

在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。

]

需考虑的特殊事项：

[综合的性能测试还包括在服务器上添加后台工作量。

可采用多种方法来执行此操作，其中包括：

直接将“事务强行分配到”服务器上，这通常以“结构化查询语言”（SQL）调用的形式来实现。

通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。

此负载可通过“远程终端仿真”（RemoteTerminalEmulation）工具来实现。

此技术还可用于在网络中加载“流量”。

使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。

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

性能测试所用的数据库应该是与实际大小相同或等比例缩放的数据库。

]

安全性和访问控制测试

[安全性和访问控制测试侧重于安全性的两个关键方面：

应用程序级别的安全性，包括对数据或业务功能的访问

系统级别的安全性，包括对系统的登录或远程访问。

应用程序级别的安全性可确保：

在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。

例如，可能会允许所有人输入数据，创建新账户，但只有经理才能删除这些数据或账户。

如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户信息（包括财务数据），而“用户二”只能看见同一客户的统计数据。

系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。

]

测试目标：

∙应用程序级别的安全性：

[核实主角只能访问其所属用户类型已被授权使用的那些功能或数据。

]

∙系统级别的安全性：

核实只有具备系统和应用程序访问权限的主角才能访问系统和应用程序。

]

方法：

∙应用程序级别的安全性：

[确定并列出各用户类型及其被授权使用的功能或数据。

]

[为各用户类型创建测试，并通过创建各用户类型所特有的事务来核实其权限。

]

修改用户类型并为相同的用户重新运行测试。

对于每种用户类型，确保正确地提供或拒绝了这些附加的功能或数据。

∙系统级别的访问：

[请参见下面的“需考虑的特殊事项”]

完成标准：

[各种已知的主角类型都可访问相应的功能或数据，而且所有事务都按照预期的方式运行，并在先前的应用程序功能测试中运行了所有的事务。

]

需考虑的特殊事项：

[必须与相应的网络或系统管理员一起对系统访问权进行检查和讨论。

由于此测试可能是网络管理或系统管理的职能，可能不需要执行此测试。

]