收藏 分销(赏)

软件测试规范模板.doc

上传人:天**** 文档编号:4560147 上传时间:2024-09-29 格式:DOC 页数:22 大小:150.54KB
下载 相关 举报
软件测试规范模板.doc_第1页
第1页 / 共22页
软件测试规范模板.doc_第2页
第2页 / 共22页
软件测试规范模板.doc_第3页
第3页 / 共22页
软件测试规范模板.doc_第4页
第4页 / 共22页
软件测试规范模板.doc_第5页
第5页 / 共22页
点击查看更多>>
资源描述

1、软件测试标准规范1 目标为了确保软件产品质量, 使产品能够顺利交付和经过验收, 特编写本文档, 以作参考2 适用范围本文档适适用于项目开发过程中单元测试、 集成测试、 系统测试、 业务测试、 验收测试以及一些专题测试。3 职责 项目测试责任人组织编制测试计划、 测试方案, 指导和督促测试人员完成各阶段测试工作。 项目组测试人员按照测试计划、 测试方案完成所负担测试任务, 并按要求填写问题汇报及维护统计。 测试经理依照确认规程和准则对工作产品进行确认, 提出对确认规程和准则修改意见 项目责任人组织测试环境建立。 项目经理审核负责控制整个项目标时间和质量。 研发人员确认修改测试人员提交bug。4

2、工作流程4.1 测试依据详细设计是模块测试依据。所以设计人员应向测试人员提供系统需求规格书名书、 详细设计、 概要设计等关于资料。测试人员必须认真阅读, 真正弄懂系统需求和详细设计。4.2 制订测试方案在测试之前, 由项目责任人依照测试计划要求, 组织人员编制对应测试方案, 测试方案应包含以下内容: 测试目标; 所需人员及对应培训要求; 测试环境、 工具和测试软件; 测试用例、 测试数据和预期结果。4.3 单元测试项目开发实现过程中, 每个程序单元( 程序单元划分视详细开发工具而定, 通常定为函数或子程序级) 编码调试经过后, 要及时进行单元测试。单元测试由单元开发者自己进行, 使用白盒测试方

3、法, 依照程序单元控制流程, 争取达成分支覆盖。对于交互式运行产品, 不便于进行自动测试, 能够采取功效测试方法进行。单元测试针对程序模块, 从程序内部结构出发设计测试用例。多个模块能够独立进行单元测试。 单元测试内容包含模块接口测试、 局部数据结构测试、 路径测试、 错误处理测试等; 单元测试组织标准一遍依照开发进度安排对已开发完成单一模块进行测试; 单元测试停顿标准: 完成了全部要求单元测试, 单元测试中发觉bug已经得到修改。4.4 集成测试 编码开发完成, 项目组内部应进行组装测试。集成测试由项目责任人组织策划( 编写测试计划、 测试用例) 并实施。集成测试着重对各功效模块之间接口进行

4、测试, 验证各功效模块是否能协调工作、 参数传递及功效调用是否正常。测试采取交叉方法, 即个人开发软件应由其它项目组组员进行测试。集成测试过程应填写问题汇报及维护统计, 测试结果应形成测试汇报。4.5 系统测试在项目开发完成之后, 应对整个系统软件和硬件进行系统测试。对性能、 可靠性、 健壮性、 压力承受力等方面分别进行评价, 以验证系统是否满足要求需要。系统测试由测试责任人组织策划( 编写测试计划、 测试用例) 并实施, 系统测试过程应形成问题汇报及维护统计。系统测试通常进行以下几个情况测试: 正常情况 非正常情况 破坏性测试 边界情况 非法情况 强度测试 性能测试 兼容性测试 用户友好性测

5、试界面设计规范测试: 光标初始位置 字体是否统一 字号是否符合要求 标题颜色 按钮名称是否规范 界面布局是否合理, 整体效果怎样输入值测试: 数据类型 数据长度 约束条件是否满足, 是否完整 TAB和Enter键是否起作用 键盘操作能否全部代替鼠标操作 输入( 光标) 是否按照次序前进按钮测试: 将按钮放开和封闭是否严格、 准确, 不能使用按钮必须封闭 检验”退出”、 ”取消”等具备共性按钮功效异常情况测试: 在完成正常功效测试后, 安正常处理相同操作次序, 执行与正常处理不一样动作比如 正常处理中要求输入日期字段, 这时输入字符或数字 正常处理中输入字段有范围要求, 这时输入超出范围值 正常

