美文网首页
测试流程以及参与人员的建议

测试流程以及参与人员的建议

作者: 猪儿打滚 | 来源:发表于2019-10-10 21:56 被阅读0次

一、参与人员

角色 职责
测试人员 - 根据Bug规范提交Bug
- 跟踪并验证Bug是否已解决
- 对有争议的Bug,需及时和开发、产品人员进行讨论,得到解决方案
- 对长期未得到解决的Bug,需及时和开发人员了解情况
开发人员 - 根据Bug的验证程度和实际情况进行Bug的修复工作
- 对有异议的Bug,需和测试、产品人员进行讨论,不可置之不理甚至私自关闭
- 定期review Bug,对Bug多的模块加强code review和单元测试,并对相关模块进行风险评估
产品人员 - 当Bug存在争议时,进行需求或解决方案的确认
- 必要时,从产品角度划分Bug修改的优先级

二、测试流程

一、需求分析/宣讲阶段

1.新项目:了解项目背景、项目整体功能模块和业务逻辑
2.迭代时期:着重负责的模块以及关联的模块,无关联模块也需要了解
3.共同点:记录有疑惑的地方,产品宣讲后进行提问

二、编写测试用例(思维导图or测试用例)

1.编写前,一定要先熟悉所要编写用例的模板/项目,可通过看多几次需求文档的方方式进行熟悉
2.根据个人习惯以及项目需求来进行选择
3.编写过程中,如果有疑问,可整理成文档,跟产品或开发进行询问(询问开发的主要是确定下代码逻辑)

三、测试用例评审
  • 对象
    测试用例
  • 流程
    第一轮:组内评审
    1.人员:项目组测试人员
    2.方式:测试人员编写完测试用例后,发邮件给项目组其他测试人员,其他人员进行评审。评审完毕后,右键方式发送评审结果给该测试人员
    3.评审内容:
    a.找出遗漏或有误的测试点、逻辑
    b.用例尽可能详细,但是不能啰嗦
    第二轮:用例评审会
    1.人员:开发、测试、产品
    2.方式:会议室举行会议,测试人员就测试用例进行说明。其他人员进行评审,现场提出修改意见
    3.说明内容:总结测试用例所涉及的模块、功能点、测试点以及逻辑
    4.评审内容:找出遗漏或有误的测试点、逻辑
四、 提交Bug

1.提交Bug的一些规范

  • 标题/主题【重点】
    1.简洁易懂,最好是能达到开发人员看到标题就能知道一些简单Bug如何复现、如何修改的效果
    2.小技巧:可在标题上带上Bug的模块路径,若是偶现Bug可注明为偶现
  • 类型/跟踪
    1.错误:测试人员添加,Bug
    2.功能:产品人员添加,新增的需求等
    3.优化:测试人员/产品人员都可添加,主要为前端页面的优化(或者需求性功能优化)
  • 功能模块
    1.Bug所处的功能模块,具体Bug所处的模块路径可在标题或Bug描述中进行说明
  • 测试环境
    1.操作系统、浏览器型号版本、网络情况等
  • 详细描述【重点】
    1.复现步骤
    a. 用简洁的语言描述清楚复现步骤,能够让开发人员知道,并能够复现Bug
    2.实际结果
    a.当前Bug的实际结果,一般用截图进行说明,更清晰直观
    b.尽可能多地提供Bug的信息给开发人员,包括不仅限于:接口情况、日志情况
    3.预期结果
    a.期望Bug修复后想要达到的结果,一般情况下以需求文档为准
    b.预期结果不能模棱两可的情况,不能带有可能、也许、应该等字眼
  • 严重程度/优先级
    1.不同的Bug管理工具有不同的等级划分,无严格规定。测试人员结合实际情况来进行定级
  • 状态
    1.在下面的“跟踪Bug-状态”进行说明
  • 指派人员
    1.一般是负责该Bug的开发人员,特殊情况是产品人员
    2.如果不知道负责该Bug的开发人员,可询问项目的测试或开发负责人
  • 测试人员
    1.提出Bug的测试人员
  • Ps.
    1.截图是个好东西,能够更直观地进行Bug描述,但也不能滥用。
    2.可根据实际情况来添加/删除上述字段
