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

一、参与人员

二、测试流程

一、需求分析/宣讲阶段

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的复现