软件测试工作流程要求规范0509

《软件测试工作流程要求规范0509》由会员分享，可在线阅读，更多相关《软件测试工作流程要求规范0509（14页珍藏版）》请在装配图网上搜索。

1、软件测试工作流程规XV1.0xxxxx某某2017年4月20日修订历史记录版本日期修订模块修订者说明V1.02017.5.10文档新建技术部1.目的42.工作X围43.工作职责44.测试流程45.测试准备65.1测试计划65.2测试用例6测试用例设计方法7测试用例操作步骤7测试用例选择准如此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书写规X10测试人员BUG提交10开发人员BUG解

2、决118.标准文档111. 目的通过规X公司测试流程，确保测试工作的规X性和有效性，以验证软件产品的质量满足用户的需求。测试作为质量控制的一种有效，运行测试用例找出软件中潜在的各种缺陷，通过协助开发人员修正缺陷来提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患和降低质量本钱。通过测试管理为产品与过程改良提供可靠的数据分析，起到缺陷预防的作用。本过程的方针： 实施测试策划活动 根据测试策划所规定的要求编写测试需求与用例，实施相关的测试活动 管理测试活动中发现的产品缺陷2. 工作X围测试人员在软件开发过程中的任务：1) 参与评估软件需求，编写测试需求；2) 根据用户需求，编写软件测试

3、用例；3) 在开发人员完成单元测试后，进展模块测试，以期尽早发现bug；4) 根据软件测试用例，执行集成测试，寻找尽可能多的bug；5) 对bug进展追踪与分析，保证bug与时得到修复；6) 对软件性能进展衡量，并进展测试总结，提交软件测试报告书。3. 工作职责工作内容输出文档提交每天工时申报OA工时登记提交每周工作周报工作周报每月5号前提交上月工作考核评价表月工作考核评价表假如有加班/请假/调休，在OA上走相应流程加班/请假/调休登记测试组长，测试计划阶段提交测试计划、测试用例测试计划、测试用例测试执行阶段提交测试报告系统测试报告测试评估阶段提交遗留问题分析报告测试遗留问题分析报告4. 测试

4、流程l 需求分析需求分析由产品人员制定，细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进展建模。l 需求评审所有参与项目人员进展，开发人员、测试人员、项目责任人。测试人员提出需求，开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。项目责任人是最终对软件质量进展验证的人，所以也需求了解需求。l 开发人员编写排期开发人员需求根据需求功能点进展排期。然后将该计划转交给测试人员。l 测试计划排期测试人员根据开发计划，对测试拟定具体测试时间，也就是开发功能完成后的时间，进展几轮测试等。然后，把项目的开发与测试计划

5、发送给各部门负责人与参与项目的所有人员。l 编写测试用例根据详细的需求分档，开始进展用例的编写。l 用例评审在用例进展评审之前，先以形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进展验证以与验证的细节。然后，测试人员组进展用例评审，开发人员对用例与实际功能不符合有哪些，产品人员对会通过用例对功能的具体实现进展把握等等。l 执行测试测试人员第一轮测试，发现的问题通过缺陷管理工具进展反应，开发人员对问题进展修复，完成第一轮测试后，需要写测试结论，发到相关人员。然后进展第二轮测试，第二轮会对第一轮中发现的问题进展重点回归。l 测试通过经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无

6、法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。验收方案是交由项目责任人进展验证的。在现公司的流程中是将测试与项目责任人分开的，测试人员重点关注的是功能是否可以正常运行。项目责任人关注的是整个流程的质量以与最终用户的质量。5. 测试准备5.1 测试计划根据需求文档和项目计划制定测试计划。测试计划旨在说明各测试阶段任务、人员分配、时间安排、测试要点、工作规X等。测试计划在策略和方法方面说明如何计划、组织和管理测试项目。测试计划完成后应该在项目组内进展评审。5.2 测试用例测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以与期望结果的一个特定的集合。解决

