夜深了，但我还不愿睡去，总觉得应该对上周那五天兵荒马乱的工作生活做个总结备忘，心里有个底，才能睡得踏实。
上周主要做了3件事，那便一个个讲起。
第一件事：测试用例的执行
在这件事上，没有出太大的问题，基本是属于回归测试和冒烟测试,因为是很成熟的产品，回归一般问题比较少，冒烟测试的话，新开发出的软件BUG很多，找起来也相对容易。
不过作为下周的常规工作之一，还是需要注意以下几点 ：
1. 提升用例执行的速度，每次的用例，执行起来都会有一些不懂意思的或不知道如何执行的，或许跟其他人交流下最开始是如何熟悉用例的。
按今天的分享内容来看，还有一点很需要注意的，就是把握回归测试的力度，用例虽说重要，但是在充分了解功能的基础上，并不必按着用例一条条执行完毕。
用例是服务于测试工作的，但工作不是执行用例~
2. 学会报BUG，就像xc姐说的，报的BUG直接体现我们的工作量，所以先报，之后可以花时间慢慢确认问题，总结复现问题的最少步骤。
另外，跟开发沟通一起定位问题应该会比自己确认高效很多。
所以说，觉得有不妥之处时，正确的做法是立刻记录，以保证不遗漏问题，这方面应该更加大胆一些，不宜太过谨慎，反正最多就是扣工资~/笑/
3. 培训内容的巩固
上周总共两场培训，第一个是学习云控方面的用例执行方法，但我什么host之类的完全不懂，也没有实际操作过，现在虽然不是十分必须，但还是应该把它学会的。
第二个是自动化用例的编写，不过我是上周五才第一次开始写用例，也只是验证BUG而已，写用例这件事或许可以慢慢来？
不过我看今天hz就针对没有用例的皮肤功能设计编写了用例，不知是可以自己直接写还是说被分配了任务，这一点有待观察。
OK，那么接下来第二件事：用户反馈
用户反馈是一个优先级最高的日常工作，也正是这项工作让我焦头烂额，碰了一头包。
那么就记录下出现问题的具体案例：
反馈A：本地验证没有复现，我是等到下班以后才慢悠悠的验证的，大概原因似乎是当时手头的工作都很紧急，虽说并没有耽误工作，但是当时没有重视到这件事的优先级，现在想来其实是一个隐患。
反馈B：本地验证没有复现，上午验的差不多，留了个小尾巴，就吃饭去了，中午回来以后继续验完然后回了邮件，结果被ww说了。
因为是工作日的白天发的用户反馈，运营、用户都在线，所以立马验证完就可以继续和用户沟通，但我回邮件晚了，虽然只是一个不太重要的问题，但确实因为我耽误了事情的进度。这件事情一方面确实是我没有意识到，另一方面当时手边还有一个很难的反馈，也就是马上要出场的反馈C。
两件事同时摆在我面前，B容易验证但重要性低，C不易验证而且重要性高，在这种情况下我似乎有些懵了，差不多是东验一下西验一下，没有条理直接导致了效率低下，耽误时间。实际上这种时候快速验证B并回复，之后仔细验证C似乎是最好的解决方法，但当时的实际情况是C正在验证的过程中，要验证B需要切换环境，C的很多东西就会丢失，所以搞的我手忙脚乱、顾此失彼。
反馈C：跟反馈B同时进行的重要反馈，之前已经处理过两例用户反馈，都是这同一个问题，本地验证一直没法复现用户的问题，后来还是xc姐找了与用户同样的系统环境，帮我复现了问题，又教我邮件里该怎么说（OS：我爱xc姐，雪中送炭真的是有被救了的感觉），但这个反馈相当于完全是xc姐弄的，所以说我的工作其实还是没有做好的。
反馈D：P0级别的重要反馈，我的精神完全高度紧张，但本地一直没法复现，为了验证多种环境又要现场搭环境，导致响应非常的慢。因为这个反馈我不仅见到了运营那边的负责人，还被老大亲自问了进度，还第一次去了机房用了虚拟机，也是没谁了……/苦笑/。总之，随着这个慌乱中几乎全体总动员才弄完的反馈，我负责用户反馈的这一周结束了，我也感到了深深的挫败感。
Anyway，总结一下吧：
1.在工作时间里一定要尽量避免费时间搭环境，需要的环境自己没有时，优先去问别人是否有这样的环境，有就先用别人的。需要搭环境配电脑啥的等下班弄吧（别忘了把要做的事记在小本上，防止忘记）。
2.用户反馈中没有注明具体环境时用win10 64 或 win7 64 位验证，没有复现就先回邮件，告诉运营继续跟用户沟通；若注明环境，则优先使用相同环境验证，不复现就回邮件说明。另外，邮件最好只写客观现象及推断的结论，不要告诉运营该如何工作（避免出错）！！！
3.相信自己的判断，有大量反馈的问题就是可能不复现，最多重启电脑或重装软件再验一遍。
4.脑子要会分区，最近似乎有点秀逗了，要能够把一件事跟另一件事分开，理智点，不要混成一团！
5.运营给了我一个建议，让我弄个固态硬盘，把虚拟机装在里面，就可以快速切换各种环境，还能多种环境同时验证，明天可以先跟jl姐商量一下。
第三件事：修改点验证
修改点验证基本是jl姐手把手教我的，记一下流程：
1.看修改点的描述，先复现一下之前的情况
2.最好在提测包出来之前去找开发对需求，不过这几次都是jl姐带我去对的，我自己并不知道开发说的那些是啥意思，对需求大概有几项内容：本次的修改是基于哪个版本；改了哪些内容；是否影响其他模块；功能以谁为参照，是否有PRD；应该如何验证修改点；应回归哪些模块；所有涉及到的相关BUG。
3.提测包出来之后，先去看一眼包里的diff文件，看看开发都改了哪些地方。
4.开始验证修改点功能，以及回归所有相关模块，涉及的bug。
5.验证完以后再花半小时进行下随机测试。
6.每天应该在任务平台上同步测试进度。
7.验证通过的话，开始补充新版本用例，涉及到模块用例及回归用例的，没有操作过，需要去找jl姐确认。
8.最后用例写完，BUG关掉，就可以修改任务平台状态，至此修改点验证完毕。