14教务管理系统测试计划

软件测试计划说明书§1.引言1.1.编写目的本计划是教务管理系统的总体测试计划。目的是说明各种测试阶段任务、人员分配和时间安排、工作规范等。也是为以后的测试设计、测试开发、测试执行、测试评估有所标准。1.2.项目背景a．本项目的名称为教务管理系统；b．本项目是由计算机科学与技术学院08计11班郭琼、王娟、何婷婷、李姣、金欢欢、褚强、孙超为了进行软件测试实训而进行开发的。1.3.定义1.3.1.测试用例中的编号功能名+界面名(每个字第一个汉语拼音大写)+编号例如：登录第一个用例DL00011.3.2.测试用例文件名命名规则模块名+测试用例例如：学生模块学生测试用例1.3.3.黑盒测试黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。1.3.4.白盒测试白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序第1页中的每条通路是否都能按预定要求正确工作。这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。1.3.5.静态测试静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导1.3.6.动态测试动态方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。1.3.7.组件功能测试组建功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。1.3.8.业务测试业务测试，在单元测试的基础上，将所有业务流程的模块按照设计要求（如根据结构图〕组装成为子系统或系统，进行测试。1.3.9.压力、容量、性能测试就是将业务测试完后的系统进行进一步的业务流程测试，例如：在线人数和系统反应时间的测试。1.3.10.认可度和可用性测试认可度和可用性测试，系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。第2页1.3.11.DREDefectRemovalEfficiency，通过复审、检查和测试消除掉的缺陷的百分比。是应用于软件开发生命周期过程中不同类型的缺陷的重要评价方法。通过缺陷消除有效性评估，可以帮助我们选择那些测试种类在什么时候执行会更加有效。对于测试阶段的缺陷清除率，可以近似等于：DRE=在开发过程中缺陷被解决的数目（Defectsremovedduringadevelopmentphase）X100%在该阶段缺陷潜伏的数目（Defectslatentintheproductatthatphase）1.4.参考资料参考资料名称作者《教务管理系统软件需求说明书》王娟《教务管理系统软件概要设计说明书》郭琼、李姣《教务管理系统软件详细设计说明书》金欢欢、何婷婷《教务管理系统数据库设计说明书》褚强、孙超§2.任务概述2.1.目标2.1.1.测试当前版本的产品是否达到设计阶段的的要求.包括：各个功能点是否以实现，业务流程是否正确。2.1.2.产品规定的操作和运行稳定。例如：进行一些评判学生成绩的数据库操作时，数据库会不会正常运行。2.1.3.Bug数和缺陷率控制在可接收的范围之内。例如：估计总代码行数为6000行缺陷数为30个，第3页那么测试缺陷密度=1000×30/6000=5。目标是测试缺陷密度小于1。2.1.4.产品可以通过用户检测，初步让客户满意。可以到达运行基本不出BUG，可以正常使用。2.2.运行环境测试工具：Junit运行工具：Myeclipse，Tomcat数据库：DB2机型操作系统CPU内存AcerAspire4520Window7旗舰版Build7600AMDTurion64X2TL-603GHPCompaq6535sWindow7旗舰版Build7600AMDAthlonX2DualCoreQL-642GThinkpadR400LinuxUbuntu10.10Inter(R)Core(TM)2Duo2GLenove旭日C466MLinuxUbuntu10.04InterPentium双核T23903G2.3.条件与限制首先，本测试计划说明书是一个计划说明书，受限于产品开发人员提交产品测试的内容和时间。根据开发人员提交模块的实际情况，本计划会做出相应修改。§3.计划3.1.测试方案3.1.1测试模型：第4页W型，测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。3.1.2测试方法：黑盒测试，白盒测试，静态测试，动态测试。3.2.测试项目3.2.1.组件功能测试3.2.1.1.易用性：1):确认按钮要支持回车的快捷方式。2）:界面要支持键盘自动浏览按钮功能，即按Tab键、回车键的自动切换功能。3):界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。4):同一界面上的控件数目最好不要太多，最好不要超过10个，多于10个时可以考虑使用分页界面显示。5):默认按钮要支持Enter及选择操作，即按Enter后自动执行默认按钮对应操作。6):可控制项检测到非法输入后应该给出说明并能自动获得焦点。7):Tab键的顺序与控件排列顺序要一致，目前流行总体从上到下，同时行间从左到右的方式。8):界面空间较小时使用下拉框而不用选项框。9):选项数較少时使用选项框，相反使用下拉列表框。3.2.1.2.规范性：1):图标能直观的代表要完成的操作。2):滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。3):菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。3.2.2.业务测试第5页功能测试完成后进行业务测试，业务测试关注的要点是业务流程，及数据流从软件中的一个模块流到另一个模块的过程中的正确性。3.2.3.压力、容量、性能测试3.2.3.1.压力测试说明压力测试根据实际情况包含性能测试，重点模拟客户进行多用户测试。压力测试有一条8：2原则。及百分之八十的业务量在百分之二十的时间内输入。例如:正常每天有100条新数据，测试时在两小时内输入80条数据。3.2.3.2.压力测试方法及标准设计试图对Web服务进行压力测试的压力测试系统时，要让它们以某种特定的方式运行代码。这些风格超越了功能验证，目的是要弄清楚被测试的Web服务是不是不仅能做我们认为它能做的事，而且在被施加了某些高强度压力的情况下仍然继续正常运行。压力测试必须对Web服务应用四个基本条件：1、重复：最明显的且最容易理解的压力条件就是测试的重复。测试的重复就是一遍又一遍地执行个别操作或功能，比如重复调用一个Web服务。功能验证测试可以用来被弄清楚一个操作能否正常执行。而压力测试将确定一个操作能否正常执行，并且能否继续在每次执行时都正常。2、并发：并发是同时执行多个操作的行为。换句话说，就是在同一时间执行多个测试。这个原则不一定适用于所有的产品（比如无状态服务），但是多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码示例才能测出来压力测试需要一次模拟多个客户机来进行测试。3、量级：压力系统应该应用于产品的另一个条件考虑到了每个操作中的负载量。重复执行一个操作，但是操作自身也要尽量给产品增加负担。例如，一个Web服务允许客户机输入一条消息，可以通过模拟输入超长消息的客户机来使这个单独的操作进行高强度的使用。换句话说就是，您增加了这个操作的量级。这个量级总是特定于应用的，但是可以通过查找产品的可被用户计量和修改的值来确定它—例如，数据的大小、延迟的长度、资金数量的转移、输入速度以及输入的变化等等。4、随机变化：任何压力系统都多多少少具有一些随机性。如果随机使用前面的压力原则中介绍的无数变化形式，就能够在每次测试运行时应用许多不同的代码第6页路径。下面是几个关于怎样在测试生命周期内改变测试的示例。使用重复时，在重新启动或重新连接服务之前，您可以改变重复操作间的时间间隔、重复的次数，或者也可以改变被重复的Web服务的顺序。使用并发，您可以改变一起执行的Web服务、同一时间运行的Web服务数目，或者也可以改变关于是运行许多不同的服务还是运行许多同样的实例的决定。量级或许是最容易更改的—每次重复测试时都可以更改应用程序中出现的变量（例如，发送各种大小的消息或数字输入值）。如此反复，是很好的测试情况。3.2.4.认可度和可用性测试认可度和可用性测试，是项目进行验收时的测试。是需求方与开发项目组共同进行业务测试和压力测试等，使得项目能够成功的被需求方验收。3.3.测试机构及人员测试团队：08计11第一开发小组测试流程：测试步骤动作负责人相关记录要求1编译代码王娟、何婷婷成功编译表单确认可测试2审核并测试郭琼、李姣审核编译表单李姣审核3接受测试金欢欢无金欢欢签字编译表单4开始测试褚强、孙超BUG单编写BUG单第7页3.4.测试计划及人员分工测试阶段开始时间完成时间测试人员阶段完成标志测试环境准备2011-06-262011-06-26王娟测试工具安装完毕文档测试2011-06-262011-06-26王娟、何婷婷保证文档有效无误测试策略2011-06-262011-06-26褚强、孙超完成检查表，对文档进行分解执行测试2011-06-262011-06-26王娟、何婷婷保证文档有效无误系统测试2011-06-262011-06-27所有小组人员所有系统测试完毕并进行缺陷反馈设计测试用例2011-06-262011-06-26褚强、孙超、郭琼、金欢欢测试用例覆盖所有功能测试用例review2011-06-262011-06-27郭琼、金欢欢、李姣确定最终的测试用例执行测试2011-06-262011-06-27郭琼、金欢欢、李姣确定系统的完整认可度测试2011-06-272011-06-27王娟、何婷婷系统能满足需求文档编写2011-06-272011-06-27所有小组人员测试总结报告第8页3.4.1测试分工模块名称测试人员需求跟踪王娟、何婷婷数据库维护金欢欢、李姣环境维护郭琼、褚强安全模块褚强、孙超讨论组模块王娟、李姣教务处开设课程模块郭琼、何婷婷教师成绩管理模块金欢欢、孙超用户登录模块褚强、王娟管理员数据管理模块李姣、金欢欢学生成绩查询模块何婷婷、孙超管理员人员管理模块郭琼§4.测试项目说明4.1.测试项目名称及测试内容4.1.1.项目名称：教务管理系统4.1.2.测试内容：4.1.2.1.功能测试1）：登录功能用户是否可以成功登登录是否可以区分不同类别的用户登录第9页错误密码是否可以登录2）：学生模块的查看成绩模块学生是否能看到自己的成绩学生能否越权看到别人的成绩学生是否越权能修改成绩3）：教师的成绩评定教师是否可以评定所教学生成绩教师是否可以越权修改成绩教师是否可以越权评定非自己学生的成绩4）：教务处及管理员人员管理教务处及管理员是否可以添加用户教务处及管理员是否可以删除用户教务处及