测试人员最本质的工作就是发现Bug，提交Bug，验证Bug，推动Bug的解决，直到软件达到发布标准，提升质量软件，提高工作效率和质量。1、什么是漏洞？BUG在软件中，狭义的概念是指软件程序的漏洞或缺陷，广义的概念还包括测试工程师或用户可以改进软件的细节，或与需求文档的差异。功能实现等2.Bug生命周期缺陷在生命周期中的状态：新增-->assign-->resolved-->待检查-->closefoundBUG-->submitBUG-->assignBUG-->开发并确认BUG->研发修复BUG-->回归验证BUG-->验证是否通过-->关闭BUG1，找到bug1）按照测试用例操作，发现不一致有了测试用例的预期结果，就可以称之为bug了。2）测试用例不能穷尽，总有超出你预期的因素，或者神操作出现的bug。3）成本问题，没有足够时间写测试用例，发现bug2，提交bug 提交缺陷时，先尝试描述缺陷的属性。Bug重现环境、Bug类型、Bug级别、Bug优先级以及详细重现步骤、结果和期望等。 当然，在提交问题之前，我们首先要确保这个缺陷没有被提及，以免被导致重复缺陷票。3.分配错误的步骤不是必需的。它与项目模型有关。在一些公司，测试部门独立于开发部门，因此测试人员不确定哪个开发人员负责他们正在测试的模块。在这种情况下，测试人员将问题统一分配给项目组长或经理，项目组长（或经理）确认问题后再次分配给相应的开发人员。 一些测试人员穿插在不同的研发团队，所以不同开发人员负责的开发模块非常清晰。这时候可以直接将问题分配给相应的开发人员。 还有一种情况，这个问题本来应该是开发者A负责的，但是由于开发者A调动或者离职，一些问题就交给了其他人员处理。“分”强调上级对下级；“转”强调的是同级之间。4.确认缺陷当开发人员收到缺陷时，他首先对其进行分析和重现。如果分析后不是缺陷（可能是测试人员不理解需求）或者无法重现问题，那么需要将这个问题返回给测试人员并说明原因。如果确认为缺陷，则需要进行处理。5.修复BUG，延迟处理 处理完问题后，需要判断是否延迟处理。有些需求已经确认是问题，因为它们可能只在极端情况下才会出现，或者系统架构需要调整变更，或者它们的优先级很低，所以不需要处理这个问题（或者修复在下一个版本）。Fixing 延迟处理可以临时修复（“修复”是QC中的称呼。）一般修复的问题需要项目经理和测试经理协商后修复。处理缺陷 开发人员在确认需要处理的问题后进行处理。（比如redmine支持处理人员时时更新问题的处理进度，比如处理30%，处理80%等，当然也不一定非要时时更新处理进度对于可以在短时间内修复的问题。）6.回归验证BUG回归缺陷对于测试人员来说是一项非常重要的工作，它有三个入口和两个出口。 确认非缺陷问题：对于提交的缺陷，开发人员将其作为非问题处理或无法重现，然后直接传递给测试人员进行回归。测试人员再次确认，如果开发人员所说的属实，则关闭该问题。如非开发者表示由于问题描述模糊或其他原因导致问题重现，请再次说明原因并反馈给开发者。 确认问题修复：再次确认开发者修复的问题，如果问题确认，则关闭问题。如果确认失败，重新打开issue并转发给开发者。 确认已修复的问题：有计划地确认已修复的问题。随着时间的推移版本更新，一些已修复的问题可能不再存在。此类问题应及时关闭。一些固定的问题仍然存在，已经成为紧迫的问题。对于此类问题，应及时开放给开发者处理。7.关闭缺陷 关闭已经修复的缺陷，也是缺陷的最后状态。做接口测试的时候，可以使用国内的接口测试和接口文档生成工具apipost
