- 1、本文档共12页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
软件测试计划说明书
引言
编写目的
本计划是教务管理系统的总体测试计划。目的是说明各种测试阶段任务、人员分配和时间安排、工作规范等。也是为以后的测试设计、测试开发、测试执行、测试评估有所标准。
项目背景
a.本项目的名称为教务管理系统;
b.本项目是由计算机科学与技术学院08计11班郭琼、王娟、何婷婷、李姣、金欢欢、褚强、孙超为了进行软件测试实训而进行开发的。
定义
1.3.1.测试用例中的编号
功能名+界面名(每个字第一个汉语拼音大写)+编号
例如:登录 第一个用例 DL 0001
1.3.2.测试用例文件名命名规则
模块名+测试用例
例如:学生模块 学生测试用例
1.3.3.黑盒测试
黑盒测试也称功能测试,它是通过测试来检测每个功能是否都能正常使用。在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。
1.3.4.白盒测试
白盒测试也称结构测试或逻辑驱动测试,它是按照程序内部的结构测试程序,通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行,检验程序中的每条通路是否都能按预定要求正确工作。 这一方法是把测试对象看作一个打开的盒子,测试人员依据程序内部逻辑结构相关信息,设计或选择测试用例,对程序所有逻辑路径进行测试,通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。
1.3.5.静态测试
静态方法是指不运行被测程序本身,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析,找出欠缺和可疑之处,例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错,并为测试用例选取提供指导
1.3.6.动态测试
动态方法是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率和健壮性等性能,这种方法由三部分组成:构造测试实例、执行程序、分析程序的输出结果。
1.3.7. 组件功能测试
组建功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。
1.3.8.业务测试
业务测试,在单元测试的基础上,将所有业务流程的模块按照设计要求(如根据结构图〕组装成为子系统或系统,进行测试。
1.3.9.压力、容量、性能测试
就是将业务测试完后的系统进行进一步的业务流程测试,例如:在线人数和系统反应时间的测试。
1.3.10. 认可度和可用性测试
认可度和可用性测试 ,系统开发生命周期方法论的一个阶段,这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。
1.3.11.DRE
Defect Removal Efficiency,通过复审、检查和测试消除掉的缺陷的百分比。是应用于软件开发生命周期过程中不同类型的缺陷的重要评价方法。通过缺陷消除有效性评估,可以帮助我们选择那些测试种类在什么时候执行会更加有效。对于测试阶段的缺陷清除率,可以近似等于:
DRE= 在开发过程中缺陷被解决的数目
(Defects removed during a development phase?) X100% 在该阶段缺陷潜伏的数目
(Defects latent in the product at that phase)
参考资料
参考资料名称 作者 《教务管理系统软件需求说明书》 王娟 《教务管理系统软件概要设计说明书》 郭琼、李姣 《教务管理系统软件详细设计说明书》 金欢欢、何婷婷 《教务管理系统数据库设计说明书》 褚强、孙超
任务概述
目标
2.1.1.测试当前版本的产品是否达到设计阶段的的要求.
包括:各个功能点是否以实现,业务流程是否正确。
2.1.2.产品规定的操作和运行稳定。
例如:进行一些评判学生成绩的数据库操作时,数据库会不会正常运行。
2.1.3.Bug数和缺陷率控制在可接收的范围之内。
例如:估计总代码行数为6000行 缺陷数为30个,
那么测试缺陷密度 = 1000 × 30 / 6000 = 5。
目标是测试缺陷密度小于1。
2.1.4.产品可以通过用户检测,初步让客户满意。
可以到达运行基本不出BUG,可以正常使用。
运行环境
测试工具:Junit
运行工具:Myecl
文档评论(0)