一名QA的碎碎念

只要在互联网一天，就继续写下去，这个是个人第一篇博客，碎碎念吧

提问：

一、你印象深入的项目

接入abacus，至关于中国的中航信，拓展国际业务；单独负责一个项目，从无到有，到丰富，这个项目本身真的当成了一个owner，花了不少心血；然并卵，因为运营政策投放不到位，铺的政策面太广，致使用户点击次数不少，每次点击都要调用lowfaresearch接口，这个接口八分钱，致使每个月offcie超流量，接口被停用了，开发另外一个接口，本身解析返回。。。这也让我体会到，作好一个项目，须要多方的协调配合推进；

对于这个项目也想了不少，需求review自没必要说了，环境搭建也没必要说了，这个项目算是接口测试的一个典型吧，反正dubbo写参数能碰到的问题我都碰到了，作了大量的接口调用的自动化，自动化的效果仍是很明显的，到后面的小需求点一次就能测试并回归整个主流程了；对项目的关键监控也梳理并迁移到wather上，方便快速定位问题；

可是没考虑到的点仍是不少，主要是session管理的复杂性，session是有上限的，各类异常状况下没释放怎么办，机器重启怎么办，用户请求量过大怎么办；最开始咱们开放公布运价，并无这些问题，随着开放私有运价，请求量增大，咱们链接境外的服务器网络也不稳定，一系列问题开始暴露出来；最开始没有作性能压力测试是最大的缘由，还觉得本身当时作的实在是圆满了；

哦，后来等接口稳定后还作了mock，毕竟，请求别人的接口要钱么；

二、遗漏的bug都是由于什么缘由

主要是一些优化，缘由是一些性能问题或者一些beta和线上的差距（数据量）没有考虑到、还有就是效果不明显：

譬如：有一个项目中用http线程池去调用，但因为接口的报文长度超出它的限制，致使发送出错；没有形成故障，由于上线的时候先发了一台，而后观察了日志，发现有问题就立马回滚了；

还有一部分缘由是case覆盖不全；

发布出故障的不多，缘由是在发布前三方定下了发布步骤和回滚步骤，发一步，线上验证和观察一段时间，且每次先发一台小流量机器灰度一下，无问题再分批发剩下的机器，无异常发布下一步，若是出现问题则回滚，对于没法回滚或者回滚成本比较高的状况，通常都会作一个开关，出现问题则关上开关；

三、一个项目测试的流程

（1）需求review

（2）出checklist

（3）三方过case

（4）环境搭建

（5）codediff

（6）项目进度控制：进度日报、case执行、bugfree记录和追踪

（7）组间协调测试或者支持测试

（8）上线前准备：sql审核 、线上机器申请权限、核对线上配置、三方核定发布步骤、回滚步骤

（9）线上发布、盯核心监控至少30分钟；

四、项目测试中碰到的难点

测试方面，没有数据本身造，本身mock，若是依赖别的组的系统，并且又没有一个稳定的环境的时候，沟通成本就会比较高；

记得刚进来的时候，对java知之甚少，出现问题不晓得怎么定位，登上服务器查看日志的意识比较淡薄，被开发们鄙视，checklist也挖掘不出什么点，只可以对着需求文档左思右想，当时个人心里是万分受挫的；

在一次被人说不行之后，开始对惧怕的代码抱着吞血的心态看，又有一个女同事耐心教我，到如今，可以对着代码的改动点挖掘测试点了，可以阅读代码，可以看着服务器日志本身定位问题，偶尔也debug一下，也写写代码帮助测试，额，不过须要百度一下；其实能读代码写代码的QA幸福感会强一些，QA读不懂代码，就没办法和开发交流；

五、你以为怎样工做是最有效的？

清晰的作事逻辑，得当的作事方法、主动的作事态度，要跟公司的文化合拍；

六、怎么作自动化测试的，怎么想到去作的，效果怎么样，有推广吗

自动化测试有自动化工具的开发和工具的应用，我作的项目即是对工具的应用，可是在实际使用过程当中发现公司的自动化工具并不能知足需求，因而本身写了些代码进行扩展；

