测试计划 CODEARTS TESTPLAN-缺陷处理流程和注意事项:缺陷处理流程

时间：2024-07-15 16:51:18

缺陷处理流程

开发和测试均是软件产品质量的责任人，在产品质量保障方面有着共同的目标和意愿，区别只在于从事的工作活动内容，缺陷处理流程的制定和落地应该本着作二者之间协作的粘合剂和润滑剂的目标，帮助实现互信、高效的协作，而避免作为不作为的借口和矛盾的引火线。以下讲述了一个完整的缺陷处理流程，在实际操作中可以借鉴。

发现缺陷
 在软件开发和测试中，随着代码和模块的叠加和层层调用，一个底层问题可能会表现出多个表象问题。最初发现的问题，仅仅是一个问题表象，此时不能草率给出问题内容和问题原因的结论，而需要做一番有逻辑的系统性分析。
- 首先，需要发散分析，除了发现的第一个问题表现外，是否还有别的问题表现，这些表现是同时存在的还是有一定的依赖关系、时间先后关系，需要叠加一些更多的测试操作步骤。
  例如：在一次测试中，发现使用手机号+验证码无法成功登录某IT系统之后，需要分析使用手机号+密码等其它登录方式、使用手机号+验证码登录“其它”系统，使用APP和浏览器或者其它设备登录、使用其它运营商的手机号是否也会出现问题。
- 其次，猜测问题的原因并验证是否是导致问题的原因。这里要避免把“测试步骤”作为原因，而应该分析测试步骤背后引起的数据变化作为原因，由此分析是否有其它场景会出现类似的问题，层层抽丝剥茧，尽量还原出问题的本质。如果是偶现问题，也需要尽量分析问题原因，请开发人员帮助定位定界问题。
- 最后，整理问题发生条件、操作步骤、问题表现。
重现缺陷
 缺陷如果无法重现，开发还是难以定位问题。一般而言，保证缺陷可复现的责任在测试人员，如果问题实在是偶现，难以找到确定性的复现步骤，说明问题根源很深，需要及时寻求开发人员的帮助共同做问题分析。测试人员重现缺陷需要做到：
- 首先，发现缺陷的测试人员，换一些输入数据或者组合、换一个测试环境，可以按照问题发生条件和操作步骤，重新还原出问题。
- 其次，其他人员（如开发）根据缺陷文字和截图描述，可以还原出问题。
确认缺陷
 测试人员在提交问题单之前，尽量和开发人员做一轮确认，包括：是否是缺陷而不是优化或者新需求，是否是重复问题，缺陷是否可以重现，是否需要补充问题日志等信息，缺陷严重程度定级是否准确，是否阻塞测试工作需要确定解决日期。

开发、测试确认缺陷时间不做限定，可以在发现问题到开发启动问题修复之前的任何时间，鼓励尽早进行信息确认，也不限定是否直接找具体的开发人员做确认工作，也可以把缺陷单提交至模块的负责人做统一确认和反馈。
提交问题单
 提交的问题单需要清晰、全面、可管理、可追溯。问题单需要有专门的缺陷管理系统，缺陷管理系统最好和需求、开发任务管理系统同源使用同一系统，以便于做统一的管理和规划。缺陷单一般包含问题单级别、类型、问题描述、根因分析、处理意见、测试建议、关联的测试用例、环境信息描述、开发定位所需日志、截图等。
修复问题单
 开发人员接到问题单后，初步分析工作量安排时间计划。除了修复问题单中描述的问题外，还需要举一反三，进一步测试可能关联的场景，做深入测试，发现可能的深层次问题，并解决。修复问题单后，需要在问题单中介绍问题的根因、发生问题的条件、解决问题的方法。有的缺陷管理系统还可以把问题单和代码提交记录关联，帮助做跟踪统计和追溯。
自验证
 问题修复后除了在本地开发环境验证没有问题外，还需要创建个人构建、部署至测试环境。测试环境尽量和测试人员使用的环境或者发现问题的环境保持一致，以尽量排除环境差异。在测试环境中进一步测试没有问题之后才算自验证通过。在DevOps工具中，可以通过个人级流水线实现个人构建打包、环境部署的全流程自动化，提高个人构建自验证的效率。
提交版本
 代码修复完成后，经过必要的代码评审，发布至目标修复版本的代码分支。
验证修复
 测试人员在测试环境部署包含缺陷修复的代码分支，验证是否完整修复问题。如果问题没有修复，或者修复引入了新的问题，需要把问题记录在缺陷单中，转回给开发人员做进一步分析和修复。
关闭问题单
 在回归测试最终验证问题已经解决，并且没有产生新问题的情况下才能正常关闭。关闭问题单一般只能有三类情况：问题解决正常关闭、非问题关闭、重复问题关闭。可以在问题单中添加一些说明和图片，记录在哪个版本中已经修复解决。