今天完成的事：详细的了解了BUG的生命周期 :BUG的生命周期
   从一个bug被发现到这个bug被关闭的这一段时间，Bug可能会有以下状态；new,open,Postpone,Pending Retest,Retest,Pending Reject,Reject,Deferred,closed.
    根据不同情况来决定怎样或者是否需要跟开发人员沟通
    解释
    new；新的
              当某个 bug 第一次被发现到时候，测试人员需要与项目负责人沟通已确认发现的的确是一个 bug，就将其记录下来，并将 bug的状态设为 new
    Assigned；已被指派的
                    当一个bug被指认为new之后，将其给开发人员，开发人员将确认这是否是一个Bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为 assigned
   open；打开的
               一旦开发人员快开始处理bug的时候，他就将这个bug的状态设置为open，这表示开发人员正在处理这个bug
    fixed；已修复的
               当开发人员进行处理(并认为已经解决）之后，他就可以将这个bug的状态设置为 fixed，并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组
   pending reset；待在测试的
                  当bug被返还到测试组后，我们将bug的状态设置为 pending reset
    reset；再测试
                测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为 reset
   closed；已关闭的
               如果测试人员经过再次测试之后确认bug已经被解决之后，就将bug的状态设置为 closed
  reopen；再次打开的
                如果经过再次测试发现bug（指bug本身而不是包括因修复而引起的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为 reopen
   pending reject； 拒绝中
                                如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug 的状态设置为pending reject
   rejected；被拒绝的
                  测试组的负责人接到上述bug的时候，如果他发现这是产品说明书中定义的正常行为或者经过开发人员的讨论之后认为并不能算作bug的时候，开发组负责人就将这个bug的状态设置为 rejected
  postponed；延期
                    有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，这种情况下，bug的状态就被设置为 postponed
  deferred；延期的
                   有些情况一些特殊的bug显得不那么重要，同事也是可以消除的，这个时候我们可以将bugd的状态设置为 deferred    

 BUG等级划分标准：

1.blocke,阻碍开发或测试工作的问题 。

2.Critical; 系统无法执行，崩溃或严重资源不足，应用模块无法启动或异常退出，无法测试，造成系统问题。 

3，Major; 影响系统功能或操作，主要功能存在严重缺陷，但不会应到系统稳定性 

4，Minor; 界面，性能缺陷

5，Trivial：易用性及建议性问题

以及三个环境：

开发环境
  指的是代码可以随意修改，方便开自身测试用，但是该环境由于可以直接修改，很多BUG不容易被发现了，只能是开发自测或者代码的时候自用
测试环境
   软件运行的平台，软件，硬件和网络三种环境的合计.用于测试，发现开发者发现不了测试问题，保证线上环境无bug。
线上环境
   是交付时的环境，三个环境中的最后一步，用于交付给甲方。

   完善了任务一的用例，研究了任务二。

   用XMIND根据原型图画了一下流程分析，但是感觉不对。和别人的流程分析相差很多。

明天计划的事情；认真研究任务2，

遇到的问题；最开始不会用XMIND，后来琢磨回了。

                      根据原型图和验收标准文档编写用例的时候有点看不懂验收标准文档。