离开A公司，去了一家创业公司，0开始组建自动化团队，为了早点看到自动化效果，所以我优先选择在接口层做自动化。因为当时只有我一个人做所以我就想着尽可能少代码，易维护，所以选择通过excel管理api的方式来做接口自动化。 大概做法：
- 在excel配置所有接口信息（接口名，接口地址，请求方式，请求参数，最基础的校验点等等）
2.编写个框架(poi+log4j+httpclient+testng整合)，写个方法做到逐行读取excel文件，自动发起请求，并自动化做一些最基本脚本（状态码，必须包含什么字段等）并把结果写回到excel。
这种方式虽然免去了一个一个脚本写代码的麻烦，但这个过程其实心里知道存在下面两个问题：
- 接口校验不全，只能保证服务没挂，很难保证接口数据是否准确
- 开始意识到如果自动化组不扩大，难成事（一个人的思路有限）
遇到这两个问题一开始我当然希望通过添加人来解决问题，后来因为很多原因始终招不到人，所以我就开始内部发展，想让现有的QA更多的参与到自动化进来，但是因为他们不懂代码所以我一边每周定期给他们上课，另一方面就是引入soapUI工具来做接口自动化，但这个工具用不到2个迭代就被我抛弃了原因一来工具用的是破解版经常崩溃二来soapUI生成导出的脚本是一个xml文件，而且多人参与非常难合并。
我又把excel管理api驱动的方式拿出来，改了下变成了（详细可见 http://blog.csdn.net/meyoung01/article/details/46008439 ）简单说就是（httpclient+testng+poi+log4j+mybatis框架的整合），这会我只做了通过读取excel来拼接我的请求，而所有的返回我都通过代码去校验，这样校验完善了，当然这样就意味着一个api我需要写多个case了，增加了不少代码量，当然通过封装，其实每个接口写法都大同小异，又这段时间的简单培训带了QA，后面基本上这活就交给她了，这过程excel维护也一直是个工作量，也是考虑过把excel里面的api维护也自动化完成，后来因为发现开发文档维护很差，所以只是提了想法并没真正实践。
在创业公司除了做api，还一大块就是UI自动化。UI自动化当时web端我选用的是webdriver，移动端我那会比较生疏，通过对市面上流行的UI自动化逐个写demo了解优缺点后（当时画了个图 http://naotu.baidu.com/file/4196dc577d4c220ceca11fd90f0077a5?token=541f96728fa87f75
那webdriver这套的封装大概做了：
- 重新封装driver类
- 封装查找元素的方法做到智能等待
- 常用操作的二次封装
- log4j 整合实现每个步骤打印log便于调试和定位问题
- 常用类整合例如日期，随机数excel处理等
- Testng整合 重新封装Assert类，而外添加了几种校验方式和重新封装fail方法，失败自动截图。重新封装IAnnotationTransformer和TestListenerAdapter 做到失败自动截图和自动化重跑
- 编写case采用page-object+数据驱动的理念
- 结合jenkins 完成每日构建和代码变更自动构建以及构建失败自动化发邮件和测试报告
在创业公司还帮QA完成了公共用例的编写，case等级的定义等问题
离开创业公司去了一家上市公司，当时冲着团队玩BDD去的和团队一个移动端自动化做得还不错的人去。
刚进去这边团队已经玩几个月的bdd了，采用的是ruby语言cucumber+calabash+webdriver，第一个迭代完全是边学边做中完成，没有过多想法。当第二个迭代开始，老大要求提高自动化的覆盖率，而那时我们已经感觉很多能自动化的case我们基本完成了，想要提高覆盖率需要着手解决那些我们之前认为无法自动化或者难以自动化实现的case，通过统计其实我们发现很多case没法自动化基本都是因为校验难做或实现成本很大的，例如QAcase描述XXX控件显示XX颜色，XXX控件在靠左显示什么的等等。这时我们商量提出半自动化做法。
半自动化做法实现还是相对简单，半自动化的case我们自动化脚本能做到前面的when的操作，无法完成then的操作，所以我们就执行到这类then操作时进行截图，并把截图图片和then语句同时调用api传给一个半自动化校验平台，这个半自动化校验web平台其实简单的实现了：
- 截图的图片展示
- 对应then语句的展示
- 通过人工校验判断是否通过。
这样每次跑完所有脚本，之前很多还需要QA手工去校验的case现在只需要去平台上面通过人为的去判断图片展示和then描述是否一致。
bdd玩一段时间，原本设想着开发一旦提交代码，我们就可以立即去执行新功能的自动化脚本，然而最后这过程我们一直处于追赶状态，我们一直无法做到提前介入，这时我们再次进行反思，总结出若干个问题点，其中一个比较主要原因就是我们除了要编写feature对应的脚本外，还得去维护QA编写的feature，为啥？因为不同的QA对同一意思的一句话会有不同的描述例如：我用XX账号登录；我在XX页面用XX账号登录；我登录用XX账号等等。。。这些对我们而言处理的脚本都是一致的，但是这样的语句我们发现了我们得去修改feature，没发现我们可能就会再去实现一遍，这个过程工作量增加了非常多。
咋办？我们开始不仅仅给开发提供页面定位元素id，还给QA提供每个控件的操作语句，QA从我们定义的语句中去copy拼接成case，但其实实践来看这个过程是失败的，因为看似我们自己的工作量少了，QA却纠结了，也多了得跟QA交流的工作。
这时我就提出做个feature编写的平台，一开始我画了几个简单原型：
提出这个想法做featureIDE完全就是为了：
- 减少QA编写feature的工作量
- 减少同一句话不同描述。
通过几轮讨论下来，最后我们决定做的是一个平台。这个平台基本思想是bdd+keyword+po+数据驱动，理想化就是QA用自然语言写完feature，我们自动化人员可以不去写一行代码，这个case就可以被执行。我们自动化人员去定义句式（页面元素类型是可以枚举的，元素操作也是可以枚举的，根据元素确定操作的思路）例如：我在XX页面点击XX按钮。 然后cucumber胶水层完全匹配到这句话，并把XX页面和XX按钮作为参数通过某个接口去拿到提前定义好的这个按钮的定位方式。这样一个元素的定位方式有了，操作有了。自然calabash实现就容易了。
当然关于这个平台我们还有无限设想，很多未完成的功能，我们完全朝着一个产品化方向去思考。
这个平台我参与了整个过程的需求讨论和部分自动化代码实现。慢慢的发现我们的自动化实现完成了，基本工作量在平台前后端，为了避免没活干，刚好又出现性能问题，所以我主动去接了性能测试。
性能测试，工具VS平台？
通过跟之前性能测试人员和开发等沟通考虑开发也经常会自测需要测试提供脚本而jmeter仅仅是一个工具，一来不方便完成脚本的共享 ，二来发现开发迭代频繁，而QA难提供性能测试历史记录包括报告和场景。所以我开始考虑抛弃jmeter，而采用web平台。通过小段时间了解后，最后引入nGrinder平台，该平台分为controller,agent和monitor三个模块。 controller用例管理测试，脚本，测试报告和分发脚本等，agent主要用于发起并发，monitor模块用于收集监控数据等。
在使用过程中因平台已经好几年没人维护了，存在一些bug，所以去修改了个别bug，并对提供的方法做了简单封装并在脚本开发过程中加了poi第三方库，完成了通过excel完成的执行脚本需要的数据准备，最后一个接口的脚本简化到大概如下：
