今天完成的事情：

   了解了线上的操作，一般线上如果发现问题，五分钟应该立刻解决，不能解决的话就回滚，特别要注意，不能再线上进行调试和解决。

   而发布时间也必须是每天用户时间活跃最少的时候。

    版本发布的重要度决定了用户是否公告停机还是维护不停机，同时重要度也决定是新功能是否进行运营和推广，而在线上发布的时候，所有人都应该在线，发布之后呢，从运维，研发，测试，产品，都应该去依次验证，根据发布的情况，用户的反馈，系统的日记来进行观察总结，总会有很多意想不到的问题发生，就像你永远不可能完全了解一个人一样。

    一般发布的时候选择两时间点发布，分别是星期二和星期四，不能选在周末之前，因为这样做即使发布失败，也还有一天的时间去解决问题，发布又分为正常发布和紧急发布。

    线上bug，出现major级别及以上，被称为事故，一般这个时候应该摆脱平常发布时的限制，直接紧急发布，然后单独用wiki登记，产品经理和技术总监画押。

  流程可以后补，不能不补，特别是没有打版就发布时的场景，例如一些手工更改的页面啊，一些字段啊，这些都会导致开发人员忘记，最后又被覆盖掉。

  APP是有审核限制的，所以向前兼容性必须是在测试环境里就严谨测试。

  学习了测试，测试分为能测试，性能测试，自动化尝试。

  首先，自动化测试就是把过去的测试用例顺序执行一遍，来确认之前功能的可能性，节省测试人员大量的时间，提高发布效率和测试的严谨度。

  而回归测试的利器是selenium，而selenium最简单的就是自动化录制，而录制按钮就是记录你的动作，并且重复。

   自动测试的问题，一旦需求变更，自动化测试的脚本必须跟着改，经常改的话对测试的压力很大，特别是一些需求频率高的互联网公司来说，很多功能都不能自动化测试的。

   而相对一些稳定的功能，基本模块都很清楚，自动测试的意义又不大。

   性能测试其实在项目的研发后期，开发人员抽出一些时间测试是没有问题的，但相对于，边界测试法或者复杂情况下的测试，需要一个更稳定的测试环境来去做。

   了解了如何去使用禅道，禅道非常适合进行项目管理，禅道的测试功能也可以单独拿来使用，非常适合测试团队使用。

  禅道的测试流程基本上是，提bug-开发解bug-测试验证关闭

   首先，当发现一个bug时，我们要先创造bug，要填好影响版本，bug的标题，和重复的步骤，而所属项目，相关产品和需求可以忽略。

   然后开始创建bug，可以直接派人处理，没有则暂时先保留。之后便是解决bug，通过各种标签和检索条件找到自己要处理的bug。派给某位开发区解决，然后再验证，最后就到关闭bug，bug指派到创建者上，测验这个bug是否修复，验证通过则关闭。

  敏捷测试流程；通常一个月的需求分析，可能用2 3天就能完成了，但这个需求会定的和模糊，但整体的框架，基本能确定。

   然后下午晚上一直在弄入学手续，弄了一天，导致学习进度没有

明天计划的事情：

学习任务一和二

遇到的问题：

无

收获：