測驗，沒有分析與設計就失去了靈魂；

測驗人員在撰寫用例之前，該如何進行測驗分析與設計呢？上次在《測驗的底層邏輯》中講到了【輸入輸出測驗模型】，還講到了【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 流測驗：按照一定的順序操作執行的測驗

1. 測驗由多個處理步驟相連的流程

2. 在相關操作或處理間不要重設系統

3. 改變時間和順序，并且進行并發操作

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）最好的用戶測驗是涉及多種用戶角色，并且多用戶并行、交叉操作，不僅僅是單一一種用戶或一個用戶操作，

作者：京東零售 張強

內容來源：京東云開發者社區

標籤：其他

上一篇：測驗工程師都是怎么寫測驗用例的？

下一篇：返回列表