我為何從開發轉測試，並堅持了 16 年？
此文是由茹炳晟老師的直播整理文，主題為“去 QE 時代，測試開發者該如何迎難而上？”。簡單介紹下茹炳晟老師，他是 eBay 中國研發中心測試基礎架構技術主管，有著 16 年的測試經驗，而且有著從開發轉型測試的奇妙經歷，算是國內第一批做自動化測試的工程師。現在他還在極客時間開始了一個專欄 -《軟體測試 52 講》，覆蓋率測試、開發者所需要的知識點，讓測試更加精通，讓開發瞭解測試。
我為何從開發轉測試，並堅持了 16 年？
茹炳晟：剛才我們聊到自動化測試，我們做 GUI 自動化測試的過程當中，以前就只要把這個自動化做起來就好了，但隨著你的用例，用的數量越來越多之後，你不單單是把一個場景自動化就可以了。因為隨著你的用例變多之後，你所有的用例設定，包括你的程式碼的結構，都要考慮這個東西的可維護性，因為可維護性一直是 GUI 自動化測試很大的一個痛點。我們在後面的 GUI 測試過程中，就會去考慮，怎麼來做分成？怎麼來做基於可重用的指令碼？怎麼來做基於頁面的物件模型？甚至到後面還有 BDD，就完全是業務，使用者行為驅動的這種測試。那麼，從這些概念當中，可能你已經聽出來了， 不管是你之前有沒有接觸過這些概念，你都能夠發現一個很重要的資訊點，自動化測試沒你想的這麼簡單，也完全不是一個簡單的錄製，或者回放。
所以說，我自己當時在轉型的過程中（從開發轉向測試），我就是看到了這些點，覺得這裡面的學問，或者說可以做得東西，尤其在當時的大環境下，是非常多的。因為當時沒有人去做這塊，而且當時是沒有有開發經驗背景的人會去專門做這一塊的東西。我也是看中了這樣一個機會，後來事實證明，轉型並沒有錯。
隨著時間的發展，後來就越來越證明整個自動化測試到後期的一些基於 API 測試，或者現在很多一些新的測試技術越來越多，而且整個測試地位也越來越高，從早年的並不受重視，或者是一些比較弱的開發去做測試，到現在一個優秀測試工程師可能是比一個開發人員更懂開發程式碼。因為如果他不懂程式碼，或者不懂開發是怎麼來做得，你讓他怎麼去發現開發當中的一些問題？這個過程是相輔相成的。
其實我們很多測試已經分為了三大塊。
一塊是 所謂的傳統意義上的基於業務功能的測試， 基於手動測試，或者現在非常流行的，基於探索式測試，也就是說基於一些錯誤猜測，以及基於一些你做了哪些測試，你假定哪些地方有可能會出錯，而且做進一步測試，這樣一個過程，所以說這是一部分做業務測試的同學。
那麼 第二塊是做自動化測試的同學， 自動化測試的同學對業務瞭解程度並不是很深入，但是他所做的事情是把一些手動的指令碼，很方便得把它翻譯成一些自動化的指令碼，可以讓機器去執行，那麼他的主要技能是主流的一些 GUI 的 Framework，比如說現在主流的像 Mobile 端的可能就是 API，或者是不同框架的這種自動化開發技術，這是第二類。
第三塊是很大的一塊， 就是現在意義上的叫測試開發。 測試開發並不是傳統去做自動化用例的開發，他會去做一些測試平臺、測試服務，或者一些測試基礎架構的開發。你可能會問，這些基礎架構包含什麼東西？我可能舉兩個例子，你可能就知道了，你現在要跑測試，你要跑一個 Web 端的，或者跑一個 API 手機上的一個 Mobile Native 的 app 測試，你肯定一定要有執行環境，你如果是手機端的，你一定要有手機，要有安卓的 Device，或者有 IOS 的 Device，去讓你跑這些測試，那麼這些手機你怎麼來？單個來拿嗎？你肯定會去建一些機群，甚至建一些私有云，像國外的 Lab 服務，其實包括國內的一些其他伺服器，類似雲測的服務，就是把這些裝置集中在一起。
那麼這部分工作是誰做的？就是現在的測試開發去做。
軟體測試對於學歷的要求高嗎？
茹炳晟：反問下大家，你在學校裡面學的東西是什麼呢？你真正去看，學校裡面出來，你上了工作崗位之後，學校裡的東西立馬能用的有多少？ 我覺得基本上是在 10% 以下的，所以說我覺得學校裡面學的是什麼呢？我個人認為更多學的是一些思想方法，就是說你面對一項新事物的時候，你會用什麼樣的方式，如何在很短的時間內用自己的方法，把整個這件事物的來龍去脈搞清楚，並且你能夠接受它並且你能夠運用它，這是個很重要的點。
所以說跟學歷沒有必然的關係。像喬布斯這種公司，它不注重你的出生，或者你是從哪個方面去做這個事情， 他看中的是你的思維方式，你的能力。 這又讓我想到另外一個點，現在講到面試， 我個人是十分反對刷題的。 因為我們碰到過一些同學，面試過程中，你給他一個演算法去做一下，如果他能立馬給出一個最優解，那這個肯定是有問題的。因為我的理解，正常的情況下，你不可能一下子就找到這麼一個非常好的最優解，你能找到這個最優解的前提一定是你之前看到過這樣的演算法，或者是你看到過這樣一個最優的解法。
我們想看到的是一個什麼樣情況呢？ 你不是給我一個最優解，而是你給了我一個方法，這個方法不一定完美，但在我們的引導下，你逐漸把它完善，逐漸發現你這個演算法的問題在哪裡，哪些地方可以去做更多的改進，然後把這個演算法逐漸變完美。 這個是我們想看到的，我們是想看到的是你在面對一個有挑戰事物的情況下，你是怎麼把一個大問題化解成一個小問題，每個小問題又是如何去解決，最終解決這個大問題，解決了這個大問題之後，再去回顧一下，你在解決這個大問題的過程當中，有哪些地方是可以改進的，是可以優化的。我們是想看到的是這種過程，所以是這樣一個情況。
去 QE 時代，測試工程師該如何修煉？
茹炳晟：首先我想先解釋一下，什麼是“去 QE”。“去 QE”這個概念在國內還是非常新，但是在一些像 Facebook、Google、Ebay 這樣的公司，已經都在做這些事情，而且有很多都已經真正落地了。首先我先表明我的一個觀點，我並不是“去測試”這樣模式的推崇者，因為去不去測試根本的原因不在於說，你覺得能不能去， 而是完全取決於你的組織上下文、你的組織成熟度、你成員的水平、你工具的成熟度、你的體系、你的上下文、你生態的成熟度。
那為什麼 Google 能做？
因為 Google 拉任何一個測試工程師出來，直接去做開發是沒有任何問題的，但在國內，你讓測試去做開發通常是比較難的，所以你面對的上下文、面對的環境，差異性就非常大。這種情況下，你說去 QE 一定好，或者去 QE 一定不好，都是沒有一個定論的。
我的觀點在於，並不是一定要說那個好，而是我們應該面對一個特定的專案，或者面對某一個組織，我們怎樣去兩邊取各自的長處，兩邊去各自的短處，有機地結合在一起。這也就是現在所謂的“去 QE”，就是“沒有測試工程師，開發自己做測試”這種架構。
那麼哪些情況下是適合讓開發自己去做測試的？哪些情況下還是需要一些專業的測試人員來做測試的？
傳統的測試策略，更多的是一個金字塔模型，也就是說 UT 會做的比較多，中間層，像 API 的整合，或者是整合測試會做的相對少一點，最上層的 UI 一般是更少，是個輕量級。
但在現在網際網路的時代，尤其是一些去 QE 的公司，他是怎麼玩兒呢？他會把整個三角形變成一個類似於菱形這樣的一個架構，也就是說 UT 這塊是非常的少了，中間層，API 這一層，由於微服務化，這層會非常的厚，上層的 UI，會做的相對比較少，而且更會去做端到端的，面向對終端使用者的這種測試。除此以外，這個菱形的頂上還飄了一朵小的雲，這朵小的雲就是現在非常流行的 ET，也就是所謂的探索式測試。
沒去 QE 之前，整個架構是金字塔，底部 UT 是開發做，API 測試跟 UI 測試都是測試人員來做，但是在去 QE 之後，是什麼樣的一個架構呢？ UT 開發做，API 測試也是開發做，UI 測試還是開發做。 唯一是測試人員可以做的是哪裡呢？ 是頂上飄的那塊小云，也就上面那個 ET，探索式測試。 因為這一塊需要更多的是一些發散性的思維，而且需要你對業務有非常好的理解。這還需要你除了理解業務外，還要明白產品內部的一些實現，以及它的架構，才能比較有針對性的去做一些探索性的測試。
面對這樣一個大的變革，你可以看到有點類似於把測試上移了，就是你原來的測試工程師只是做上面的 ET 部分，但是原來的那些像下面的 API 測試，或者 UT，或者基於 UI 測試，這些測試誰做呢？由開發做，但是由開發做不表示這個活沒有，測試這個活還是在的，只不過是換了一批人去做這個事情，本質上並沒有根本性的變化。根本性的變化就在於可能從組織架構的角度來看，現在可能不再有集中的一個測試團隊了，這些負責測試業務的測試工程師會打散到各個開發團隊裡面去，而且他承擔的角色也不一定是全職的測試，他有可能會做一部分開發，也會去做一部分的測試
開發人員哪有那麼多時間測試？
茹炳晟：這是個非常好的問題，也從兩個點來講，就是開發很忙，開發最大的價值在哪裡？ 它是開發功能，這是它的核心價值，測試不是他的核心價值。 那麼以前為什麼說開發不做測試，沒有問題？因為後面是有測試幫你做的，你的工作範圍不包含測試，也就是說你在打分的時候，你所有的績效是不把測試的工作量算進去的。測試的工作是由後期專門的測試人員去做的。那麼現在開發去做測試，他就會把測試這部分工作量算到它的打分裡面，也就是說測試的工作量是算在了開發上面，那麼勢必就會讓開發的工作量就會變少了。
第二個點， 以前測試人員做測試的時候，測試有很多輔助的東西，其實開發人員並不知道，比如說測試執行環境，還有去搭建測試執行環境， 比如說你拿到一個包，這個包你要去部署，你怎麼先把這個包部完，然後才開始測試，就簡單來講就裝環境。當時這種模式下，這種協調都是測試人員自己去做的，因為測試人員天天在做這些事情，他對跨 demo 非常清楚，他知道這些資料怎麼來，並且這些資料在每個團隊裡面是怎麼來。但如果讓開發人員去做，開發人員就不清楚了，他很難找到，或者說他要找到，需要花很多額外的精力才能去創建出這樣一個 case，創建出這樣一批測試資料出來，或者說他要花很長的精力去找到一個測試環境，或者去做一次測試包的部署，他都非常累。
正是因為這些問題，所以就會有後面我們想聊的 工程效能團隊的概念，現在非常流行，包括 Google 現在也在執行的模式。 工程效能團隊這批人，一般都是由當時的測試開發人員組成。剛才我談到有三類人，通常只有第三種人，也就是說工具平臺 Service，平臺化正式開發的人，他會轉到工程效能團隊裡去。這個 Team 做什麼事情呢？ 他就是給開發賦能，賦給開發測試的能力。
那麼他通過什麼樣的方式來給開發賦能？他提供非常簡單的 Service，可以讓開發去創造任何他想要的資料，他可以給開發人員提供一套部署好的測試執行的環境，他可以給讓開發人員非常方便地去建立一個包，並且讓它自動化的部署完成。這些都是工程效能團隊為了提高開發本身的執行效率、提高它的工程效能，所做的一些平臺化，服務化，工具化的東西。這個模式現在是非常的流行，目前像 eBay 就在執行這樣的模式，Google 就是業內做的非常成功的一家公司。
Google 引起“去 QE”的故事
茹炳晟：做測試的同學肯定知道一件事情，Google 在業內有一個非常知名的大會，叫 GTAC，它是 Google 在全球的自動化測試大會，每年都會在倫敦、歐洲、亞洲等地方舉行。但是到了去年，也就是 2017 年的時候，Google 突然把這個大會停掉了，並在官網上給出了這樣一個說明，說了我們為什麼會把這個大會停掉？我們的原因在哪裡？
這個大會成立已經有十多年了，當時成立這第一屆到現在第十幾屆的時候，他這個初衷是什麼？Google 是想提高自動化，提高測試的創新，測試的高效方法，來提高整個工程效率。但到了 17 年的時候，Google 意識到，單靠測試已經不是最好的途徑去提高整個企業研發的效能了，所以說，他在這時候把大會停掉，並且提出了 Google 在 2018 年會迴歸，但會把這個會的名字改掉，不再是一個測試大會，而會是變成一個工程效能 Topic 的大會。
那麼 Google 官方的主頁都去宣稱了這樣的一些策略，以及他的想法，對於工程效能的一個定位，並且提供了一篇很漂亮的文章，去解釋 Google 的測試開發、測試工程師，及他們的定位，以及在工程效能團隊之後，他們這幫人是怎麼來定位的。大家可以在 Google 的會議官網首頁裡找到這篇文章的連結，大家可以去讀一下，還是蠻有意思的。
針對初級測試人員，有沒有什麼建議的學習路線？
茹炳晟：這個是個非常好的問題，而且非常具有典型性。
首先作為一個初級測試人，我對初級的定義一般是在 0 到 5 年，或者 0 到 3 年。要回答這個問題，先明確的一點是，前面我們講到測試已經不是以前傳統的測試，是一個大的測試，是一個廣義的測試，那麼在這種情況下，測試分為三類人： 一類是做業務功能的測試；一類就是做自動化測試，把這些業務功能的測試轉換成自動化的指令碼；那麼第三類人就是做測試平臺、測試工具、測試服務開發的。
你首先需要明確的是，你想在這三塊當中所做的是哪一塊？明確了這個之後，我們再來看每一塊怎麼去做發展。
第一類，你想做一個業務的專家，也就是說你怎麼來把業務做得非常的精通。這類人在將來應該還是比較吃香的，但是，這類人的數量應該是非常少。為什麼？你會發現這類人他非常懂業務，它的業務可以懂到什麼程度呢？他可能就變成了一個類似於產品經理的角色，他可以很好的定位這個產品，怎麼使用，怎麼提高轉化率，怎麼提高變成一個能夠帶來流量、帶來使用者活躍度這樣一個角色。他會基於探索式測試的方式，基於對業務的理解，在業務的理解基礎上去優化整個流程，提供 UX 這種測試，提高一整個產品的轉化率。
那麼對於這樣一類人，他的成長路徑，或者學習方法是什麼呢？ 非常簡單，他關注的就是業務，要把這個業務本身的來龍去脈，使用者的使用者場景，以及使用者怎麼來用你的產品，以及這個產品怎麼樣幫助使用者去解決問題，並且整個業務流程是怎麼來操作的，這些業務流程有哪些分支都要懂得清清楚楚。 但這個也是蠻寂寞的，而且劣勢也是有的，一旦你離開了這個領域，你是很難找到更好的機會，除非你還在這個領域裡跳槽，或者在這個領域找同樣的型別。如果離開了這個領域，你的業務積累是沒有用的，這是第一類人。
第二類人，開發測試工程師。這種就比較簡單了，他的點在於他有些高效的 case 組織方法，或者對於不同測試框架的應用，或者對於不同的測試框架之間的差異、優勢劣勢有自己的理解，並且能夠基於這些測試框架的優勢、劣勢來選擇最適合目前自己產品，或者最適合目前專案的框架選型，並且基於這樣的框架選型來定義它的測試的力度，測試用例的力度，測試封裝層次，以及程式碼的結構，並且能夠提供一個高穩定性、低維護成本的這種 case。那麼這類人更多的是對工具的熟悉。
這個學習主要是一些工具的學習。這個工具學習當中，我認為有一個非常重要的點，因為我接觸很多剛剛接觸自動化測試，或者剛剛開始做測試的同學，他們對於這種工具的理解是有一個很大的短板，這個短板在哪裡呢？他們過度地強調怎麼去使用這個工具，也就是說他們拿到的工具，我舉個例子來講，早期的 selenium 1.0 或者現在 selenium 2.0，他就拿過來用，他就根據培訓機構手把手交的步驟，把整個東西建立起來，把測試跑起來，然後就完了。自己做一些封裝，做一些額外的操作，讓這個指令碼跑得漂亮就完了。 但實際上，我覺得欠缺了一個很重要的關鍵點，你必須搞清楚這個工具的原理，如果你不能搞清楚這個工具原理，一旦碰到任何問題，你就不知道怎麼解決，你也不知道，你在做一些更深層次事情的時候，你怎麼來去設計你的方案。
就比如我可能問在聽課的大家，你用過 selenium 2.0？你知道 selenium 2.0 真正的原理嗎？你能講出它的原理是怎麼實現的嗎？你能講出 selenium 1.0 的原理嗎？1.0 和 2.0 是完全不同的事情，雖然看上去只是兩個版本的差異，但它的實現原理，內部的機制是完全不同的。
那麼現在非常流行 API，如果你把 selenium 原理搞得非常清楚的話，你就能很容易地理解 API 了，否則你可能覺得 API 又是另外一套新的東西。實際上不是，它還是基於 selenium 那套東西在走。 如果你能真正理解了它實現的原理，也就能夠面對變化的時候，你能知道知其然，知其所以然，並且甚至能夠開發自己的框架去應對，你可能想過 selenium 為什麼可以支援各種各樣的語言，有 Python，有 Java，有各種各樣的語言支援，有 Ruby，它為什麼能夠支援？為什麼能夠做這麼多支援？
如果你不懂它的原理，你是很難理解它為什麼能支援這麼多語言的，但如果你能夠理解它的這個原理，你就豁然開朗，原來它是這樣子做的，所以它能支援更多的語言。關於這些東西原理的理解，在我的《軟體測試 52 講》專欄裡，我也會去做非常深入的講解，我會講到一些工具，比如 selenium、API，我可能不會太多的去講你怎麼來使用這個工具，因為我認為怎麼來使用這個工具，官方文件永遠是最好的一個教材。 官方文件永遠是最權威，而且是最新的，如果通過文字的教材，或者通過這種手把手這種教程，它早晚是過時的，而且是跟不上變化的，我建議是這種工具的使用是通過官方的文件。
我的專欄更多的是會基於這些工具，它背後的原理，它怎麼做得，它的來龍去脈，以及我們知道了來龍去脈之後怎麼用好這些工具，更多的是會講這樣的東西。這樣的東西會給你帶來更多的價值，而且可以跟市面上現有的一些教材，或者書籍，或者跟官方文件體現出一些差異性，而且能夠給你帶來真正的一些價值，所以是這樣一個狀態。
第三類就是測試開發工程師，那麼測試開發工程師可以不用講太多，因為我說白了，他就是個開發，只不過他開發的產品不一樣。他是為測試服務的產品，僅此而已。所以對第三類的成長路徑，完全就是一個開發的成長路徑，你必須作為一個開發人員的角度去做，去讓你自己慢慢成長為比較好的開發人員。
但是跟開發又有一個小的不同點。你還是需要理解測試的上下文，你才能做得比較好，你才能真正知道你的產品怎麼幫客戶去解決測試問題，你還是需要一些對於這種測試的理解，或者是對於這個測試服務需求的這種抽象化的能力。
基於這個問題，聊得比較多，因為這個問題比較典刑，展開的就會比較多，希望不同的人都能，這三類人當中都能有各自的收穫。
以上內容取自極客時間的《軟體測試 52 講》專欄，學習該專欄更多深度內容，請訂閱： ofollow,noindex">http://t.cn/EUC3kGQ