软件测试流程规范最全样本.docx
- 文档编号:26293196
- 上传时间:2023-06-17
- 格式:DOCX
- 页数:20
- 大小:105.67KB
软件测试流程规范最全样本.docx
《软件测试流程规范最全样本.docx》由会员分享,可在线阅读,更多相关《软件测试流程规范最全样本.docx(20页珍藏版)》请在冰豆网上搜索。
软件测试流程规范最全样本
软件测试流程规范
整体流程图
1.详细流程执行
1.1筹划与设计阶段
整体流程图
1.1.1立项会议
由高层主管立项会议,会议重要对项目可行性进行分析,并且拟定项目经理及项目测试组长。
过程要点
详细阐明
输入条件
立项会议
工作内容
●项目(产品)可行性分析。
●项目经理拟定.
●依照项目信息,测试经理拟定测试组长。
退出原则
测试组长拟定.
负责人
测试经理(拟定测试组长)
1.1.2需求评审
过程要点
详细阐明
输入条件
需求定义完毕
工作内容
测试团队成员对需求中不清晰、不完整、太概括或存在疑义地方
提出问题,有关人员解答并确认。
退出原则
所有人员对需求无异议
参加人员
需求调研人员,开发组,测试部(需求提出者,高层主管)
负责人
需求调研人员(或高层主管)
注:
1.需求定义基本完毕,此时应在评审会议召开之前发给测试团队,预留时间给测试有关人员熟悉、理解。
2.测试部参加人员由测试部经理指定,重要由测试组长、测试设计等人员构成(还应涉及配备管理人员、质量保证人员)。
1.1.3测试工作启动
过程要点
详细阐明
输入条件
项目(产品)开发筹划完毕
工作内容
1.项目/产品经理邮件告知测试组长正式测试交接时间,测试规模预估等,同步提
交有关最新项目资料:
●项目需求及软件规格定义文档
●项目开发筹划
●开发设计过程中提供概要设计、详细设计文档。
●其她有关资料
2.组建测试小组,拟定小构成员
3.召开测试启动会议,开发团队提供需求规格阐明书和开发筹划,确认开发组与
测试组对需要交接测试内容、测试目的达到一致,统一项目组目的和测试工
作重点。
退出原则
测试小构成立,双方对测试目的及内容达到一致。
负责人
产品(项目)经理,测试组长
注:
在正式测试任务下达前,开发团队应在项目(产品)开发筹划完毕后及时向测试团队下达预告知,告之较为确切测试日期,提供当前最新有关资料。
部门经理和测试组长组建测试小组,并视详细状况决定与否需要调节人力、时间安排、测试环境等其他资源。
测试小构成员可预先熟悉必要项目(产品)资料。
1.1.4测试设计阶段
1.1.4.1设计测试筹划
注:
针对需求分析文档和项目开发筹划文档测试完毕后,测试组需要编写测试筹划文档、制定测试测略及预估测试过程中风险,并设计出合理规避风险方略,为后续测试工作提供直接指引。
过程要点
详细阐明
输入条件
项目需求文档建立,项目开发筹划完毕
工作内容
依照项目需求文档、设计文档,按照测试筹划文档模板编写测试筹划。
测试筹划中
应当至少涉及如下核心内容:
●根据项目背景及规定,拟定测试环境。
●测试需求——需要测试组测试范畴,估算出测试所耗费人力资源和各个测试
需求测试优先级
●测试方略——拟定项目测试筹划内容,整体测试测试办法和每个测试需求
测试办法,同步做好测试进度安排及人员调节。
●测试资源——本次测试所需要用到人力、硬件、软件、技术资源
●测试组角色——明确测试组内各个成员角色和有关责任
●可交付工件——在测试组工作中必要向项目组提交产物,涉及测试筹划、测试
报告等等
●风险管理——列举出测试工作所也许浮现风险
测试筹划编写完毕后,必要提交给项目组全体成员,并由项目组组中各个角色组联合
评审。
退出原则
●测试筹划由项目组评审并通过.
●在项目开发过程中,要适时对测试筹划进行跟踪,以及评估此筹划
完整性、可行性,在项目结束时还要最后评估一下测试筹划质量
负责人
测试设计工程师
1.1.4.2设计测试用例
注:
在需求分析文档确立基线后来,测试组需要针对项目测试需求编写测试用例,在实际测试中,测试用例将是唯一实行原则。
1.1.4.2.1设计测试用例惯用办法
a.等价划分法
有效等价类:
是指对于程序规格阐明来说是合理故意义输入数据构成集合运用有效等价类可检查程序与否实现了规格阐明中所规定功能和性能
无效等价类:
与有效等价类定义碰巧相反
b.边界值法:
Ø边界值分析法就是对输入或输出边界值进行测试一种黑盒测试办法。
普通边界值分析法是作为对等价类划分法补充,这种状况下,其测试用例来自等价类边界。
Ø普通状况下,软件测试所包括边界检查有几种类型:
数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。
Ø相应地,以上类型边界值应当在:
最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等状况下。
Ø边界值分析基本思想是使用在最小值、略高于最小值、正常值、略低于最大值和最大值处取输入变量值,记为:
min、min+、nom、max-、max考虑到健壮性测试,还可以加一种略不不大于最大值max+,以及一种略不大于最小值min-值。
举例阐明:
例如规定0 ⏹x=0状况 ⏹x=5状况 ⏹x=-1状况 ⏹输入一种X不不大于5值,例如输入X=6 c.错误推断法 基于经验和直觉推测程序中所有也许存在各种错误,从而有针对性设计测试用例办法。 思路: 分析程序中最易出错场景和状况,在此基本上有针对性设计测试用例,需要完毕前提条件如下: ●深度熟悉被测系统业务、需求。 ●对被测系统或类似系统之前缺陷分布状况进行过系统分析。 涉及功能缺陷,数据缺陷,接口缺陷和界面缺陷等等。 举例阐明: 聊天窗口功能 }输入特殊字符(全角,半角)后,窗口与否可以正常显示 }输入空格,与否可以过滤,与否会算入长度计算 }输入html字符 }输入脚本语言函数 }在需要密码验证,或者需要二次输入确认地方,通过复制粘贴第一次输入内容与否可以通过 1.1.4.2.2接口测试办法 Ø测试接口文档。 Ø依照接口文档编写测试用例(用例编写办法完全可以按照黑盒测试用例编写规则来编写,如: 边界值、等价划分等等设计办法)。 Ø和数据库中执行测试,查看接口返回接口数据与否对的,重要检查返回接口与否和接口文档中定义同样,尚有要检查返回数据与否保持一致。 1.1.4.2.3安全性测试办法 Ø手工检测: 对于CSRF、越权访问、文献上传、修改密码等漏洞,难以实现自动化检测效果,这是由于这些漏洞涉及系统逻辑或业务逻辑,有时候还需要人机交互参加页面流程,因而此类漏洞检测更多需要依托手动测试完毕。 手工检测网站URL、后台登陆与否具备SQL注入 ◆举例阐明: 关于上传: Ø上传文献与否有格式限制,与否可以上传exe文献; Ø上传文献与否有大小限制,上传太大文献与否导致异常错误,上传0K文献与否会导致异常错误,上传并不存在文献与否会导致异常错误; Ø通过修改扩展名方式与否可以绕过格式限制,与否可以通过压包方式绕过格式限制; Ø与否有上传空间限制,与否可以超过空间所限制大小,如将超过空间大文献拆分上传与否会浮现异常错误。 Ø上传文献大小不不大于本地剩余空间大小,与否会浮现异常错误。 Ø关于上传与否成功判断。 上传过程中,中断。 程序与否判断上传与否成功。 Ø对于文献名中带有中文字符,特殊字符等文献上传。 1.1.4.2.5兼容性测试办法 Ø操作系统/平台兼容 Ø不同浏览器兼容 Ø不同辨别率间兼容 1.1.4.2.4界面测试办法 Ø风格统一 Ø重要和惯用元素优先布局,且放置在醒目位置 Ø布局合理紧凑,疏密有致 Ø明显区别只读区域与可编辑区域 Ø使用红色符号’*'来标记必填项 Ø语句流畅,表述清晰,没有错别字 Ø字段名称通俗易懂、尽量使用专业术语 1.1.4.2.5易用性测试办法 Ø易理解 Ø易学 Ø易操作 Ø吸引性 1.1.4.2.6APP兼容性测试 Ø辨别率: 当前市场上辨别率是各种各样什么辨别率均有了,因此需要在app在不同辨别率设备上进行测试,显示UI效果怎么样。 Ø系统: Android系统在不断升级,就会产生不同系统版本,对系统版本是不断进行兼容来对来符合系统版本。 而在市场上开发了不同定制版本,也需要进行兼容。 Ø机型: 当前所涉及到厂商生产出来机器较多,因此需要使用不同厂商不同辨别率来进行适配app运营状况 Ø语言: 当前诸多app已经支持较多语言,因此需要对语言方面进行测试,是app显示语言国际化显示效果 1.1.4.2.7测试用例维护 存在如下几种状况,需对测试用例进行更新: }先前测试用例设计不全面或不精确 }某些严重软件错误未在测试用例中覆盖 }新版本有新功能需求或改动 }编写测试用例不规范或者语句错误 }旧测试用例不再合用 过程要点 详细阐明 输入条件 测试需求明确,测试筹划明确 工作内容 依照测试筹划设计测试用例,设计参照原则: ●等价类划分 ●边界值分析 ●错误推测等 ●业务知识及有关流程 退出原则 ●测试用例需要覆盖所有测试需求 ●测试用例集需进行评审并通过 ●项目进行过程中,适时依照需求变更来对测试用例进行维护 负责人 测试构成员 1.1.4.3设计内容评审 注: 测试筹划及测试用例设计工作完毕后,需告知项目组有关成员召开评审会议。 在这之前需要将待评审内容发给有关人员熟悉和理解。 过程要点 详细阐明 输入条件 测试筹划、测试用例集完毕 工作内容 评审测试筹划内容对的性及合理性: ●测试环境、测试资源; ●测试需求范畴,各个测试需求优先级; ●测试方略及风险管理等; 评审测试用例集: ●测试用例优先级 ●测试用例集基于需求覆盖限度 退出原则 测试筹划及测试用例集评审通过 负责人 同行测试组,项目经理, 1.2实行测试阶段 整体流程图 1.2.1测试交接 过程要点 详细阐明 输入条件 测试设计内容评审完毕,开发团队编码工作完毕,并已完毕内部测试; 工作内容 1.开发组依照测试启动会上所规定内容,填写送测单,向测试组提交测试内容。 2.测试小组检查提交部件完整性和可测性: ●检查接受测试内容(按照测试启动会上所规定交接内容); ●检查程序与否有病毒; ●能否对的安装/卸载; ●检查送测软件与否完整,能否进行测试; 退出原则 提交部件经测试组检查通过 负责人 产品(项目)经理,测试组长 1.2.2实行测试 1.2.2.1实行测试 注: 实行测试用例将耗费测试组大某些时间,这些工作都是建立在前期诸多筹划工作基本上。 过程要点 详细描述 输入条件 测试组长于前一工作日定出当天测试筹划,拟定可用测试用例。 工作内容 ●测试工程师依照测试筹划中分派给自己测试任务和提供测试用例,实行相应 测试用例。 ●记录实行用例成果,提交当天测试纪录。 ●提交缺陷。 退出原则 测试用例中所有任务被执行,成果被记录。 负责人 测试构成员 1.2.2.2提交阶段性测试报告 在商定测试周期完毕之后,测试组长需要总结本次测试成果,编写阶段性测试报告。 过程要点 详细描述 输入条件 测试组完毕了预定周期测试任务 工作内容 测试组长依照此轮测试成果,编写阶段性测试报告(参照测试阶段性报告模板),重要应包括以 下内容: ●测试报告版本 ●测试人员和时间 ●测试所覆盖缺陷——测试组在这轮测试中所有解决缺陷,报告测试组长解决 缺陷和实行工程师验证缺陷。 不但要写出覆盖缺陷总数,还要写明这些缺陷去向: ●测试新发现缺陷数量 ●上一版本活动缺陷数量 ●通过此轮测试,所有活动缺陷数量及其状态分类 ●测试评估——写明在这一版本中,那些功能被实现了,那些还没有 实现,这里只需写明和上一版本不同之处即可 ●急待解决问题——写明当前项目组中面临最优先问题,可以 重复提出 退出原则 在每轮测试结束之后应尽快将符合原则测试报告发给全项目组 负责人 测试组长 1.2.3回归测试 在每轮测试结束之后,由测试组重新针对修改后最新版本,进行回归测试。 过程要点 详细描述 输入条件 在每轮测试中,按照既有测试用例没有新缺陷被发现,测试报告中所有 活动缺陷都被解决。 工作内容 ●测试组将按照测试筹划中对于回归测试方略对产品进行回归测试,回归 测试用例属于测试用例一某些或者是所有测试用例,但不能超过原先预定测试用 例范畴。 ●记录取例实行成果,提交回归测试记录。 退出原则 ●回归测试所运营用例所有通过 ●缺陷通过验证 ●所有缺陷都被指明解决方式 负责人 测试工程师 1.2.4同行审查 过程要点 详细描述 输入条件 回归测试结束,所有缺陷都被关闭。 工作内容 1.进行对测试组所测试项目或产品测试审查工作.基本原则: ●不根据所设计测试用例,进行自由测试. ●测试时间保持在3个正常工作日以内. ●如发现严重缺陷,则一轮测试结束后,更新版本,执行回归测试. 2.提交当天测试纪录. 3.编写同行审查总结报告(报告以简朴为好). 退出原则 同行审查没有新缺陷或没有严重缺陷产生. 负责人 同行测试组 1.3总结阶段 整体流程图 1.3.1测试报告总结 在回归测试结束之后,测试组长将要编写测试总结报告,对测试进行总结,并且提交给全体项目组,为产品后续工作提供重要信息支持。 过程要点 详细描述 输入条件 测试组完毕了所有测试实行工作,同行审查结束. 工作内容 测试组长依照测试成果,按照测试总结报告文档模板编写测试报告,测试报告必要包括如下 重要内容: ●测试资源概述——多少人、多长时间。 ●测试成果摘要——分别描述各个测试需求测试成果,产品实现了哪些功能点, 哪些还没有实现 ●缺陷分析——按照缺陷属性分类进行分析 ●测试需求覆盖率——原先列举测试需求测试覆盖率,也许一某些测试需求由于 资源和优先级因素没有进行测试,那么在这里要进行阐明 ●测试评估——从总体对项目质量进行评估 ●测试组建议——从测试组角度为项目组提出工作建议 退出原则 测试组长完毕了符合原则测试报告,发送给全项目组。 负责人 测试组长 1.3.2测实验收 测实验收工作是在以上工作所有结束后,对测试过程,效果进行验收,宣布测试结束。 过程要点 详细描述 输入条件 测试组完毕了所有测试实行工作,测试组长完毕符合原则测试总结 文档 工作内容 由测启会上商定验收构成员,对本次测试收进行验收,验收内容涉及: ●测试效果验收——测试与否达到预期目 ●测试文档验收——测试过程文档与否齐全,可信,符合原则 ●测试评估——从总体对测试质量进行评估 ●测试建议——对本次测试工作指出局限性,需要在后来工作 中改进地方 ●宣布测试结束——测实验收构成员签字宣布本次测试结束 退出原则 测实验收通过,测实验收会议记录整顿完毕 参加人员 验收组人员,测试经理,测试组长,产品(项目)经理 1.3.3测试归档 测试归档是在测实验收结束宣布测试有效,结束测试后,对测试过程中涉及到各种原则文档进行归类,存档。 过程要点 详细描述 输入条件 测实验收通过 工作内容 归类、存档测试过程涉及到文档,重要涉及如下文档(必要) ●测试任务书 ●测试筹划书 ●测试用例书 ●阶段性测试报告 ●测试总结报告 ●测实验收会议记录 退出原则 所有文档归类完毕,版本号封存 负责人 测试组长 1.3.4测试工作总结 过程要点 详细描述 输入条件 项目验收工作完毕。 工作内容 由测试组长召开项目测试工作总结会议,会议内容重要为: ●测试组长对项目期间整个测试组工作状况进行总结,指出测试工作中存在 问题,同步也对工作中体现好地方给与必定。 (详细涉及整个测试状况、流程实行、人 员安排、测试办法等) ●参加本次项目测试工作所有成员个人体会和建议。 ●讨论测试工作中浮现问题,谋求更好解决办法。 ●宣布解散测试小组。 退出原则 所提问题谋求到较好解决方式,测试小组解散 参加人员 测试部所有成员 1.4测试工具 1.4.1BUG管理工具简介 当前BUG管理工具备Bugzilla、QC(QualityCenter)、BugFree、EasyBUG、Mantis、jira,我自己使用过Bugzilla也就是禅道,觉得还是挺以便 1.4.2自动化测试工具QTP 自动化测试工具QTP: 1.使用前提是大某些功能已验证通过 2.重要用于进行回归测试、功能测试 1.4.3性能测试工具LoadRunner 性能测试工具: Loadrunner重要用于进行系统性能测试也就是压力测试,例如登录界面并非测试、数据库性能测试、服务器性能测试,限制是免费版并发顾客最大数量只能是50个, 详细操作详见LOADRUNNER操作手册 测试有关文档解释阐明: 需求分析文档需包括内容规范: }无歧义性: 需对某些特殊术语要有有关解释阐明,存在歧义地方需予以有关阐明 }完整性: 功能、性能、接口、约束 }可验证性: 需求中每个功能点需要可以进行验证 }一致性: 不能存在先后矛盾问题 需求分析文档需包括内容: }流程图、功能点、输入输出规定、运营环境规定,最重要是要阐明: 是为哪个软件产品编写,开发这个软件产品意义、作用、以及最后要达到效果 概要设计文档也就是原型文献包括内容: }菜单、按钮、文本框、单选框、复选框等等存储位置,即整体页面布局、排版 数据库设计文档: }表名称、字段名称、中文描述、字段类型、字段大小、备注
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 流程 规范 样本