越迷信技巧越容易失敗

最近和幾位測試經理在一起閒聊的時候，提到了一個比較有趣的話題，就是在當前降本增效的大環境下，測試人員如何提升自己的競爭力或者影響力？因為大家都發現了一個問題，很多測試人員過份追求自動化，又沒有很好的落地實踐經驗，也沒有鍛鍊自己處理問題的能力。本文聊點自己的看法。

先提一句比較好玩的諺語：房間裡的大象。

我們知道，大象的特點是體積巨大，行動遲緩——假如說，現在房間裡如果站著一頭大象，那麼你肯定是能看見這個龐然大物的。所以這裡的 “大象”，是指那些非常明顯的、以至於讓我們根本無法忽視的事實和真相。那麼所謂房間裡的大象，說的就是：雖然有些事情就明擺在那裡，每個人都知道發生了什麼，但出於各種原因，人們卻對這些事絕口不提，要麼保持沉默，要麼用打岔的方式來顧左右而言他，逃避，或者回避。這種奇怪的場景，就像是我們明明知道房間裡站著一頭大象，卻假裝對其視而不見，甚至連走路都要小心翼翼地繞開，生怕碰著它。

那麼，在提升測試人員的價值，或者說測試人員個人能力提升的場景中，非常明顯的 “大象” 是什麼呢？個人認為有以下三個基礎的內容：

精業務：對於被測系統的業務邏輯，需要有很深瞭解，才能更好地開展測試活動。不能僅僅停留在頁面操作上，知道被測系統，什麼是核心功能，什麼是輔助功能，哪些業務是不能出錯的，哪些業務與周邊哪些系統有千絲萬縷的聯絡，能夠基於業務流程、資料流程來做測試用例的設計。

同時，需要具備一些探索式測試的能力。能夠貼近使用者，基於使用者的視角進行測試，關注功能點的實際業務價值，從客戶的角度評估軟體的實際工作方式。它更注重的是「思考」和「學習」，不斷地發現新的問題。

懂技術：伴隨著軟體複雜度的提升，功能測試已無法滿足日常的測試要求了。在很多場景下，需要測試人員能夠開發一些小工具來幫助自己從有序的、重複的活動中釋放出來。比如一些常規的造數、驗證等。還有就是自動化測試相關的內容，也需要我們對程式碼能力有一些瞭解。

程式碼能力現在基本上會成為測試人員的必備技能，可能在深度上無法與開發相對比。但是基礎的使用、基本的框架和常見的技術棧，都需要去了解和學習。日常測試內部的一些工具研發，還是要能夠勝任。在一些專項測試領域，測試人員應該要能夠做到對框架十分的瞭解，比如在介面測試層面，Junit、Pytest 等常見的框架需要知道他們的現實原理，能夠進行簡單的二次開發等等。

會架構：除了懂技術外，為什麼還要會架構呢？因為現在的企業級產品，基本上都會拆成若干個，基於幾十個微服務。在這種情況下，如果你不懂架構，不瞭解這些服務或者元件的特性、通訊方式、適用場景，你就很難發現一些深層次的問題。對於被測試系統的技術架構，需要每個測試人員都能夠了解並畫出來，這樣在測試用例設計的時候，也會有更好的針對性。

在這三者的基礎上，如果你還能夠獨立推進和解決問題，那就是個非常優秀的測試人員了。

但在現實中，很多測試從業人員並不認可這些東西，

提起業務，會說大家都是點工，不需要什麼測試思維，是個人都能點，但現實是很多人連自己負責的業務系統較全面的資料流都說不清楚；

提起技術，會覺的測試要什麼技術，會技術我還做什麼測試？但現實是很多時候開發在討論問題的時候不帶上你，是因為你根本就聽不懂他們在說什麼。

提起架構，更是離測試很遙遠，那你不是架構，效能測試又是怎麼做的？那些深層次的缺陷又如何能被發現？

很多測試從業者，並不會從這三方面去提升自己，反而越來越迷信各類 “捷徑”：搞介面自動化，但是基礎的程式碼能力都沒有，做 UI 自動化，PO 模式都沒弄明白，只是為了讓簡歷更好看些，但是一問，又說不出什麼來，各類前沿名詞一大堆，落地時遇到的難點又都沒有解決方案，人浮於事。

技巧，只有在紮實的基礎上，才能錦上添花。沒有紮實的基礎，技巧只能讓你更快的失敗。

先解決 “大象” 的問題，而不是視而不見。

我們要學會複雜的事情簡單化，看透問題本身，動作就會變得簡單，你就不會做錯誤的動作，確保自己走在正確的路上。

共勉。