软件测试工作作业流程标准规范.docx

软件测试工作步骤规范V1.0xxxxx4月20日修订历史统计版本日期修订模块修订者说明V1.0.5.10文档新建技术部目录1.目的42.工作范围43.工作职责44.测试流程45.测试准备65.1测试计划65.2测试用例65.2.1测试用例设计方法75.2.2测试用例操作步骤75.2.3测试用例选择准则75.3测试环境75.4测试数据准备76.测试执行76.1测试准入条件76.2项目测试阶段76.3测试退出标准76.4测试变更87.缺陷管理87.1BUG管理流程87.2BUG状态87.3BUG解决方案97.4BUG优先级97.5BUG严重等级97.6BUG书写规范107.6.1测试人员BUG提交107.6.2开发人员BUG解决118.标准文档111. 目标经过规范企业测试步骤，确保测试工作规范性和有效性，以验证软件产品质量满足用户需求。测试作为质量控制一个有效手段，运行测试用例找出软件中潜在多种缺点，经过帮助开发人员修正缺点来提升软件质量，回避软件公布后因为潜在软件缺点和错误造成隐患和降低质量成本。经过测试管理为产品和过程改善提供可靠数据分析，起到缺点预防作用。本过程方针： 实施测试策划活动 依据测试策划所要求要求编写测试需求和用例，实施相关测试活动 管理测试活动中发觉产品缺点2. 工作范围测试人员在软件开发过程中任务：1) 参与评定软件需求，编写测试需求；2) 依据用户需求，编写软件测试用例；3) 在开发人员完成单元测试后，进行模块测试，以期尽早发觉bug；4) 依据软件测试用例，实施集成测试，寻求尽可能多bug；5) 对bug进行追踪和分析，确保bug立即得到修复；6) 对软件性能进行衡量，并进行测试总结，提交软件测试汇报书。3. 工作职责工作内容输出文档提交天天工时申报OA工时登记提交每七天工作周报工作周报每个月5号前提交上月工作考评评价表月工作考评评价表若有加班/请假/调休，在OA上走对应步骤加班/请假/调休登记测试组长，测试计划阶段提交测试计划、测试用例测试计划、测试用例测试实施阶段提交测试汇报系统测试汇报测试评定阶段提交遗留问题分析汇报测试遗留问题分析汇报4. 测试步骤需求评审产品需求人员开发人员测试人员开发人员写开发计划（排期）测试人员写测试计划（排期）邮件通知部门全部些人开发代码及自测编写测试用例运维人员布署测试环境测试用例评审产品需求人员开发人员测试人员测试人员实施测试开发修复测试经过测试汇报验收方案软件上线需求分析l 需求分析需求分析由产品人员制订，细化每一个功效细节，每一个按钮位置，对于稍大或复杂一点需求全部进行建模。l 需求评审全部参与项目人员进行，开发人员、测试人员、项目责任人。测试人员提出需求，开发人员考虑功效实现方案和可行性、当然开发负责也是要参与。测试人员关键是对需求了解提出疑问，方便才能依据需求写用例。项目责任人是最终对软件质量进行验证人，所以也需求了解需求。l 开发人员编写排期开发人员需求依据需求功效点进行排期。然后将该计划转交给测试人员。l 测试计划排期测试人员依据开发计划，对测试确定具体测试时间，也就是开发功效完成后时间，进行几轮测试等。然后，把项目标开发和测试计划发送给各部门责任人及参与项目标全部些人员。l 编写测试用例依据具体需求分档，开始进行用例编写。l 用例评审在用例进行评审之前，先以邮件形式将用例发送给相关人员，方便她们事先了解用例对哪些功效进行验证和验证细节。然后，测试人员组进行用例评审，开发人员对用例和实际功效不符合有哪些，产品人员对会经过用例对功效具体实现进行把握等等。l 实施测试测试人员第一轮测试，发觉问题经过缺点管理工具进行反馈，开发人员对问题进行修复，完成第一轮测试后，需要写测试结论，发到相关人员。然后进行第二轮测试，第二轮会对第一轮中发觉问题进行关键回归。l 测试经过经过两到三轮或四轮测试后，直到没发觉新问题，或临时无法处理，或不紧急问题。经过上级确定，能够经过。编写测试汇报和验收方案。验收方案是交由项目责任人进行验证。在现企业步骤中是将测试和项目责任人分开，测试人员关键关注是功效是否能够正常运行。项目责任人关注是整个步骤质量和最终用户质量。5. 测试准备5.1 测试计划依据需求文档和项目计划制订测试计划。测试计划意在说明各测试阶段任务、人员分配、时间安排、测试关键点、工作规范等。测试计划在策略和方法方面说明怎样计划、组织和管理测试项目。测试计划完成后应该在项目组内进行评审。5.2 测试用例测试用例是为实施测试而向被测试系统提供输入数据、操作或多种环境设置和期望结果一个特定集合。处理要测什么、怎么测和怎样衡量问题。依据用户需求分析说明书、概要设计文档和开发具体设计说明书来设计测试用例，发觉需求和设计中问题后，和需求者立即沟通确定。5.2.1 测试用例设计方法测试用例设计方法有等价类测试、边界值分析、基于判定表测试、基于因果图测试、基于状态图测试、基于场景测试。在设计测试用例时常见设计方法有等价类测试、边界值分析两种方法。5.2.2 测试用例操作步骤1) 在设计编写测试用例时，首先要从测试用例库中选择对应功效测试用例，在原有测试用例基础上依据系统需求文档对测试用例进行修改、更新，评审经过后将使用该测试用例测试被测系统。2) 在测试实施过程中和进行回归测试后，对已设计测试用例进行维护更新。5.2.3 测试用例选择准则 测试用例代表性：能够代表多种合理和不合理、正当和非法、边界和越界,和极限输入数据、操作和环境设置等； 测试结果可判定性：即测试实施结果正确性是可判定或可评定； 测试结果可再现性：即对一样测试用例,系统实施结果应该是相同。5.3 测试环境依据需求文档提供内容，和开发部沟通确定测试项目所需软硬件环境，完成对测试项目所需软硬件资源准备工作，使软硬件资源得到满足。5.4 测试数据准备完成对测试项目基础数据准备操作，包含数据库连接、用户信息、用户角色权限、单位组织等信息和测试相关测试数据。6. 测试实施6.1 测试准入条件1) 不接收无具体需求文档和开发说明项目；2) 需要测试项目最少提前2个工作日提交测试进行需求分析；3) 开发人员经过自测经过，最少确保程序能够正常运行；对应功效在正常步骤下是能够正常使用。6.2 项目测试阶段测试人员依据测试计划和测试用例进行测试活动。测试通常分为两个阶段：1) 测试实施阶段：该阶段测试人员测试出bug后将缺点提交至缺点管理库。2) 回归阶段：开发修改完bug以后，测试进行验证回归。6.3 测试退出标准1) 全部测试用例实施完成；2) 根据系统测试计划完成了系统测试，系统测试功效覆盖率达100；3) 系统功效和性能满足产品需求规格说明书要求；4) 在系统测试中发觉错误已经得到修改而且各级缺点修复率达成标准；5) 系统测试后不存在1、2类缺点；6) 3类缺点许可存在，不超出总缺点10。6.4 测试变更当需求变更，功效改变，测试人员依据变更情况，评定测试变更所需时间，提出变更风险。如变更情况被项目组经过，测试人员将按上述步骤进行变更测试。7. 缺点管理7.1 BUG管理步骤重新打开（Reopen）提交BUG（New）确定BUG修复BUG关闭BUG（Closed）是否延期BUG验证保留BUGYNYNNY7.2 BUG状态l 激活1) 新创建bug；2) 已处理但验证未经过bug；3) 已关闭bug重新出现需要再次激活。l 已处理开发已经修改完成bug。l 关闭已验证经过bug或系统工程师确定转为需求bug。7.3 BUG处理方案l 已处理Bug已经被修改，待测试进行验证。l 设计如此测试人员了解错误，无需改动，即无效bug。l 反复bug已经有一样bug，需标明反复bug号。l 无法重现依据测试写重现步骤，无法重现bug。l 延期处理确实是bug，但现在不处理，以后处理。l 新增/变更需求分析确实是存在问题，但需求没有描述清楚，应指派给需求确定，进行需求新增或变更。7.4 BUG优先级l 高阻止和此亲密相关功效深入测试，需要立即修复。l 中必需修改，不一定立即修改，必需修改，发版前必需修正。l 低对系统影响较小，假如时间许可应该修改。7.5 BUG严重等级l 严重（一类）不能实施正常工作功效或关键功效，因软件原因造成系统死机等，须立即修正致命错误。通常有以下情况：1) 系统停机（含软件、硬件）或非法退出，且无法经过重启恢复；2) 系统死循环；3) 和数据库连接错误；4) 数据库发生死锁或程序原因造成数据库断连；5) 数据通讯错误或接口不通；6) 关键功效无法正常使用、功效不符适用户需求。l 通常（二类）影响系统功效或操作，应用模块错误使业务中止无法进行后续操作，关键功效存在严重缺点，影响到产品使用，但不会影响到系统稳定性。具体基础上可分为：1) 业务步骤错误或不完整；2) 业务数据起源不正确、业务数据紊乱或丢失；3) 业务数据保留不完整或无法保留到数据库；4) 部分功效使用存在问题，不影响业务继续开展，但造成使用障碍；5) 初始化未满足用户要求或初始化错误；6) 功效点能实现，但结果错误；7) 缺乏数据有效性检验或检验不合理；8) 删除操作不给提醒； 9) 日志统计信息不正确或应统计而未统计；10) 数据库表、业务规则、缺省值未加完整性等约束条件；11) 在产品申明支持不一样平台下，出现部分通常交易无法使用或错误；12) 系统一些查询、打印等实时性要求不高辅助功效无法正常使用。l 轻微（三类）使操作者不合理或不方便或操作碰到麻烦，但它不影响实施工作功效或关键功效，次要功效，对产品使用影响不大。比如：程序在部分显示上不美观，不符适用户习惯，或是部分文字错误。具体基础上可分为：1) 缺乏产品使用、帮助文档、系统安装或配置方面需要信息；2) 联机帮助、脱机手册和实际系统不匹配；3) 系统版本说明不正确；4) 提醒说明未采取行业规范语言；5) 显示格式不规范；6) 界面不整齐；7) 软件界面、菜单位置、工具条位置、对应提醒不美观，但不影响使用；8) 辅助说明描述不清楚；9) 提醒窗口描述清楚；10) 输入输出不规范；11) 可输入区域和只读区域没有显著区分标志。l 提议（四类）7.6 BUG书写规范7.6.1 测试人员BUG提交1) 专题 用一个简短句子描述问题，不要写成一大段 以进入问题模块路径开头，方便项目经理分配任务，和开发人员定位问题 描述问题时要具体、简练、抓住关键点，直接切入正题，不要罗嗦 不要夸大或缩小问题严重程度2) 步骤 用数字编号，一步步描述重现问题全部操作步骤 提供明确再现问题步骤，避免问题被以“不能重现”关掉 设置区域需要具体描述，如：各设置项值为默认、*值更改为“”，其它设置项值为默认 尽可能用动词作为开头，描述每个步骤。如：打开、点击、设置、选择、插入、双击等 不要在一个步骤中描述不相关多个操作。假如是相关一系列操作，能够使用“”来连接描述 根据你写步骤去实施，看问题能否重现 不要在步骤中使用含糊不清缩写词描述3) 实际结果 实际只描述一个问题 一样操作步骤产生多个现象，要在一个缺点汇报中加以描述 不一样操作步骤产生不一样问题，分别报bug 假如有截图，请列出所附图片信息4) 预期结果 不要加入实际结果描述信息 描述要清楚，不要使用含糊不清缩写词描述 假如有截图，请列出所附图片信息5) 备注 避免写成大段落，要写得简单、易读 问题特征 出现问题后处理方法 对终端用户影响情况 假如有必需，列出产生问题配置环境 一样问题也在其它模块发生需写明备注信息7.6.2 开发人员BUG处理1) BUG原因2) BUG修改方法3) BUG能够在哪个版本上进行验证4) 测试人员验证bug时，需要写明：验证了什么，在什么版本验证，是否经过，假如不经过需写明原因。假如在验证目前bug时有新现象产生阻碍了验证此bug，则该bug不能关闭，写明没有验证原因，并为新现象提bug。8. 标准文档测试申请单测试计划测试用例测试汇报