赞
踩
前言:
规范测试流程,提高测试效率和测试质量。
测试流程是开展测试工作的基础,本规范对测试流程中的关键节点进行约定,明确测试时必须进行的工作项,所有测试任务必须按照本规范执行。
本流程只适用于测试部内部,测试组所有参与的项目或者任务都可以参照此流程,可根据实际的项目情况对此流程中操作步骤进行删减。
需求评审未开始前,产品经理需要输出需求文档提前(至少提前1天)同步给到对应开发、测试人员。
1)若产品经理未提前给到需求文档,测试人员需推进产品经理在评审前把需求文档给到大家,并且有权拒绝临时加塞的需求评审。(临时加塞的需求评审是指:未提前沟通时间,未提前给到需求文档的需求评审,或者是 临时给到需求文档,立马开会的需求评审,这种会议效率极低)
2)测试人员需要在需求评审前查阅需求,尽可能的发现需求中的问题,描述不清晰的地方,可以让产品经理细化需求。
需求评审未开始前 / 过程中 / 结束后,有什么需求不明白的地方,可以全部汇总在一起,整理为一个需求清单然后统一发给产品确认。
1)若有需要紧急确认的需求,可以直接先找产品确认。
2)若不需要紧急确认的需求,可以一起给产品确认。
3)若当前产品不能及时确认的需求,需产品给出最后确认时间。
4)若需求清单确认完成后,测试需要将需求确认清单发送在钉钉群里同步给相应的开发,减少二次确认成本。
对于非必要需求评审的小需求、小优化项,产品经理需要提前说明,测试人员也可以主动确认是否需要需求评审。
1)对于不开展需求评审的需求,测试人员同样需要充分理解需求,对于有争议且无法在钉钉群内沟通达成一致的需求,有必要让产品组织评审确认。
2)有什么需求不明白的地方,同样需要整理需求确认清单,确认完成后发送在钉钉群里同步给相应的开发,避免开发实现与需求不一致。
1)明确测试在需求评审阶段已经开始。测试工作是贯穿于项目的整个流程中的,并不是在开发完成编码提测后才开始的。需求阶段要进行需求评审,每个阶段都有测试需要做的工作,测试人员首先要有这个意识。
2)认真听取需求评审过程中不同的意见,相关内容及修改的地方。参加需求评审的过程中,必须认真地听取需求讲解的内容,大家讨论的不同意见。
3)积极从以往的经验中提出自己不同的意见。在需求评审的过程中,根据自己以往的测试经验,对业务的掌握情况,用户使用的习惯,对本次需求提出不同的意见。从需求评审阶段对需求进行测试,及早地发现需求中存在的问题。
4)督促大家对所有异议达成一致。需求评审时难免出现不同的意见,大家需要进行讨论一下,从而找到最优的解决方案。当然也有对异议达不成一致地方,测试需要协助会议的组织者督促大家达成一致,或是给出解决方案的时间节点。
5)根据需求内容明确测试范围。确定本次需求需要保证的内容,可能影响的原有业务,是否需要其他业务的支持等。
计划与控制是测试第一个阶段的内容,后面所有的工作都是以测试计划为指导进行的,所以测试计划中的时间、任务和资源的安排显得很重要。
项目的测试计划是归属在项目计划中的。
1)测试主要负责人需要根据项目需求情况、预估填写测试时间;
2)预估后测试组长、产品经理会根据预估情况进行调整,敲定后以测试计划为准;
3)测试计划实施过程中,如有延期风险的情况,需要提前及时提出&说明原因(开发提测延期/冒烟不通过可能会导致延期/测试执行延期/并行任务冲突可能会导致延期),再协商应对方案(资源协助/测试时间调整/测试任务调整等)
日常需求的测试计划是根据对应迭代的上线时间来安排的。
1)测试组长会根据组员对需求的熟悉程度、工作饱和度等情况来安排任务指定给测试人员(一般需求的测试只会安排一位测试人员);
2)需求的测试任务的截止时间为一般统一为上线前1-2天,测试人员需要根据自己的任务合理安排每一个测试任务,确保测试按时保质完成,输出测试报告,并给到产品验收的时间;
3)测试计划实施过程中,如有延期风险的情况,需要提前及时提出&说明原因(开发提测延期/冒烟不通过可能会导致延期/测试执行延期/并行任务冲突可能会导致延期),再协商应对方案(资源协助/测试时间调整/测试任务调整等)
测试用例设计是一切测试的基础,也是一个优秀测试人员的基本功,注意这里用的是“设计”而不是简单的“编写”,一份合格的测试用例一定是设计出来的,它需要从各个角度去思考以覆盖到所有可能的测试点,最终尽可能达到系统没有任何缺陷的完美程度。
测试用例是测试过程中操作行为的方法指引,用例让整个测试过程有章可循,高效快捷,不至于有所疏漏,除以下情况外,其他需求都需设计测试用例。
可以不用设计用例&用例评审的场景:
生产修复上线Bug
不需要测试人员测试的需求(产品测试/开发测试)
小需求(UI、文案、交互、控件调整等小需求)
●功能需求有大有小,有的很小的需求甚至只是简单的改一行文字,这种简单的需求,测试的时候自然是不用画思维导图的,当然也不用设计测试用例,需要设计测试用例的往往是中等以及较大的系统功能,也就是实现逻辑复杂,所谓逻辑复杂站在测试的角度可以理解为,不能一眼就看到是否正确实现的功能,要验证其正确性往往需要在一定的条件下,进行一系列合理操作才能看到结果,这个时候我们就认为它是复杂的,需要画思维导图辅助设计测试用例。
在需求确认完成后,可以先列一个大纲,把所有的功能点或者流程全部梳理一遍,会对你写测试用例起到事半功倍的效果,这点主要是辅助测试用例设计,不作规范要求。
1)最好一个功能点写一个即可;
2)做到条理清楚、层次分明、简明扼要。
测试用例编写可以按照功能划分或者业务划分来划分:
1)一个功能点最好只写一条用例,不要一个用例里面几个功能点糅合在一起,这样不方便用例执行;
2)若用例编写过程中需要立即确认的点,可以立即找产品确认;
3)若不需要立即确认,可以先标红表示,然后记录在需求确认清单再进行统一确认;
4)测试用例编写可以用 Xmind/Excel 模版编写;
5)测试用例需结合可视化,方便展示(增加流程图/原型截图)。
一个测试对象的时候至少从以下六方面来考虑:
1)功能性
2)兼容性(钉钉、PC端)
3)易用性
4)可靠性、性能(考虑数据量大的情况加载数据是否较慢)
5)安全
●考虑页面权限、按钮操作权限、数据权限、导出权限等;
●考虑快速连续点击操作按钮,数据是否允许重复操作;
●考虑是否有安全漏洞。
6)生产历史数据兼容
以上考虑的点需在测试用例中体现。
测试用例管理在云效-测试管理-用例库,根据产品分别管理 。
在用例评审完成,修改为最终用例后,必须按模板导入云效对应产品用例库进行管理。(个别项目测试时间紧张的情况先把用例的Xmind文档线上化管理。)
用例需要根据模块-页面进行管理,导入数据时,注意根据云效支持的用例模版导入。
Xmind 用例模版示例:xxx项目_测试用例模版
Excel 用例导入模版:xxx项目_测试用例模版
请至钉钉文档查看附件《测试用例导入模板.xlsx》
如无需评审的用例,可以直接在云效-测试管理-用例库Web端编写用例,无需导入,提高效率。
云效导入用例帮助文档:https://help.aliyun.com/document_detail/323525.html#p-x3k-6og-8ra
用例评审是测试流程中必备的环节。
测试用例设计者组织用例评审会议,具体细则内容如下:
1)项目级开始用例评审工作前,测试人员需优先组织测试组成员开展内部用例评审工作,提前发现问题及时修改,为对外评审做好准备(涉及多位测试必须内部评审);
2)非特殊情况,必须在开发提测之前,完成测试用例 & 组织测试用例评审;
3)预约用例评审时间与对应的产品经理、开发、测试、项目经理及项目组相关干系人提前确认沟通好,确认好之后在群内发布用例评审通知,创建日程&预约会议室,并提前把用例发至群内让大家查看;
4)用例评审会开展之前,测试人员需提前在会议室准备好设备,做好远程连接准备;
5)用例评审过程中测试人员评审记录问题问题,评审通过后对用例进行更新维护;
6)用例调整后,把用例(含冒烟用例)发至群内艾特对应人员,并将用例管理在云效上。
测试用例设计者根据需要功能点宣读用例,内容包括:
1)时长最好控制在1H~1.5H左右,每次会议不得超过2H(如果是超2H,但每2H是不同开发参与,允许);若东西太多,可以分多次评审;
2)用例评审时,表达要准确,思路清晰,语速适中,宣讲完一个模块后需要停下来问问大家是否有问题提出;
3)陈述时,要有主题和层级,若主题/层次切换,要有对应的语言过渡;
4)可视化结合:针对页面时,需先打开 对应的UI页面/原型/设计图;
5)评审过程中,参与人员会存在视觉和听觉疲劳,主讲人要抓住重点和重要人员;
6)根据原型、系统模块、功能点简要说明:重点评审业务模块复杂、需求优先级别高的模块;优先级较低的用例可不宣讲,内部已形成统一标准的用例可不宣讲(如有开发新人参加评审,已形成统一标准的用例也需要宣讲)
7)用例评审前,需要把有疑问的问题全部确认好,只保留产品经理无法敲定的问题才在用例评审会上讨论;
8)用例评审时,若有冒烟测试用例时,也需展示,简单宣读,并提及对应的开发。
用例评审时相关人员必须全部到场,由测试人员进行组织。用例评审完成后测试人员把用例评审记录整理好,发送到钉钉群内,让相关研发人员查看一下还有没有遗漏或者记录错误的点。
1)测试用例评审通过或者未通过,需要做好相关记录。若未通过,请填写好未通过的原因。
2)若评审过程中有争议的地方,可以先记录在案。然后私下讨论,并把最后结果同步给项目组内成员。
3)若评审过程中修改的内容较小,可立即现场及时修改。
4)若评审过程中修改的内容较大,可以先记录,会议过后再修改。修改完成后,钉钉群里同步给相应的项目成员。
日常迭代工作中针对用例设计、用例评审的特殊情况,进行特殊处理,但是日常工作中必须尽量减少此类特殊情况,并且针对特殊情况,必须要有原因说明。(注:项目级必须有用例输出、用例评审环节,不做特殊处理。)
日常迭代工作中特殊情况举例:
1)临时插入测试执行任务,直接测试,无用例编写时间。
● 特殊处理:开发提测后,测试先冒烟保障主流程功能正常,边测试边梳理测试点,后期补上完整用例。
● 缺少流程节点:用例编写、用例评审、开发冒烟用例执行。
2)迭代前期已安排的中小型需求(非临时插入任务),用例编写期间时间不够(原因包括不限于:可能是其他任务插入导致的用例编写时间不够/其他任务优先级更高,需要并行处理),开发即将提测,测试执行时间不多。
● 特殊处理:测试可以先输出一份冒烟测试用例给到对应的开发执行,后期补上完整用例。
● 缺少流程节点:用例编写、用例评审。
3) 其他特殊情况,未一一说明,围绕:保障质量,把控风险,灵活应变,按期发布来调整,以上特殊情况都需与测试组长、产品经理说明。
开发提测必须满足测试准入标准。
1)填写提测申请,并提醒到相关干系人(产品经理、对应测试人员、开发组长、测试组长)
2)冒烟测试通过
●提测申请填写要求
1)一个提测申请对应一个需求;
2)一个需求仅前端时,由前端开发人员编写;
3)一个需求仅后端时,由后端开发人员编写;
4)一个需求包含前后端开发时,需联调完成后一并提测,由后端开发人员编写;
5)填写完成之后,需要抄送给对应产品经理、对应测试负责人、开发组长、测试组长。
●提测申请包含内容
必须包括:提测需求名称、提测端、对应开发、对应分支名、自测情况。
1.开发人员填写提测申请访问链接:(类似于调查问卷的方式填写)
2.开发人员填写申请提测需求、提测申请人、开发冒烟情况、提测端、提测分支、备注,提交表单(全部开发人员都可以填写,外部人员也可以填写)
3.填写完成后,钉钉群内可通知到大家(只能设置钉钉内部群通知)
不需要提测申请的需求场景:
1.生产紧急Bug
2.不需要冒烟测试的需求
测试用例编写+评审完成后,开发不一定马上会提测,在正式测试之前,以下工作测试有必要自己提前完成,推进开发完成:
1)测试数据准备完成(测试数据由测试、开发共同准备,日常迭代下,可以提前准备测试数据的情况下,需将数据准备好);
2)在开发联调阶段,定期确认开发进度(风险前置预警,必须)
○提测前1-2天:开发进度是否正常,是否能按期提测
○联调当天:确认联调进度是否延误,是否正常进行
○自测当天:开发冒烟是否顺利
○提测当天:提测是否能按期提测
●测试负责人可以要求开发主动同步以上进度。
3)一旦上述情况发生,由测试负责人主导,群内提出风险点,讨论解决方案。必要时组织产品,研发,项目经理一起重新评估时间,确认是否适当增加测试时间,或延迟发布时间;
4)开发完成开发、自测、提测,测试环境搭建完毕。
测试执行阶段要做的事情:
① 冒烟测试 ② 测试执行 ③ 提交Bug,记录结果 ④ 验证Bug,回归测试 ⑤生成测试报告
1)用例编写时,需提取出冒烟测试用例,冒烟测试用例是总用例的 5-10%;
2)冒烟测试用例在用例评审的时候,需要宣讲并提醒对应执行开发;
3)冒烟测试用例评审后,修改无误后需给到对应的开发;
4)提测之后,测试也需执行同份冒烟用例,验证开发冒烟情况。
5)测试进行冒烟验证:
5.1)若冒烟不通过,立即打回,并记录冒烟不通过理由。
5.2)若冒烟通过,直接进入系统测试。
开发冒烟用例执行通过率80%及以上,不通过则打回
无冒烟测试用例的,冒烟测试通过标准:主业务流程通过,增删改查操作正常,没有系统崩溃,页面跳转空白,主功能缺失,功能严重错误等阻塞问题,具体参照:《IT_开发提测标准规范_V1.0(正式运行)》
1)测试需提前在 请至钉钉文档查看附件《IT_开发提测冒烟情况记录》填写开发冒烟的信息与用例条数;
2)推进开发执行冒烟用例,填写开发冒烟通过条数;
3)提测之后,测试执行冒烟用例,填写测试冒烟通过条数。
1)严格制定的测试计划、测试时间进行测试,满足质量优先,进度前紧后松原则;
2)测试执行中,评估测试执行时间不足,需及时上报风险;
3)测试执行需对用例描述的检查点逐一检查,避免遗漏;
4)执行过程中发现有前期设计遗漏用例,需补充到用例文档并执行验证;
5)执行过程中发现开发实现方案更优/实现效果与需求存在细小差别,但与需求不一致的情况,需与产品沟通确认;
6)用例的执行情况需要在用例管理工具中标明(用例通过、用例不通过、未执行、阻塞);
7)使用测试管理工具记录、提交、跟踪缺陷,并督促开发人员复现、定位、修复缺陷,然后验证和关闭缺陷;
8)复杂需求(单个需求测试时间≥ 7个工作日),建议先内部测试后才能给到产品验收;
9)新人入职3个月内的测试任务项,建议先内部验收后才能给到产品验收;
10)产品协助测试:在需求评审期间/测试执行前期,若紧急插入任务,测试组内无资源协调完成测试,但产品又想按照某个特定日期上线,产品根据需求的优先级高:可以由自己来做测试 ; 也可以与用户需求澄清时,沟通降低需求优先级为低:来延后需求的上线时间,由测试人员来承担这部分的测试工作。(尽量减少产品来做测试的情况)
测试环境缺陷统一在云效平台-需求管理项目-左侧进入缺陷,进行管理。
详情见:《测试规范_缺陷管理》测试环境缺陷管理
测试报告是对测试的过程和结果进行详细记录的文件,是测试阶段最后的文档产出物。
项目系统测试结束,要求输出测试报告。
项目的测试报告根据模版输出:《xxx项目_测试报告模板》
日常需求测试结束,同样要求输出测试报告。
日常需求测试报告主要体现测试通过截图。
日常需求的测试报告根据模版输出:《xxx日常需求_测试报告》
可以不用输出测试报告的场景:
1.生产修复上线Bug
2.不需要测试人员测试的需求(产品测试/开发测试)
3.小需求(UI、文案、交互、控件调整等小需求)
4.紧急上线需求(来不及输出测试报告)
5.需求评审/用例评审中约定不需要输出测试报告
日常:
1.产品可根据测试提供的测试报告、测试截图进行验收;
2.复杂功能有必要验收(复杂功能满足以下条件之一:单个需求测试时间>=3天/人,需求涉及3个以及3个以上部门)
3.复杂功能产品有必要到测试环境进行验收测试,尽量从主流程、测试报告未覆盖的场景、贯穿上下业务流程场景、用户习惯等角度进行验收,确保测试无遗漏;
4.日常验收以及打回标准见:《产品_内部验收通过标准_V1.0(试运行)》;
项目:
1.项目上线前,产品必须验收;
2.项目验收以及打回标准见:《产品_内部验收通过标准_V1.0(试运行)》;
3.验收问题需要记录:《验收项名称_验收问题模版示例》;
日常需求不做UAT验收测试强制要求,产品经理可以根据需求复杂程度、是否有必要UAT测试等多角度来看是否需要UAT验收测试,日常需求UAT测试全权由产品把控、负责、安排。测试人员负责UAT测试的问题复现、定位、提交、验证,反馈问题进度。
项目上线必须要有UAT测试环节。以下UAT准入标准、UAT测试细则、UAT准出标准均为 项目UAT验收测试标准。
1)转UAT测试前提准备、资料齐全(需求文档/操作手册、UAT环境&数据准备、UAT场景用例、SIT测试问题解决情况)
2)UAT测试培训
项目UAT测试分为以下5个行动项,各行动项下又细分为子项;
产品经理为UAT验收测试的主负责人,负责把控、推进UAT验收测试;
项目测试负责人、项目测试人员配合产品经理完成UAT验收测试中的细项,是UAT验收测试的次要负责人;
UAT业务测试人员主要负责业务数据确认、以及UAT测试执行;
1)UAT测试用例执行率达到 100%(无效用例除外);
2)所有发现的 BUG 都已记录在《问题登记表.sheet》并且全部修复完成、UAT验收通过;
3)UAT不修复/新需求/产品确认非 BUG 的需在《问题登记表.sheet》的【备注】中记录。
需满足上线准入要求才可以上线。
日常&项目上线需发起:【IT004 系统发布管理流程】 以及测试通过/产品验收通过 ,项目需UAT测试通过。
日常迭代上线前,产品需要走OA流程【IT004 系统发布管理流程】,目的:通知相关人员确认上线内容、分支。测试人员需要检查云效发布文档的内容是否为可上线的内容,上线后,需要对线上可验证的内容进行验证、相关数据字典配置等。
项目上线前,参照项目的上线计划来安排上线验证计划,同样需要走OA流程【IT004 系统发布管理流程】,需上线后需要根据项目上线计划中的测试验证项来验证内容。
1)开发在上线前需要检查有没有要删除的数据或者日志;
2)开发要申请的数据库,或者操作权限是否都已申请;
3)上线是否有上线顺序;例如:先system服务,后端才能上线。
4)上线是否有需要注意要的点;例如:先配置xx配置项,PC方可进行验证。
5)是否有历史数据需要处理;
6)数据字典、配置文件是否已配置;
7)相关账号是否已开通。
上线后,测试人员需要对线上可验证的内容进行验证,确保上线后,生产环境正常运行,且本次发布内容成功上线。
验证需要关注本次上线内容成功上线,之前原有功能正常; 如果1个功能拆分为多个版本的,本次只更新某个版本,需要确保其他不上线的版本功能未被带上线。
如果无法验证的功能(比如:需要操作用户数据的操作)需要关注线上运行状态,观察是否有潜在的问题。
生产缺陷都需记录至IT服务台,详情见:《测试规范_缺陷管理》生产环境缺陷管理
●项目制的允许项目上线初期(1个月过渡平稳期)先表格登记,最终把表格内容导入到云效缺陷管理中。
上线后发现生产问题,若是测试发现/用户发现反馈到测试,需第一时间通知到产品,产品必须知晓。上线后发现缺陷,各自职责如下:
产品:了解缺陷、跟进上线事宜、IT服务台缺陷流转
测试:了解缺陷、复现、测试验证、IT服务台缺陷流转、上线验证
开发:定位、修复缺陷
运维:发布紧急生产hotfix
测试复现后,确定是Bug 或未排查到原因,需给到开发组长这边安排开发资源定位排查、修复。生产缺陷优先级最高,根据缺陷的严重程度,生产事故大小安排当天时间发布,或跟随最近一次发布迭代一起发布。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。