测试理论（4）
缺陷：
缺陷的三种叫法：
BUG ； 缺陷 ； ISSUE
缺陷级别：
致命：系统崩溃、数据丢失、数据毁坏、安全性被破坏。
严重：操作性错误、结果错误、功能遗漏。
?般：?问题、拼写错误、UI布局、罕?错误。
建议：对产品的改进建议。
缺陷优先级 优先级表示修复缺陷的重要程度和紧迫程度。
紧急：影响进?步测试，需要?即修复。
?：必须在版本发布前修复。
中：必须要修复，不?定?上修复，可以讨论确定在某个时间节点修复好。
低：对产品影响?较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。
缺陷类型
优化：指的是产品不是那么很好，优化下会更加好，比如提示信息123改成456
BUG：指的是程序存在的缺陷
需求：客户有了新的想法，增加到产品里面
缺陷状态
主要描述缺陷当前的状态。状态如下：
新建：测试?员新提交的bug、优化或者建议的状态。
进?中：开发?员确认是bug，在修复bug过程的状态。
已解决：开发?员已修复bug的状态。
已关闭：测试?员验证修复的bug，确定已解决问题的状态。
不解决：开发?员认为不是bug，拒绝解决问题的状态或者?法解决问题的状态。
重开：测试?员验证修复的bug，发现没有完全修复好bug，重新打回开发?员的状态。
暂缓：开发?员认为该bug不急于修复，可以放置?段时间再修复的状态。
√bug的缺陷流程：
测试人员在测试的过程中，发现问题，提交给开发人员，|开发人员确认是bug之后，进行修复，测试人员进行跟踪，在开发修复完成后再次验证，验证没有问题后关闭bug。|开发如果拒绝bug，在双方确认后，关闭bug。|如果在后面的测试中，这个问题再次出现，则重新提交bug，再次给开发，开发进行修复，直到解决。
√issue注意事项：
1、BUG标题一定要表达出问题的核心，看了标题就知道是什么问题
2、BUG步骤要清晰明了，通俗易懂，步骤要非常详细
3、提交的BUG最好有问题的截图
4、提交BUG最好有详细的日志信息（主要针对的是后台服务）
tapd提交缺陷：
测试计划的定义及?的
?个叙述了预定的测试活动的范围、途径、资源及进度安排的?档。它确认了 测试项、被测特征、测试任务、?员安排以及任何偶发事件的?险。软件测试计划是指导测试过程的纲领性?档。计划可以统?认识，可以规划过程。测试计划包含了产品概述、测试区域/测试范围（测试项）、 测试?标（被测 特征）、测试优先级、测试配置/测试资源<硬件、软件、??、技术等>、测试周期、进度安排（测试任务、?员安排）、 测试策略、测试?法/途径、测试交流、?险分析、测试标准、需交付?档等内容。
软件测试计划内容
测试范围：明确测什么？
测试策略： 明确怎么测
资源安排：包括测试?员的安排和资源环境安排
进度安排： 在明确测试范围、?法和?员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接。
发布标准：发布标准是测试完成和产品上线需要满?的条件，以便项?内所有??都有?致认可的?标。
?险预防：最后，我们需要对整个测试过程中可能存在的?险，以及当这些?险发?时的应对措施提前进??些考虑和准备，并在测试计划中体现出来。
（测试计划案例 见测试计划随笔）