服務驗證和測試

基礎要點：

1.確保新的或變更的產品與服務能夠滿足既定的要求。

2.服務驗證：建立部署和發布管理驗收的標準，側重于服務的功能與效果，圈定了測試的活動范圍和重點。

3.測試策略：基于服務驗收的標準，保證利益相關者的要求，確保針對內部開發的系統和外部解決方案的測試，符合風險偏好和測試目的。

4.功能性測試：單元測試、系統測試、集成測試、回歸測試。

5.非功能性測試：性能與能力測試、安全測試、合規測試、運營測試、保障需求測試、用戶驗收測試。

解讀：

新版ITIL 4 里的服務驗證與測試實踐，是由ITIL v3以及2011 版的“服務轉換”發展而來，當然此處所討論的內容會更加具體與深入。

總的說來，其基本次序是：服務驗證在先，測試在后。通常情況下，我們需要服務提供方的業務負責人和技術負責人，來共同參與和協商服務驗證的相關標準。也就是說，為了確保后續的測試活動能夠及時、有效地開展，我們應當在服務驗證環節明確如下關鍵要點：

1.概括性地描述產品、以及服務中的待測對象。

2.明確測試的目標、量化預期的效果。

3.根據需求文檔和SLA，準備相應的測試用例。

4.定義即將采取的測試方法、工具、類型與步驟。

5.明確測試中需要涉及到的人員角色和工作量估算。

6.定義可能調用的軟、硬件及環境資源，以及產生的費用與成本開銷。

7.揭示測試可能帶來的風險。

那么在完成開發或應用搭建之后，我們就需要通過測試來證明系統和服務是否符合前面所制定的驗證標準，能否達到當初的設計初衷，以及用戶的需求。這同時也是服務提供方能夠順利交付產品的前提。

可見，測試主要應當關注已完成產品和服務的如下三個方面：

是否滿足那些指導其設計和開發的業務和技術需求；是否能夠按需運行，并提供穩定的服務；既定的服務功能與效果是否能夠重復實現與交付。

在測試方法上，服務提供方既可以采取傳統的手動測試，也可以運用時下流行的自動化測試方法。兩者之間的不同在于：

手動測試是測試人員需要針對目標，手動執行每一個測試用例，人工提供不同的結果集，并仔細記錄每一個環節的成敗率。當然，有時也需要人工進行測試結果的判斷，因此，手動測試不但費時費力，而且難免會產生人為的疏忽。

自動化測試是測試人員憑借一些能夠自動化運行的工具，開展諸如回歸、或頻繁密集的測試（例如：模擬不同的操作系統及不同的瀏覽器，反復登錄某個頁面，或是輸入各種數據），以實現更高的效率、更少的人力，以及更低的出錯幾率。

正如前面基礎要點中所提到的，我們首先需要開展的是功能性測試。此類測試一般會涉及到如下四個層次：

1.單元測試：著眼于開發出的系統與服務是否符合詳細設計中的要求。通過劃分出最小的測試單元，我們應盡快地找出各個模塊或組件中的明顯錯誤，以提高單個服務功能項的質量，并減少后期返工的成本。

2.集成測試：檢查各個服務組件能否協同工作，測試整個系統能否通過成功構建達到預期的效果。我們應當在此環節發現系統架構與模塊之間、模塊與模塊之間是否存在接口問題，并記錄下測試的結果。

3.系統測試：關注的是作為產品的系統是否符合前期規格說明的要求。我們可以通過運行整個系統，來根據在驗證環節中制定的測試用例，執行全面測試，驗證并確證系統的功能與性能，是否符合需求規格說明中的要求。

4.回歸測試：在整改了在上述三種測試中所發現的問題之后，我們需要重新進行測試，以確認沒有給系統或服務引入新的錯誤或缺陷。自動回歸測試將大幅降低系統測試、維護升級等階段的成本。有時候為了保證最終用戶的滿意度，我們甚至需要邀請用戶參與進來，共同檢測系統或服務的平穩度和易用性。

在完成并通過了上述功能性測試的相關步驟之后，我們就可以采取非功能性測試了。可以說，此類測試更注重的是發現系統或服務在某種環境或臨界狀態下的反應狀態及魯棒性。也就是說，我們在實際測試中，需要模擬在非常規或非標準化的內、外部場景中，使用待測系統與服務，并收集相關的特征參數。

我們經常會在非功能性測試中引入極限測試。該測試的好處不言而喻。不過值得注意的是，如果我們過于苛求測試的全面性和真實性的話，則會在無形中給增加測試前期的準備，以及開發的整體成本。因此，我們應當注意上述基礎要點中提到的要“符合風險偏好”。

顯然，測試的輸出就是要發現被測服務與實際需求之間的差距，以及自身存在的錯誤與缺陷。為了有針對性地進行及時整改，我們可通過如下三步來實現缺陷管理：

定位與分析缺陷，進而填寫并提交缺陷報告；完成整改后發起變更需求，并在獲批后予以實施和修復；再次驗證與測試整改的有效性，并留下最終記錄。

當然，對于經過測試和后期整改仍無法解決的問題，我們應當及時將其納入前文提到的已知錯誤知識庫中，以便盡早告知用戶。

最后，需要注意的是，對于那些持續發展或經歷過變更的系統與服務，我們需要定期進行跟進驗證與測試，以向用戶證明其能夠維持原有服務級別水平。

實務：

企業通常會在新的系統和服務尚未完工之前，就事先確定好了有哪些標準需要滿足，有哪些功能需要實現，以及有哪些影響用戶使用體驗的重點。在此基礎上羅列出系統和服務的各種特征，并圈定測試的范圍與深度。

當然，這些都屬于服務驗證的基本準備工作。

如果說服務驗證主要關注和設定的是最低要求的話，那么我們在服務測試環節則會更加全面。為了提高產品的質量，確保服務的有效性，以及系統的穩定性，我們設計出了如下測試用例的基本類型：

功能性測試用例；

錯誤輸入測試用例；

圖1 通用處置流程

邏輯與流程測試用例；

物理與運行環境測試用例；

用戶接口與界面測試用例。

值得一提的是，針對測試中出現的錯誤、問題和缺陷，我們采取了如圖1 所示的通用處置流程。

圖中的每一個節點所對應的解釋如下：

1.新建：這是缺陷被首次提交時初始狀態。不過，對于一些復雜的問題或缺陷則可能需要測試人員予以進一步的確認。

2.審核：由主管人員審核該缺陷的真實性，并判斷是否屬于重復提交。一旦確認，他們則會分配給相應的研發人員或團隊接手處理，否則直接“關閉”或進入下面的“整改”環節。

3.分析：研發人員受理該缺陷，通過深入分析，以便制定整改方案。如果該缺陷的優先級不高，或是交付時間較為寬松，則會被設置為“延期”，直至下一個版本才予以修復。

4.整改：研發人員通過變更管理流程對缺陷實施修復與整改，并在完成后流轉給測試人員。

5.測試：測試人員針對原有缺陷展開新一輪的測試。如果通過，該缺陷的狀態變更為“已修正并關閉”；如果未能通過，則重返“分析”環節；如果循環多次仍無法修復，其狀態應被設置為“已知錯誤”。

當然，在整改與測試完成之后，我們應當及時且徹底地清理系統中殘留的測試數據、各類警告信息，以及歷史日志等，以便系統或產品能夠順利地流轉到正式部署或交付環節。