這是一篇雜文

做IT這一行，寫文章的話，對於我個人而言，我覺得可以分為兩類，一類是技術文章，一類的雜文。

這兩種哪一種都不好寫，但是非要做個比較的話，我覺得技術文章比較好寫，因為技術文章不需要表達自己的情感，只需要把自己認為重要的知識點寫出來就行。

但是技術文章有時候有很大的弊端，比如你覺得A知識點重要，B知識點也重要，在不侵犯作者權的情況下，你想把A/B知識點通過自己的方式分享出來。

這樣做的情況導致的結果可能有三種，第一種是覺得這又是抄襲文章，沒有價值。第二種是覺得不錯，鞏固了一下，第三種是之前沒有了解過，完全是一個新大陸，以備不時之需。

所以有時候害怕寫技術文章，但是還好，有些還是幫助了別人。對於那些說謝謝的人，在此我需要對你說一聲謝謝。因為你的言語真的會影響一個人是否堅持寫作。我雖不是玻璃心，但是在這個充滿鍵盤俠的時代，真的是有點害怕。

說說2017,2017我覺得是軟體測試行業比較蓬勃的一年。

2017年養成了一個習慣，就是沒事就會刷拉鉤、BOSS直聘類軟體。主要是想看周邊的一些企業會用哪些主流技術。根據企業所需去判斷自身有哪方面能力欠缺。這個習慣給我帶來了很多好處，從技能方面來說，以前可能需要一個月時間去寫自動化程式碼，現在或許只要一半時間。

手工測試雖然不會被取代，但是純手工測試一定被取代。

昨天看京東測試團隊寫的一本書，京東的分層測試主要分為三個階段。

第一階段：UI測試的探索，在此階段，對大部分核心功能進行了指令碼的覆蓋。效果雖然不錯，但是隨著業務的改變。UI指令碼也會變得越來越不適用。

第二階段：UI測試加介面測試。提升介面覆蓋率，降低UI指令碼覆蓋率。

第三階段，大部分介面指令碼覆蓋，少數UI核心指令碼覆蓋，剩餘只要手工測試時關注頁面顯示和瀏覽器相容性。京東這種大型企業測試模式，雖然不適合每個測試團隊，但是我覺得可以給我們帶來一定程度的思考，那就是手工測試人員如何去改變？

有個領導曾經跟我說過這樣一句話，說我希望你不但要學會提出問題，也要學會把解決問題的思路告訴我。

既然我在上面丟擲了這個問題，那麼我也結合自己的經驗說一下自己的想法。

提升是必須的。這個我相信絕大多數人都會這麼想。但是難就難在怎麼提升。目前軟體測試行業來說，我覺得提升方式主要分為三方面，第一是自學，第二是公司培訓，第三是機構培訓。

在此不談這三種方式的好壞。

因為這三種方式都為達到一個目的，那就是達到某個標準。

拿UI自動化來說，我覺得可以分為以下幾步：

第一步，先搞清楚你要學習什麼UI自動化，是移動端還是web端，不要想一口吃成胖子，不現實。

第二步：想好了做哪種自動化，再去判斷主流自動化測試工具和語言。

第三步：找到了語言和工具後，先從基礎做起，比如selenium，你要學會一些常用Webdriver API吧，Python你要知道什麼是類、物件吧。

第四步，你學完了基礎，想寫正式專案程式碼了，你要學什麼是單元測試框架吧。

這四步其實已經基本滿足你做一個UI自動化專案了，但是我覺得PO、CI也很重要，所以也要學習吧。別跟我說這些我都知道，但是我不知道怎麼學，我想說網上免費資源那麼多，那些已經足夠了，你只是不夠勤奮或者開啟的思路不對。

如果連資源都不會找，下載個東西還要別人幫助，你是不是應該反思一下，少玩兩把王者，少逛兩次街，一個階段只鑽研一件事情，會不會變好一點？問問題不可怕，怕的是問的問題沒有經過自己深思熟慮的思考。

2018，就要來了，俠客們，加油吧！