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