今天完成的事情：

   学习qa的三个环境，环境其实就是服务器，三个环境分别是开发和测试以及线上，三个环境是各自独立的，不会有任何关联，在很多严格的公司，都会将三个环境进行物理隔离，互相不可通信。

为什么会会有三个环境呢，因为线上很慎重，没人敢把没有测验过的代码放到线上。

   测试环境需要稳定的一个环境，不能随时进行更改和发布，而开发环境不一样，开发每天都基本会更改4 5次。

再开发提交提测之前，需要先参加demo，来判断是否达到提测标准。

在整个测试环境，都是自己的工作平台，直到验收无误，才可以提交到线上。

   测试其实就是有计划的对系统挑刺，项目模块的功能也就是功能点，而在测试的时候应该先了解测试的需求，在通过需求，开脑动，用各种各样的测试方法去测试，而这个时候就需要一个固定的模板，去做测试记录，这个记录就叫做测试用例了。

   还学习了测试的基本属性呢，有前置条件，操作步骤，预期结果，以及对应的功能点。

   前置条件则是，用户操作的时候必须是有顺序的，要想达到这个需求，那么肯定有什么必要的条件。

   操作步骤则是具体要做的事，把它给计划好。

   预期就是结果，系统能看到的结果。

   学习了对bug的定义和了解，bug其实就是应该发生的事情却没有发生，不应该发生的事情它发生了，其次呢，bug的存在跟经验没有关系，正确的认知bug的存在，不要带有太多的困惑，把出现的bug消除，把bug的出现率尽量变小，这次是最应该做的事情。

    当然，当一个程序猿他的bug特别少，那么说明他的水平特别高，其实很多程序员，犯错是因为他根本不知道自己犯错了，所以，快速的反馈，修复bug，并提醒自己下次不要再犯同样的错误，这才是正确的应对方法。

    大多数的测试，其实不是很懂技术，但感受却很直接，他们知道哪个程序员项目容易出问题，负责的模块容易故障，哪个花的时间更少，这些都是能很直观的感受到的。

    不要在开发阶段进行测试，除非开发请求，开发到测试，最重要的阶段是demo。

    作为测试，应该明确说明时候能发布，什么时候放弃发布，什么时候舍弃一些功能。

    在功能测试阶段，上线往往取决于bug的级别，而功能不好不代表不可以上线，相反只有能通，是符合上线的条件的。

     每个系统的环境 使用  体验 功能不一样 所以遇见的bug也是不一样的，所以这个时候，体现到bug优先级重要的原因。

     bug的严重程度；

critical；最严重，代表着系统不可用，系统崩溃，例如网页404

而bug的严重程度不代表着critical的解决难度会很大，出现网址打不开可能只是域名过期，交交钱就可以解决。

block；非常严重，网页界面操作卡死，不能进行下一步

major；严重，系统的流程能过，但是关键的业务或者数据错误，会影响用户的正常体验，major相当于一条分界线，它是很多团队的初期目标，完全消除major为目标。

normal；常见的bug，不是特别影响用户的体验，像normal级的bug，应该重点与控制数量，在开发提交数据测试时，nprmal类的bug不应该超过3个，normald类的bug很容易发现。

minor的bug，无伤大雅的bug，一些小问题，如错字，字体，样式，兼容，修复这些bug呢看程序员有没有空。

关于对bug的处理思维习惯，不应该是 主逻辑的习惯  不是先把整体跑通 再去管细节，而是在demo之前，交付所有正常使用的功能，才是一个好的习惯，这样测试的时候，测试环境才有意义。

   测试应该明确守好dmeo这一关，处理好bug的优先级。

  提bug时，一定要描述清楚 操作步骤 附截图 再到使用环境 系统版本型号，再到预期的结果                                                  

