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

1、软件测试工作流程规XV1.0 xxxxx2017年4月20日修订历史记录版本日期修订模块修订者说明V1.02017.5.10文档新建技术部 TOC o 1-3 h z u HYPERLINK l _Toc480461012 1.目的 PAGEREF _Toc480461012 h 4 HYPERLINK l _Toc480461013 2.工作X围 PAGEREF _Toc480461013 h 4 HYPERLINK l _Toc480461014 3.工作职责 PAGEREF _Toc480461014 h 4 HYPERLINK l _Toc480461015 4.测试流程 PAGERE

2、F _Toc480461015 h 4 HYPERLINK l _Toc480461016 5.测试准备 PAGEREF _Toc480461016 h 6 HYPERLINK l _Toc480461017 5.1测试计划 PAGEREF _Toc480461017 h 6 HYPERLINK l _Toc480461018 5.2测试用例 PAGEREF _Toc480461018 h 6 HYPERLINK l _Toc480461019 测试用例设计方法 PAGEREF _Toc480461019 h 7 HYPERLINK l _Toc480461020 测试用例操作步骤 PAGER

3、EF _Toc480461020 h 7 HYPERLINK l _Toc480461021 测试用例选择准如此 PAGEREF _Toc480461021 h 7 HYPERLINK l _Toc480461022 5.3测试环境 PAGEREF _Toc480461022 h 7 HYPERLINK l _Toc480461023 5.4测试数据准备 PAGEREF _Toc480461023 h 7 HYPERLINK l _Toc480461024 6.测试执行 PAGEREF _Toc480461024 h 7 HYPERLINK l _Toc480461025 6.1测试准入条件

4、PAGEREF _Toc480461025 h 7 HYPERLINK l _Toc480461026 6.2项目测试阶段 PAGEREF _Toc480461026 h 7 HYPERLINK l _Toc480461027 6.3测试退出标准 PAGEREF _Toc480461027 h 7 HYPERLINK l _Toc480461028 6.4测试变更 PAGEREF _Toc480461028 h 8 HYPERLINK l _Toc480461029 7.缺陷管理 PAGEREF _Toc480461029 h 8 HYPERLINK l _Toc480461030 7.1BU

5、G管理流程 PAGEREF _Toc480461030 h 8 HYPERLINK l _Toc480461031 7.2BUG状态 PAGEREF _Toc480461031 h 8 HYPERLINK l _Toc480461032 7.3BUG解决方案 PAGEREF _Toc480461032 h 9 HYPERLINK l _Toc480461033 7.4BUG优先级 PAGEREF _Toc480461033 h 9 HYPERLINK l _Toc480461034 7.5BUG严重等级 PAGEREF _Toc480461034 h 9 HYPERLINK l _Toc480

6、461035 7.6BUG书写规X PAGEREF _Toc480461035 h 10 HYPERLINK l _Toc480461036 测试人员BUG提交 PAGEREF _Toc480461036 h 10 HYPERLINK l _Toc480461037 开发人员BUG解决 PAGEREF _Toc480461037 h 11 HYPERLINK l _Toc480461038 8.标准文档 PAGEREF _Toc480461038 h 11目的通过规X公司测试流程，确保测试工作的规X性和有效性，以验证软件产品的质量满足用户的需求。测试作为质量控制的一种有效，运行测试用例找出软件

7、中潜在的各种缺陷，通过协助开发人员修正缺陷来提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患和降低质量本钱。通过测试管理为产品与过程改良提供可靠的数据分析，起到缺陷预防的作用。本过程的方针：实施测试策划活动根据测试策划所规定的要求编写测试需求与用例，实施相关的测试活动管理测试活动中发现的产品缺陷工作X围测试人员在软件开发过程中的任务：参与评估软件需求，编写测试需求；根据用户需求，编写软件测试用例；在开发人员完成单元测试后，进展模块测试，以期尽早发现bug；根据软件测试用例，执行集成测试，寻找尽可能多的bug；对bug进展追踪与分析，保证bug与时得到修复；对软件性能进展衡量，并进

8、展测试总结，提交软件测试报告书。工作职责工作内容输出文档提交每天工时申报OA工时登记提交每周工作周报工作周报每月5号前提交上月工作考核评价表月工作考核评价表假如有加班/请假/调休，在OA上走相应流程加班/请假/调休登记测试组长，测试计划阶段提交测试计划、测试用例测试计划、测试用例测试执行阶段提交测试报告系统测试报告测试评估阶段提交遗留问题分析报告测试遗留问题分析报告测试流程需求需求评审产品需求人员开发人员测试人员开发人员写开发计划排期测试人员写测试计划排期通知部门所有人开发代码与自测编写测试用例运维人员部署测试环境测试用例评审产品需求人员开发人员测试人员测试人员执行测试开发修复测试通过测试报告

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

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

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

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

