本文主要总结了日常测试中遇到的问题,并总结了相应的优化方案
产品要求文件是A,开发技术实施是B,要求文件与实施不符(产品最终可以同意技术实施计划B)
存在的问题：
- 由于测试同学分析需求时按照需求文档A进行分析，测试时需要重新返工按照技术B进行分析，中间浪费一点时间和人力，且后期分析时由于时间进度等原因考虑可能没有那么周全，容易出现漏测情况
- 如果产品不同意技术方案B的开发,技术也需要重新加工
优化方案：
- 开发需要仔细阅读需求文档,根据需求文档实施代码逻辑,在遇到与产品需求不一致时或有更好的程序时,产品提前与产品沟通,然后根据沟通实施程序
- 在开发过程中,加强与开发者沟通,并确认开发者是否按照产品要求文件实施
- 当产品进行自测试时,必须提高测试质量,特别是对测试的逻辑实现
产品开发的沟通要求不明确,双方不同意
存在的问题：
- 它导致了产品要求标记误差,测试误差被认为是新的约束条件,其扩展分析是很好的例子
- 当测试时被认为是未实现的开发要求,标记为错误
优化方案：
- 产品、开发、测试需调整沟通方式，尽量使用较能理解的语言描述问题、需求、实现逻辑、注意事项等
- 产品、开发、测试沟通完成后需要梳理调整需求文档，测试进行确认三方理解是否一致，针对不一致处，再次沟通直到三方理解一致
- 在实施开发时,加强产品与开发之间的沟通,并确认开发是否符合产品要求文件
例句不够完美,每次需要优化侧面测试时,甚至有时需要重新组合
优化方案：
- 每次花费大量时间,充分了解需求并优化实例。在实例分析阶段,跟踪实施实例,了解它们是否符合实际场景,并优化它们
- 要求必须了解实现前后需求/缺陷优化的逻辑、修改的领域和接口、涉及的范围和考虑
当产品和开发讨论修改文档和同步测试的要求时,部分信息没有更新
存在的问题：
- 学生信息的测试落后,开发实现的结果与产品要求不一致,误认为是错误
- 要求改变,信息没有同步测试,例分析方向误差需要重新显示,浪费时间和精力
优化方案：
- 测试前需要和产品开发重新确定需求文档、实现逻辑和代码执行逻辑是否改变,如果如此,产品是否同步更新需求文档
- 要求产品、开发和测试尽可能地了解问题的三个方面(不要只了解一个方面,导致另一个方面的信息缺口)
在测试之前未知的实现逻辑和代码执行逻辑
存在的问题：
- 不考虑代码的实现逻辑不够完善,例如分析
- 无法确定客户端或服务端是否是一个问题,导致及时的错误修正
优化方案：
- 与开发确认问题/需求优化程序(旧逻辑、新逻辑)的原因,分析原因和测试范围
- 当产品和开发讨论优化点或问题时,你可以倾听与范围、实现逻辑、考虑等有关的需要/错误优化。