今天完成的事情：
在网上查了一下软件测试的全流程

首先用户将自己需要的东西跟产品经理进行沟通，然后由产品经理记录，并转化为

需求文档，然后我们测试人员和开发人员拿到需求文档后进行需求评审，去了解用

户到底需要一个什么样的功能，软件。在评审的过程中需要对需求进行测试，测试

需求文档有没有二义性的内容，有没有描述不准确理解不清楚的内容。然后又测试

组长或者测试经理编写一份测试计划。测试计划写完后然后召集所有的测人员对测

试计划进行评审。评审测试计划内安排的时间是不是合理，时间是否够用，测试机

和系统的准备是否全面。测试的方法。然后根据测试计划上安排的任务模块 书写测

试用例。写好测试用例后进行测试用例的评审，评审有没有遗漏的点。评审通过后

执行测试用例然后进行一轮又一轮的测试迭代，直到验收测试，然后发布上线，编

写测试 报告。

bug处理流程

首先测试人员发现bug 将这个缺陷提交到bug管理工具里。

此时bug的状态是New 代表是新建的一个bug，此时开发组长

或者产品经理会收到bug管理工具的消息，代表此bug通知到

开发组长或产品经理，此时开发组长（产品经理）就要去看

这份缺陷报告，因为有可能我们提交的bug并不是一个缺陷

。 开发组长（产品经理）看完缺陷报告后，若发现并不是

缺陷，就将bug的状态改为拒绝，相应的测试人员会收到这

个缺陷被拒绝的消息以及被拒绝的原因。若看完缺陷报告后

发现确实是一个缺陷，此时开发组长（产品经理）会将这个

缺陷定义一个优先级别，然后将缺陷的状态改为open，表示

此缺陷被确认打开，确认打开后就需要被修复，然后开发组

长（产品经理）安排给相应的开发人员，开发人员收到缺陷

报告后就会按照缺陷报告去重现并修复bug，开发人员修复

完bug后将缺陷状态改为fixed表示修复完成，测试人员再去

严重缺陷是否被修复，若确认被修复就将这个缺陷的状态改

为closed 表示缺陷被确认解决并关闭了，若测试人员发现

缺陷还存在 那么将缺陷的状态改为（re）open 表示继续打

开缺陷继续给开发，然后开发继续去修复，测试人员继续去

验证。直到测试人员确认bug确实被修复成功并关闭bug。

明天的计划：

1参与25期demo

2提交任务6

遇到的问题：

在企业中也会有类似禅道的stroy的东西吗，就是把验收标准写的很详细的那种

收获：

学习了测试的全流程 以及bug的处理流程