6、处理中用两个值限定范围, 这时用一个值或不限定 正常处理中要求用”Tab”键, 这时安”Enter”键或其它键 正常处理中单项选择框、 多项选择框、 下拉框等, 十一偶那个非指定键操作 使用不一样于指定按钮操作4.6 业务测试在组装测试与系统测试结束后, 均可由最终用户或测试人员对系统进行测试。业务测试着重测试业务流程, 功效、 用户界面等方面。项目、 测试责任人负责组织相关人员制订测试方案和测试用例, 并进行测试。测试结果应形成问题汇报及维护统计。4.7 验收测试4.7.1 验收测试条件 按照项目计划要求验收测试进度安排进行测试准备 在验收测试前, 各项内部测试活动都受到监控并争取执行4.7

7、.2 交付版本要求 按照集成测试用例完成了整个系统集成测试 集成版本满足设计定义各项功效、 性能要求 提交数据库脚本样本需要完整, 没有冗余数据 在集成测试中发觉bug已经得到处理, 各级缺点修改率达成标准 软件需求分析说明书中定义全部功效都已经实现, 性能指标全部达成性能需求指标 提交阶段性测试汇报, 包含功效和性能测试汇报 全部文档齐备完整4.7.3 版本公布准则 软件产品经过了单元测试、 集成测试、 业务测试、 系统测试、 性能测试 测试部提交文档: 测试计划、 测试方案、 测试用例、 测试分析汇报 全部测试项必须符合以下标准n 致命错误: 无n 功效错误: 无n 功效缺点: 项目经理、

8、 技术经理、 测试责任人审核经过n 界面缺点: 项目经理、 技术经理、 测试责任人审核经过n 提议: 项目经理、 技术经理、 测试责任人审核经过 以上几项其中之一不满足要求, 视为不合格在产品交付和用户验收之前, 经过验收测试来确认在要求使用环境下整个产品运行情况是否满足要求要求。在产品交付之前, 由指定验收责任人组织制订测试方案和测试用例, 主持验收。验收测试过程应形成问题汇报及维护统计。4.8 用户现场测试将软件布署到用户实际生产环境后, 因为环境差异, 需要在用户现场进行确认测试, 确保系统功效、 性能完备, 可正常运行。测试内容: 依照软件系统规模, 准备现场测试用例, 涵盖全部主要功

9、效点, 若规模小, 需要将全部功效点全部测试一遍 对于后台已定义好工作流、 功效栏目路径以及用户信息等数据, 不可进行修改和删除操作, 新增测试数据也需要在测试完成后给予清楚 重点检验上传、 下载数据是否能够正常打开或保留 确认界面美观, 基本信息和链接无错误 考虑用户实际软件环境和网络环境, 以客户端最为复杂软硬件环境作为测试机器, 检验有没有异常情况出现 针对前期发觉bug进行回归测试, 以确保公布版本为最新版本4.9 编写测试文档4.9.1 测试点将测试模块分解成多个功效点, 测试点应涵盖功效点, 也涵盖了正常测试和异常测试。4.9.2 输入数据 输入数据包含界面输入数据、 数据库初始数

10、据及其它外部输入数据。尤其是数据库初始所需属性一一列出, 全方面是指: 数据能达成模块所包括全部功效, 经典是指这个数据能充分反应功效特点。4.9.3 测试描述 描述测试步骤, 包含: 操作员所执行动作( 包含鼠标、 键盘、 加载外部数据等操作) ; 系统反应, 包含: 光标定位、 光标聚焦、 显示字段值、 按钮封闭和放开、 功效键封闭和放开、 系统提醒和系统消息等。4.9.4 预期输出数据 按准备输入数据和设计要求处理过程, 模块应输出数据。 输出数据包含: 屏幕输出数据、 输出到数据库数据、 输出到其它外部介质上数据, 并指出断点结果或最终止果。4.9.5 实际输出 填写本测试点程序运行后

11、实际输出。4.9.6 正确是否 程序运行后, 实际输出结果和预期输出结果一致时, 为正常, 不然为不正常。4.9.7 测试结论 填写此次测试结论, 是合格或不合格。若不合格时, 应总结存在问题, 能够让修改者一目了然。5 缺点管理5.1 缺点定义及其基本属性缺点是指在软件开发过程中针对软件产品和开发过程中问题, 这些问题已经影响或可能会影响软件产品质量。缺点应该具备以下属性, 也就是往缺点管理库或者缺点列表中提交缺点应该具备以下属性: 属性名称描述缺点标识标识某个缺点一组符号, 每个缺点必须有一个唯一标识缺点类型依照缺点自然属性划分缺点种类缺点验证程度因缺点引发故障对软件产品影响程度缺点所处模

