做好軟體測試需要具備的思維方式！

最近部門來了好幾位應屆畢業生加入團隊，我們也大張旗鼓的組織了集中式的培訓，其中我需要對關於測試工作進行簡介，在培訓內容中，我特地整理和回顧了做好軟體測試需要具備的思維方式，當時也就4張PPT。在此，我再詳細整理出文字內容也分享出來給廣大的同行。

首先，從需求，使用者及研發角度考慮，要想為產品貢獻最大的力量，就不能只專注於做好測試保證質量這一個方面，而應該是從多個角度全面衡量。

從圖中，體現出我們也應該站在使用者的角度，研發的角度來考慮產品的整體規劃。

使用者思維

在工作中，一部分測試同行特別是初入者在對待需求時都過於被動，不太會把產品各個模組的業務串聯起來，成了因為需求來了所以做需求，純粹看著需求文件就開始做測試用例的設計了，並沒有想著先把需求理順了想明白了再開始著手。其實這個階段也即是非常重要的需求分析及功能點拆解，即使說這主要是產品經理們的主要工作，但是他們也並非聖賢，對產品設計的細節考慮可能並不周全，甚至嚴重時會出現較大的需求漏洞，引發較嚴重的影響。而我們也應該具備該項能力，如果不能站在公司戰略層面考慮該需求對業務上能帶來哪些促進，也至少能站在使用者的角度考慮能給使用者帶來什麼價值，能滿足使用者哪方面的需求，同時能及時發現對於使用者操作過程中的體驗問題，在糗事百科創始人著作的《結網》一書中，也提出了使用者體驗的三大原則：別讓我等，別讓我想，別讓我煩。我覺得作為一名合格的QA是需要具備這方面能力的，但是在實際工作實操中還是需要具備溝通技巧，畢竟能對於使用者體驗方面的改進需要產品經理拍板，如果的的確確非常明顯的體驗問題，是有必要堅持真理說服他們優化的，否則還是把話語權留給他們，我們只是提供建議吧，不然工作中的火藥味一定會很濃。

架構思維

要想設計一份有效的測試用例，就必須要對軟體開發設計思路有深入的瞭解，我們也經常有類似的事情，業務需求未做任何改變，而架構做了優化，如果單純地拿著一份根據業務整理出的用例是無法準確而有效的測試的，架構的調整包括：底層資料結構的調整如分庫分表，服務化（SOA），日誌的收集處理以及容災處理等等，另外，為了能有助於測試開展，我們同樣需要了解開發技術，畢竟在測試環境的搭建及維護，測試過程中各種場景的模擬特別是異常情況，以及自動化測試，如果不借助於開發技術，自動化工作也是很難開展的。比如被測系統依賴其他系統發的一條MQ訊息而做相應的處理，那自動化程式碼中為了驗證該邏輯，就需要MOCK這條訊息（即設定樁Stub）並且傳送到某個管道中，讓被測應用接受並處理它，如果連MQ是什麼都不知道，也不知道如何在程式碼中傳送訊息，那這個部分的自動化測試是沒法開展下去了。

上面只是舉了一個例子，總結一下，需要具備的架構思維包括：

1）瞭解並熟悉開發使用的技術及開發框架，比如用到的Spring MVC，Mybatis，Redis，前端HTML，JS，相關協議等（視不同專案具體情況而有所不同）；

2）理解研發設計的架構及設計思路，並考察開發設計是否滿足業務需求；

3）Review技術方案時，考察是否滿足易維護性，易擴充套件以及對效能和安全的要求，並且在關鍵業務出現異常時是否新增報警等，而這一點也是大多數從事功能測試的同學最易忽略的。

測試思維

如果要特意區分使用者思維和架構思維的話，在測試過程中，就要額外關注：以嚴謹的測試設計方法覆蓋需求功能點及程式碼分支，具有場景思維和對異常情況的考察。對此我們可以細化總結為以下幾點：

1. 逆向思維

比如我們經常需要對介面做測試，通過輸入驗證輸出，如果我們使用各種輸入都無法得到介面設計中某一種輸出的情況時，就需要從輸出來逆向推導輸入，另外比如驗證一些異常情況，介面需要返回一些error code，使用正常手段是肯定不能得到的，就需要為了出現該error code藉助環境及工具來模擬。另外，我們在分析很多問題時，同樣也離不開逆向思維。

2. 組合思維

比如軟體在多使用者，多程序，多次執行等情況下，都可能出現意想不到的缺陷，甚至對於複雜的業務場景，在對同一份資料進行操作時，不同子業務並行執行情況下，都有可能造成資料上的錯誤，特別是對於與核心資料有關的業務上（如money），是否新增行級鎖都是需要測試到的，同時，不同業務不同的操作順序，組合方式下，不同的維度等都有可能出現bug。

3. 全域性思維

即能把握整個專案的多個方面，多個團隊的任務及分工，整體的資料流及業務流，從全域性思考是否滿足業務需求，這其實並不只是說對於需求的評審，更多的是關注上下游相關聯的系統或介面等，凡是涉及跨團隊開展的工作，一定就需要更多的溝通協調，很明顯的就體現在對業務理解不正確，介面定義有誤，具有全域性思維的人更能在大型專案中游刃有餘，體現其leader的潛質，畢竟做leader就需要關注本部門之外其他部門都在幹些什麼，以備能做出對大局有利的決定。

4. 兩極思維

即站在事情的兩個極端來考慮，比如資料上的無窮大與無窮小，在資料儲存上，資料庫層面欄位設定為int與bigint所支援的數量級是不一樣的，基於**，如果存在超過int的長度的資料，那麼在儲存上以及程式碼中，都需要做相應支援，否則就只會顯示到該型別的最大值了，而且在業務層面也經常有兩個極端的情況，比如商家入駐開店，很多時候都只是考慮到開店該怎麼做，卻忽略關店的情況。其實在邊界值用例設計方法中也用到了兩極思維模式。

5. 簡單思維

簡單思維表現在很多方面，比如經常非常嚴重的bug都可能是犯了一個很簡單的錯誤引起，在處理測試環境時經常出現無法正常訪問，也許可能只是磁碟空間滿了而已或者一個簡單的配置不正確引起，在日常工作中這樣的例子非常多，我們也要善於一層一層剝開問題的現象，找到其本質，就好比剝洋蔥一樣，不要一開始就把問題想的過於複雜，往往事情並沒有那麼複雜。

6. 比較思維

比較思維其實貫穿在我們整個測試生涯中，測試本來也就是一種驗證，根據實際結果跟預期結果對比。而且我們在平時工作排查問題時，也有非常多需要去對比的，比如配置檔案的差異，環境的差異引起的不正常結果，此外，我們也通過svn中程式碼diff的差異來明確改動的範圍制定迴歸策略。還比如在做一些前後兩個版本吐出的資料差異時，頁面顯示差異時，都可以使用diff的思想來開展自動化的工作，大大提高效率

——————————————————————

最後給大家推薦一個學習資料分享群（574253227），裡面大牛已經為我們整理好了許多的學習資料，有自動化，介面，效能等等的學習資料！