软件测试规程标准Word文档格式.docx
《软件测试规程标准Word文档格式.docx》由会员分享，可在线阅读，更多相关《软件测试规程标准Word文档格式.docx（27页珍藏版）》请在冰点文库上搜索。
3.6升级测试用例 15
3.6.1升级用例 15
3.7压力测试 15
3.7.1 压力测试用例 15
3.8 增、改、删、查询常用用例 16
3.8.1新增用例 16
3.8.2修改用例 16
3.8.3删除用例 16
3.8.4查询用例 17
3.9 用例的审批意见表 17
3.9.1 审批表 17
附录2.3：
系统测试报告 18
附录2.4：
缺陷管理报告 19
1. bug状态 19
2. bug提交表 19
3. bug统计表 19
4. 缺陷管理流程 20
附录2.5测试分析报告 错误！
未定义书签。
22
一.概述
本规范是对项目软件测试的一份指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程以及软件产品开发单位所承担的职责进行总体规范，以有效保证软件产品的质量。
二.软件测试理论
1 .什么是软件测试
无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。
在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺，因此，在软件生命周期的每个阶段都不可避免地会产生差错。
我们力求在每个阶段结束之前通过严格的技术审查，尽可能早地发现并纠正差错；
但是，经验表明审查并不能发现所有差错，此外在编码过程中还不可避免地会引入新的错误。
如果在软件投入生产性运行之前，没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果。
测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。
目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。
软件测试在软件生命周期中横跨两个阶段。
通常在编写出每个模块之后就对它做必要的测试（称为单元测试），模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。
在这个阶段结束之后，对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项工作。
2 .系统测试的简介
系统测试（SystemTest,ST）是将经过测试的子系统装配成一个完整系统来测试。
它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。
测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
系统测试过程域是SPP模型的重要组成部分。
本规范阐述了系统测试的规程，该规程的“目的"
、“角色与职责”、“启动准则”、“输入”、“输出”、“主要步骤”、“完成准则”和“度量”、“产品发布准则”均已定义。
本规范适用于国内IT企业的软件研发与测试项目。
建议用户根据自身情况（如商业目标、研发实力等）适当地进行修改本规范，以推广使用。
三.软件测试流程
1.软件测试流程图
系统测试流程如图1・1所示。
由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计，所以当产品需求和系统设计文档完成之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，而不必等到“实现与测试”阶段结束如图1・2所示。
这样可以提高系统测试的效率。
（图1-1）
（图1-2）
2.系统测试细则
项目经理设法组建富有成效的系统测试小组。
系统测试小组的成员主要来源于：
◊机构独立的测试小组（如果存在的话）。
◊邀请其它项目的开发人员参与系统测试。
◊本项目的部分开发人员。
◊机构的质量保证人员。
系统测试小组应当根据当前项目的特征确定测试内容。
一般地，系统测试的主要内容包括：
•功能测试。
即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。
由于正确性是软件最重要的质量因素，所以功能测试必不可少。
•健壮性测试。
即测试软件系统在异常情况下能否正常运行的能力。
健壮性有两层含义：
一是容错能力，二是恢复能力。
•性能测试。
即测试软件系统处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考。
•安全测试。
即检查系统对非法侵入的防范能力。
安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。
•用户界面测试。
重点是测试软件系统的易用性和视觉效果等。
•安装与反安装测试。
对软件的全部、部分或升级安装与反安装处理过程的测试。
系统测试过程域产生的主要文档有：
◊ 《系统测试计划》，模板见 ［附录2.1］。
◊ 《系统测试用例》，模板见 ［附录2.2］。
◊ 《系统测试报告》，模板见 ［附录2.3］。
◊ 《缺陷管理报告》，模板见 ［附录2.4］。
3 •系统测试注意事项
根据《软件开发规范》仔细检查软件的界面是否合乎要求。
（每一个子界面也应如此）其中，应注意提示信息和软件开发商信息是否正确。
小的图标是否合乎要求。
检查菜单当中的各项功能和功能按钮是否能正确使用。
根据《软件开发规范》和《用户需求》及《软件详细设计》设计测试用例。
（以边界值法、等价类划分法为主）。
对功能界面要求注意与功能相关的信息显示及显示位置是否正确。
数据输入界面应注意文字格式及数字和文字的区别。
是否能够正确保存信息。
数据查询（显示）界面应注意显示信息是否正确和完整。
是否能正确查询。
对打印功能要求注意打印出的报表是否正确。
（包括报表各项信息、数据信息和报表字体等）。
这一项测试主要是对软件的错误处理功能进行测试。
就是进行错误的操作或输入错误的数据，检杏软件对这些情况是否能做出判断并予以提示。
特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
对测试错误结果一定要有一个确认的过程。
一般有A测试出来的错误，一定要有一个B来确认,严重的错误可以召开评审会进行讨论和分析。
制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
"
I归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。
妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
四.系统测试规程
软件系统测试的基本规程由下述几个步骤组成：
1. 目的
对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
2. 角色与职责
• 项目经理组建系统测试小组，并指定一名成员任测试组长。
• 系统测试小组各成员共同制定测试计划、设计测试用例、执行测试，并撰写相应的文档。
测试组长管理上述事务。
• 开发人员及时解决测试人员发现的缺陷。
3. 启动准则
• 产品需求和系统设计文档完成之后。
4. 输入
• 产品需求和系统设计文档
5. 主要步骤
［Stepl］制定系统测试计划
系统测试小组各成员共同协商测试计划。
测试组长按照指定的模板起草《系统测试计划》。
该计划主要包括：
•测试范围（内容）
•测试方法
•测试环境与辅助工具
•测试完成准则
•人员与任务表
项目经理审批《系统测试计划》。
该计划被批准后，转向EStep2］o
［Step2］设计系统测试用例
•系统测试小组各成员依据《系统测试计划》和指定的模板，设计（撰写）《系统测试用例》0
•测试组长邀请开发人员和同行专家，对《系统测试用例》进行技术评审。
该测
试用例通过技术评审后，转向［Step3］o
［Step3］执行系统测试
•系统测试小组各成员依据《系统测试计划》和《系统测试用例》执行系统测试。
•将测试结果记录在《系统测试报告》中，用“缺陷管理工具”来管理所发现的缺陷，并及时通报给开发人员。
［Step4］缺陷管理与改错
•从［Stepl］至［Step3］,任何人发现软件系统中的缺陷时都必须使用指定的“缺陷管理工具”。
该工具将记录所有缺陷的状态信息，并可以自动产生《缺陷管理报告》。
•开发人员及时•消除已经发现的缺陷。
•开发人员消除缺陷之后应当马上进行回归测试，以确保不会引入新的缺陷。
6. 输出
• 消除了缺陷的最终软件系统
• 系统测试用例
• 系统测试报告
• 缺陷管理报告
7. 结束准则
• 对于非严格系统可以采用“基于测试用例”的准则：
◊ 功能性测试用例通过率达到100%;
◊非功能性测试用例通过率达到80%时。
• 对于严格系统，应当补充“基于缺陷密度”的规则：
◊ 相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m0例如n大于10,m小于等于1。
• 木规程所有文档已经完成。
8. 度量
测试人员和开发人员统计测试和改错的工作量、文档的规模、以及缺陷的个数与类型，并将此度量数据汇报给项目经理,也就是《系统测试报告》。
1）测试度量类型：
A：
项目度量：
规模、测试工作量、测试进度、测试生产率
B：
质量度量：
缺陷率（阶段）、缺陷排除率、可靠性等
2） 测试用例设计阶段的度量
规模：
测试方案数量、测试用例数量、测试工具设计数景、测试用例/人月
工作量：
文档的草稿编写工作量、评审前阅读工作量、评审工作量、修改工作量
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%
暂不作要求
以上比例为错误占总测试模块的比例。
软件产品未经测试合格，不允许出公司。
系统测试计划
1.测试范围与内容
系统测试小组应当根据项目的特征确定测试范围与内容。
一般的，系统测试一般分为：
功能测试、用户界面测试、安全性测试、安装与反安装测试等。
2.测试方法
黑盒测试（Black-boxtesting）：
黑盒测试是以用户的观点，从输入数据与输出数据的对应关系出发进行测试的，它不涉及到程序的内部结构。
很明显，如果外部特性本身有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。
黑盒测试法注重于测试软件的功能需求，主要试图发现几类错误：
功能不对或遗漏、界面错误、数据结构或外部数据库访问错误、性能错误、初始化和终止错误。
3.测试环境与测试辅助工具
测试环境
测试》
溉资源
资源名称/类型
配置及数量
测试辅助工具
工具中英文名称
标识号
产商/自产
版本
4.测试完成准则
1.计划的测试用例己全部执行。
2. 经确定的所有缺陷都已得到了商定的解决结果。
3. 所计划的测试用例已全部重新执行，已知的所有缺陷都已按照商定的方式进行了处理，而且没有发现新的缺陷。
对于非严格系统可以采用“基于测试用例”的准则：
（1） 功能性测试用例通过率达到100%；
（2） 非功能性测试用例通过率达到95%时。
对于严格系统，应当补充“基于缺陷密度”的规则：
（3） 相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m。
例如n大于10,m小于等于1。
5.人员与任务表
人员安排与任务表
角色
姓名
任务安排与职责
时间
测试经理
测试设计员
测试员
6.缺陷管理与改错计划
见：
缺陷管理报告
7.测试计划审批意见表
项目经理审批意见：
审批是否通过：
签名：
日期：
附录2-2：
系统测试用例
1-文档介绍
1.1文档目的
1.2文档范围
1.3读者对象
1.4参考文献
提示：
列出本文档的所有参考文献（可以是非正式出版物），格式如下:
［标识符］作者，文献名称，出版单位（或归属单位），日期例如：
［AAA］作者，《立项建议书》，机构名称，日期
1.5术语与缩写解释
缩写、术语
解释
spp
精简并行过程，SimplifiedParallelProcess
2.测试需求分析
2.1被测试对象的介绍
2.2测试范围与目的
2.3测试环境与测试辅助工具的描述
3.测试用例
3.1功能测试用例
3.1.1功能A/B描述
用例编号
001/002
功能描述
用例目的
前提条件
字段名称
输入/动作
期望输出
实际输出
典型值
边界值
异常值
3.2性能测试用例
3.2.1性能用例A/B描述
001
性能A描述
特殊的规程说明
用例间的信赖关系
回归测试
典型值…
边界值…
异常值…
002
性能B描述
3.3安全性测试
试用例
3.3.1安全用例A/B描述
安全描述
覆盖单元
假想目标
非法入侵手段
是否实现目标
代价■■利益分析
3.4界面测试用例
易用性规范性帮助设施合理性美观与协调性 快捷方式的组合
菜单位置安全性考虑界面的友好性独特性多窗口的应用与系统资源
3.4.2界面测试用例
界面描述
界面风格一致性
色彩与字体
窗口的风格
布局与间距
文本框的正确性
必填项
字段长度
格式较验
日期格式
用户界面的行为
鼠标
光标定位
Tab键
3.5安装与反安装测试
安装/卸载测试
1.安装/卸载程序能正确运行
2. 程序安装/卸载正确
3. 程序安装/卸载后能正确运行
4. 完善性安装/卸载后程序能正确运行
3.5.1反装与反安装测试用例
配置说明
安装选项
安装情况描述
使用难易程度
全部
部分
升级
其他
卸载选项
卸载性况描述
修复
3.6升级测试用例
1. 基本功能测试查看系统的基本功能是否能在新的版本中应用，且不会产生数据错误
2.文档测试 文档测试主要是验证相关的文档信息在新的版本中的完整性
3. 数据库测试 对系统升级时是否会对数据库的影响
3.6.1升级用例
用例描述
基本功能
文档
数据库
3.7压力测试
3.7.1压力测试用例
功能模块名称A
运行时间
并发用户数与事务执行情况
并发用户数
事务平均响应时间（s）
事务成功率
每秒点击率
例如50个用户
例如8。
个用户
并发用户数与数据库主机
CPU利用率
AvailableMbytes
磁盘I/O
其它
例如80个用户
并发用户数与应用服务器的关系表
ProcessorQueueLength
3.8增、改、删、查询常用用例
3.8.1新增用例
新增描述
新增按钮的可用性
页面字段与需求的一致
查询新增的数据
字段的检查
非法数据
编辑数据
空数据
重复数据
3.8.2修改用仞
修改描述
修改按钮的可用性
数据是否会丢失
是否可保存
数据的完整性
3.8.3删除用伊
删除描述
删除按钮的可用性
删除一条记录
删除多条记录
删除全部数据
点删除是否数据库中也一并删除
删除后是否可添加同样的数据记录
3.8.4查询用例
查询描述
查询页面字段与需求一致
查询按扭的正确性
单条查询
条件查询
组合查询
模糊查询
错误查询
3.9用例的审批意见表
测试组长邀请开发人员和同行专家，对《系统测试用例》进行技术评审。
3.9.1审批表
审批意见：
附录2-3：
系统测试报告
测试报告
编号:
测试人
审定人
软件名称
编号/版本
测试阶段
测试用例
测试结果（月
亳点描述异常、错误情况）：
错误类别：
致命性错误（）功能性错误（）建议性错误（）
测试结果分析与建议：
修改情况描述：
修改人：
时间：
说明与备注：
附录2-4：
1.bug状态
新信息（New）:
测试中新报告的软件缺陷；
打开（Reopen）：
bug未解决，重新分配给相关开发人员处理;
修正（Fixed）：
开发人员已完成修正，等待测试人员验证；
拒绝（Declined）：
拒绝修改缺陷；
延期（Deferred）：
不在当前版本修复的错误，下一版修复；
关闭（Closed）：
错误已被修复；
2.bug提交表
项目名称
版本号
缺陷编号
当前状态
缺陷类型
严
重
性
优先级
缺陷环境描述
创建时间
完成时间
所属模块
提交人
接收者
对应
需
求
复核测试
解决时间
备注
3.bug统计表
被测对象
总数
致命
严重
一般
建议
缺陷率/用例质量
功能
测试
设计
代码
需求
升级会员 