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

最近部門來了好幾位應屆畢業生加入團隊，我們也大張旗鼓的組織了集中式的培訓，其中我需要對關於測試工作進行簡介，在培訓內容中，我特地整理和回顧了做好軟體測試需要具備的思維方式，當時也就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。

4. 兩極思維

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

5. 簡單思維

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

6. 比較思維

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

總之，用好了以上幾種思維方式，我想在以後的測試工作中，一定更加的游刃有餘，有效且高效！

原文

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

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

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

轉行軟體測試，需要做好哪些準備？

相關推薦