五、跟踪Bug
  • 状态
    1.进行中:Bug修复工作正在进行中
    2.已解决:开发已解决完毕,指派给测试人员进行验证是否已修复
    3.返修:测试人员验证后,发现Bug未修复,则需要返修
    4.已关闭:确定修复完成,则关闭Bug
    5.已拒绝:开发人员认为不是Bug、不需要修复则选择此选项(需经沟通后)
  • 根据Bug此刻处于的状态来进行跟踪工作
    1.进行中
    a.若长期处于该状态,则和负责开发进行沟通,了解情况
    2.已解决
    a.对该Bug进行验证,如该Bug可能会受到缓存影响,则先清除对应浏览器/小程序的缓存(app则卸载旧版本,再安装新版本)
    3.返修
    a.返修时,要写上返修原因(文字or截图)
    b.如果当前Bug的修复工作已解决,但是引发了新的Bug,则关闭当前Bug,重新提交个新的Bug
    4.已关闭
    a.验证Bug已得到修复后,测试人员进行关闭Bug后的状态
    5.已拒绝
    a.开发人员如果拒绝修复Bug,则查看其备注,然后询问产品人员的意见。如果同意则进行备注,如果不同意则三方进行商量,并就商量结果进行下一步工作(仅备注或备注并重新打开该Bug)
六、执行测试_回归测试

时间点
1.系统/模块目前已发现的Bug都处理完毕(“已关闭”状态、特殊Bug已进行合理处理)
2.系统上线之前
3.系统上线部署完毕后
内容
此时可对系统/模块的主要流程、易错流程进行一遍测试,看是否有新Bug或者漏掉的测试点


三、一些建议
测试人员
  • 需求方面
    1.在进行需求评审/宣讲之前,尽可能浏览需求文档,对项目的情况有个初步的认识,避免宣讲时从0开始
    2.从需求评审/宣讲阶段就要开始对项目的背景、需求进行初步的认知和了解
    3.在编写测试用例之前,要多看几次需求文档
    4.最大限度去理解需求,对需求不明的地方进行总结和记录,最好是形成文档,然后和产品、开发进行沟通,确保三方对需求的理解能够达成一致
  • Bug方面
    1.提交Bug时,要按照Bug规范进行提交(上方的提交Bug中有简单说明)
    2.提交Bug时,尽可能提供更详细的信息给开发人员,包括不仅限于:接口情况、日志情况
    3.开发人员对Bug有疑问时,要配合开发人员
    4.对于返修状态的Bug,一定要进行备注,并且这个备注的目的要和提该Bug时的一样,否则可能需另外新建Bug。
    5.对多次返修状态的Bug,要当面和开发人员进行沟通,提高Bug的解决效率
    6.对长期没能得到解决的Bug,需要和相关人员沟通,了解情况,视情况进行处理。
    7.在遇到和开发有歧义的Bug,在和开发进行沟通无果后,需要叫上产品人员也参与讨论。在讨论出解决方案后,不止产品人员需要更新文档,测试人员也可以进行备份
    8.在关闭Bug时,可进行简单的备注说明,就算是一句已解决也好
  • 文档方面
    1.除了测试用例以外,也可以形成另外一些文档:需求询问、工具使用、经验总结等文档(非硬性要求)
  • 沟通方面
    1.在沟通时要先说清楚自己的操作场景以及出现的问题、想要达成什么效果。避免浪费时间在无用的沟通上
    2.如果有现成的文档,有相关疑问可先进行查阅。如果还不理解,可询问相关人员,减少沟通上所花费的时间
