測試，沒有分析與設計就失去了靈魂；
測試人員在編寫用例之前，該如何進行測試分析與設計呢？上次在《測試的底層邏輯》中講到了【輸入輸出測試模型】，還講到了【2W+1H測試分析法】，但2W1H分析法是初步的分析方法，具體在測試中如何落地，還需要更細的設計。
今天就給大家介紹一下由測試領域專家James Batch總結的測試分析與設計模型，HTSM啟發式測試策略模型。
什麼是HTSM？
HTSM是一套測試思路啟發的方法，旨在幫助測試人員更好地思考測試策略，指導測試人員在進行測試分析和設計的時候如何去思考，思考哪些點。HTSM包括四個重點領域：測試技術、專案環境、產品元素和質量標準。James Batch建議：你可以隨意地使用它們，它對任何型別的軟體都是通用的，另外在落地應用的時候，建議根據實際場景調整模型的內容，以適應自己的組織環境。
James Batch原文解釋：The Heuristic Test Strategy Model is a set of patterns for designing and choosing tests to perform. The immediate purpose of this model is to remind testers of what to think about during that process.
下面是HTSM和2W1H分析法進行的對比，透過對比可以看出HTSM可以與2W1H進行對應，透過分析專案環境，瞭解為什麼測試這個專案，瞭解專案背景；透過分析產品元素，確定了我們的測試範圍，明確我們要測什麼；然後透過測試技術和質量標準指導了我們該怎麼去測。
HTSM與２W１H對比：
HTSM模型概覽：
在HTSM模型中，專案環境、產品元素、質量標準、測試技術每一項都列出了很多子項；其中【專案環境】和【產品元素】不需要按照模型提供的子項進行全量的分析，所以大家可以作為參考，挑選對自己有用的資訊進行分析即可。
我也會結合自己的經驗增加一些內容；【質量標準】和【測試技術】參考的價值會更大一些，我對原文進行了詳細的翻譯；因為只是模型，所以作者也不會對每一種測試方法或測試標準進行詳細的講解說明，只是作者根據他的經驗進行的總結，大家都可以結合自己的經驗總結更具體的方法；但測試技術和質量標準的每一個子項是可以作為測試人員進行測試設計的參考標準，質量標準也可以參考ISO9126軟體質量模型。
總之，模型不是詳細的知識講解，而是指導大家進行測試分析和設計的思路方法集合。
ISO9126軟體質量模型
下面分別講解HTSM的四個領域：專案環境、產品元素、質量標準、測試技術。大家也可以按照這個順序去使用HTSM，按照2W1H的方法去分析，參考HTSM提供的子項和經驗，最終形成完整的測試方案。
測試第一步：【專案環境】，測試之前一定要先了解專案背景，瞭解我們為什麼做這個專案？
專案產生背景： 為什麼要做這個專案？專案產生的背景原因是什麼？
所解決的問題： 這個專案解決了什麼問題？
透過了解背景，能夠更好的幫助我們分析需求，瞭解最原始的需求和目的；瞭解了最原始的需求，才能去分析PRD中的功能設計是否能夠滿足使用者最原始的需求，也才能更好的理解業務，理解需求，從而可以去挖掘需求文件中存在的問題或不足。
專案所屬級別： 是戰略專案？還是技術維護升級專案？瞭解專案的級別也就是重要程度，也決定了我們應該投入的資源；對質量的要求是什麼級別，使用者對質量的要求是什麼樣的。
專案期望完成的時間： 對完成時間的瞭解，可以決定我們後續會採取什麼樣的測試策略，哪些測試方法是必須採用的，哪些可以不用或者上線後再使用等等。比如時間特別緊張，最重要的還是要保障功能，其他效能可以根據上線的方案決定；是一上線就會有大量使用者使用還是隻有少部分種子使用者；相容性是否可以上線後進行，還是說針對C端的，相容性必須保障；自動化測試可能就無法做了，也或者自動化技術已經非常成熟，有錄製相關的工具，且經驗豐富，那這個時候自動化錄製工具或錄製回放工具就可以起到很大的作用。
系統使用者情況： 系統的使用者是誰？使用者量有多大？關注使用者量，第一是瞭解系統是否有效能壓測方面的需求，第二是瞭解系統的使用者量級是幾個，幾十個、幾百個人還是成千上萬？使用者的數量不同，他的價值必然不同。
系統客戶是誰： 系統的客戶是誰？客戶最原始的述求是什麼？
下面的是HTSM【專案環境】的具體內容，部分內容我做了補充和調整。
測試第二步：【產品元素】，就是我們計劃要測試的內容；測試人員必須保證覆蓋所有的產品元素，而且不僅僅是我們所看到的部分。
產品最終就是為客戶提供的一種經驗或解決方案；產品有多個維度，要測試好，我們覆蓋的維度必須要全面。每一個維度都代表了產品獨特的一個面 。如果測試只是覆蓋了一部分，就有可能錯過嚴重的bug。 分析產品的元素，就是分析我們的測試範圍，有哪些方面或內容是需要我們測試的。一般人確定測試範圍都來自於需求文件，其實需求文件之外還有很多東西需要我們關注，需要我們測試。下面是HTSM的【產品元素】：
HTSM模型【產品元素】列出的內容比較多，也比較複雜，這些內容可以作為我們的參考，絕不是要求完全按照下面的內容進行測試。
Structure結構：產品所包括的一切；
這一部分我覺得是我們最容易忽略的，我們大部分時間都是在測試軟體，硬體部分很容易忽略；另外容易忽略的就是非執行檔案，例如幫助文件、許可協議等，這些雖然很多都是業務提供，但出於對公司負責、對產品負責、對使用者負責，我們還是需要再檢查一下這些非執行的文件；幫助文件是否簡單易懂，是否有缺失，是否有錯誤或與系統功能不符；因為上線前對系統最熟悉的不是產品經理，也不是研發，而是測試人員。
另外分享一下我的一些經驗；首先，測試範圍的確定是非常重要的，大部分人會忽略這一步，這樣就有可能會導致漏測。這一步容易忽略，是因為我們的測試依據就是PRD，所以測試範圍都在PRD裡；但實際情況是，大部分測試範圍都在PRD裡，還有一部是在設計文件中，或者在文件之外。
對於從0開始的新專案，可以從兩個角度去考慮測試範圍：
一、產品角度，透過分析PRD基本就夠了；當然有些內容PRD可能也會疏忽遺漏，我們就需要對需求進行分析，挖掘出可能存在的隱性需求。
二、技術角度，除了使用者看到的可以操作的功能，有些功能是使用者無法直接用到的，或者是給其他系統技術開發使用者使用的；例如對外提供的介面服務、系統後臺非同步處理的任務、定時執行的任務、上線前刷的基礎資料、前置資料等。
從1.X到1.（X+1）或2.0的升級維護專案：
除了正常的測試範圍評估，最重要也是最難的就是迴歸測試範圍的評估了，也就是對原有系統的影響範圍是最難評估的。
對於迴歸測試範圍的確定，其實就是成本與質量的博弈；對於質量要求非常高的軟體，每一次測試都會要求進行全量的迴歸，所以這種場景下，自動化迴歸測試是非常重要的；對時間要求非常緊急質量風險可承受或可控的，迴歸範圍可以縮小到本次修改的相關功能即可；但大部分場景是時間要求比較緊，但質量也不能出現問題。這時如何圈定範圍，首先是本次修改的相關功能的迴歸必不可少；其次就是要守住系統的底線，也就是確定這個系統哪些功能是不能出問題的，這些功能就需要作為這個系統每一次迴歸的必選範圍。另外還可以透過程式碼diff的功能，分析本次改動點，影響到的功能。
除了功能迴歸範圍的評估，對於升級專案，一定要注意對原有資料的相容驗證；大概有以下幾種情況：
1）功能變化，對原有進行中的資料的操作是否會影響；
2）流程變化，對流程中的資料或駁回重新提交的資料是否可以正常進行；
3）資料傳輸物件（PO、VO、DTO等）發生變化，進行中的資料或重新編輯後的資料是否能正常操作，最主要時要驗證資料的傳輸或儲存。
4）底層資料庫表發生變化，是否影響原有資料的展示、操作；新增欄位是否需要刷數；刷數後功能是否正常。
測試第三步：【質量標準】，確定具體的測試策略，明確系統應該進行什麼型別的測試；
質量標準就是產品定義的應該滿足的一些要求，測試人員判斷一個系統是否驗證透過的規則；透過考慮不同型別的標準，你可以更好地規劃測試，並可以快速發現重要問題。下面的每一個型別都可以被視為是潛在的⻛險區域。
功能性（Capability） ：系統功能是否正確，是否滿足了使用者需求？
可靠性（Reliability） ：在任何情況下是否都可以正常工作？
- 健壯性（容錯性） ：系統在出現故障時，是否能夠自動恢復或者忽略故障繼續執行。
- 錯誤處理： 產品在出現壞資料的情況下能夠抵抗失敗，在失敗時能保持優雅，並易於恢復。（在失敗時，也能夠給出準確的提示資訊，並告知使用者如何進行處理解決）
- 資料完整性： 系統中的資料是受保護的，不會發生資料丟失或資料損壞。
- 安全性： 系統發生故障後，不會造成較大金額上的損失。
易用性（Usability）： 真實使用者使用產品是否很容易？
- 易學性： 產品的操作可以被⽬標⽤⼾快速掌握
- 易操作： 產品可以輕鬆操作
- 可訪問： 產品符合相關的可訪問性標準，並與 O/S 可訪問性功能配合使⽤。
安全性（ Security ）： 產品對未經授權的使⽤或⼊侵的保護程度如何？
- 身份驗證： 登入使用者是否經過系統驗證
- 授權： 使用者的許可權是否進行了控制，根據不同角色或級別進行授權
- 隱私： 客⼾或員⼯資料是否進行了加密保護
可擴充套件性（ Scalability ）： 是否有合理的規劃，應對系統的增長（資料量、流量、複雜性）
相容性（ Compatibility ）： 與外部的元件以及配置等是否可以相容，正常工作？在不同的硬體平臺上、不同的應用軟體之間、不同的作業系統中、不同的網路環境中是否可以正常的執行。
- 應⽤程式相容性： 該產品與其他軟體產品是否可以協同⼯作。
- 作業系統相容性： 產品是否能夠在不同型別的作業系統中工作。
- 瀏覽器的相容性： 產品是否能夠相容不同型別、不同版本的瀏覽器。
- 硬體相容性： 該產品適⽤於特定的硬體元件和配置。
- 向後相容性： 產品可與⾃⾝的早期版本是否可以同時使⽤，資料、功能是否能夠相容。
效能（ Performance ）： 系統的響應速度是否夠快？
效能測試很多時候是由專門的效能測試人員負責，但作為功能測試人員也一定要關注；效能測試除了常見的併發壓測，其實更多的場景是由於系統的資料量大，最終導致查詢、匯入、匯出等功能響應很慢；尤其再同時發生併發，或多工並行，最終就很有可能導致一個匯出任務，需要幾天之後才能完成。
易安裝性（ Installability ）： 系統是否能夠很容易得安裝到對應的平臺。
- 系統要求： 產品是否能夠識別某些必要元件缺失或不⾜？
- 配置： 系統的哪些部分會受到安裝的影響？⽂件和資源儲存在哪裡？
- 解除安裝： 產品解除安裝時，是否能夠清除乾淨？
- 升級/補丁： 可以輕鬆新增新模組或升級新版本嗎？他們是否會影響現有的配置嗎？
- 管理： 安裝是否是由專⻔的管理⼈員處理，還是按照特殊的時間表進行的？
易維護性（ Development ）： 系統是否容易進行開發、測試、維護？
-
可⽀持性： 是否可以以較低的成本向產品使用者提供協助支援
-
可測試性： 是否可以用盡可能簡單的方法進行快速測試
-
可維護性： 構建、修復或增強產品的難易程度及成本如何？
-
可移植性： 在其他地⽅移植或復⽤該技術的經濟性如何？
-
可本地化： 將產品應⽤於其他地⽅的經濟性如何？
測試第四步：【測試技術】，確定我們怎麼來測，透過哪些手段、方法進行測試，以保障系統的質量符合質量標準、要求。
測試技術就是進行測試的策略分析，常用的測試技術有下面九種。
Function Testing功能測試： 對產品的各功能進行驗證，根據_功能測試_用例，逐項測試，檢查產品是否達到使用者要求的功能。
Claims Testing 約束測試： 挑戰每⼀項宣告！保證使用者看到的任何資料中提到的功能的正確性及一致性。
1）明確相關的參考資料，如 SLA、⼴告、說明書、 幫助⽂本、操作⼿冊等 ；（_SLA_一般指服務級別協議。 服務級別協議是指提供服務的企業與客戶之間就服務的品質、水準、效能等方面所達成的雙方共同認可的協議或契約。）
2）參照上面的資料，測試產品的每⼀項宣告
Flow Testing 流測試：按照一定的順序操作執行的測試
-
測試由多個處理步驟相連的流程
-
在相關操作或處理間不要重設系統
-
改變時間和順序，並且進行併發操作
Domain Testing領域測試：
1）分析產品任何可能的輸入、輸出
2）確定測試採用的資料進行測試。例如邊界值、典型值、常用值、無效值、以及最具代表性的值。
3）考慮測試的資料的組合。
Scenario Testing場景測試
1）⾸先考慮可能發⽣的⼀切實際場景
2）設計測試用例，包括對產品有意義的功能，以及複雜互動的場景
3）⼀個好的場景測試是⼀個引人入勝的故事，講述⼀個重要的⼈如何 做⼀些對他來說很重要的操作
Stress Testing壓力測試
1）確定壓測的範圍，這個子系統或功能可能會承受量非常大的資料壓力，或由於資源受限，出現大併發導致系統過載或“損壞”；
2）識別與這些⼦系統和功能相關的資料和資源；
3）選擇或⽣成具有挑戰性的資料，或限定條件下的資源；例如，大型或複雜的資料結構、⾼負載、⻓時 間的測試執行、大量測試⽤例的執行、低記憶體情況下執行
Automatic Checking自動化測試
Risk Testing風險測試
１）思考產品可能會出現哪些問題、風險？
２）哪種問題出現的可能性會最多？專注於這些出現機率較多的問題
３）如果它們存在，你將如何檢測並發現它？
４）列出這些問題並設計相應的測試用例，專門用來挖掘他們
５）另外還可以諮詢相關的專家、檢視設計⽂檔、過去的缺陷報告或應⽤⻛險啟發式⽅法，這些可能都會有所幫助
User Testing使用者測試
1）識別使用者的類別和角色
2）確定每個類別的使用者日都都會做什麼操作，他們一般會如何操作，他們重點使用的功能有哪些？
3）獲取真實的使用者資料，或引⼊真實的使用者，提前使用系統進行測試
4）系統地模擬真實使用者使用場景（雖然你不是真實使用者，但也很容易把自己想象成使用者去使用）
5）最好的使用者測試是涉及多種使用者角色，並且多使用者並行、交叉操作，不僅僅是單一一種使用者或一個使用者操作。
作者：京東零售 張強
內容來源：京東雲開發者社群