7、要测、测和如何衡量的问题。依据用户需求分析说明书、概要设计文档和开发详细设计说明书来设计测试用例，发现需求与设计中的问题后，与需求者与时沟通确认。5.2.1 测试用例设计方法测试用例的设计方法有等价类测试、边界值分析、基于判定表的测试、基于因果图的测试、基于状态图的测试、基于场景的测试。在设计测试用例时常用的设计方法有等价类测试、边界值分析两种方法。5.2.2 测试用例操作步骤1) 在设计编写测试用例时，首先要从测试用例库中选择相应功能的测试用例，在原有测试用例的根底上依据系统需求文档对测试用例的进展修改、更新，评审通过后将使用该测试用例测试被测系统。2) 在测试的执行过程中和进展回归测试后，

8、对已设计的测试用例进展维护更新。5.2.3 测试用例选择准如此 测试用例的代表性：能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以与极限的输入数据、操作和环境设置等； 测试结果的可判定性：即测试执行结果的正确性是可判定的或可评估的； 测试结果的可再现性：即对同样的测试用例,系统的执行结果应当是一样的。5.3 测试环境根据需求文档提供的内容，和开发部沟通确定测试项目所需的软硬件环境，完成对测试项目所需软硬件资源的准备工作，使软硬件资源得到满足。5.4 测试数据准备完成对测试项目根本数据的准备操作，包括数据库连接、用户信息、用户角色权限、单位组织等信息和测试相关的测试数据。6. 测试执

9、行6.1 测试准入条件1) 不承受无详细需求文档和开发说明的项目；2) 需要测试的项目至少提前2个工作日提交测试进展需求分析；3) 开发人员经过自测通过，至少保证程序可以正常运行；对应的功能在正常流程下是可以正常使用。6.2 项目测试阶段测试人员依据测试计划和测试用例进展测试活动。测试一般分为两个阶段：1) 测试执行阶段：该阶段测试人员测试出bug后将缺陷提交至缺陷管理库。2) 回归阶段：开发修改完bug之后，测试进展验证回归。6.3 测试退出标准1) 全部的测试用例执行完毕；2) 按照系统测试计划完成了系统测试，系统测试的功能覆盖率达100；3) 系统的功能和性能满足产品需求规格说明书的要求

10、；4) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准；5) 系统测试后不存在1、2类缺陷；6) 3类缺陷允许存在，不超过总缺陷的10。6.4 测试变更当需求变更，功能变化，测试人员根据变更情况，评估测试变更所需时间，提出变更风险。如变更情况被项目组通过，测试人员将按上述流程进展变更测试。7. 缺陷管理7.1 BUG管理流程YNYNNY7.2 BUG状态l 激活1) 新创建的bug；2) 已解决但验证未通过的bug；3) 已关闭的bug重新出现需要再次激活。l 已解决开发已经修改完成的bug。l 关闭已验证通过的bug或系统工程师确认转为需求的bug。7.3 BUG解决方案l 已

11、解决Bug已经被修改，待测试进展验证。l 设计如此测试人员理解错误，无需改动，即无效bug。l 重复bug已经有同样的bug，需标明重复bug号。l 无法重现根据测试写的重现步骤，无法重现bug。l 延期处理确实是bug，但现在不解决，以后处理。l 新增/变更需求分析确实是存在问题，但需求没有描述清晰，应指派给需求确认，进展需求的新增或变更。7.4 BUG优先级l 高阻止与此密切相关功能的进一步测试，需要立即修复。l 中必须修改，不一定马上修改，必须修改，发版前必须修正。l 低对系统的影响较小，如果时间允许应该修改。7.5 BUG严重等级l 严重一类不能执行正常工作功能或重要功能，因软件原因导

