软件测试作业流程标准规范_第1页
软件测试作业流程标准规范_第2页
软件测试作业流程标准规范_第3页
软件测试作业流程标准规范_第4页
软件测试作业流程标准规范_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件测试步骤规范通读项目需求设计文档测试准备阶段;仔细阅读《软件需求规格说明书》;依据测试手册,做前期测试准备;明确测试任务范围=1\*GB2⑴功效测试;=2\*GB2⑵界面测试;=3\*GB2⑶接口测试;=4\*GB2⑷容错测试;=5\*GB2⑸负载测试;=6\*GB2⑹安全测试;=7\*GB2⑺性能测试;=8\*GB2⑻稳定性测试;=9\*GB2⑼配置测试;=10\*GB2⑽安装测试;=11\*GB2⑾恢复测试;=12\*GB2⑿文档测试;=13\*GB2⒀可用性测试;学习了解被测试软件由开发人员组织讲解所要实施测试软件或产品,测试人员必需认真了解拿到手中待测试软件或产品。制订测试计划“工欲善其事,必先利其器”。软件测试必需以一个好测试计划作为基础。作为测试起始步骤和关键步骤。测试计划应包含:产品基础情况调研、测试策略、测试纲领(功效模块测试、具体测试、高级测试)、测试内容(界面测试、测试需求说明)、测试人力资源配置、测试计划变更、测试硬件环境、测试软件环境、测试工具、测试进度计划表、问题跟踪汇报、测试经过准则、测试计划评审意见等。另外还包含测试计划目标、测试对象信息、测试计划使用范围及测试参考文档。项目介绍;对产品(项目)一个了解和概述,关键对产品(项目)功效简述。测试背景;产品在那种情况下开始研发,实施测试,交待为何而测试产品背景。测试手段\环境;(手工和自动化工具)测试环境测试辅助工具测试类型(方法);(黑盒测试)=1\*GB2⑴功效测试;=2\*GB2⑵界面测试;=3\*GB2⑶接口测试;=4\*GB2⑷容错测试;=5\*GB2⑸负载测试;=6\*GB2⑹安全测试;=7\*GB2⑺性能测试;=8\*GB2⑻稳定性测试;=9\*GB2⑼配置测试;=10\*GB2⑽安装测试;=11\*GB2⑾恢复测试;=12\*GB2⑿文档测试;=13\*GB2⒀可用性测试;测试资源;=1\*GB2⑴人力资源=2\*GB2⑵系统资源人员角色职责、任务时间测试策略\测试需求\测试任务\测试点;针对测试需求定义测试类型、测试方法和需求测试工具等。=1\*GB3①对于每种测试,全部应提供测试说明,并解释其实施原因。=2\*GB3②制订测试策略时所考虑关键事项有:将要使用技术和判定测试何时完成标准。=3\*GB3③下面列出了在进行每项测试时需考虑事项,除此之外,测试还只应在安全环境中使用已知、有控制数据库来实施。=4\*GB3④不实施某种测试,则应该用一句话加以说明,并陈说这么理由。比如,“将不实施该测试。该测试本项目不适用”。测试工作计划表;No工作内容开始时间结束时间责任人提交结果备注设计测试用例测试用例关键起源为:1)需求说明书及相关文档2)相关设计说明(概要设计,具体设计等)3)和开发组交流对需求了解统计(能够是开发人员一个解释)4)已经基础成型UI(能够有针对性地补充部分用例)从所得到资料中,分解出若干小“功效点”,了解“功效点”,编写对应测试用例。测试用例模板(Excel):项目名称程序版本功效模块名用例编号编制人编制时间论坛功效特征测试目标参考信息预置条件特殊规程说明参考信息测试用例基础流序号名称说明12备选流序号名称说明12相关用例无测试场景序号名称说明测试数据测试数据集1:序号操作描述数据预期输出实际输出测试状态(P/F)1P2P测试人员开发人员项目责任人确定软件测试软硬件环境CPU:内存:硬盘:数据库:IE/版本:服务器:平台:操作系统/版本:搭建测试环境统计下配置环境,常见软件均要安装,实施测试(集成测试、系统测试、验收测试)和优先级控制集成测试:也叫组装测试或联合测试。在单元测试基础上,将全部模块根据设计要求(如依据结构图〕组装成为子系统或系统,进行集成测试。实践表明,部分模块即使能够单独地工作,但并不能确保连接起来也能正常工作。程序在一些局部反应不出来问题,在全局上很可能暴露出来,影响功效实现。集成测试应该考虑以下问题:1、在把各个模块连接起来时候,穿越模块接口数据是否会丢失;2、各个子功效组合起来,能否达成预期要求父功效;3、一个模块功效是否会对另一个模块功效产生不利影响;4、全局数据结构是否有问题;5、单个模块误差积累起来,是否会放大,从而达成不可接收程度。所以,单元测试后,有必需进行集成测试,发觉并排除在模块连接中可能发生上述问题,最终组成要求软件子系统或系统。对子系统,集成测试也叫部件测试。任何合理地组织集成测试,即选择什么方法把模块组装起来形成一个可运行系统,直接影响到模块测试用例形式、所用测试工具类型、模块编号和测试次序、生成测试用例和调试费用。通常,有两种不一样组装方法:一次性组装方法和增值式组装方法。提交缺点汇报BUG单模板简版主表BUG编号:被测系统名称:被测系统版本号:被测模块:测试阶段:BUG类型:测试人员:BUG严重性:测试日期:BUG优先级:BUG概要:BUG详情测试路径导航:操作描述:1.2.……结果描述:修改提议:附件:(可选)备注:(以上内容由具体测试人员填写)BUG状态:BUG结论:BUG原因:处理人员:处理方法:处理日期:BUG处理意见:(以上由BUG修复人员填写,通常是具体研发人员)Bug单附表环境CPU:内存:硬盘:数据库:IE/版本:服务器:平台:操作系统/版本:Bug状态说明:新建:测试人员汇报bug状态已指派:测试人员分配bug状态已处理:修改人员修改bug状态,在处理bug界面正确标注bug完成度已确定:修改人员对临时不能、以后修改bug进行确定状态反馈:测试人员对开发人员认为不修改、但测试人员需要修改bug反馈给经理状态公认:经理查看反馈bug后认为需要修改,则标示bug状态为公认,认为不做修改,直接关闭此bug,注明原因已关闭:测试人员对修正后bug进行回归测试后,确定bug已修正即可关闭bug状态注:BUG等级说明A(严重级):操作系统或网络瘫痪;B(中等级):应用程序瓦解、非法退出或功效模块无法实现。C(通常级):篡改设计;功效实现错误或功效不完善,容错失败、数据逻辑关系错。D(许可级):界面布局;操作不方便;提议性修改。职责:测试人员:正确定位bug,新建bug,指派bug和开发人员对修正后bug进行验证,确定修正后将其关闭经过验证,bug仍然存在,重新指派给开发人员对修改人员认为不需要修改,而测试人员认为要修改bug,反馈和经理对已关闭bug以后又出现,将其重新打开,指派和原开发人员研发人员:查看指派给自己bug,正确选择bug完成度,添加bug注释,将其状态置为已处理查看bug,确定是bug,进行修正,并注明原因对不属于自己模块bug指派其它人修改对延迟处理bug标注确定需要讨论bug,将其状态置为公认经理:查看测试人员提交bug,确定要修改,添加注释,指派和修改人员需要讨论bug,将其状态置为公认对不做修改bug,将其关闭管理员:对项目、人员进行管理维护,定时备份数据库对于反复汇报bug,查看汇报时间,将汇报晚删除对因为配置、数据库未更新将其删除测试退出准则系统满足需求规格说明书要求根据测试计划完成了系统测试测试用例实施覆盖率达成100%测试需求覆盖率达成100%Block,Crash,Major级缺点修复率达成100%Minor,Trivial级缺点修复率达成80%Text,Suggestion,Feature级缺点修复率达成75%程序能够处理要求负载系统在要求硬件和软件平台上工作正常。编制测试汇报测试汇报是把测试过程和结果写成文档,并对发觉问题和缺点进行分析,为纠正软件存在质量问题提供依据,同时为软件验收和交付打下基础。测试汇报基于测试中数据采集和对最终测试结果分析。包含:测试实施情况(测试组织、测试时间、测试版本)、覆盖分析(需求覆盖、测试覆盖)、缺点统计图表(测试管理工具自动生成多种图表)和分析(缺点汇总、缺点分

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论