今天完成的事情：

需求分析，测试用例内容，bug等级，bug跟踪
明天计划的事情：
遇到的问题：暂无
收获：

需求分析：

首先要确定产品要做成什么样，想要得到什么样的效果。作为测试需求分析的对象和依据，一般有这么几种形式：产品需求文档，业务的交互稿，技术文档（比如后端的接口文档）等。然后我们用测试的观点和思路来分析，为了保证实现的效果，测试需要做什么。在实际分析过程中，会有一些分析方法来指导我们。然后也会有一些工具来帮助我们更好地整理思路，并把结果呈现出来。我们经常会看到一些流程图，通过流程图把业务逻辑表现出来。测试需求分析的过程，就是从广度和深度这两个维度对每个功能点不断进行发散思维的过程。比如我们要考虑正常流程有哪些输入和使用场景，又会有哪些因素会导致从正常流程走到异常处理流程。到了异常处理流程后，产品又需要怎样的容错处理等等。它可以把思考过程和思考结果层次化、形象化地表达出来。

测试用例内容：

功能模块，测试编号，测试点，测试点描述，测试背景，前置条件，优先级，重要级，测试数据，测试步骤，预计结果，实际结果

禅道bug等级：

P1：致命（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）

P2：严重（不影响其他功能测试的情况下可以继续该版本测试）

P4：建议（测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

bug跟踪：

测试人员在测试过程中，发现并创建BUG（创建完成后状态为：激活状态），记录产品 缺陷，分析并跟踪BUG直至问题解决；

BUG创建后会指派给对应人员，若存在中间分析/分配BUG人员，则指派给该人员，分析/分配BUG的人员查看BUG并进行分析，确定为BUG则确认BUG（状态变为：已确认）并将问题指派给对应解决人员（一般为研发人员）；

研发人员及时分析处理问题，问题解决后修改BUG状态为：已解决，并填写解决方案、解决版本，然后指派给测试人员（一般为创建BUG的人员），若有特殊说明，则在备注中说明；

测试人员对已解决状态的问题及时进行回归，若问题解决则关闭BUG，若问题未解决则激活。