1. 程式人生 > >3年測試經驗的文藝青年,從京東測試團隊淺談純功能測試人員該何去何從?

3年測試經驗的文藝青年,從京東測試團隊淺談純功能測試人員該何去何從?

                                          這是一篇雜文

        

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

UI自動化來說,我覺得可以分為以下幾步:

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

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

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

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

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

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

2018,就要來了,俠客們,加油吧!