测试过程遇到的问题和提升方法
早上上班看到鹏哥零点46分在产研群发了季度目标总结的内容。
从中受到启发，之前我有一个困惑，就是现在自己不清楚后续的测试任务，那好像不怎么好去确定测试目标。
基于现在可能不是非常清楚后面非常具体的工作任务，归类工作当中遇到的问题，思考是否有提升的方法。
需求理解不够充分
遇到问题
- 不少需求评审是被叫去临时参加，没有事先阅读需求，在评审时无法完全理解需求。
- 有些需求没有参加需求评审，需要自己负责测试。
- 需求规则描述不足够清晰。
- 需求描述与开发实现一致。
- 不熟悉新接触的项目。
- 没有更深入地理解系统。
提升措施
- 在测试前花时间仔细阅读并理解需求，有疑问向产品人员一一确认，并在对应需求的tapd下添加评论。
- 编写测试用例时，发现需求没有提及到的场景、规则，与产品人员沟通，并在对应需求的tapd下添加评论。
- 在编写测试用例前，主动向开发人员了解这次需求的改造点，原来系统、功能、规则是怎样的，现在是改成怎样，了解清楚后，根据自身对系统、功能、规则的了解设计测试用例。
- 测试过程当中发现开发实现与需求描述不一致的问题，向产品人员反馈，由产品人员确定最终要实现的效果，并在对应需求的tapd下添加评论。
- 接到新项目测试任务，了解需求后，列出疑问，首先向熟悉项目的人了解清除，再开始测试。测试过程当中充分记录，测试结束后进行条理化归纳总结。
- 由表及里从页面到涉及的数据库表、接口、数据流了解系统、产品、项目。
测试过程跟踪不够完善
遇到问题
- 没有测试用例进行测试。
- 没有测试计划进行测试。
- 没有统一登记待跟踪问题、待确认问题、优化建议问题。
提升措施
- 每一个测试任务都先设计再测试，首先确定测试策略，在时间充分的条件下，先编写测试用例然后再进行测试，在时间紧急的情况下也先编写出测试分析的思维导图再进行测试。
- 在测试过程当中，根据实际情况，剔除、修改、增加测试用例。
- 测试设计时，除了分析需求功能点的测试要点，也充分考虑需要进行回归测试的功能。
- 测试设计时，除了考虑功能性需求，也考虑非功能性需求的测试。
- 大的需求，召开测试用例评审会议，汇聚群体智慧，提高测试用例覆盖度。
- 小的需求，在进行测试设计后，主动向测试组长阐述测试思路。
- 每次测试在tapd记录一个台账，登记待跟踪问题、待确认问题、优化建议问题。
欠缺测试质量评估
遇到问题
- 完成测试任务后，怎么评估本次的测试质量，不能总是等到生产爆出问题后，才知道前面的测试不够完善。
- 测试过程当中提的缺陷，严重程度划分不清晰，现在绝大多数的缺陷严重程度都是一般，实际上应该是要划分缺陷严重程度，这是度量开发交付质量的一个指标。测试结束后要向开发人员反馈测试情况，让开发人员注意本次测试过程当中发现的缺陷，使其反思开发过程当中可以提升的地方。
提升措施
- 主动留意uat验收测试提出的问题，确认是缺陷的，反思为什么自己没有考虑到这个测试场景。
- 在测试结束后，进行测试总结。
- 主动留意测试组长提出来的问题，登记下来，提醒以后自己测试过程当中也要关注这些要点。
- 主动留意生产反馈问题，分析缺陷出现原因，分析漏测原因。
测试流程没有形成闭环
遇到问题
现在实际情况是下面的测试流程，有时候有部分是欠缺的。
- 需求评审
- 测试设计
- 用例编写
- 测试执行
- 测试报告
- 质量评估
- 持续改进
提升措施
- 在无法全局推动的情况下，局部推动。遇到问题，思考是否可以推动优化问题。
- 测试完毕，主动出具测试报告，说明本次测试范围，阻塞测试场景，测试缺陷情况。