学了bug管理工具，记录了一个bug被创建再到被指派然后被修复后关闭的过程，而bug的生命周期就是，bug有哪些状态，这些状态是由谁触发，角色又是谁。 

    当记录一个bug并不能就直接认为它是刚出现的，可能已经出现很久了，只是你没发现而已。

    学习了偶现 必现， 偶现就是偶尔或新出来的问题   而必现呢，则是经常出现的问题。

    新建一个bug，最重要的就是记录运营环境和操作步骤，然后截图。

    有些bug，是只有在特定的情况，特定的环境，发生在特定的人身上才会出现。

    无论前端也好，后端也好，用户也好，谁发现了bug，要第一时间汇报给qa，好让qa去录入这个bug，知道这个bug现在是一个怎样的状态，是否正在修复，是否需求一致，是否方法不对。

    修复bug就是，qa提出bug，然后把bug交给哪个倒霉鬼，让他去修复，不要过于去纠结，这个bug到底派给谁，这不是你的职责，因为有专门的研发团队的小组leader来接手。

    而bug并不是指派一次，那就可以了，而是要多次的指派，在修复的过程中，这个bug会交到不同的人手中，而有些时候还会碰到一些人，bug他认为不是自己的问题，但他又不将bug及时扔出，导致bug就卡在那里。

    修复bug的确认时间是有级别的，major以上的bug，应该放下手头手头上的工作，两个小时以内，必须把这个bug修复，而normal的bug，不应该超过两天，下一期版本修复，或者更新一些小版本。

    修复bug，也会有发现不是自己的问题，然后指派到下一个人，下一个人把属于自己的问题解决掉，再继续指派另外一个人，在继续指派的过程中，bug无论在谁手里都是已接受的状态。

   而研究院并不是只有接受的权利，他们对付qa的武器有  无法实现 设计如此    推迟修复    重复bug 等等

  bug的关键点在于bug区分优先级  处理的bug是否和当前项目有冲突  如果修复完bug  对当前的项目有影响  研究人员自己承担。

   不要未修改时就发布到测试环境，不要没有演示就修改状态。

    线上环境或测试环境验证通过了，就可以关闭状态了

    如果没有通过，就加入reopen用来标记，它跟未分配是一样的 一个是主 一个是配

    学习了开发环境，开发环境简单来讲就是，对环境的未知会特别多，昨天发生了，今天可能就不一样了，为什么会这样呢，因为研究团队会用假数据，来保证前端后端的开发，研究团队也经常会出现思维漏洞，没有持续集成的习惯，另外开发环境没有版本管理，依赖关系不稳定，开发环境是思想从诞生到落地的重要过程。

    在来不及测试的时候，应该明确优先级的重要功能，再把它加入测试环境。

    测试需要做的是在每天晨会后。或者任意一个时间段，去看看开发团队的关键的逻辑有没有错误，有没有重大的偏差，而不是做严谨的测试，开发环境对测试而言最重要的是demo，demo依照story来演示有没有遗漏，demo完之后会打tag，所以整个过程是严谨的，从来没有所谓的主流程跑通，必须的一行代码都不用改动，直接发进测试环境。

    而demo通过的原则是；肉眼能看见的错误，就不能通过，而不是只有几个minor级别的小问题，就可以通过了。

    demo的时候，只展示问题，会节省很多时间，demo的数据应该使用仿真数据，而不是随意填写，如测试一之类的。

    demo测试之前必须通过性能测试，再到ui自检规范和codereview三者通过后才允许demo。

   bug修复  开发环境应该像测试演示  才能允许发布测试数据 demo发现问题要及时记录。

   发布到测试环境需要登记，我们一般使用wiki管理测试环境的发布，测试环境有两种情况才能发布，一种是新迭代开发，一种是bug的修复。

   不允许说发布功能改什么，而在需求和bug管理工具看不到。

     发布测试环境，回滚版本，测试环境由运营开发依次检验是否发布成功。

   测试环境，每天只允许发一次。

   运维人员，所有操作步骤写在wiki上，脚本和sql都应该在wiki登记，不能脱离wiki单独发布，测试环境中，开发人员，只有读日志的权限，不应该有重启和发布的功能。

明天计划的事情：

学习什么是线上，和自动化测试以及性能测试，以及常见的功能模块有哪些，

正确的提Bug--用离子炮发起向程序们的攻击

遇到的问题：

暂时没有

收获：

学了很多测试相关的知识，做了很多笔记以及总结