开发人员
  • 遇到需求不明的地方,需要询问产品人员,不可自以为地去实现,以免出现没必要的Bug;在确定方案后,需通知测试人员,要达成三方对需求的理解一致
  • 对有异议的Bug,需和测试、产品人员进行讨论,不可置之不理甚至私自关闭
  • 如果测试人员对Bug的指派人员指派错误,需通知该测试人员,并指派给真正的负责开发人员
  • 对Bug的描述不清楚,或无法进行Bug的复现时,需及时和提交Bug的测试人员进行沟通,而不是简单的修改状态后就置之不理(这种情况不能修改状态,需沟通后再决定后续操作)
  • 如果和测试人员对某Bug有歧义,则可叫上产品人员参与讨论,在讨论出确定的方案,并且产品人员更新了文档后,就更新后的需求进行开发。
  • 开发人员在转交指派人、切换状态时,需要加上备注。比如说解决了Bug,切换成已解决状态时,需简单说明下Bug的产生人员。这样有利于开发人员review Bug以及自我提升
产品人员
  • 需求文档尽可能详细,明确,避免出现有歧义或模糊的情况,这样能减少歧义的出现
  • 同个功能的词语要一致,不能出现一意多词的情况,这样容易产生歧义
  • 对于同事的资讯,尽量提供帮助,并确定解决方案
  • 如果有Bug指派给了产品人员,则在讨论确定了解决方案后,产品人员需对该Bug进行处理,并进行备注说明解决方案,并同步需求文档以及通知项目的相关人员
  • 在确定了解决方案后,需及时更新需求文档,并通知相关人员以及测试、开发负责人(涉及较多的,需经过项目经理,架构师等人员的批准;并且可添加一份文档修改的日志性文档,方便回溯和寻找)
  • 产品人员若发现了Bug,可通知测试负责人,提醒其进行跟进,必要时可协助Bug的复现

相关文章

  • 测试流程以及参与人员的建议

    一、参与人员 二、测试流程 一、需求分析/宣讲阶段 1.新项目:了解项目背景、项目整体功能模块和业务逻辑2.迭代时...

  • 工作流程

    所在公司的流程 1、需求评审:产品、开发、测试、UI等相关人员参与,需求会提前发送至邮箱,评审期间提出疑问/建议,...

  • 测试工程师-笔试题

    一、测试人员在软件研发过程中,需要参与哪些流程环节?每个环节存在哪些风险? 答:需要参与流程为:需求分析审查、设计...

  • 可用性测试怎么做2-正式测试

    一、测试记录 二、录像录音 参与测试的人员: 主持人:引导整个测试流程 记录员:记录操作行为,访谈内容 发现的问题...

  • 中高级测试人员怎么保证产品质量

    测试流程的把控: 需求的把控 测试人员必须参与需求评审,提前介入项目。要深度挖掘显示需求和隐式需求(这部分东西比较...

  • 与测试流程有关的二三事

    我目前的工作流程如下: 1.需求评审:测试人员参与度不高,主要是开发和业务人员(产品)主导讨论 2.用Excel撰...

  • 测试基础

    一、测试流程 1.需求澄清-参与人员:开发、测试、产品 2.开发串讲-开发自己写的开发方案,针对需求实现内容 3....

  • bug?软件测试之缺陷管理流程

    缺陷管理流程图 在QC中,缺陷的管理流程: 流程中的角色: 1、 测试人员:进行测试的人员,缺陷的发起者; 2、 ...

  • 测试准备与环境部署---测试前置

    一、什么是测试人员前置 测试人员介入项目流程的时间 1、前期 国外-----全流程 国内-----RD提测后 2、...

  • 测试用例的流程和注意点

    测试用例的流程 1,在产品的原型确认后,召开原型讨论确认会,此时参与人员:相关后台开发、测试、产品、前端开发等.2...

网友评论

      本文标题:测试流程以及参与人员的建议

      本文链接:https://www.haomeiwen.com/subject/mdwulctx.html