我负责的一个项目，接口测试特别多，而且大都是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）对照流程图，对比未覆盖分支，测试基本完成；