【轉】作好軟件測試須要具有的思惟方式

　最近部門來了好幾位應屆畢業生加入團隊，咱們也大張旗鼓的組織了集中式的培訓，其中我須要對關於 測試 工做進行簡介，在培訓內容中，我特意整理和回顧了作好 軟件測試須要具有的思惟方式，當時也就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的思想來開展自動化的工做，大大提升效率。其中，包括我好久以前寫的《我在蘭亭這三年（九）之AutoDiff自動化測試框架》也是基於比較的思惟。

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