测试流程以及参与人员的建议
2019-10-10 本文已影响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的复现
