为什么突然想写这个测试习惯呢？源于一次会议。
在一次和后端开发、itpm开会期间，关于bug解决的时效性问题上引发了一场争执：
开发同学：我们没办法做到和测试同学一样，时时刻刻关注bug。
测试同学：我们每天上班后会及时打开缺陷管理平台，了解bug的情况，及时进行跟进和回归。你们开发为什么做不到？
当时心里就在想，这不应该是一些习惯吗？
测试将BUG的状态管理，视为自己的本职工作，于是形成一种行为惯性。
我询问过一些比较熟的开发同学，得到的结论是，有些开发会每天都关注，有些就是关注会少点，没那么频繁，所以，怎么说呢，每个人有每个人的工作习惯，测试人员有测试人员的工作习惯，开发人员有开发人员的工作习惯，不同角色的工作习惯又不同，习惯是每个人自己养成的，有好的有坏的，但是，好的习惯会让工作进展的更顺利，更效率。
以下是我自己的一些好的工作习惯分享，结尾会附上一些测试人员的一些想法，欢迎指正。
一、沟通的习惯
我所在的项目中，最基本沟通的方式就是邮件。于是每天到公司的第一件事就是打开邮箱，把最新的未读邮件按照我定义的优先级看完，再分根据紧急和重要成都划分程四个象限，按照一定的主次顺序处理。
邮件我大致进行了分类，诸如@我关注处理的、我负责的项目、流程要求类、企业文化宣传类，构建通知类、培训分享类等等，分类也决定了我阅读和邮件的优先级。
扫完一遍邮件后在头脑中有个概念，将邮件按照紧急且重要、紧急不重要，重要但不是特别紧急，不重要不紧急，四个象限进行划分，接下来一天的工作中穿插解决。
以下是对邮件处理的简单的象限图：
有时候放个周末或者长假，那么未读的邮件有时候好几十甚至将近100，一封一封的去处理查看肯定费时，这个时候就要活用邮箱的功能，我习惯设置各种规则，分不同的文件夹，每次新启动一个项目就会设置好规则，一键运行规则，然后再根据象限图中的方法去处理。
除了最基本的沟通方式邮件，有时候还需要辅助其他的方式，来推动事情的解决速度，特别是紧急的情况。我一般会采用邮件发出——电话通知——微信响应的顺序，根据不同的情况，灵活的运用各种沟通方式，甚至于直接face to face，视频会议等。
二、追根寻底的习惯
在根据项目的不同阶段，都做到追根寻底。
需求阶段，总是习惯一次性把各种需求文档，各种设计稿，交互，还会把备忘录打开，一边了解需求，一边把不清楚的，有歧义的地方，圈圈画画，记下，大概过一遍之后，结合上述各种沟通方式，进行逐一确认和补充，不放过任何一处纰漏。
用例编写阶段，我习惯借助不同的工具和展现形式，一步步细化来完成。
用xmind来理顺逻辑用例，列好大纲，接着用excel细化用例，遇到有变动的地方会跟开发，产品再次确认，或者询问逻辑实现方式，然后导入到平台中，后续执行中，如遇到跟初始的情况不同，有变动的，再在用例管理平台里进行少量的修改和新增。
三、善于借鉴，保持自我思维的习惯
每个人都有自己的思维，很多时候我们可以在保持自己原则思维的情况下，借鉴其他人的想法，方式等，说句俗话就是取其精华，去其糟粕。
以下简单举个例子：
用例是用来加固我对这个需求的了解，理顺逻辑，从而帮助接下来的测试任务。
1.编写设计时是从各个层次角度来考虑如何测试这个功能，可以借鉴一下其他人的设计思维。例如参加其他人的用例评审，看看其他人的用例等；
2.编写用例，有时候是处于一个理想的状态下进行设计，实际上，会因为各种原因导致逻辑的改变或者一些细节只有在实际测试中才能发现，所以用例也只是一个指导的作用。
3.经过了设计编写用例的梳理，对大致的测试方向实际在脑中已经有一个概念了，个人不推荐看着用例测试，很多时候，就能自主的进行更广更深的测试，等到进行的一定程度了，这个时候回顾一下用例，可以查漏补缺。
所以一般情况下，我还是比较倾向于看交互，需求，只有对这个功能原型了解，我觉得才能发挥测试的举一反三能力，而不是被圈在别人的思维中，可以借鉴，但不希望被禁锢住。
有时间还会偶尔去观察一下其他同事报的bug，了解其他同事思考的维度，对比一下自己缺失的地方。
四、多用图示的习惯
有时候文字很难表达清楚，用图示来表示更清晰，上面说过了思维导图的一个作用，用于剖析需求；编写测试用例，除了用思维导图，当逻辑依赖不同的条件得出不同的结果，可以使用判定表来整理用例。
某个功能的思维导图图示：
对于比较复杂的逻辑，可以通过流程图来梳理，加强记忆，百度百科有这么一句话，千言万语不如一张图，从而可以看出，通过流程图，能够对需求解读的更清晰；如图：
在其它的地方也可用图示来分析，例如分析bug，用表格，用饼图等，项目问题总结，用鱼骨图等，以下图示是举例。
五、测试的习惯
模块化测试阶段，这个时候我会习惯两台手机一起（对于app测试而讲），iOS和android一起操作，然后连上电脑，打开各种抓包工具，日志平台，既可以看同时对两个端进行测试，检查两个端样式，操作方式，也可以了解两个端处理的方式，过程中也可以顺利的抓取到前端日志，也会把redmine等管理bug的工具打开，一段时间了解bug的进度，有时候结合修改后的bug一起测试。
有时候还会把视觉和交互打开，进一步确认实现不一致的地方。
对于验证bug的习惯，比较倾向于开发备注原因影响范围，这样一来，验证bug就可以在在开发修改过的文件以及备注的影响点进行bug的回归，不仅仅是验证当前bug的问题，还要对其他相应的影响范围进行回归。如果开发人员没有标注原因，对于一些复杂点的bug，也最好还是跟开发咨询一下原因，影响的范围，验证也最好是备注好验证的点。
相信很多测试同学都有相同的习惯，如果有其他提高效率的方式或者好的习惯，欢迎提出，以下是我咨询一些同学关于测试习惯，经过同意可以展示出来的，中心思想大抵一致：
@Nancy：我觉得我是让开发给评估风险，重点影响哪里，这样结合经验，快速评估测试重点，相对好些效率稍微高点
@Celina：大需求就先测试主流程，主流程通了再过细节，有些内容错了就得重新测试的，能预估到哪个点容易出错就先测试哪个点，时间紧的话，就看自己所有的测试内容中有耦合的部分不，有的话就规划一起测试
@王丹：还没开始测试的时候可以根据细化捋清业务流程，整理测试场景，确认环境，准备数据；后续测试发现问题，解决之后验证问题等