今天完成的事情：

  对任务二‘逗你学’的软件进行实际测试，按照测试用例，一步一步的去测试，完善好测试结果。

  找出了bug，利用优先级判断bug的级别，在跟踪bug的状态，上传到禅道。

   上传任务一和二，下载任务三需要的资料。

   任务三暂时做不了。去看了一下任务四的流程，稍微了解了一下。

   看了任务一的深度思考，学习了冒烟测试和回归测试，了解了它们之间的区别；

   首先冒烟测试就是，完成一个版本开发后，对这个版本进行最基础的测试，保证基本的流程走的通，基本的功能能用，这些通过的话，就进行下一步测试，（功能测试，集成测试，系统测试）

   不通过的话，回开发那边重新开发。

   冒烟测试的优点；测试的时候能节省时间，预防开发失败。 缺点的话，覆盖率较低。

   回归测试就是，当你修复一个bug，把以前的测试用例，重新的用在修复后的版本进行测试

   还有一种情况就是，新的版本开发完，冒烟测试通过后，用上个版本的测试用例再次用来测试新版本，这样的做法是为了检查是否有bug。

做了一下深度思考；

测试过程中，Bug应该每天提到禅道一次，还是发现一个提交一个？

我认为， 不应该依靠bug的数量去决定每天提交禅道的次数，而是依靠bug的级别来去处理，级别越高，处理的时间就要越快。

怎么将bug偶现变成必现？

偶先变必现其实就是将测试的范围和输入的条件去缩小，让它固定到某种条件和某种情况下，而且通常那些看起来很诡异的问题，往往都是因为一些初级bug而造成的，就像很多问题看起来很难，但其实解决起来很简单。

作为一名测试，应该多去看日志，多去对代码进行审查，业务背后的原理，测试也要多去了解。

为什么测试需要预期结果？

因为测试的目的就是为了得到一个结果，而这个结果需要一个标准去衡量，这个标准就是预期结果。

程序员新人怎样在复杂代码中找 bug？

先去解决重现的bug，应该第一时间解决掉，因为好找，调试测试反复进行就好了，吧最后解决的解决掉，这样最省时间。

当遇见没头绪，很古怪的bug时，不知道从哪里入手，应该先去问问有经验的同事，看看他们的思路又是怎么样的，因为在很多大型的系统里，经常会出现很多原因一样的问题，改一处，过一会儿又出现，无法根治。

可以去放大bug的现象，这种是在bug现象不太明显的情况去使用，想办法去放大它的破坏性，依靠这样的思路反而更好的去发现问题的原因在哪里。

利用二分定位法，一点点的去注意程序的逻辑，看问题出现在哪里，然后慢慢的去把问题进行缩小。

模拟现场；看看在什么样的情况下，才能制造出这样的bug，故意的去制造这样的bug，这样更容易知道问题发生在哪里。

制作工具；当系统没有完善的崩溃报告时，这个时候就需要自己去做一个检测工具或者去制造工具，去检测某一个崩溃点，更方便的去定位，更方便的去寻找问题。

掩盖问题其实也是一种策略，在时间不够的情况下，可以只治症状，而不去找病因。

明天计划的事情：

把任务三搞定，再去看看深度思考，多去提提问题，再把做的笔记预习一遍

遇到的问题：

在提bug的时候，有一点过于盲目去在乎方法，去检测什么都想着有什么捷径，但其实在测试的时候，很多东西就应该要慢慢的去找，慢慢的去做。

收获：加深入的了解了bug的解决方法，和各种情况。