隨着軟件和互聯網行業的發展，軟件測試正受到方方面面的機遇和挑戰。從技能層面上講：領域知識、測試工具、測試思維、自動化測試框架、編碼技能…..等等方方面面都有待提升，又都無法一蹴而就；從職業發展跑道的角度上來講：管理通道、技術通道、甚至擴崗位轉型都是可以考慮的，但也無一坦途。測試人員大腦被各種的思潮不停拍打着…..測試會不會死掉？我們到底應該怎麼走？從當前從網上的各種分享渠道來看，理性的觀點應該是：測試崗位可能會死掉，但是測試的職能不會死掉。大牛們建議給測試人員的發展提升方向主要是：測試工具與技術、測試思維、測試策略。在我看來這三個都是測試人員的關鍵提升方向，三者並不是誰替代誰的關係，而是應該選擇合適的學習路徑全面提升。但無論選擇何種學習路徑終極的修煉一定是思維。
一.軟件開發和測試中的一些現象：
我們先來看看測試和開發工作中的一些現象：
做測試設計的時候，很多人會沉迷於輸出大量的測試用例。比如，在測試網絡設備端口工作模式的時候，本端端口、對端端口所支持的工作模式、介質類型兩兩組合，輸出茫茫多的用例，樂此不疲的Copy、Paste，測試執行和工作彙報的時候似乎也很滿足與自己的工作量。而後呢？當新的測試測試任務增了不同的硬件單板，增加了更多的接口類型和工作模式之後呢…..？類似這樣的例子還很多，我們都很辛苦,加班很多，但這樣自己的成長在哪裏？那這裏究竟缺少一個什麼能力呢？
還有些測試人員（包括曾經的我），認爲測試用例的編寫應該事無鉅細，儘可能的詳細，在用例步驟中應該儘可能的清晰的描述清楚每一個細節，讓任何新手一看就能夠明白該怎麼測試。在以往非敏捷研發模型的大背景下，一個版本交付週期20幾天甚至1個月的情況下，其實時是OK的，即使你拿出3-5天做測試設計測試時間還是足夠的。但學習了邰曉梅MFQ 的TestCondition後，我發現一個用例其實並不需要展現每一個細節，只需要將其重要的覆蓋場景、覆蓋數據或其他條件參數清楚就可以了。在敏捷大背景下應儘可能減少測試設計過程中文本化編寫的時間，把時間歸還給測試人員，讓他們有更充足測試執行和思考的時間，價值更大。那麼從事無鉅細的的腳本化用例到TestCondition的轉變過程需要的是一種什麼能力呢？
在開發過程中，讓我看到了更多軟件設計與實現方面現象：大量的配置約束腳本，在增一個單板類型的時候所有腳本都要進行維護，缺少的是什麼？還是新增單板，只是變更了底層BSP，但依然波及着上層協議棧，這裏面缺少的是什麼？一個原本清晰的代碼邏輯，在做了若干年的需求之後，代碼架構已經喪失了層次感、變得理不清脈絡故障難以定位了，缺少的是什麼？
對，缺少的是抽象！
測試人員的測試設計需要抽象出什麼是測試邏輯？什麼是測試數據？什麼是測試條件？使得測試用例具備可複用性。作爲軟件開發人員抽象能力更是必不可少。”設計模式”裏面就提到了要基於“抽象編程”，這樣才能減少耦合，使得程序的可維護性和可擴展性更好。
可見，當測試人員還在糾結自己到底應該繼續走測試的道路還是應該轉型做開發是不是更有出路的時候其實你更應該修煉的是抽象能力。抽象能力是你在不同行業和崗位可無縫平移的重要技能之一。
下面我從：架構、設計和執行三個維度來橫向對比一下開發人員和測試人員都應該具備的抽象能力：
二.架構層面的抽象：
無論是軟件開發活動還是軟件測試活動，在架構從層面上都應該是有抽象的。我們最常見的一種抽象就是進行分層。第一次聽到分層的概念是在學習TCP/IP的5層和OSI的7層網絡模型如下圖所示：
圖2.1 網絡分層模型
這兩個都是經典的網絡模型，從提出到現在40年以上了我們依然可以看到當前從大到一個複雜的網絡，小到一個網絡設備的設計實現，都在從抽象層面上遵循着這樣的分層的規律。它的核心思想是：
從下層到上層，每一層爲上層提供提供服務，上層依賴下層所提供的接口，各司其職專注其應該做的事情。
其實這樣的分層理念在任何行業都是適用的，具有普適意義：
2.1 軟件開發領域的分層：
DDD（領域驅動設計）是當前炙手可熱的的軟件開發範式。在DDD裏面就提到了4層分層模型，如下圖所示：
圖2.2 領域驅動設計分層模型
DDD四層模型將整個軟件分爲了:用戶界面層(User Interface Layer)、應用層(Application)、領域層（Domain Layer）、基礎設施層(Infrastructure Layer)。
其中：基礎設施層提供通用的技術能力。如：網絡通訊接口、數據庫接口等；領域層是站在用戶和應用的角度抽象出來的軟件的核心概念，它是衆多領域對象、聚合的集合，領域層的設計力爭做到軟件真實應用的領域模型和設計模型的一致；應用層要定義軟件要完成的事務，事務的實現依賴領域層的支持；用戶接口層也就是提供軟件給用戶的界面呈現。
DDD四層模型的核心是領域層，但我們看到了它和TCP/IP層次模型同樣理念。DDD對整個軟件每個層次職責定義和聚焦點是定義十分清晰和明確的，保證每個層次做好它該做的事情，併爲上層提供着支持。
2.2 測試領域的分層和分級：
複雜的軟件設計，會將軟件從函數/類單元、模塊、組件、子系統、系統這樣從微觀的層級進行劃分。我們測試隨之也會有單元測試、集成測試、系統測試、甚至是系統集成測試，這就是我們的測試分層。而按照邰曉梅的MFQ理論每一個分層我們又可以進行分級：單功能（M）、功能交互(F)、整體上的質量屬性(Q)。單功能驗證更偏向LLT(Low Level Testing),而Q更偏向於HLT(HIGH Level Testing),如下圖所示：
圖2.2測試分層分級
不同測試分層體現的是不同的測試視角的融合；在大公司裏不同層次的測試工作可能還是由不同團隊來完成，它體現的是不同團隊的協作；分工之後各個團隊也可以更聚焦自己做的測試工作。
總結：
無論測試人員還是開發人員，在面對複雜問題時一定要具備層次化思考的習慣，要學會切蛋糕，並將蛋糕進行有效的分配和協作。
三.設計層面的抽象：
設計層面的抽象，我們通常見到的是將自己具體工作對象進行模型化的梳理。模型的使用可以參考，但不存在最佳實踐。
3.1軟件開發領域的模型(模式)：
軟件開發領域中提到模型，我第一反應想到的是“設計模式”中提到的23種常用設計模式。它們都是爲解決具體設計問題提供的一種參考，比如：
工廠模式：
圖3.1 工廠方法類圖（摘自《大話設計模式》）
給所有”產品”抽象出一個公共的接口，工廠類根據需要實例化不同的”產品”。它抽象出產品創建接口。業務代碼可以依賴工廠接口進行編碼。解決了 當“產品”種類擴展時對於其他業務代碼的修改和波及問題。
中介者模式（Mediator）：
圖3.2 中介者模式（摘自《大話設計模式》）
用一箇中介對象來封裝一系列的對象交互，中介者使得各對象不需要顯示的相互引用，從而使其鬆耦合，而且可以獨立地改變他們之間的交互。它解決的是對象間的複雜引用和交互問題。
我們可以看到“設計模式”，它是軟件開發中對具體事務進行分析後進行抽象的一種選擇。軟件設計有了合適的模型可以使軟件更合理的構建，軟件才能做到：可維護、可複用、可擴展。清晰的模型也更加便於不同開發人員之間的交流。
3.2軟件測試領域的模型：
在MFQ理論中，我們有着一套對被測對象的建模的方法：P:Parameter ;P:Proccess D:Data C: Combination S:State。
比如：在通訊協議行業的軟件測試中，對於有狀態的協議測試採用S:State的模型進行建模比較合適。例如下面的 ARP協議的基於狀態的建模：
圖3.3 ARP協議基於S-STATE建模
表3.1 ARP協議基於S-STATE建模
在對被測對象進行建模的時候着重分析和考慮它所體現出來的外在特徵選取合適的建模方式，這個建模的過程即是對被測對象抽象理解的過程。但並不代碼它只能用一種建模方式，任何一種建模方式也很難涵蓋它的方方面。同樣好的測試模型也便於團隊內部的交流和評估。
總結：
無論是開發還是測試，對被測對象都需要對所工作的對象進行分析和學習，而分析和學習的產物之一就是模型。前人爲我們留下了許多經典的模型、模式我們可以根據工作對象的特徵進行選取，但並不代表這種選擇是唯一的，只要能更好的解決問題我們也完全可以提出自己的模式或模型，而真正的高手更是能達到“無招勝有招”的境界。
**
四.執行層面的抽象：
**
執行，在漢語詞典中的解釋是：貫徹施行;實際履行。
從字面上就彷彿告訴我們，執行工作存在着一張有形或無形的Paper，讓你完全遵從它一步一步去履行，它像由機器去執行一段固定的腳本那麼的機械。然而無論是測試還是開發領域，目前都有着這麼一些實踐不那麼遵循Paper卻做的似乎也非常成功。
執行層面的抽象，我想講的是跳出腳本化去追尋事物的本質。
4.1開發編碼過程中的抽象：
傳統的研發流程開發人員可能習慣於等待，等待完善的架構和方案，然後再按照Paper進行編碼。然而，好的架構不是設計出來的。需求是不斷變化甚至一開始都是無法明確的，開發人員又如何能期待拿到一張靠譜的Paper包治百病，永遠Match住不斷變化的需求呢？
所以最新的研發思維是TDD，認爲好的架構是“重構”出來的。基於滿足實例化的需求、用戶故事的測試用例永遠寫出剛剛夠用的代碼。最求完美的架構和方案並不是實物的本質，快速響應變化，抓住用戶的應用場景爲用戶提供價值是我們做編碼的本質。在重構中我們不斷的滿足變化的需求，也不斷的提煉出我們的架構。
當然在最求爲用戶提供價值的同時，也同樣要考慮團隊內部的成本和價值。有的人會說，不是儘快的給用戶提供價值就行了嗎？還要什麼重構？還要什麼抽象？有新需求代碼Copy,Paste一把；加個功能宏塞代碼；運行狀態梳理不清楚了加個標誌位（全局變量）；那麼長此以往………..我想說的是那麼多程序員加班不是爲了理想而只是爲填坑。長期處於填坑狀態的程序員，必定會處於一種“稀缺”狀態，會導致認知帶寬急劇下降（稀缺，認知帶寬的概念，請參考《稀缺》這本書），埋下更多的坑。這樣填坑式的加班對於客戶和項目都沒有任何的價值。
4.2測試執行過程中的抽象：
從測試的本質上來說：測試是爲了發現缺陷而不是爲了證明軟件沒有缺陷。《軟件測試的藝術》也在測試心理學的章節中提到了“測試是爲了發現錯誤而執行程序的過程”。
簡單說就是發現聚焦風險的缺陷纔是硬道理。
測試用例精美與否，文檔漂亮與否都不是關鍵問題。我們說到了需求是變化的用戶場景也是變化的如果能夠要求一份一成不變的Paper就能滿足所有測試的需求？基於上面提到的兩個方面ET探索性測試被越來越多的提起。ET更注重測試人員的測試思路；信息的及時反饋；策略的及時調整；而不是讓文本化的工作佔據大量的精力，更不是用例機械化的執行限制了自己的思路。
當測試人員在每個測試周期一遍一遍的重複執行測試用例而逐漸開始發現沒有任何斬獲的時候，是否還是還應該還是爲了測試執行率，覆蓋率進行機械的執行呢？答案是否定的，執行用例並不是測試的本質。本質是發現更多的缺陷。比如，在項目生命週期的中期，按照《軟件測試經驗與教訓》那本書中提到的缺陷率“倒浴盆曲線”那樣,你應該嘗試的是新的測試策略來保持持續的缺陷發現率，採用新的工具、手段，收集新的測試Idea進行探索。
總結：
正如《簡單思考》一書中的觀點：“排除表面價值”，實現真正的簡單思考就是要“抓住本質，精簡一切”。作爲開發人員，本質就是持續交付內/外部價值，降低成本。而測試人員的價值就是儘可能早、多的發現產品缺陷。這樣你才能從繁雜的事務中正確的應用你有限的精力。這樣的簡單思考的抽象思維，無論是測試人員還是開發人員都是需要的。
最後，我想說的是與其焦慮測試人員的未來，不如先力爭從測試技術、測試策略、測試思維這三個維度努力讓自己成爲業界的專家再說，修煉到高階之後重點在思維；任何一個行業無論處在什麼階段，你要能站在金字塔的頂尖總不會混得太差。多學習一些除了測試之外的“軟技能”。不僅僅是大家熟悉的溝通力、表達力….。在互聯網P to P時代的個人分享能力；個人營銷能力；如何技術換資源？資源建平臺？….這些都是要成功的重要技能。