基礎(chǔ)要點(diǎn)：

1.確保新的或變更的產(chǎn)品與服務(wù)能夠滿足既定的要求。

2.服務(wù)驗(yàn)證：建立部署和發(fā)布管理驗(yàn)收的標(biāo)準(zhǔn)，側(cè)重于服務(wù)的功能與效果，圈定了測試的活動(dòng)范圍和重點(diǎn)。

3.測試策略：基于服務(wù)驗(yàn)收的標(biāo)準(zhǔn)，保證利益相關(guān)者的要求，確保針對(duì)內(nèi)部開發(fā)的系統(tǒng)和外部解決方案的測試，符合風(fēng)險(xiǎn)偏好和測試目的。

4.功能性測試：單元測試、系統(tǒng)測試、集成測試、回歸測試。

5.非功能性測試：性能與能力測試、安全測試、合規(guī)測試、運(yùn)營測試、保障需求測試、用戶驗(yàn)收測試。

解讀：

新版ITIL 4 里的服務(wù)驗(yàn)證與測試實(shí)踐，是由ITIL v3以及2011 版的“服務(wù)轉(zhuǎn)換”發(fā)展而來，當(dāng)然此處所討論的內(nèi)容會(huì)更加具體與深入。

總的說來，其基本次序是：服務(wù)驗(yàn)證在先，測試在后。通常情況下，我們需要服務(wù)提供方的業(yè)務(wù)負(fù)責(zé)人和技術(shù)負(fù)責(zé)人，來共同參與和協(xié)商服務(wù)驗(yàn)證的相關(guān)標(biāo)準(zhǔn)。也就是說，為了確保后續(xù)的測試活動(dòng)能夠及時(shí)、有效地開展，我們應(yīng)當(dāng)在服務(wù)驗(yàn)證環(huán)節(jié)明確如下關(guān)鍵要點(diǎn)：

1.概括性地描述產(chǎn)品、以及服務(wù)中的待測對(duì)象。

2.明確測試的目標(biāo)、量化預(yù)期的效果。

3.根據(jù)需求文檔和SLA，準(zhǔn)備相應(yīng)的測試用例。

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

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

6.定義可能調(diào)用的軟、硬件及環(huán)境資源，以及產(chǎn)生的費(fèi)用與成本開銷。

7.揭示測試可能帶來的風(fēng)險(xiǎn)。

那么在完成開發(fā)或應(yīng)用搭建之后，我們就需要通過測試來證明系統(tǒng)和服務(wù)是否符合前面所制定的驗(yàn)證標(biāo)準(zhǔn)，能否達(dá)到當(dāng)初的設(shè)計(jì)初衷，以及用戶的需求。這同時(shí)也是服務(wù)提供方能夠順利交付產(chǎn)品的前提。

可見，測試主要應(yīng)當(dāng)關(guān)注已完成產(chǎn)品和服務(wù)的如下三個(gè)方面：

是否滿足那些指導(dǎo)其設(shè)計(jì)和開發(fā)的業(yè)務(wù)和技術(shù)需求；是否能夠按需運(yùn)行，并提供穩(wěn)定的服務(wù)；既定的服務(wù)功能與效果是否能夠重復(fù)實(shí)現(xiàn)與交付。

在測試方法上，服務(wù)提供方既可以采取傳統(tǒng)的手動(dòng)測試，也可以運(yùn)用時(shí)下流行的自動(dòng)化測試方法。兩者之間的不同在于：

手動(dòng)測試是測試人員需要針對(duì)目標(biāo)，手動(dòng)執(zhí)行每一個(gè)測試用例，人工提供不同的結(jié)果集，并仔細(xì)記錄每一個(gè)環(huán)節(jié)的成敗率。當(dāng)然，有時(shí)也需要人工進(jìn)行測試結(jié)果的判斷，因此，手動(dòng)測試不但費(fèi)時(shí)費(fèi)力，而且難免會(huì)產(chǎn)生人為的疏忽。

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

正如前面基礎(chǔ)要點(diǎn)中所提到的，我們首先需要開展的是功能性測試。此類測試一般會(huì)涉及到如下四個(gè)層次：

1.單元測試：著眼于開發(fā)出的系統(tǒng)與服務(wù)是否符合詳細(xì)設(shè)計(jì)中的要求。通過劃分出最小的測試單元，我們應(yīng)盡快地找出各個(gè)模塊或組件中的明顯錯(cuò)誤，以提高單個(gè)服務(wù)功能項(xiàng)的質(zhì)量，并減少后期返工的成本。

2.集成測試：檢查各個(gè)服務(wù)組件能否協(xié)同工作，測試整個(gè)系統(tǒng)能否通過成功構(gòu)建達(dá)到預(yù)期的效果。我們應(yīng)當(dāng)在此環(huán)節(jié)發(fā)現(xiàn)系統(tǒng)架構(gòu)與模塊之間、模塊與模塊之間是否存在接口問題，并記錄下測試的結(jié)果。

3.系統(tǒng)測試：關(guān)注的是作為產(chǎn)品的系統(tǒng)是否符合前期規(guī)格說明的要求。我們可以通過運(yùn)行整個(gè)系統(tǒng)，來根據(jù)在驗(yàn)證環(huán)節(jié)中制定的測試用例，執(zhí)行全面測試，驗(yàn)證并確證系統(tǒng)的功能與性能，是否符合需求規(guī)格說明中的要求。

