碧水涟涟，夏至未至，秋风依依，梅花落时，已是一生。

　　一初衷：

　　为什么写这篇博客？

　　个人性格偏于低调，最近换了新工作，坐标成都，就任于一家T系公司。

　　1、公司是以项目为单位，有测试团队但没有测试部这个概念，测试团队人数大概60人左右，但都基本跟你没任何关系，只有项目上的其他两个成员跟你有交集，缺少后方养分，差异性，一时间不太适应；

　　2、业务划分很精细，能接触到的东西十分有限，还有各模块之间弱化了连接测试，担忧。已经发现过问题，而且也和组员讨论过他们也赞同这种方式容易出现质量弱化。

　　基于以上有些迷茫吧。今日加班值班，做个小小的往期回顾和总结。

距离上一篇17年2月《软件测试之路浅谈》，刚刚好两年半了～

当时入行软件测试半年后，是一种既有点期待（有些兴趣）更多是迷惑（当时所在测试部门不追求技术，功能测试为主）的状态写下来的记录，碎碎叨叨，想不忘初心。

文采拙略，叙事体再做一篇回归。

二回顾：

　　薪资

　　阶段一：J公司

　　?K（2016年上半年-2018年上半年）

　　阶段二：X公司

　　?K+3K(2018年上半年-2019年7月)

　　阶段三：K公司

　　?K+4.3K(2019年7月-今)

备注：有些线索可以猜到博主所在公司，一个是为了职业素养，二来避免不必要的麻烦，博主只展示一下待遇的提升，主要还是聊聊测试之路，三年测试风雨。

　　经历：

　　J公司：16年毕业于一家极其普通的本科院校，年少轻狂，学术不精，毕业时虽有公司愿意我前往，但我简历写的是测试，入职后是干的开发的活，终日闹累，加班严重，对于测试的一些兴趣和自己的思维方式（HP以前在学校做过测试讲座，出了一道拓展题目，桌子上有一杯水，怎样使水不在杯中，大家穷举例，物理、化学、电解等等方法，最后我举手回答，把杯子的外部注满水，这样就是杯在水中，不在是水在杯中了），我觉得自己适合做测试一些，2个月后辞职找了一家普通的公司做测试，测试团队大概15人左右，妹子较多，业务复杂，只要求功能测试，自己在项目期间看了很多基于测试的书籍，理论的，比如《微软测试之道》、《google软件测试之道》、《探索性测试》、《测试的艺术》等等，自学了Python、Selenium。并应用到项目中，个人应用过来，在团队推广过自动化测试，但是，妹子们表示，那都是花架子，没得意思。没有共鸣，这也是我为何辞职的原因。

状态：影响力较小，和开发关系很普通，脚本能力一般，但有一定的涉及和基础。

　　X公司：18年初，进入了X公司，当时团队正在扩建，是很明显的重QA类型，开发水平参差不起，后来招的的人要求高，前期的较为一般，我当时负责App的测试，版本迭代较多，后做为这个项目的测试负责人，前期，我总结和查询了大量App的测试方法，并应用于测试，发现了不少崩溃，闪退，和ANR问题，作为测试负责人后，第二是公司的要求CI，Jenkins自动打包模块的建立和App自动化主导形成一个闭环的质量链，成长了不少，接触到了接口测试，并运用脚本实现了接口自动化，紧接着，性能测试也做起来了。测试团队大概30人左右，后成立了技术专家委员会，有幸成为其中一员，成员大概7人左右，里面基本都是大佬，我实属菜鸡，但我年限最低3年，他们基本都是5年以上。最大的12年测试经验。技术专家委员会会有双周会，讨论公司的质量把控和提升，流程的优化，新工具的尝试和总结，工具脚本的开发，会有一些难度系数的任务，并为整个测试部服务，这些需要在工作之余完成。

　　具体聊一下我负责App的测试：

　　UI自动化（Android）基于appium+robot framework，PO模式业务逻辑数据分离，自动启动环境，关闭环境，执行失败时，自动抓取日志文档并分析，如果日志出现敏感字段，比如空指针什么的，根据提单规则，自动提交bug到JIRA，截取图片保存日志，自己还添加了一些图片断言，手机状态监测等。

　　接口自动化 前期基于robot framework+requests 写的，后用的pytest+request PO模式，设置了定时任务，每天清晨跑一遍，监测各接口状态数据正确性

　　后期做了一些IOS自动化试点，基于facebook-wda，也做了an droid的uiautomator2，这个和appium比起来效率太高了。也简单研究了一点点安全测试的工具

　　团队里面也做过几次技术分享

　　状态：有一些影响力，和开发关系较为和谐（学习Android的知识的时候，很多都是共同进退，共同拓展，测试出一些深层次的bug，开发认同感也会上升），有一点脚本能力，对测试的理解进一步加深。

离职是因为：老板不兑现承诺，三次。

　　见解：

　　测试之路一直追求的是测试效率和测试覆盖率，如果不基于这两个目的出发，对于项目而言，都是耍流氓，身边也有不少例子，整天搞自动化写脚本，同事、开发都是怨声连连，基本的测试用例都写不好，业务完全没整明白，反馈到项目负责人去了，大会上明确不让他再写脚本了，贼尴尬。不能头重脚轻，断章取义。

　　测试的方向：不是所有人都得进行自动化脚本的测试，有的人的确不适合，业务方向精通也是吃香的，要清楚的自己的定位和兴趣，国内整个测试行业整体代码能力偏低，大家都是八仙果过海，各显神通，守护质量。

　　提升测试人效：

　　第一代：接口自动化+UI自动化

　　第二代：服务化测试平台

　　第三代：录制回放

　　第四代：智能化测试

　　公司的不同存在几种不同的QA模式：

　　重QA模式：业务复杂，开发能力较低，各环节把控度不高

　　轻QA模式：业务中度，开发能力强，各环节密切，且开发有自测能力

微QA模式：业务简单，开发能力强，基于以完善的测试工具和开发自有测试能力，完全放开

　　传统的测试评估手段：故障数，用例个数，测试用例review，代码覆盖率 以表现出单一

　　就写到这儿吧，还有些迷迷糊糊的东西就不写了，理论的东西和实际的结合感悟能体会才是有用的，不管怎样，不要停止学习，停止探索，时间不早了，夜生活开始了（假装有夜生活）。以上是基于自己的一些听闻和见解，欢迎大家共同讨论，共同进步。

原文链接：https://www.cnblogs.com/-lisunman/p/11310612.html