第一篇：打酱油篇

因为刚进入公司，对测试和业务都不了解，结果就被安排到一个大的项目里面负责2-3个小模块的测试工作，说是负责这些模块的测试工作，实际上，用例都是别人写好的，自己只需要去执行用例就可以了（当然，培训还是有的），标准就是保证这些用例执行后没有质量问题，其实就是没有执行漏测就可以了。

刚开始还是怀着一颗敬畏的心去做的，但是2个月新鲜劲过了后马上就开始迷茫了，尼玛这工作也太无聊了吧，而且毫无技术含量而言。难道这就是我后面一直要做的事情？不过虽然不爽，但是因为项目比较紧，所以还是调整了下心态坚持将整个项目按照这样的方式弄完了，整个过程持续了6-7个月的时间。结果居然因为项目表现比较好拿到了优秀的考核结果，原因是自己负责的模块质量比较稳定，并且过程中发散测试的时候发现了几个严重的bug，这更加让我不知所措，但是自己知道不能够在这样下去了。

没有办法，找老大聊了下，得到的大概信息就是，现在项目比较紧，只能优先去保证项目，至于改进，后面慢慢再做；因为，这样对于自己的成长肯定是没有帮助的（至少当时是这么认为的），于是，选择了走人（当然，提前找到了另外一家，也就是现在这家公司）。

因为两家公司的业务完全是不同领域，并且以前的测试流程跟当前也有很大的区别，所以，基本上又是从头学起，做的也是测试执行的工作，这个过程差不多又持续了半年左右，但是跟以前有点不一样的是，开始能够接触自动化以及一些新的测试方法了（这个后面会讲到），整体来说，虽然后面半年也是做的测试执行工作，但是至少自己看到了希望（因为组内已经有这方面很厉害的人物了），也大概清楚了自己应该想哪些方向去努力（选择比努力更重要这句话还是挺有道理的）；但是第1年自己基本属于打酱油篇，因为自己在测试这块领域还是刚刚入门。

第二篇：自动化篇

开始去涉及自动化应该大部分是自己主动去做的，那个时候因为团队开始去尝试做自动化，所以鼓励大家多去思考如何通过自动化去提高自己的工作效率，但是因为项目实际上也压的很紧，所以老大采取了这样的两个方法：1、加班去完成任务 2、每个人将最基本的功能梳理出来做成自动化；并且内部给大家灌输了一堆这样做的好处；不管是不是真的，效果还是很明显的。大家像打了鸡血一样（这点只能说跟对老大还是很重要的），每个人去花时间学习脚本（最开始用qtp，后来用pythen，ruby等）以及尝试去做自动化。经过3个月后，虽然自动化的很多东西都不规范和稳定，但是我们总算是取得了一定的效果，就是总共完成了200个左右的bvt用例，而且最重要的是大家的自动化开发能力提升还是比较快的（至少对于我这个门外汉来说，呵呵）；

后来，将这块的效果展示出去后，上面也比较认可，于是开始给我们一些人力和时间去投入做这块的工作，这样就正式开始了整个自动化的持续投入和产出，笔者也有幸正式成为自动化开发小组的一员（50%左右的时间去做自动化的开发工作），这个过程差不多持续了10个月左右的时间，直到自己开始去尝试新的方向；虽然说1年左右的时间对于写代码还没有掌握的很深，但是笔者认为已经能够完全胜任该工作了;更重要的是，自己的思想也发生了很大的变化（过程中看了很多测试人员的职业发展相关的文章）。

第三篇：测试分析篇

到这里，个人认为自己的思想转变最大的一点就是：作为一个测试人员，我们的目的是什么？怎样将我们的价值最大化？而不是仅仅去想如何去提高自己的技术；另外就是感触比较深的就是解决问题的能力比技术本身更重要（当然，好的技术能够更快的解决问题）；后来偶尔跟老大沟通，如何去更好的去提高产品的质量？老大也正在想这个问题，于是开始去涉及测试分析相关的工作了（个人觉得主动性应该是一个好的测试人员很重要的技能）。