12、块或子系统缺点分步模块或子系统缺点出现几率指发觉错误几率缺点重现步骤详细缺点重现步骤附件与缺点相关附件( 截图、 附件、 用例等) 备注对缺点其它描述5.2 缺点分类依照缺点定义, 将缺点分为以以下: 文档缺点: 是指对文档静态检验过程中发觉缺点。检验活动包含同行评审、 产品审计等。评审缺点要依照被评审对象类型来确定, 被评审对象包含最终出产物和中间过程产出物, 比如需求文档、 设计文档、 计划、 汇报、 用例等 代码缺点: 是指对代码进行同行评审、 审计或代码走查过程中发觉缺点 测试缺点: 是指由测试活动发觉测试对象( 被测对象通常是指可运行代码、 系统, 不包含静态测试发觉问题) 缺点,

13、测试活动包含单元测试、 集成测试、 系统测试、 性能测试等 过程缺点: 有称为不符合项问题, 是指经过过程审计、 过程分析、 管理评审、 质量评定、 质量审核等活动发觉关于过程缺点和问题。过程缺点发觉者通常是测试人员、 项目经理等5.3 文档缺点分类 缺点分类描述描述不完整文档内容缺失, 或文档应该包含范围没有涵盖不一致一致性问题有两类: 一是与源头说明书不一致, 比如需求和客户业务需求不一致、 设计与需求不一致等二是上下文或者与前提不一致描述错误文档描述是错误, 不可实现或造成错误输出或结果功效问题该缺点将会造成用户功效错误、 不满足、 不可用不清楚或有歧义内容描述不清楚、 不能准确表示、

14、或表示意思有歧义逻辑错误内容组织逻辑不清楚、 逻辑错误接口问题与最终用户接口问题、 与外部系统接口问题、 内部子系统或模块接口问题输入输出问题输入输出不完整、 不正确、 不可测试或验证不细化内容还需要深入细化性能问题文档设计或实现方式存在性能问题安全性问题文档设计或实现方式存在安全性问题5.4 代码缺点分类缺点分类描述常量变量定义问题不满足设计或需求编写代码不符合规范条件判断处理循环处理错误异常处理算法逻辑问题注释问题代码冗余性能问题5.5 系统测试缺点分类缺点类型描述功效错误影响了主要特征、 用户界面、 产品接口或全局数据结构, 而且设计文档需要争取变更。如逻辑、 循环、 递归、 功效等缺点

15、结构错误Web应用程序结构化页面无法显示, 或者显示错误脚本错误Web应用程序当中出现脚本错误, 包含客户端对数据进行校验和运算各种情况下产生错误页面链接错误Web应用程序页面出现空链接、 错误链接、 死链接页面文字错误Web应用程序页面出现中外文拼写、 使用、 以及不一样语种页面编码错误页面图形错误Web应用程序页面出现图片内容使用不妥, 或者无法显示ALT错误Web应用程序页面当中超文本标识语言、 文本标签解释错误排版错误Web应用程序页面排版不符合要求或者不符合使用习惯业务逻辑不合理应用程序实现流程和要求业务流程不一致, 或者实现流程无法正确完成。包含流程数据部分并行、 争用、 同时等操

16、作, 引发流程断裂、 死锁、 以及其它异常情况业务逻辑不方便应用程序实现流程在实际情况下即使能够完成, 可是存在无须要重复、 等候、 冗余等影响使用效率情况其它错误其它未分类错误提议系统改进提议5.6 缺点等级定义缺点严重程度对以上所述缺点类型都是适合, 缺点严重程度反应是对缺点发觉对象可能造成影响或后果来定义。缺点等级缺点性质系统中对应错误分类描述一级致命错误系统瓦解系统死锁造成对被描述主要对象了解错误、 不可行、 不可运转、 对业务和整个系统造成重大损失或损害; 对使用、 维护或保管人员有危险或不安全, 以及对产品基本功效有致命影响缺点二级严重缺点严重错误对被描述部分对象了解或实现错误,

17、部分模块或系统不可行或不能运转或部分模块和系统缺失, 对整个系统有重大影响或可能造成部分损失或损害; 严重影响使用安全三级通常缺点次要错误布局不合理文字错误系统中部分单元模块或单个功效描述和实现有错误、 有偏差、 不一致或有缺失, 不影响模块正常运行, 或有影响, 但能够有代替方法或防止方法四级微小缺点微不足道基本不影响系统运行和功效实现。可是与标准、 规范和定义不一致五级提议缺点新特征不在定义、 标准、 范围定义和约束之内, 可是从提出者来看是需要完善提议5.7 缺点优先级定义缺点优先级描述特急需要马上进行修改加急一天到两天之内必须修改高介于中和加急之间中缺点需要正常排队等候修复或列入软件公

