軟體測試思維如何提升？
送：《不止測試》一本，文末獲取。
如果你是一個軟體測試從業者，你應該會有一種感覺，那就是以前累計到的測試經驗在某個時刻忽然不再起作用，以前用得很順手的測試方法在新項目中沒有發揮的餘地。
以前的軟體測試工作上手還是很快的。畢業之後，參加個培訓，學一下用例怎麼設計、邊界值、等價類之類的，再學幾個測試工具和管理工具，就直接上手了。 現在的話，學這些東西估計就不夠了。
軟體在不停的發展，業務越來越複雜、技術架構在不停的演進、基礎設施不停的構建，生態越來越複雜、不確定性越來越多，品質風險越來越不可預測。
軟體研發的模式一直在改變，我們積累起來測試經驗和測試思維也需要不停的升級換代，測試人員需要站在更高的維度來保證產品品質，甚至還需要學習產品思維和運維思維。
首先我們看一下產品思維。測試人員需要更多的考慮產品的業務價值，幫助企業盈利，滿足企業發展要求，滿足用戶需求、讓用戶使用方便。
這種業務驅動的思想使軟體測試人員必須具備三種能力：測試左移能力、測試右移能力和共創能力。
測試左移需要我們把測試工作向左移動，也就是在需求分析和研發階段就提早介入測試。
在需求分析階段，測試需要協同產品經理，明確用戶是如何使用這個產品的功能特性的。一、驗證文檔、操作手冊是否正確編寫；二、對功能的合理性、完整性提出質疑，包括用戶操作流程是否繁瑣、用戶操作流程是否完整、是否考慮特殊人群以及其他人群的使用場景和習慣；三、挖掘用戶需求，功能是否達到了用戶預期。
測試人員在開展具體工作時最好不要照搬以往的經驗和套路，凡事深入一步。
在思考、設計測試用例並執行測試的時候，不能簡單的套用用例設計方法去機械地進行，而是要考慮用戶可能的行為習慣、使用場景等。比如在影片播放時，用戶可能會頻繁的切換wifi訊號以及蜂窩網路，這些在傳統的測試中很少會測試到，測試人員需要還原真實的用戶使用場景，進行測試。
對產品文檔和需求分析不再停留在表面，需要不斷的對流程和交互提出質疑，討論其合理性。
站在用戶角度，深入挖掘產品功能是否達到了用戶的期望。比如「朋友圈」的功能流程是否能滿足用戶展示自我、分享心情等期望，驗證點贊、評論等功能能不能被朋友正確閱讀。
共創測試方案。測試方案在創建之前，跟業務人員溝通清楚對應功能特性的業務目標、業務價值，跟開發人員溝通相應功能模組的技術風險，基於風險的測試才是最能體現價值的。
傳統測試思維和現代QA思維
在產品研發階段，測試需要協同開發制定標準的程式碼交付流程，並加入一些特定的測試手段。
- 進行程式碼掃描和審計
- 進行簡單的單元測試
- 建立編程規範和工程標準，制定 git 提交規範、標準上線流程。
- 進行程式碼覆蓋率統計和分析
- diff 檢測，標記哪些程式碼進行了修改，在回歸測試時可以基於程式碼修改位置實現精準化測試手段
- 引入test double，進而Continuous Testing， 上下游依賴，第三方服務，數據構造，做隔離，Mock（如阿里的doom）， Stub（常見的搜索回放），能夠有效模擬場景，提升穩定性，降低數據準備的成本，方便模擬異常場景，簡化問題定位。
- 程式碼插樁。
測試右移則需要測試人員關注生產環境。 傳統的測試方法通常是在測試環境進行測試，某些時候會準備預發布環境模擬生產環境，但是用戶是在生產環境上進行操作，所有的真實數據和用戶場景都是來源於生成環境，因此在生產環境的測試行為更貼近真實的用戶使用過程。
測試人員永遠不能代表所有的真實用戶，永遠都不能完全模擬出所有的用戶行為。用戶的行為路徑、目的的隨機性太強，很難完全模擬，因此需要把測試過程右移到真實的線上環境，從真實用戶那裡去獲取用例、監控以及獲取用戶回饋。
測試右移可以進行的實踐有。一、直接在生產環境測試 ；二、監控預警；三、錄製用戶流量，生成真實測試數據；四、收集用戶回饋。由於生產環境的特殊性，在測試時需要注意很多問題，我們在下篇再討論。
最後是共創能力。 由於測試左移和測試右移，測試人員經常需要和產品經理、研發工程師、運營人員溝通和討論，共同制定測試計劃和策略。
通過和產品經理的溝通和配合，我們能更快的挖掘出用戶的真實需求，從而在用戶更關注的功能特性和交互上進行測試點的提煉。
通過和研發工程師的溝通和配合，我們能更清楚的知道產品可能潛在的風險，從而實現基於風險的測試實行。
通過和運營人員的溝通和配合，我們能更快的提煉出線上環境用戶的行為路徑和數據，及時對用戶進行監控，儘快收集到用戶的回饋和意見。
這些具體的操作實踐，測試界大佬已經用一本叫《不止測試》的書詳細解讀了。包括測試左移和測試右移的實踐、如何提升測試水平、甚至有詳細的職業規劃路線和需要的技能。掃碼領取電子版。（備註：不止測試）
