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