離開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完成的執行腳本需要的數據準備，最后一個接口的腳本簡化到大概如下：
