只要在互联网，继续写下去，这个是我的第一篇博客，碎碎念吧
　　提问：
　　1、你印象深刻的项目
　　接入abacus，相当于中国的中航信，拓展国际业务；单独负责一个项目，从无到有，到丰富，这个项目自己真的当成了一个owner，花了很多心血；然并卵，由于运营政策投放不到位，铺的政策面太广，导致用户点击次数很多，每次点击都要调用lowfaresearch接口，这个接口八分钱，导致每月offcie超流量，接口被停用了，开发另一个接口，自己解析返回。。。这也让我体会到，做好一个项目，需要多方的协调配合推动；
　　对于这个项目也想了很多，需求review自不必说了，环境搭建也不必说了，这个项目算是接口测试的一个典型吧，反正dubbo写参数能碰到的问题我都碰到了，做了大量的接口调用的自动化，自动化的效果还是很明显的，到后面的小需求点一次能测试并回归整个主流程了；对项目的关键监控也梳理并迁移到wather上，方便快速定位问题；
　　但是没考虑到的点还是很多，主要是session管理的复杂性，session是有上限的，各种异常情况下没释放怎么办，机器重启怎么办，用户请求量过大怎么办；开始我们开放公布运价，并没有这些问题，随着开放私有运价，请求量增大，我们连接境外的服务器网络也不稳定，一系列问题开始暴露出来；开始没有做性能压力测试是大的原因，还以为自己当时做的实在是圆满了；
　　哦，后来等接口稳定后还做了mock，毕竟，请求别人的接口要钱么；
　　2、遗漏的bug都是因为什么原因
　　主要是一些优化，原因是一些性能问题或者一些beta和线上的差距（数据量）没有考虑到、还有是效果不明显：
　　譬如：有一个项目中用http线程池去调用，但由于接口的报文长度超出它的限制，导致发送出错；没有造成故障，因为上线的时候先发了一台，然后观察了日志，发现有问题立马回滚了；
　　还有一部分原因是case覆盖不全；
　　发布出故障的很少，原因是在发布前三方定下了发布步骤和回滚步骤，发一步，线上验证和观察一段时间，且每次先发一台小流量机器灰度一下，无问题再分批发剩下的机器，无异常发布下一步，如果出现问题则回滚，对于无法回滚或者回滚成本比较高的情况，一般都会做一个开关，出现问题则关上开关；
　　3、一个项目测试的流程
　　（1）需求review
　　（2）出checklist
　　（3）三方过case
　　（4）环境搭建
　　（5）codediff
　　（6）项目进度控制：进度日报、case执行、bugfree记录和追踪
　　（7）组间协调测试或者支持测试
　　（8）上线前准备：sql审核 、线上机器申请权限、核对线上配置、三方核定发布步骤、回滚步骤
　　（9）线上发布、盯核心监控至少30分钟；
　　4、项目测试中碰到的难点
　　测试方面，没有数据自己造，自己mock，如果依赖别的组的系统，而且又没有一个稳定的环境的时候，沟通成本会比较高；
　　记得刚进来的时候，对java知之甚少，出现问题不晓得怎么定位，登上服务器查看日志的意识比较淡薄，被开发们鄙视，checklist也挖掘不出什么点，只能够对着需求文档冥思苦想，当时我的内心是万分受挫的；
　　在一次被人说不行以后，开始对害怕的代码抱着吞血的心态看，又有一个女同事耐心教我，到现在，能够对着代码的改动点挖掘测试点了，能够阅读代码，能够看着服务器日志自己定位问题，偶尔也debug一下，也写写代码帮助测试，额，不过需要百度一下；其实能读代码写代码的QA幸福感会强一些，QA读不懂代码，没办法和开发交流；
　　5、你觉得怎样工作是有效的？
　　清晰的做事逻辑，得当的做事方法、主动的做事态度，要跟公司的文化合拍；
　　6、怎么做自动化测试的，怎么想到去做的，效果怎么样，有推广吗
　　自动化测试有自动化工具的开发和工具的应用，我做的项目便是对工具的应用，但是在实际使用过程中发现公司的自动化工具并不能满足需求，于是自己写了些代码进行扩展；
　　部门有段时间刮起了工具热，大概是绩效里面有要求技术贡献这一列吧，但说实话，qa自己做的一些工具，拓展性并不强，只能解决某一些项目的问题，碰到某些情况无法支持，所以一个非常棒的工具是支持多种情景的，做过非常充分的调研和规划；QA能够自己写一些工具能够提高测试效率，是非常值得肯定的，但在推广上有一定问题，能在公司技术部的框架上扩展，能够适用于当前的测试，我觉得会是一个更有效率的事情；