測試策略
測試策略簡單來講就是需要明確“先測什么后測什么”和“如何來測”這兩個問題。
病有輕重緩急，測試也是一樣的道理，重要的項先測，而不重要的項要后測。測試策略會要求有明確測試的重點，以及各項測試的先后順序。
比如，對用戶登錄模塊來講，“用戶無法正常登錄”和“用戶無法重置密碼”這兩個潛在問題，對業務的影響孰輕孰重一目了然，所以，你應該按照優先級來先測“用戶正常登錄”，再測“用戶重置密碼”。
測試策略還需要說明，采用什么樣的測試類型和測試方法。 這里需要注意的是，不僅要給出為什么要選用這個測試類型，還要詳細說明具體的實施方法。
第一，功能測試
對于功能測試，你應該根據測試需求分析的思維導圖來設計測試用例。
主線業務的功能測試由于經常需要執行回歸測試，所以你需要考慮實施自動化測試，并且根據項目技術棧和測試團隊成員的習慣與能力來選擇合適的自動化測試框架。
這里需要注意的是，通常應該先實現主干業務流程的測試自動化。
實際操作時，通常需要先列出主要的功能測試點，并決定哪些測試點適合采用自動化測試，并且決定具體使用什么樣的框架和技術。
對于需要手工測試的測試點，要決定采用什么類型的測試用例設計方法，以及如何準備相關的測試數據。
另外，你還要評估被測軟件的可測試性，如果有可測試性的問題，需要提前考慮切實可行的變通方案，甚至要求開發人員提供可測試性的接口。
第二，兼容性測試
對于兼容性測試來說，Web 測試需要確定覆蓋的瀏覽器類型和版本，移動設備測試需要確定覆蓋的設備類型和具體 iOS/Android 的版本等。
你可能會問，我要怎么確定需要覆蓋的移動設備類型以及 iOS/Android 的版本列表呢？這個問題其實并不難：
如果是既有產品，可以通過大數據技術分析產品的歷史數據得出 Top 30% 的移動設備以及 iOS/Android 的版本列表，那么兼容性測試只需覆蓋這部分即可。
如果是一個全新的產品，你可以通過 TalkingData 這樣的網站來查看目前主流的移動設備，分辨率大小、iOS/Android 版本等信息來確定測試范圍。
兼容性測試的實施，往往是在功能測試的后期，也就是說需要等功能基本都穩定了，才會開始兼容性測試。
當然也有特例，比如，對于前端引入了新的前端框架或者組件庫，往往就會先在前期做兼容性評估，以確保不會引入后期無法解決的兼容性問題。
兼容性測試用例的選取，往往來自于已經實現的自動化測試用例。道理很簡單，因為兼容性測試往往要覆蓋最常用的業務場景，而這些最常用的業務場景通常也是首批實現自動化測試的目標。
所以，UI 自動化框架就需要能夠支持同一套測試腳本在不做修改的前提下，運行于不同的瀏覽器。
第三，性能測試
對于性能測試，需要在明確了性能需求（并發用戶數、響應時間、事務吞吐量等）的前提下，結合被測系統的特點，設計性能測試場景并確定性能測試框架。
比如，是直接在 API 級別發起壓力測試，還是必須模擬終端用戶行為進行基于協議的壓力測試。再比如，是基于模塊進行壓力測試，還是發起全鏈路壓測。
如果性能是背景數據敏感的場景，還需要確定背景數據量級與分布，并決定產生背景數據的技術方案，比如是通過 API 并發調用來產生測試數據，還是直接在數據庫上做批量 insert 和 update 操作，或者是兩種方式的結合。
最后，無論采用哪種方式，都需要明確待開發的單用戶腳本的數量，以便后續能夠順利組裝壓測測試場景。
性能測試的實施，是一個比較復雜的問題。首先，需要根據你想要解決的問題，確定性能測試的類型；然后，根據具體的性能測試類型開展測試。
性能測試的實施，往往先要根據業務場景來決定需要開發哪些單用戶腳本，腳本的開發會涉及到很多性能測試腳本特有的概念，比如思考時間、集合點、動態關聯等等。
腳本開發完成后，你還要以腳本為單位組織測試場景（Scenario），場景定義簡單來說就是百分之多少的用戶在做登錄、百分之多少的用戶在做查詢、每個用戶的操作步驟之間需要等待多少時間、并發用戶的增速是 5 秒一個，還是 5 秒 2 個等等。
最后，才是具體的測試場景執行。和自動化功能測試不同，性能測試執行完成后性能測試報告的解讀，是整個測試過程中最關鍵的點。
除了我給你詳細分析的、最常用的功能測試、兼容性測試和性能測試外，還有很多測試類型（比如，接口測試、集成測試、安全測試、容量驗證、安裝測試、故障恢復測試等）。這些測試類型，都有各自的應用場景，也相應有獨特的測試方法，在這里我就不再一一展開。
軟件測試52講---筆記整理