18、布清单低留到组后处理, 假如项目标进度跟担心能够在产品公布以前不处理5.8 缺点状态定义缺点状态描述初始状态( New) 测试或开发人员提交一个新缺点, 等候开发人员或项目经理分配修改责任人打回( FeedBack) 要求缺点汇报者再次对缺点进行说明已分配( Assigned) 是指已经分配给属主, 等候修改。已处理( Resolved) 缺点被属主修改, 等候测试人员验证关闭( Closed) 测试人员验证缺点已经修复重新打开( Reopen) 测试人员验证, 缺点没有修改过确遗留( Later) 经项目经理和技术经理验证此缺点在本版本中不用修改5.9 缺点完成度缺点完成度描述打开( Ope

19、n) 缺点没有被处理已处理( Fixed) 缺点已经修改遗留( Suspended) 此缺点步骤本阶段处理重新打开( Reopen) 重新打开某个缺点不做修改( Wont fix) 不对这个缺点进行修改重复( Duplicate) 与某个缺点重复需求如此经理和开发人员经过需求和设计核实后决定不需要修改不可重现被指派开发人员想要再现缺点进行修改个时候, 发觉缺点一直不能再现5.10 缺点管理流程6 处理机制6.1 退回机制若在测试过程中发生以下情况, 将系统退回到申请部门: 经过测试后, 发觉与需求说明规格说明书中定义功效项存在较大差异 单一模块, 测试过程中发觉缺点输了较多或者无法继续进行系统

20、其它功效模块测试, 继续测试无意义 测试过程中, 频繁死机或系统瓦解 主业务流程出现断点6.2 异常情况处理机制非正常情况下, 需要进行尤其处理情形, 此情况需要主管领导签字确认: 上线时间紧急情况下, 未经测试部充分测试就需要布署到用户现场 作为总包时, 子商进度显著延迟, 还未进行验收测试就需要上线6.3 汇报机制若出现以下情况, 需要及时向部门领导和项目经理汇报情况: 测试后期出现重大逻辑错误, 修改测试影响上线时间 测试过程中用户需求出现重大变更 测试责任人定时汇报测试情况7 测试完成标准7.1 被测试出、 在软件错误级别分类中定义: 一级缺点, 致命错误, 100%得到修改而且复测经

21、过 二级缺点, 严重错误, 100%得到修改而且复测经过 三级缺点, 通常错误, 95%得到修改而且复测经过 四级缺点, 轻微错误, 95%得到修改而且复测经过7.2 用户能够接收未修改软件错误7.3 测试超出了预定时间表, 由项目经理决定是否停顿测试7.4 测试结论及评价标准测试结论评价标准拒绝公布遗留了一级、 二级缺点测试经过版本不能遗留以一、 二类缺点三类 通常缺点95%得到修改而且经过复测四类轻微缺点85%得到修改而且经过复测推荐使用版本不能遗留以一、 二类缺点三类 通常缺点95%得到修改而且经过复测四类轻微缺点90%得到修改而且经过复测能够证实公布版本不能遗留以一、 二类缺点三类 通常缺点97%得到修改而且经过复测四类轻微缺点90%得到修改而且经过复测7.5 输出阶段性测试汇报性能测试汇报测试总结汇报测试问题列表8 其它约束9 统计序 号名 称编 号1测试计划2测试方案3问题汇报及维护统计4测试总结汇报

展开阅读全文
部分上传会员的收益排行 01、路***(¥15400+),02、曲****(¥15300+),
03、wei****016(¥13200+),04、大***流(¥12600+),
05、Fis****915(¥4200+),06、h****i(¥4100+),
07、Q**(¥3400+),08、自******点(¥2400+),
09、h*****x(¥1400+),10、c****e(¥1100+),
11、be*****ha(¥800+),12、13********8(¥800+)。
相似文档                                   自信AI助手自信AI助手
搜索标签

当前位置:首页 > 包罗万象 > 大杂烩

移动网页_全站_页脚广告1

关于我们      便捷服务       自信AI       AI导航        获赠5币

©2010-2024 宁波自信网络信息技术有限公司  版权所有

客服电话:4008-655-100  投诉/维权电话:4009-655-100

gongan.png浙公网安备33021202000488号   

icp.png浙ICP备2021020529号-1  |  浙B2-20240490  

关注我们 :gzh.png    weibo.png    LOFTER.png 

客服