今天完成的事情：

回顾了一下测试的整个流程，虽然之前很多步骤都没走例如需求评审，还有用例评审，但是自己查了一些资料后对这些有了一些理解为什么要评审以及通过评审的要求。

首先要找产品经理要项目相关的文档，例如需求文档，原型图。然后要找ui拿到ui图。

拿到项目相关的文档后可以通过文档，或者之前版本的系统，网上的一些资料熟悉被测系统。

熟悉了被测系统后就要对需求文档进行分析，根据需求文档，原型图上的注释，ui图，对需求进行分析和理解。每个人的理解可能都不太一样，客户描述出来的需求可能和他真实的需求不太一样，这时候就要把自己理解和需求文档上不同的地方，或是不懂得地方及时列举出来 向项目组长或产品经理反馈。这是一个不断向客户 向项目组长或产品经理沟通的过程。

正确对需求文档做完分析后就要对测试点进行提取，可以根据自己对被测系统的理解，以及阅读需求文档，原型图上的注释，ui图 进行对测试点的分析和提取。提取测试点要保证将所有的需求都覆盖到，必须要有正向测试和反向测试。然后将测试点以文档的形式保存下来。

做完后就是需求评审，一般会有项目组长产品经理开发人员和测试人员共同来进行评审。产品经理负责将需求表达的全面，要求做到不二性一致性完整性，若产品经理讲完需求后，每个人都有不同的需求理解，那肯定是不行的，这时需求评审不通过，产品经理需要对需求进行修改，完善，统一，若在评审的时候，测试人员或开发人员发现了重大bug，同样视为评审不通过。然后在约定好时间进行评审。若还是不通过重复上一步骤知道参与需求评审的每个人都理解了需求且对需求的理解是一致的。

然后就是进行测试用例的编写，根据提取的测试点，编写测试用例，一条用例可以对应多个有效测试点，但一条用例只能对应一个无效测试点。测试用例的内容包含 用例编号 用力名称 测试背景 前置条件 重要级 优先级 测试数据 测试步骤 预期结果 实际结果 执行人 备注。各个公司测试用例的编写可能也是不同的。

写完测试用例后会对测试用例进行评审，一般会有项目组长产品经理开发人员和测试人员共同来进行评审。首先是审核测试用例是否完整的覆盖了测试点，用例的结果是否符合需求。若没有完整的覆盖测试点或用例的结果不符合需求，那么评审部通过，测试人员继续修改，完善用例。并确定时间再次评审。直到评审通过。

书写完测试用例后就执行测试，记录 将所有通过或者未通过的测试用例进行记录。且要全面观察结果（实际结果和预期结果是否一致）若不一致可能并不是软件本身的问题 可能是测试环境的问题，也可能是测试用例本身的问题。在执行的过程中也要不断的对测试用例进行更新，审查，发现不足的地方并补充 纠正。

发现缺陷后反复重现bug确认是系统的缺陷还是用例或是测试环境的问题，确认确实是系统缺陷后就在禅道上提交bug，提交bug的内容包含：缺陷的标题 缺陷的描述 测试的环境 缺陷的重现步骤 预期结果和实际结果 缺陷的截图 缺陷的严重级 。提交完后及时向开发确认，确认开发是否理解bug和修复bug大概需要多长时间。

开发修复完bug后进行回归测试，若缺陷依旧存在，那么继续提交bug重复上一步骤。若缺陷确实被修复了就关闭这个bug。

然后决策人员在看完缺陷的解决情况和用例的执行率来决定是否发布线上。

发布线上后进行冒烟测试。先测试线上版本主要的功能是否能正常运行，系统是否能跑起来。能正常运行后在进行更深入的系统测试，

明天的计划：

1继续学习jmeter的用法。

2学习一些面试的知识

遇到的问题：

做了几道面试题，发现自己确实理解这个东西，但是不知道怎么去表述出来。可能还是理解的不够透彻吧

收获：

回顾了一下测试的整个流程。