4.回歸測試：在整改了在上述三種測試中所發(fā)現(xiàn)的問題之后，我們需要重新進(jìn)行測試，以確認(rèn)沒有給系統(tǒng)或服務(wù)引入新的錯(cuò)誤或缺陷。自動(dòng)回歸測試將大幅降低系統(tǒng)測試、維護(hù)升級(jí)等階段的成本。有時(shí)候?yàn)榱吮ＷC最終用戶的滿意度，我們甚至需要邀請用戶參與進(jìn)來，共同檢測系統(tǒng)或服務(wù)的平穩(wěn)度和易用性。

在完成并通過了上述功能性測試的相關(guān)步驟之后，我們就可以采取非功能性測試了。可以說，此類測試更注重的是發(fā)現(xiàn)系統(tǒng)或服務(wù)在某種環(huán)境或臨界狀態(tài)下的反應(yīng)狀態(tài)及魯棒性。也就是說，我們在實(shí)際測試中，需要模擬在非常規(guī)或非標(biāo)準(zhǔn)化的內(nèi)、外部場景中，使用待測系統(tǒng)與服務(wù)，并收集相關(guān)的特征參數(shù)。

我們經(jīng)常會(huì)在非功能性測試中引入極限測試。該測試的好處不言而喻。不過值得注意的是，如果我們過于苛求測試的全面性和真實(shí)性的話，則會(huì)在無形中給增加測試前期的準(zhǔn)備，以及開發(fā)的整體成本。因此，我們應(yīng)當(dāng)注意上述基礎(chǔ)要點(diǎn)中提到的要“符合風(fēng)險(xiǎn)偏好”。

顯然，測試的輸出就是要發(fā)現(xiàn)被測服務(wù)與實(shí)際需求之間的差距，以及自身存在的錯(cuò)誤與缺陷。為了有針對(duì)性地進(jìn)行及時(shí)整改，我們可通過如下三步來實(shí)現(xiàn)缺陷管理：

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

當(dāng)然，對(duì)于經(jīng)過測試和后期整改仍無法解決的問題，我們應(yīng)當(dāng)及時(shí)將其納入前文提到的已知錯(cuò)誤知識(shí)庫中，以便盡早告知用戶。

最后，需要注意的是，對(duì)于那些持續(xù)發(fā)展或經(jīng)歷過變更的系統(tǒng)與服務(wù)，我們需要定期進(jìn)行跟進(jìn)驗(yàn)證與測試，以向用戶證明其能夠維持原有服務(wù)級(jí)別水平。

實(shí)務(wù)：

企業(yè)通常會(huì)在新的系統(tǒng)和服務(wù)尚未完工之前，就事先確定好了有哪些標(biāo)準(zhǔn)需要滿足，有哪些功能需要實(shí)現(xiàn)，以及有哪些影響用戶使用體驗(yàn)的重點(diǎn)。在此基礎(chǔ)上羅列出系統(tǒng)和服務(wù)的各種特征，并圈定測試的范圍與深度。

當(dāng)然，這些都屬于服務(wù)驗(yàn)證的基本準(zhǔn)備工作。

如果說服務(wù)驗(yàn)證主要關(guān)注和設(shè)定的是最低要求的話，那么我們在服務(wù)測試環(huán)節(jié)則會(huì)更加全面。為了提高產(chǎn)品的質(zhì)量，確保服務(wù)的有效性，以及系統(tǒng)的穩(wěn)定性，我們設(shè)計(jì)出了如下測試用例的基本類型：

功能性測試用例；

錯(cuò)誤輸入測試用例；

圖1 通用處置流程

邏輯與流程測試用例；

物理與運(yùn)行環(huán)境測試用例；

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

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

圖中的每一個(gè)節(jié)點(diǎn)所對(duì)應(yīng)的解釋如下：

1.新建：這是缺陷被首次提交時(shí)初始狀態(tài)。不過，對(duì)于一些復(fù)雜的問題或缺陷則可能需要測試人員予以進(jìn)一步的確認(rèn)。

2.審核：由主管人員審核該缺陷的真實(shí)性，并判斷是否屬于重復(fù)提交。一旦確認(rèn)，他們則會(huì)分配給相應(yīng)的研發(fā)人員或團(tuán)隊(duì)接手處理，否則直接“關(guān)閉”或進(jìn)入下面的“整改”環(huán)節(jié)。

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

4.整改：研發(fā)人員通過變更管理流程對(duì)缺陷實(shí)施修復(fù)與整改，并在完成后流轉(zhuǎn)給測試人員。

5.測試：測試人員針對(duì)原有缺陷展開新一輪的測試。如果通過，該缺陷的狀態(tài)變更為“已修正并關(guān)閉”；如果未能通過，則重返“分析”環(huán)節(jié)；如果循環(huán)多次仍無法修復(fù)，其狀態(tài)應(yīng)被設(shè)置為“已知錯(cuò)誤”。

當(dāng)然，在整改與測試完成之后，我們應(yīng)當(dāng)及時(shí)且徹底地清理系統(tǒng)中殘留的測試數(shù)據(jù)、各類警告信息，以及歷史日志等，以便系統(tǒng)或產(chǎn)品能夠順利地流轉(zhuǎn)到正式部署或交付環(huán)節(jié)。