只要在互联网一天，就继续写下去，这个是我的第一篇博客，碎碎念吧
提问：
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能够自己写一些工具能够提高测试效率，是非常值得肯定的，但在推广上有一定问题，能在公司技术部的框架上扩展，能够适用于当前的测试，我觉得会是一个更有效率的事情；
我负责的一个项目，接口测试特别多，而且大都是dubbo接口，接口调用之间有关联关系：一个session要在所有接口使用且只有5分钟的失效时间；测起来挺费事的，而且以后的回归测试又要重新调用16个接口；这种情况下，我用公司的Qunit，自己扩展了一些本地类，将16个接口调用串联起来，可以做到点击一次，自动调用16个接口跑完主流程，大大提高了效率，还把Qunit返回结果展示美化了一下，使其更清晰直接；如果这种做法应用到其他项目上，思想是可以复用的，即一键主流程；框架是可以利用的；但主流程的case，都要针对项目去写；
如果没有特别棒的idea，我觉得发现测试过程中的痛点，自己动手改造一下已有的资源，就已经很棒啦~
7、你觉得测试中最重要注意哪些点
测试最重要的是质量和效率，体现在项目上最主要有两点：
第一：改动点的把控、风险控制：
（1）弄清涉及的系统，这里得画一下系统结构图；
（2）codediff了，要清楚哪些方法哪些变量被改动，这些方法和变量在哪些地方被调用；更要在逻辑判断中多问几个if else，做异常处理，关键点打日志，接口交互和业务指标监控记录；
第二：进度的控制：
（1）项目开始测试前一定要有全面详细的checklist，这会让你把所有你以为想明白了，实际上根本没有细想明白的功能点弄清楚，会在心中形成比较详细的系统应该是什么样子的，测试时主线会更加清晰；
（2）测试中要最先把主流程跑通，开始不要太扎到其中一个项目的详细测试，这样可以更好的把握项目测试的难度和重点在哪里；这里可以用到分层测试，就是通过造数据、mock把这部分的功能测了，推动测试的前进；这里我自己还有一点做法：公司流程要求提测前就diff代码，但是在碰到项目比较大而你对这个代码又不十分了解的时候，这时候diff往往收不到很好的效果：开发要花很长时间给你讲解代码实现的细节；所以我会在跑完主流程，跑主流程的时候根据日志自己熟悉一下代码逻辑，然后去diff，这时候的目的就是熟悉各个接口的交互，了解详细的改动点（改动了哪个方法），补充测试点了；
（3）测试中对于大于3人日的项目，最好发测试进度日报，抄送相关人员，内容就是case的执行情况和bug数，修复数，让相关人员知道项目的进度，case的执行情况也能更好的让你清楚目前的进度；
8、linux常用指令
掌握最常用的各种查日志的指令，查看机器性能的指令，其他不常用的，等需要的时候百度之，知道什么linux能够做什么处理就行了，在苦逼兮兮的去做一件事情的时候，多想想是不是有什么指令可以实现就好了，不常用的记不清呢；
9、测试工具的使用；
最常用的就是httprequester和fiddler了，httprequester可以很方便发送各种请求测试接口，fiddler由于自己测试界面比较少所以用的也不是特别多，一般用F12就解决了；
性能测试工具用的比较少，不过在培训中还是强调了的，这方面的意识还是得重视起来；
10、我的测试方法：
测试前准备：
（1）最最开始，画系统结构图，弄清改动涉及几个系统；每个系统的哪个功能改动了；
（2）通过wiki，查看代码，弄清系统结构图中交互不明白（数据怎样取？直接读数据库还是通过接口，数据怎样同步？canal还是定时任务？）的地方，找测试点；
（3）写checklist；
测试中：
（1）先不用看日志，像产品一样跑主流程，（怎样推动跑主流程：弄清测试怎样去分层测，创造条件去测某一部分）
（2）主流程跑通后，看细节，核对是否正确；
（3）根据主流程日志梳理代码实现，记录关键日志查询方法；
（4）根据关键日志自己diff代码，开始画逻辑流程图；
（5）跟开发diff代码，梳理逻辑，修正逻辑图；
（6）继续测试，注意各个if else 分支，测试覆盖，模拟异常；
（7）对照流程图，对比未覆盖分支，测试基本完成；