12、致系统死机等，须马上修正致命错误。通常有如下情况：1) 系统停机含软件、硬件或非法退出，且无法通过重启恢复；2) 系统死循环；3) 与数据库连接错误；4) 数据库发生死锁或程序原因导致数据库断连；5) 数据通讯错误或接口不通；6) 重要功能无法正常使用、功能不符合用户需求。l 一般二类影响系统功能或操作，应用模块错误使业务中止无法进展后续操作，主要功能存在严重缺陷，影响到产品的使用，但不会影响到系统稳定性。具体根本上可分为：1) 业务流程错误或不完整；2) 业务数据来源不正确、业务数据紊乱或丢失；3) 业务数据保存不完整或无法保存到数据库；4) 局部功能使用存在问题，不影响业务继续开展，但造成

13、使用障碍；5) 初始化未满足客户要求或初始化错误；6) 功能点能实现，但结果错误；7) 缺少数据有效性检查或检查不合理；8) 删除操作不给提示； 9) 日志记录信息不正确或应记录而未记录；10) 数据库的表、业务规如此、缺省值未加完整性等约束条件；11) 在产品声明支持的不同平台下，出现局部一般交易无法使用或错误；12) 系统某些查询、打印等实时性要求不高的辅助功能无法正常使用。l 轻微三类使操作者不合理或者不方便或操作遇到麻烦，但它不影响执行工作功能或重要功能，次要功能，对产品使用影响不大。例如：程序在一些显示上不美观，不符合用户习惯，或是一些文字的错误。具体根本上可分为：1) 缺少产品使用

14、、帮助文档、系统安装或配置方面需要信息；2) 联机帮助、脱机手册与实际系统不匹配；3) 系统版本说明不正确；4) 提示说明未采用行业规X语言；5) 显示格式不规X；6) 界面不整齐；7) 软件界面、菜单位置、工具条位置、相应提示不美观，但不影响使用；8) 辅助说明描述不清楚；9) 提示窗口描述清楚；10) 输入输出不规X；11) 可输入区域和只读区域没有明显的区分标志。l 建议四类7.6 BUG书写规X7.6.1 测试人员BUG提交1) 主题 用一个简短的句子描述问题，不要写成一大段 以进入问题模块路径开头，方便项目经理分派任务，以与开发人员定位问题 描述问题时要详细、简练、抓住要点，直接切入

15、正题，不要罗嗦 不要夸大或缩小问题的严重程度2) 步骤 用数字编号，一步步的描述重现问题的所有操作步骤 提供明确的再现问题的步骤，防止问题被以“不能重现关掉 设置区域需要详细描述，如：各设置项值为默认、*值更改为“，其他设置项值为默认 尽量用动词作为开头，描述每个步骤。如：打开、点击、设置、选择、插入、双击等 不要在一个步骤中描述不相关的多个操作。如果是相关的一系列操作，可以使用“来连接描述 按照你写的步骤去执行，看问题能否重现 不要在步骤中使用模糊不清的缩写词描述3) 实际结果 实际只描述一个问题 同样的操作步骤产生多种现象，要在一个缺陷报告中加以描述 不同的操作步骤产生不同的问题，分别报b

16、ug 如果有截图，请列出所附的图片信息4) 预期结果 不要参加实际结果的描述信息 描述要清晰，不要使用模糊不清的缩写词描述 如果有截图，请列出所附的图片信息5) 备注 防止写成大段落，要写得简单、易读 问题的特征 出现问题后的解决方法 对终端客户的影响情况 如果有必要，列出产生问题的配置环境 同样的问题也在其他模块发生需写明备注信息7.6.2 开发人员BUG解决1) BUG的原因2) BUG的修改方法3) BUG可以在哪个版本上进展验证4) 测试人员验证bug时，需要写明：验证了，在版本验证，是否通过，如果不通过需写明原因。如果在验证当前bug时有新现象产生阻碍了验证此bug，如此该bug不能关闭，写明没有验证的原因，并为新现象提bug。8. 标准文档测试申请单测试计划测试用例测试报告