这个时候开始，工作重点开始转向产品的业务和整体框架学习，模块的测试用例设计评审，参与整个项目的测试重点和难点的分析，过程中对开发的bug改动分析，协助开发去排查和定位问题，过程中测试质量分析等等。在这些过程中，笔者才真正感觉到，一个测试工程师要做好还真的是很不容易，需要非常好的分析和归纳抽象能力，这样才能将一些共性的地方提炼出来，形成一些比较通用的方法。

过程中一些具体的方法，笔者就不详述了，毕竟每个人都有自己的方法，但是很重要一点就是要能够沉住气，并且真的愿意持续做下去。笔者经过一年的时间，就产出了一份从几个维度来评估产品质量的方法以及一份探索性测试的方法（要想在这块有进步，产出是一份很重要的评估标准）。

第四篇：技术改进篇

当然，这里并不是说测试分析的工作就没有开始做了（识别当前项目的测试重点和难点的工作始终贯穿着我的整个工作，而技术改进的来源也是基于整个分析的过程）。

完成整个产品的业务逻辑分析后，再加上从网上看到的一些基于代码的测试经验，就开始思考，如何将测试从黒盒向灰盒以及白盒的方向去扩展，从而能够更早期多发现问题，而不是等到开发提交测试后再去覆盖测试。这里主要做了两个主要的改进；

1、分层测试：因为产品的一个模块特点是基于apache＋php＋mysql的模型，所以比较适合分层的方式，将底层数据库接口操作提取出来，直接通过构造数据的方式来覆盖到；而php层则开始引入接口测试（其实已经类似单元测试了），过程中不断的跟开发进行沟通和确认，开发每完成一个模块后，我们马上就能覆盖到，至于UI的，因为成本太高，而且测试起来相对比较简单，就直接计划等全部完成转系统后再覆盖测试。这种方式确实大大的提升了整个模块的质量，转系统测试后基本没有发现下层的bug。

2、完成了一份问题的排查和定位文档，这样能够让测试人员直接根据里面的文档就能定位到问题的大概原因，大大减少了开发自己排查问题的时间，得到了开发的一致认可，通过一段时间的积累后，也大大提高了测试人员对于代码的理解能力。

第五篇：测试模式探索篇

通过前面的几步，整个测试团队应该相比最开始的纯黒盒测试有了很大的进步，但是感觉测试的工作还是落后开发的工作，于是，期望能够找到一种新的测试模式（应该说整个开发模式），让测试的工作能够更好的跟开发融合在一起。

过程中看了google测试之道里面的SET的工作，以及测试驱动开发等等一些新的模式，因为一些历史原因（比如：开发的思维转变），整个尝试过程还是相对缓慢的，当前主要是搭建了一套持续集成到环境，然后集成了一些自动化的用例，这样可以快速的反馈当前质量。

当然，通过以上几点离测试架构师的路还有很远，但是整个成长计划应该是比较清晰了，下面是个人觉得一个测试架构师应该要具备的能力，希望以此自勉；

1、需求分析能力：能够从客户到角度去理解需求，甚至能够直接发现需求存在的问题，去影响PO，来更好的帮助产品成功；另外就是能够将当前需求细化出来，并且通过细化的需求来思考可能在设计方面存在的问题，提前发现设计的缺陷

2、整个产品架构的理解能力：这个只有达到开发架构师级别，才能更好的去参与整个设计方案的讨论，并且发现测试方案的一些缺陷。

3、测试分析能力：能根据产品的特点来分析通过怎样的方法来更快的保证质量，从而来满足上面对测试团队不断提高要求

4、技术人员培养能力：一个架构师应该说能够通过自己的影响力来得到一群的技术追随者，而对这些人的培养也是一个很重要的能力，这样才能提高整个团队的技术水平

5、技术规划能力：技术是不断的向前发展的，测试技术也不例外，所以，一个好的测试架构师应该要能够识别后面的技术改进方向，以及一步一步的推进下去

6、技术的广度：测试架构师需要掌握很多方面的技术，这样碰到新的问题时，才会有更好的解决思路

今日福利

【Java11期开课啦】

8大实战案例模块，历时三年沉淀，Java4.0震撼发布！

偷偷告诉你前50名，还可获得价值300元的京东购物卡呦~

如有疑问，请留言告知，或者咨询柠檬班软件测试培训机构：www.lemonban.com官网客服哦