13、够代表各种合理和不合理的、合法的和非法的、边界和越界的,以与极限的输入数据、操作和环境设置等；测试结果的可判定性：即测试执行结果的正确性是可判定的或可评估的；测试结果的可再现性：即对同样的测试用例,系统的执行结果应当是一样的。测试环境根据需求文档提供的内容，和开发部沟通确定测试项目所需的软硬件环境，完成对测试项目所需软硬件资源的准备工作，使软硬件资源得到满足。测试数据准备完成对测试项目根本数据的准备操作，包括数据库连接、用户信息、用户角色权限、单位组织等信息和测试相关的测试数据。测试执行测试准入条件不承受无详细需求文档和开发说明的项目；需要测试的项目至少提前2个工作日提交测试进展需求分析；开发

14、人员经过自测通过，至少保证程序可以正常运行；对应的功能在正常流程下是可以正常使用。项目测试阶段测试人员依据测试计划和测试用例进展测试活动。测试一般分为两个阶段：测试执行阶段：该阶段测试人员测试出bug后将缺陷提交至缺陷管理库。回归阶段：开发修改完bug之后，测试进展验证回归。测试退出标准全部的测试用例执行完毕；按照系统测试计划完成了系统测试，系统测试的功能覆盖率达100；系统的功能和性能满足产品需求规格说明书的要求；在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准；系统测试后不存在1、2类缺陷；3类缺陷允许存在，不超过总缺陷的10。测试变更当需求变更，功能变化，测试人员根据变更情况

15、，评估测试变更所需时间，提出变更风险。如变更情况被项目组通过，测试人员将按上述流程进展变更测试。缺陷管理BUG管理流程重新打开Reopen提交BUG重新打开Reopen提交BUGNew确认BUG修复BUG关闭BUGClosed是否延期BUG验证保存BUGYNYNNYBUG状态激活新创建的bug；已解决但验证未通过的bug；已关闭的bug重新出现需要再次激活。已解决开发已经修改完成的bug。关闭已验证通过的bug或系统工程师确认转为需求的bug。BUG解决方案已解决Bug已经被修改，待测试进展验证。设计如此测试人员理解错误，无需改动，即无效bug。重复bug已经有同样的bug，需标明重复bug号

16、。无法重现根据测试写的重现步骤，无法重现bug。延期处理确实是bug，但现在不解决，以后处理。新增/变更需求分析确实是存在问题，但需求没有描述清晰，应指派给需求确认，进展需求的新增或变更。BUG优先级高阻止与此密切相关功能的进一步测试，需要立即修复。中必须修改，不一定马上修改，必须修改，发版前必须修正。低对系统的影响较小，如果时间允许应该修改。BUG严重等级严重一类不能执行正常工作功能或重要功能，因软件原因导致系统死机等，须马上修正致命错误。通常有如下情况：系统停机含软件、硬件或非法退出，且无法通过重启恢复；系统死循环；与数据库连接错误；数据库发生死锁或程序原因导致数据库断连；数据通讯错误或接

17、口不通；重要功能无法正常使用、功能不符合用户需求。一般二类影响系统功能或操作，应用模块错误使业务中止无法进展后续操作，主要功能存在严重缺陷，影响到产品的使用，但不会影响到系统稳定性。具体根本上可分为：业务流程错误或不完整；业务数据来源不正确、业务数据紊乱或丢失；业务数据保存不完整或无法保存到数据库；局部功能使用存在问题，不影响业务继续开展，但造成使用障碍；初始化未满足客户要求或初始化错误；功能点能实现，但结果错误；缺少数据有效性检查或检查不合理；删除操作不给提示；日志记录信息不正确或应记录而未记录；数据库的表、业务规如此、缺省值未加完整性等约束条件；在产品声明支持的不同平台下，出现局部一般交易

18、无法使用或错误；系统某些查询、打印等实时性要求不高的辅助功能无法正常使用。轻微三类使操作者不合理或者不方便或操作遇到麻烦，但它不影响执行工作功能或重要功能，次要功能，对产品使用影响不大。例如：程序在一些显示上不美观，不符合用户习惯，或是一些文字的错误。具体根本上可分为：缺少产品使用、帮助文档、系统安装或配置方面需要信息；联机帮助、脱机手册与实际系统不匹配；系统版本说明不正确；提示说明未采用行业规X语言；显示格式不规X；界面不整齐；软件界面、菜单位置、工具条位置、相应提示不美观，但不影响使用；辅助说明描述不清楚；提示窗口描述清楚；输入输出不规X；可输入区域和只读区域没有明显的区分标志。建议四类BUG书写规X测试人员BUG提交主题用一个简短的句子描述问题，不要写成一大段以进入问题模块路径开头，方便项目经理分派任务，以与开发人员定位问题描述问题时要