软件测试规程标准文档格式.docx
- 文档编号:14324105
- 上传时间:2022-10-22
- 格式:DOCX
- 页数:22
- 大小:42.29KB
软件测试规程标准文档格式.docx
《软件测试规程标准文档格式.docx》由会员分享,可在线阅读,更多相关《软件测试规程标准文档格式.docx(22页珍藏版)》请在冰豆网上搜索。
本规范适用于国内IT企业的软件研发与测试项目。
建议用户根据自身情况(如商业目标、研发实力等)适当地进行修改本规范,以推广使用。
三.软件测试流程
1.软件测试流程图
系统测试流程如图1-1所示。
由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计,所以当产品需求和系统设计文档完成之后,系统测试小组就可以提前开始制定测试计划和设计测试用例,而不必等到“实现与测试”阶段结束如图1-2所示。
这样可以提高系统测试的效率。
(图1-1)
(图1-2)
2.系统测试细则
项目经理设法组建富有成效的系统测试小组。
系统测试小组的成员主要来源于:
✧机构独立的测试小组(如果存在的话)。
✧邀请其它项目的开发人员参与系统测试。
✧本项目的部分开发人员。
✧机构的质量保证人员。
系统测试小组应当根据当前项目的特征确定测试内容。
一般地,系统测试的主要内容包括:
·
功能测试。
即测试软件系统的功能是否正确,其依据是需求文档,如《产品需求规格说明书》。
由于正确性是软件最重要的质量因素,所以功能测试必不可少。
健壮性测试。
即测试软件系统在异常情况下能否正常运行的能力。
健壮性有两层含义:
一是容错能力,二是恢复能力。
·
性能测试。
即测试软件系统处理事务的速度,一是为了检验性能是否符合需求,二是为了得到某些性能数据供人们参考。
安全测试。
即检查系统对非法侵入的防范能力。
安全测试期间,测试人员假扮非法入侵者,采用各种办法试图突破防线。
用户界面测试。
重点是测试软件系统的易用性和视觉效果等。
安装与反安装测试。
对软件的全部、部分或升级安装与反安装处理过程的测试。
系统测试过程域产生的主要文档有:
✧《系统测试计划》,模板见 [附录2-1]。
✧《系统测试用例》,模板见 [附录2-2]。
✧《系统测试报告》,模板见 [附录2-3]。
✧《缺陷管理报告》,模板见 [附录2-4]。
3.系统测试注意事项
根据《软件开发规范》仔细检查软件的界面是否合乎要求。
(每一个子界面也应如此)其中,应注意提示信息和软件开发商信息是否正确。
小的图标是否合乎要求。
检查菜单当中的各项功能和功能按钮是否能正确使用。
根据《软件开发规范》和《用户需求》及《软件详细设计》设计测试用例。
(以边界值法、等价类划分法为主)。
对功能界面要求注意与功能相关的信息显示及显示位置是否正确。
数据输入界面应注意文字格式及数字和文字的区别。
是否能够正确保存信息。
数据查询(显示)界面应注意显示信息是否正确和完整。
是否能正确查询。
对打印功能要求注意打印出的报表是否正确。
(包括报表各项信息、数据信息和报表字体等)。
这一项测试主要是对软件的错误处理功能进行测试。
就是进行错误的操作或输入错误的数据,检查软件对这些情况是否能做出判断并予以提示。
特殊情况下要制造极端状态和意外状态,比如网络异常中断、电源断电等情况。
一定要注意测试中的错误集中发生现象,这和程序员的编程水平和习惯有很大的关系。
对测试错误结果一定要有一个确认的过程。
一般有A测试出来的错误,一定要有一个B来确认,严重的错误可以召开评审会进行讨论和分析。
制定严格的测试计划,并把测试时间安排得尽量宽松,不要希望在极短的时间内完成一个高水平的测试。
回归测试的关联性一定要引起充分的注意,修改一个错误而引起更多错误出现的现象并不少见。
妥善保存一切测试过程文档,意义是不言而喻的,测试的重现性往往要靠测试文档。
四.系统测试规程
软件系统测试的基本规程由下述几个步骤组成:
1.目的
对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。
2.角色与职责
●项目经理组建系统测试小组,并指定一名成员任测试组长。
●系统测试小组各成员共同制定测试计划、设计测试用例、执行测试,并撰写相应的文档。
测试组长管理上述事务。
●开发人员及时解决测试人员发现的缺陷。
3.启动准则
●产品需求和系统设计文档完成之后。
4.输入
●产品需求和系统设计文档
5.主要步骤
[Step1]制定系统测试计划
系统测试小组各成员共同协商测试计划。
测试组长按照指定的模板起 草《系统测试计划》。
该计划主要包括:
·
测试范围(内容)
测试方法
测试环境与辅助工具
测试完成准则
人员与任务表
项目经理审批《系统测试计划》。
该计划被批准后,转向[Step2]。
[Step2]设计系统测试用例
系统测试小组各成员依据《系统测试计划》和指定的模板,设计(撰写)《系统测试用例》。
测试组长邀请开发人员和同行专家,对《系统测试用例》进行技术评审。
该测试用例通过技术评审后,转向[Step3]。
[Step3]执行系统测试
系统测试小组各成员依据《系统测试计划》和《系统测试用例》执行系统测试。
将测试结果记录在《系统测试报告》中,用“缺陷管理工具”来管理所发现的缺陷,并及时通报给开发人员。
[Step4]缺陷管理与改错
从[Step1]至[Step3],任何人发现软件系统中的缺陷时都必须使用指定的“缺陷管理工具”。
该工具将记录所有缺陷的状态信息,并可以自动产生《缺陷管理报告》。
开发人员及时消除已经发现的缺陷。
开发人员消除缺陷之后应当马上进行回归测试,以确保不会引入新的缺陷。
6.输出
●消除了缺陷的最终软件系统
●系统测试用例
●系统测试报告
●缺陷管理报告
7.结束准则
●对于非严格系统可以采用“基于测试用例”的准则:
✧功能性测试用例通过率达到100%;
✧非功能性测试用例通过率达到80%时。
●对于严格系统,应当补充“基于缺陷密度”的规则:
✧相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m。
例如n大于10,m小于等于1。
●本规程所有文档已经完成。
8.度量
测试人员和开发人员统计测试和改错的工作量、文档的规模、以及缺陷的个数与类型,并将此度量数据汇报给项目经理,也就是《系统测试报告》。
1)测试度量类型:
A:
项目度量:
规模、测试工作量、测试进度、测试生产率
B:
质量度量:
缺陷率(阶段)、缺陷排除率、可靠性等
2)测试用例设计阶段的度量
A:
规模:
测试方案数量、测试用例数量、测试工具设计数量、测试用例/人月
B:
工作量:
文档的草稿编写工作量、评审前阅读工作量、评审工作量、修改工作量
C:
进度:
每件具体工作的计划开始结束时间、实际开始结束时间、计划工时数、实际工时数、计划完成率
D:
缺陷:
评审过程中出现的错误数量、缺陷数量,级别
3)测试执行阶段的度量:
1测试用例执行率 2 测试用例通过率
3测试用例问题发现率 4BUG数量
5BUG级别统计 6BUG分布统计(模块)
7BUG分布统计(阶段) 8BUG密度
9.产品发布准则
测试完毕,整理产品发布包和相关文档并发布。
对于新产品来说,必要的文档必须包括:
(1)
安装操作手册
(2)
产品说明书
(3)
管理维护手册
(4)
用户操作手册
(5)
测试报告
五.测试错误类型
本规范定义以下五类测试错误类型。
A类—严重错误,包括以下各种错误:
由于程序所引起的死机,非法退出
死循环
数据库发生死锁
因错误操作导致的程序中断
功能错误
与数据库连接错误
数据通讯错误
B类—较严重错误,包括以下各种错误:
程序错误
程序接口错误
数据库的表、业务规则、缺省值未加完整性等约束条件
C类—一般性错误,包括以下各种错误:
操作界面错误(包括数据窗口内列名定义、含义是否一致)
打印内容、格式错误
简单的输入限制未放在前台进行控制
删除操作未给出提示
数据库表中有过多的空字段
D类—较小错误,包括以下各种错误:
界面不规范
辅助说明描述不清楚
输入输出不规范
长操作未给用户提示
提示窗口文字未采用行业术语
可输入区域和只读区域没有明显的区分标志
E类—测试建议
六.测试标准
黑盒测试的通过准则一般有:
单元功能同设计需求一致;
规定的路径覆盖率及覆盖类达到要求,且单元执行正确;
所规定的黑盒测试手段被使用,且单元执行正确;
对残留错误有合法解释或被认可暂留;
虽然路径覆盖率不能达到,但其他各测试的错误查出率趋产0或稳定(时间的长短视情况而定)。
各类软件测试合格须符合以下标准。
A类错误
B类错误
C类错误
D类错误
E类建议
无
<
1%
5%
暂不作要求
以上比例为错误占总测试模块的比例。
软件产品未经测试合格,不允许出公司。
附录2-1:
系统测试计划
1.测试范围与内容
系统测试小组应当根据项目的特征确定测试范围与内容。
一般的,系统测试一般分为:
功能测试、用户界面测试、安全性测试、安装与反安装测试等。
2.测试方法
黑盒测试(Black-boxtesting):
黑盒测试是以用户的观点,从输入数据与输出数据的对应关系出发进行测试的,它不涉及到程序的内部结构。
很明显,如果外部特性本身有问题或规格说明的规定有误,用黑盒测试方法是发现不了的。
黑盒测试法注重于测试软件的功能需求,主要试图发现几类错误:
功能不对或遗漏、界面错误、数据结构
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 规程 标准