部门有段时间刮起了工具热，大概是绩效里面有要求技术贡献这一列吧，但说实话，qa本身作的一些工具，拓展性并不强，只能解决某一些项目的问题，碰到某些状况没法支持，因此一个很是棒的工具是支持多种情景的，作过很是充分的调研和规划；QA可以本身写一些工具可以提升测试效率，是很是值得确定的，但在推广上有必定问题，能在公司技术部的框架上扩展，可以适用于当前的测试，我以为会是一个更有效率的事情；

我负责的一个项目，接口测试特别多，并且大都是dubbo接口，接口调用之间有关联关系：一个session要在全部接口使用且只有5分钟的失效时间；测起来挺费事的，并且之后的回归测试又要从新调用16个接口；这种状况下，我用公司的Qunit，本身扩展了一些本地类，将16个接口调用串联起来，能够作到点击一次，自动调用16个接口跑完主流程，大大提升了效率，还把Qunit返回结果展现美化了一下，使其更清晰直接；若是这种作法应用到其余项目上，思想是能够复用的，即一键主流程；框架是能够利用的；但主流程的case，都要针对项目去写；

若是没有特别棒的idea，我以为发现测试过程当中的痛点，本身动手改造一下已有的资源，就已经很棒啦~

七、你以为测试中最重要注意哪些点

测试最重要的是质量和效率，体如今项目上最主要有两点：

第一：改动点的把控、风险控制：

（1）弄清涉及的系统，这里得画一下系统结构图；

（2）codediff了，要清楚哪些方法哪些变量被改动，这些方法和变量在哪些地方被调用；更要在逻辑判断中多问几个if else，作异常处理，关键点打日志，接口交互和业务指标监控记录；

第二：进度的控制：

（1）项目开始测试前必定要有全面详细的checklist，这会让你把全部你觉得想明白了，实际上根本没有细想明白的功能点弄清楚，会在心中造成比较详细的系统应该是什么样子的，测试时主线会更加清晰；

（2）测试中要最早把主流程跑通，开始不要太扎到其中一个项目的详细测试，这样能够更好的把握项目测试的难度和重点在哪里；这里能够用到分层测试，就是经过造数据、mock把这部分的功能测了，推进测试的前进；这里我本身还有一点作法：公司流程要求提测前就diff代码，可是在碰到项目比较大而你对这个代码又不十分了解的时候，这时候diff每每收不到很好的效果：开发要花很长时间给你讲解代码实现的细节；因此我会在跑完主流程，跑主流程的时候根据日志本身熟悉一下代码逻辑，而后去diff，这时候的目的就是熟悉各个接口的交互，了解详细的改动点（改动了哪一个方法），补充测试点了；

（3）测试中对于大于3人日的项目，最好发测试进度日报，抄送相关人员，内容就是case的执行状况和bug数，修复数，让相关人员知道项目的进度，case的执行状况也能更好的让你清楚目前的进度；

 

八、linux经常使用指令

掌握最经常使用的各类查日志的指令，查看机器性能的指令，其余不经常使用的，等须要的时候百度之，知道什么linux可以作什么处理就好了，在苦逼兮兮的去作一件事情的时候，多想一想是否是有什么指令能够实现就行了，不经常使用的记不清呢；

九、测试工具的使用；

最经常使用的就是httprequester和fiddler了，httprequester能够很方便发送各类请求测试接口，fiddler因为本身测试界面比较少因此用的也不是特别多，通常用F12就解决了；

性能测试工具用的比较少，不过在培训中仍是强调了的，这方面的意识仍是得重视起来；

十、个人测试方法：

 

测试前准备：

（1）最最开始，画系统结构图，弄清改动涉及几个系统；每一个系统的哪一个功能改动了；

（2）经过wiki，查看代码，弄清系统结构图中交互不明白（数据怎样取？直接读数据库仍是经过接口，数据怎样同步？canal仍是定时任务？）的地方，找测试点；

（3）写checklist；

测试中：

（1）先不用看日志，像产品同样跑主流程，（怎样推进跑主流程：弄清测试怎样去分层测，创造条件去测某一部分）

（2）主流程跑通后，看细节，核对是否正确；

（3）根据主流程日志梳理代码实现，记录关键日志查询方法；

（4）根据关键日志本身diff代码，开始画逻辑流程图；

（5）跟开发diff代码，梳理逻辑，修正逻辑图；

（6）继续测试，注意各个if else 分支，测试覆盖，模拟异常；

（7）对照流程图，对比未覆盖分支，测试基本完成；