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