聯(lián)調測試方案

1、錯誤！未找到引用源。錯誤！未找到引用源。內部公開委內衛(wèi)生部接口平臺聯(lián)調測試方案中興通訊股份有限公司2011年12月 本文中的所有信息均為委內衛(wèi)生部接口平臺內部資料，未經(jīng)許可，不得向外傳播。第 24 頁 共 25 頁模板版本變更記錄（epg更新模板時填寫）：模板版本號擬制/修改日期擬制/修改人修改記錄批準人1.02011-12-3馮穎垚新增工件版本變更記錄（工件作者或修改者更新工件時填寫）：版本號擬制/修改日期擬制/修改人修改記錄批準人目 錄1編寫目的32術語、定義和縮略語32.1術語、定義32.2縮略語33適用范圍及預期讀者34聯(lián)調測試概述34.1聯(lián)調測試定義34.2聯(lián)調測試范圍44.2.1連

2、通性測試44.2.2功能性測試55聯(lián)調測試流程及操作55.1聯(lián)調測試總體流程55.1.1聯(lián)調測試相關方及角色55.1.2聯(lián)調測試階段劃分65.1.3聯(lián)調測試總體流程圖65.2聯(lián)調測試各階段詳細介紹75.2.1聯(lián)調測試申請階段75.2.2聯(lián)調測試環(huán)境準備階段85.2.3聯(lián)調測試測試設計階段105.2.4聯(lián)調測試應用設置階段125.2.5聯(lián)調測試測試執(zhí)行階段135.2.6聯(lián)調測試測試評估階段156聯(lián)調測試質量保證156.1聯(lián)調測試風險管理156.1.1風險管理流程示意圖156.1.2風險管理流程說明166.1.3風險管理機制及操作指南196.2聯(lián)調測試問題處理196.2.1問題處理流程示意圖196

3、.2.2問題處理流程說明196.3聯(lián)調測試協(xié)調管理206.3.1協(xié)調管理流程示意圖206.3.2相關文檔模板216.4聯(lián)調測試溝通管理216.4.1信息知會規(guī)則216.4.2專家會審規(guī)則226.4.3同行評審規(guī)則226.4.4領導審核規(guī)則227附錄247.1附件241 編寫目的本文檔對委內衛(wèi)生部接口平臺聯(lián)調測試階段的測試流程、操作步驟、測試內容、測試方法及質量保證等內容進行了詳細的闡述。2 術語、定義和縮略語2.1 術語、定義術語/定義說明連通性測試指服務消費方在聯(lián)調測試執(zhí)行前，對所有需要調用服務的基本功能所進行的簡單測試。連通性測試強調服務能否被正常調用，而不進行業(yè)務層面驗證。準入測試指當服

4、務提供方完成接口服務開發(fā)之后，在集成部署到接口平臺之前，由接口平臺組織進行的測試工作。聯(lián)調測試指應用系統(tǒng)為通過接口平臺，實現(xiàn)與其他系統(tǒng)的業(yè)務交互，而需要在上線前進行的各系統(tǒng)間的協(xié)同測試。整體工作由接口平臺主導和組織，由接口平臺、服務消費方項目組、服務提供方項目組共同參與。2.2 縮略語縮略語說明接口平臺委內衛(wèi)生部接口平臺服務消費方消費接口平臺所提供服務的系統(tǒng)服務提供方通過接口平臺對外提供服務的系統(tǒng)服務消費方項目組消費接口平臺所提供服務的系統(tǒng)項目組，由服務消費方集成商人員和關鍵業(yè)務用戶組成服務提供方項目組通過接口平臺對外提供服務的系統(tǒng)項目組，由服務提供方集成商人員和關鍵業(yè)務用戶組成聯(lián)調測試規(guī)范委

5、內衛(wèi)生部接口平臺聯(lián)調測試規(guī)范文檔3 適用范圍及預期讀者本文檔的適用范圍為：委內衛(wèi)生部接口平臺聯(lián)調測試涉及到的各相關系統(tǒng)。本文檔的預期讀者為：委內衛(wèi)生部接口平臺聯(lián)調測試涉及到的各相關方，包括：接口平臺、服務消費方項目組及服務提供方項目組等。4 聯(lián)調測試概述4.1 聯(lián)調測試定義聯(lián)調測試是指應用系統(tǒng)為通過接口平臺，實現(xiàn)與其他系統(tǒng)的業(yè)務交互，而需要在上線前進行的各系統(tǒng)間的協(xié)同測試。測試工作由接口平臺主導、組織和執(zhí)行，由服務消費方項目組、服務提供方項目組共同參與。聯(lián)調測試等同于系統(tǒng)間接口的uat測試，聯(lián)調測試中的服務提供方項目組和服務消費方項目組需包含接口平臺業(yè)務責任人員，業(yè)務責任人員需對整個聯(lián)調測試的

6、業(yè)務功能進行測試和確定。聯(lián)調測試在整個接口平臺服務生命周期中的階段和位置如下圖所示：聯(lián)調測試的發(fā)起應在準入測試階段結束后、系統(tǒng)部署上線開始前。通過聯(lián)調測試，可以最大限度的暴露并解決問題，以確保接口服務上線后能夠正常使用，滿足業(yè)務系統(tǒng)的接口需求，保證各業(yè)務系統(tǒng)能夠通過接口平臺服務實現(xiàn)正常的互聯(lián)互通。4.2 聯(lián)調測試范圍每次聯(lián)調測試的服務列表應在接口平臺規(guī)范所涵蓋的服務列表內，且該批服務已經(jīng)通過接口平臺準入測試。聯(lián)調測試由連通性測試和功能性測試兩部分組成。4.2.1 連通性測試連通性測試是指服務消費方在聯(lián)調測試執(zhí)行前，對所有需要調用服務的基本功能所進行的簡單測試。連通性測試強調服務能否被正常調用，

7、而不進行業(yè)務層面驗證。連通性測試的目的是為了保證在聯(lián)調測試執(zhí)行階段，服務消費方能夠順利連接，能夠正常調用所消費的服務，連通性測試包含網(wǎng)絡連通性測試及服務連通性測試兩部分工作。連通性測試之前應完成以下工作：1、 確保聯(lián)調測試環(huán)境搭建完畢2、 網(wǎng)絡策略開通完畢3、 服務提供方完成應用程序部署4、 接口平臺完成服務部署5、 服務消費方完成應用程序部署連通性的示意圖如下：4.2.2 功能性測試功能性測試是指服務消費方按照已編寫完成的測試用例對接口服務進行測試驗證，盡可能的發(fā)現(xiàn)潛在問題。功能性測試重在全面覆蓋業(yè)務場景。功能性測試是聯(lián)調測試的重點，是接口服務正常使用的保障。功能性測試之前應完成以下工作：1

8、、 完成連通性測試2、 完成測試設計，包括測試用例和測試數(shù)據(jù)的編寫審核5 聯(lián)調測試流程及操作5.1 聯(lián)調測試總體流程5.1.1 聯(lián)調測試相關方及角色聯(lián)調測試參與方包括：接口平臺、服務提供方項目組、服務消費方項目組。上述參與方在聯(lián)調測試各個階段分別作為責任方、執(zhí)行方、配合方承擔如下工作：職責重點工作內容責任方制定相關工作的方法論和質量標準制定工作分工計劃負責相關工作的整體交付執(zhí)行方工作計劃中具體任務的操作者需根據(jù)工作計劃按時和按質完成工作（如環(huán)境準備、測試設計和測試執(zhí)行等）配合方輔助執(zhí)行方，對某項任務提供建議和給予協(xié)助，確保該項任務可以更好和更快的完成接口平臺為聯(lián)調測試的總體組織方，其主要責任如

9、下：1、 負責整個聯(lián)調測試方法論的整理和編寫，為整個聯(lián)調測試提供有效的方法論指導。2、 負責聯(lián)調測試總體流程的制定，統(tǒng)一聯(lián)調測試流程，形成有效的測試流程。3、 負責聯(lián)調測試階段所有相關文檔的統(tǒng)一模板制定，形成聯(lián)調測試的企業(yè)標準。4、 負責制定聯(lián)調測試的質量標準，嚴格控制聯(lián)調測試的質量。5、 負責聯(lián)調測試整體進度的把握。6、 負責聯(lián)調測試整體進度的把控及各方協(xié)調工作。7、 依照測試流程和測試模板，組織完成聯(lián)調測試工作。8、 負責審批聯(lián)調測試申請的初審。9、 負責組織完成測試環(huán)境的準備工作，包括軟硬件準備、網(wǎng)絡策略開通、服務及應用程序部署和連通性測試。10、 組織服務提供方和服務消費方完成測試用例

10、和測試數(shù)據(jù)的準備及評審。11、 負責組織完成具體聯(lián)調測試的執(zhí)行，協(xié)調各方解決測試問題。12、 負責組織完成聯(lián)調測試工作的評估，完成評估報告的評審和會簽工作。服務消費方項目組為聯(lián)調測試工作的具體執(zhí)行方，其主要責任如下：1、 負責提交聯(lián)調測試申請。2、 負責完成服務消費方測試環(huán)境的準備工作。3、 負責完成測試用例的編寫及測試數(shù)據(jù)的準備工作。4、 負責完成聯(lián)調測試的執(zhí)行。5、 負責聯(lián)調測試評估報告的編寫，參與評估報告的評審和會簽工作。服務提供方項目組為聯(lián)調測試工作的執(zhí)行方和配合方，其主要責任如下：1、 負責完成服務提供方測試環(huán)境的準備工作2、 配合完成測試用例的編寫及測試數(shù)據(jù)的準備。3、 配合分析、

11、解決測試執(zhí)行過程中的問題。4、 參與評估報告的評審和會簽工作。5.1.2 聯(lián)調測試階段劃分本次聯(lián)調測試過程主要分解為6個過程，如下表：階段含義測試申請服務消費方完成前期準備工作之后，通過管控平臺提交聯(lián)調測試申請，測試申請由接口平臺審批環(huán)境準備確定測試環(huán)境的軟硬件現(xiàn)狀，搭建測試環(huán)境，部署應用程序和服務，進行連通性測試測試設計由接口平臺組織服務消費方項目組及服務提供方項目組，按照下發(fā)的統(tǒng)一模板共同完成測試用例的設計以及測試數(shù)據(jù)的準備應用設置服務提供方、服務消費方進行測試前的應用設置工作測試執(zhí)行服務消費方執(zhí)行測試、驗證系統(tǒng)功能以及反饋測試結果，期間包含了聯(lián)調測試問題跟蹤、進度跟蹤和風險跟蹤等工作測試

12、評估接口平臺組織服務消費方項目組評估測試執(zhí)行結果，5.1.3 聯(lián)調測試總體流程圖聯(lián)調測試的總體流程圖如下：5.2 聯(lián)調測試各階段詳細介紹5.2.1 聯(lián)調測試申請階段聯(lián)調測試申請階段主要包含如下三項主要工作：1、 服務消費方項目組提交聯(lián)調測試申請2、 接口平臺審核聯(lián)調測試申請測試申請流程如下：5.2.1.1 提交聯(lián)調測試申請服務消費方項目組確定本次聯(lián)調測試的服務清單和聯(lián)調測試計劃，并按要求填寫聯(lián)調測試申請文檔附件1-委內衛(wèi)生部接口平臺系統(tǒng)聯(lián)調測試申請表及聯(lián)調測試參加人員表附件2-委內衛(wèi)生部接口平臺聯(lián)調測試人員信息，提交至接口平臺進行審批。服務測試計劃要按照業(yè)務場景的銜接關系，區(qū)分不同的服務和消費

13、方，確定每一服務的測試執(zhí)行起始時間，盡量具體、細化。測試計劃中要預留合理的問題解決時間。聯(lián)調測試人員表需包含參加聯(lián)調測試的服務消費方和服務提供方人員。5.2.1.2 接口平臺審核申請接口平臺對申請表進行審批后，進入測試環(huán)境準備階段，若審批過程中發(fā)現(xiàn)問題，則退回上一環(huán)節(jié)進行重新處理。5.2.2 聯(lián)調測試環(huán)境準備階段環(huán)境準備需要做的工作主要有：1、 硬件環(huán)境準備2、 軟件環(huán)境準備3、 網(wǎng)絡策略開通4、 服務及應用程序部署5、 連通性測試該階段的具體明細流程如下：說明：1、 上圖中描述的環(huán)境準備包含了硬件準備、軟件準備、網(wǎng)絡策略開通、服務和應用程序部署以及連通性測試等操作。2、 由接口平臺統(tǒng)一組織搜

14、集服務提供方、服務消費方和接口平臺的測試環(huán)境資料，并統(tǒng)計現(xiàn)狀，產出文檔附件3-委內衛(wèi)生部接口平臺系統(tǒng)聯(lián)調測試環(huán)境。5.2.2.1 硬件環(huán)境準備硬件環(huán)境準備主要指服務提供方、服務消費方以及接口平臺三方各自進行的測試環(huán)境硬件準備工作，包括主機、存儲等。5.2.2.2 軟件環(huán)境準備軟件環(huán)境準備主要指服務提供方、服務消費方以及接口平臺三方各自進行的軟件環(huán)境的準備工作，包括操作系統(tǒng)、應用軟件、數(shù)據(jù)庫等。5.2.2.3 網(wǎng)絡開通網(wǎng)絡開通包括各系統(tǒng)訪問接口平臺，和接口平臺訪問各系統(tǒng)，需要開通雙向開通。5.2.2.4 服務及應用程序部署服務及應用程序部署是指服務消費方、服務提供方、接口平臺將各自的服務或應用程

15、序部署到各自聯(lián)調測試環(huán)境中。5.2.2.5 連通性測試連通性測試是指服務消費方在聯(lián)調測試執(zhí)行前，對所有需要調用服務的基本功能所進行的簡單測試。連通性測試強調服務能否被正常調用，而不進行業(yè)務層面驗證。連通性測試包括網(wǎng)絡連通性測試及服務連通性測試兩部分，操作步驟如下：1、 網(wǎng)絡連通性測試：1) 接口平臺完成與服務提供方的網(wǎng)絡連通測試。2) 服務消費方完成與接口平臺的網(wǎng)絡連通測試。2、 服務連通性測試1) 由接口平臺完成連通性測試用例設計。2) 由接口平臺依測試用例完成接口平臺到服務提供方的連通性測試。3) 接口平臺將自身到服務提供方的連通性測試報告提供給服務消費方。4) 服務消費方參考測試報告，完

16、成與接口平臺的連通性測試。連通性測試由接口平臺組織協(xié)調，服務提供方、服務消費方和接口平臺共同進行，測試結果記錄在附件4-委內衛(wèi)生部接口平臺系統(tǒng)聯(lián)調連通性測試結果中。5.2.3 聯(lián)調測試測試設計階段聯(lián)調測試設計階段主要工作為測試用例設計和測試數(shù)據(jù)準備。服務消費方項目組根據(jù)本規(guī)范中定義的測試設計策略進行測試用例的設計，由服務消費方項目組和服務提供方項目組共同準備測試業(yè)務數(shù)據(jù)。該階段的具體明細流程如下：5.2.3.1 測試設計策略5.2.3.1.1 設計步驟描述為實現(xiàn)接口平臺的聯(lián)調測試方法，聯(lián)調測試設計分3個步驟進行，每1步驟的重點各不一樣，如下表：步驟設計內容執(zhí)行方表現(xiàn)形式1編寫測試用例服務消費方

17、項目組業(yè)務操作流程、業(yè)務數(shù)據(jù)2測試數(shù)據(jù)整理及確認服務消費方項目組、服務提供方項目組、接口平臺測試數(shù)據(jù)3組織評審測試設計內容服務消費方項目組、服務提供方項目組、接口平臺評審會議5.2.3.1.2 設計策略描述服務消費方項目組根據(jù)需要聯(lián)調的內容進行相關的業(yè)務測試用例設計，明確業(yè)務功能測試的操作步驟及其產生的業(yè)務數(shù)據(jù)，并提供預期的業(yè)務數(shù)據(jù)、信息或結果；說明：服務消費方項目組業(yè)務數(shù)據(jù)的制作需要一定的周期，因此在進行業(yè)務測試設計時，需要同時準備業(yè)務測試數(shù)據(jù)并在評審測試用例時進行評審。5.2.3.2 測試設計測試設計分為三個步驟：1、 測試用例設計：測試用例編寫應按照以下三原則：a) 用例的編寫應該覆蓋實

18、際用到的所有業(yè)務場景b) 用例的編寫應該覆蓋實際用到的所有接口服務c) 用例的編寫應該針對查詢類和導入類的特點編寫用例，在進行測試用例設計時應注意業(yè)務流程前后環(huán)節(jié)的銜接，同時用例中應包含正例和反例。正例建議使用實際業(yè)務數(shù)據(jù)，反例在用例設計時要標識出違反業(yè)務規(guī)則或者接口規(guī)范規(guī)則設計點。產出文檔附件5-委內衛(wèi)生部接口平臺系統(tǒng)聯(lián)調測試用例。在測試用例準備的時候，服務提供方項目組要給予協(xié)助。2、 測試數(shù)據(jù)設計：服務消費方項目組根據(jù)測試用例里面的測試場景，結合自身系統(tǒng)的情況和服務提供方的情況，準備測試用例的測試數(shù)據(jù)，產出文檔附件6-委內衛(wèi)生部接口平臺系統(tǒng)聯(lián)調測試數(shù)據(jù)準備。測試數(shù)據(jù)準備的時候，服務提供方項

19、目組要給予測試數(shù)據(jù)確認，以保證測試數(shù)據(jù)正確，能夠滿足測試用例需要。3、 測試用例評審：由接口平臺組織，服務消費方項目組、服務提供方項目組參加，進行聯(lián)調測試用例和聯(lián)調測試數(shù)據(jù)所有內容的評審，評審通過之后提交接口平臺審批。5.2.4 聯(lián)調測試應用設置階段聯(lián)調測試的應用設置階段主要是指參與聯(lián)調測試的各系統(tǒng)在評審通過的測試用例和測試數(shù)據(jù)基礎之上，配合聯(lián)調測試進行的應用設置工作，包括了系統(tǒng)設置、基礎數(shù)據(jù)準備、設置權限等一系列操作，目的都是為了保證聯(lián)調測試能夠順利進行。該階段的具體明細流程如下：說明：當服務消費方項目組、服務提供方項目組和接口平臺完成各自應用設置之后，接口平臺需要匯總并產出文檔附件7-委內

20、衛(wèi)生部接口平臺系統(tǒng)聯(lián)調測試應用設置結果收集。5.2.5 聯(lián)調測試測試執(zhí)行階段5.2.5.1 聯(lián)調測試方法所有的服務分為寫入和查詢兩類，這兩種服務分別采用不同的測試方法，如下分別予以舉例說明。5.2.5.1.1 寫入類服務測試方法對服務提供方提供的寫入類的服務進行測試，測試方法詳細說明如下：假定寫入服務名稱為“數(shù)據(jù)寫入服務”、如果有寫入驗證服務，則驗證寫入服務名稱為“數(shù)據(jù)寫入驗證服務”，如果沒有則忽略此假定。以下內容將詳細說明寫入服務相關過程：1) 確定“服務消費方”，并確定“數(shù)據(jù)寫入服務”所需要提供的數(shù)據(jù)；2) “服務消費方”操作人員進行業(yè)務操作，生成需要進行寫入的“業(yè)務數(shù)據(jù)”；3) “服務消

21、費方”調用“數(shù)據(jù)寫入服務”進行寫入操作；4) 接口平臺接收到寫入請求，并將請求轉發(fā)到“服務提供方”，由“服務提供方”接受來自接口平臺的請求，啟動“數(shù)據(jù)寫入服務”；5) “服務提供方”將對接收的數(shù)據(jù)進行業(yè)務邏輯處理，驗證數(shù)據(jù)為合法數(shù)據(jù)后將數(shù)據(jù)正確的寫入目標數(shù)據(jù)庫數(shù)據(jù)表中；6) 返回寫入后信息予接口平臺；7) 接口平臺服務返回寫入處理信息給“服務消費方”；至此，寫入服務的無異常調用已經(jīng)完成（異常情況此處不詳細描述，如出現(xiàn)業(yè)務邏輯校驗不通過或者其他異常，“服務提供方”都應將相應信息返回供“服務消費方”參閱）。下面描述驗證過程，驗證的過程分為兩類，一類為提供了數(shù)據(jù)寫入驗證服務，另一類為不提供數(shù)據(jù)寫入驗

22、證服務。第一類的驗證方法為：1） “服務消費方系統(tǒng)”調用“數(shù)據(jù)寫入驗證服務”，并傳入“驗證數(shù)據(jù)”。2） “數(shù)據(jù)寫入驗證服務”依據(jù)“驗證數(shù)據(jù)”來“驗證結果信息”；3） “數(shù)據(jù)寫入驗證服務”將“驗證結果信息”返回給“服務消費方系統(tǒng)”，供服務消費方判定數(shù)據(jù)寫入操作是否正常完成。第二類的驗證方法為：1） 服務消費方測試人員登錄服務提供方的數(shù)據(jù)庫系統(tǒng)，進入目標數(shù)據(jù)庫數(shù)據(jù)表或者能夠進行結果比對的界面。2） 進行寫入數(shù)據(jù)的對比以及校驗。5.2.5.1.2 寫入類服務通過準則1) 服務消費方系統(tǒng)產生的“業(yè)務數(shù)據(jù)”和接口平臺中輸入顯示的“業(yè)務數(shù)據(jù)”一致；2) 服務提供方數(shù)據(jù)表中保存的“業(yè)務數(shù)據(jù)”與測試用例的“數(shù)

23、據(jù)表預期數(shù)據(jù)”一致；3) 接口平臺的“寫入后返回信息”與服務消費方平臺的“寫入后返回信息”一致；4) 服務消費方傳遞給接口平臺“業(yè)務數(shù)據(jù)”與服務提供方接收業(yè)務數(shù)據(jù)的“數(shù)據(jù)表數(shù)據(jù)”一致5.2.5.1.3 查詢類服務測試方法對查詢類的服務進行測試，采用方法如下：假定該服務名稱為“數(shù)據(jù)查詢服務”，如下說明查詢服務相關的所有過程：1) 確認連通性測試已經(jīng)完成；2) 確定聯(lián)調系統(tǒng)（“服務消費方系統(tǒng)”和“服務提供方系統(tǒng)”）；3) 在“服務消費方系統(tǒng)”進行查詢操作；4) 接口平臺收到查詢請求，啟動“數(shù)據(jù)查詢服務”；5) “服務提供方系統(tǒng)”收到“數(shù)據(jù)查詢服務”請求，進行對應的查詢操作，并將查詢結果返回給接口平

24、臺；6) 接口平臺查詢結果返回給“服務消費方系統(tǒng)”。5.2.5.1.4 查詢類服務通過準則1) 服務消費方系統(tǒng)輸入的“查詢條件”和服務提供方系統(tǒng)中輸入顯示的“查詢條件”一致；2) 服務提供方的“查詢結果數(shù)據(jù)”與服務消費方平臺的“寫入后返回信息”一致；3) 服務消費方通過測試用例中驗證方法得到的“查詢預期數(shù)據(jù)”與服務提供方通過服務返回的“查詢結果數(shù)據(jù)”一致。5.2.5.2 聯(lián)調測試執(zhí)行策略根據(jù)聯(lián)調測試規(guī)范和聯(lián)調測試設計策略，相應的，聯(lián)調測試執(zhí)行也需要分步執(zhí)行，操作步驟詳細描述如下：1）服務消費方 “數(shù)據(jù)輸入”：服務消費方項目組測試人員在相關系統(tǒng)中執(zhí)行聯(lián)調測試用例中業(yè)務測試用例的“功能操作”、“數(shù)

25、據(jù)輸入”部分；如果不正確，則需要提交bug。如果正確，進行后續(xù)執(zhí)行和驗證；2）服務消費方 “預期輸出”驗證：服務消費方項目組測試人員在相關系統(tǒng)中執(zhí)行完上述操作后，對返回的信息進行查驗和記錄（在服務消費方系統(tǒng)功能驗證的實際輸出中），并根據(jù)聯(lián)調測試用例中業(yè)務測試用例的“預期輸出”判斷該輸出是否正確：如果不正確，則需要提交bug；如果正確，測試用例執(zhí)行通過。針對不同類型的服務，如下分別說明其操作的順序：1) 如果是寫入類的測試，則按照如下順序進行操作：操作順序步驟名稱1服務消費方 “數(shù)據(jù)輸入”2導入服務的服務消費方“預期輸出”驗證3導入驗證服務的服務消費方“數(shù)據(jù)輸入”4導入驗證服務的服務消費方“預期

26、輸出”驗證2) 如果是查詢類的測試，則按照如下順序進行操作：操作順序步驟名稱1服務消費方“數(shù)據(jù)輸入”2服務消費方“預期輸出”驗證。5.2.5.3 聯(lián)調測試進度跟蹤及執(zhí)行記錄聯(lián)調測試執(zhí)行階段，接口平臺需匯總當天的聯(lián)調測試執(zhí)行情況，填寫附件8-委內衛(wèi)生部接口平臺聯(lián)調測試進度跟蹤表。服務消費方項目組需提交附件9-委內衛(wèi)生部接口平臺系統(tǒng)聯(lián)調測試執(zhí)行記錄，接口平臺將對全部服務消費方系統(tǒng)情況進行匯總形成附件10-委內衛(wèi)生部接口平臺測試進度匯總表。其中，1) 工作表“聯(lián)調測試執(zhí)行記錄”中的聯(lián)調測試用例的內容是從聯(lián)調測試用例繼承而來，根據(jù)服務消費方所需聯(lián)調測試內容進行聯(lián)調測試用例內容的選擇和組合，每個服務消費

27、方系統(tǒng)提交1份各自的聯(lián)調測試執(zhí)行記錄文檔；2) 測試結論a) 通過：所有操作步驟驗證都正確，才能填寫通過；以下的狀態(tài)，如果前者填寫了，后續(xù)的驗證失敗或成功都不需要填寫：b) 服務消費方系統(tǒng)驗證失敗：服務提供方與服務消費方系統(tǒng)之間的接口錯誤。說明：只要測試結果不為“通過”的狀態(tài)，就須填寫“bug id”。5.2.6 聯(lián)調測試測試評估階段當聯(lián)調測試進度和完成情況顯示所有問題得到解決，接口平臺組織進行評估會議；服務消費方項目組提供聯(lián)調測試評估報告，接口平臺負責組織各方（接口平臺、服務消費方項目組、服務提供方項目）對該報告進行評審，評審通過后，接口平臺組織三方簽字確認。聯(lián)調測試的評估報告使用如下模板：

28、附件11-委內衛(wèi)生部接口平臺系統(tǒng)聯(lián)調測試評估報告該工件由服務消費方項目組提供，并由接口平臺負責維護，評估確認結果同時認作是uat測試確認。6 聯(lián)調測試質量保證6.1 聯(lián)調測試風險管理聯(lián)調測試涉及很多的服務提供方系統(tǒng)、服務消費方、接口平臺，風險可能大、帶來的影響大，有必要進行聯(lián)調測試風險的管理。6.1.1 風險管理流程示意圖6.1.2 風險管理流程說明風險管理主要分為2部分，如下：6.1.2.1 風險庫管理6.1.2.1.1 風險定義風險：導致事件向不利的方向發(fā)生的可能現(xiàn)象或事件。根據(jù)風險的基本定義，對聯(lián)調測試過程中的風險主要包括如下內容（風險源）：1) 聯(lián)調測試過程本身的風險：過程定義和策略存

29、在的風險；2) 聯(lián)調測試過程人員的風險：過程執(zhí)行人員在技能、穩(wěn)定性上存在的風險；3) 聯(lián)調測試環(huán)境的風險：聯(lián)調測試環(huán)境的穩(wěn)定性、兼容性風險；4) 聯(lián)調測試技術的風險：聯(lián)調測試所需要的技術性風險；5) 聯(lián)調測試管理的風險：聯(lián)調測試管理的充分性、可控性風險；6) 聯(lián)調測試進度的風險：聯(lián)調測試進度安排和執(zhí)行的有效性風險。6.1.2.1.2 風險分類根據(jù)聯(lián)調測試的風險內涵，基本上可以將風險分為如下幾類：1) 過程類2) 技術類3) 人力資源類4) 環(huán)境類5) 管理類6) 進度類7) 其他類風險的分類，可以更加有利于風險的管理，提高聯(lián)調測試各方在風險預防和應對上的處理能力。6.1.2.1.3 設定風險管

30、理角色根據(jù)風險的管理過程，主要設定以下幾種角色：1) 風險提交人：風險識別、風險入庫；2) 風險責任人：實施和審核風險庫和風險管理的整個過程；3) 風險處理人：風險預防、風險應對；4) 風險專家：風險分析、風險跟蹤；5) 風險庫管理員：建立風險庫、更新風險庫。6.1.2.1.4 建立風險庫需要確定內容1： 風險庫存放物理地址和管理工具。在設定了風險的各個要素后，確定一個物理地址和管理工具，對風險的內容進行管理和維護。風險具有如下基礎屬性：風險源、項目名稱、公司名稱、風險類別、風險概率、風險級別、風險后果、風險狀態(tài)。1) 風險概率：0.11.02) 風險級別：0.11.03) 風險后果：0.01

31、1.004) 風險狀態(tài)：風險提交、風險預防、風險應對、風險總結、風險預防關閉、風險應對關閉、風險轉問題、風險關閉。6.1.2.1.5 更新風險庫1) 在風險處理階段，由各風險處理人在風險庫中處理情況；2) 在風險處理完成后，有風險管理員維護風險的最終處理結果，并關閉或轉化風險。6.1.2.2 風險管理6.1.2.2.1 風險識別活動說明：在聯(lián)調測試各階段，任何人（主要是風險專家）都可對預期可能存在的、帶來不利影響的現(xiàn)象或事件進行識別和提交，包括通過正式或非正式的會議、郵件、風險關聯(lián)影響分析、問題關聯(lián)影響分析等各種風險識別方法。其中，奉獻提交人所在的項目負責人自動成為該風險的風險責任人。活動結束

32、時風險狀態(tài)：無。風險識別時的屬性：風險內容（源）、風險提交人、風險識別日期、風險責任人。6.1.2.2.2 風險入庫活動說明：一旦風險被識別，則由風險管理員開通相關權限和帳號，將風險入庫；風險提交人和風險責任人都可以在風險庫中查詢，以查看是否存在類似的風險解決經(jīng)驗或方案。 活動結束時風險狀態(tài)：風險提交。風險入庫時的屬性：風險編號、風險入庫日期、風險管理員、風險關鍵字。6.1.2.2.3 風險分析1) 活動說明：風險在入庫后，風險責任人及時邀請風險專家對沒有解決經(jīng)驗和方案的風險進行風險分析，確定風險應對和預防措施?；顒咏Y束時風險狀態(tài)：風險預防。2) 活動說明：經(jīng)過分析，該風險需要進行協(xié)調處理，則

33、走協(xié)調流程?；顒咏Y束時風險狀態(tài)：風險轉協(xié)調。風險分析時的屬性：風險分析日期、參與風險專家、風險描述（詳細內容）、風險概率、風險級別、風險后果、風險預防措施、風險預防閥值、風險應對措施、風險應對閥值、風險責任人（可以在此時修改該角色）、風險處理人、風險協(xié)調人。6.1.2.2.4 風險預防活動說明：風險在分析后處于風險預防階段，由風險處理人對風險實施預防措施；同時風險責任人則需要跟蹤風險預防的情況。1) 如果預防成功，風險沒有繼續(xù)朝著不利的方向發(fā)展，則在風險預防閥值后則提交風險預防報告；活動結束時風險狀態(tài)：風險總結。2) 如果預防超過閥值，風險不可避免發(fā)生，則需要實施風險應對措施。活動結束時風險狀

34、態(tài)：風險應對。風險預防時的屬性：風險預防日期、風險預防效果、風險預防報告。6.1.2.2.5 風險應對活動說明：風險在預防失敗后處于風險應對階段，由風險處理人對風險實施應對措施；同時風險責任人也需要跟蹤風險應對的情況。1) 如果應對成功，風險沒有繼續(xù)朝著不利的方向發(fā)展，則在風險應對閥值后則提交風險應對報告；活動結束時風險狀態(tài)：風險總結。2) 如果應對超過閥值，則需要進行風險轉化，即轉化為問題，走問題處理流程?；顒咏Y束時風險狀態(tài)：風險轉問題。風險應對時的屬性：風險應對日期、風險應對效果、風險應對報告。6.1.2.2.6 風險跟蹤和總結1) 活動說明：在風險分析后，風險責任人對風險的預防和應對過程

35、進行風險跟蹤，監(jiān)控風險的變化情況，在風險應對或預防結束后進行風險總結?；顒咏Y束時風險狀態(tài)：無。2) 活動說明：風險預防成功，風險責任人及時對風險管理的整個過程進行總結，提交到風險庫中?；顒咏Y束時風險狀態(tài)：風險預防關閉。3) 風險應對成功，風險責任人及時對風險管理的整個過程進行總結，提交到風險庫中?；顒咏Y束時風險狀態(tài)：風險應對關閉。4) 在超過風險應對閥值后，風險責任人及時對風險管理的整個過程進行總結，提交到風險庫中。活動結束時風險狀態(tài)：風險轉問題。5) 當問題解決后，風險管理人將風險的最終狀態(tài)置為風險關閉?；顒咏Y束時風險狀態(tài)：風險關閉。風險總結時的屬性：風險關閉日期。6.1.3 風險管理機制及

36、操作指南為了能夠最大限度的降低聯(lián)調測試的風險以及減少風險轉化為問題的可能，需要建立聯(lián)調測試階段的風險管理機制。接口平臺聯(lián)調階段的風險管理機制是在標準的cmmi管理基礎之上演變而來，總的來說，主要強調兩個方面的工作和機制：1、 接口平臺要定期對聯(lián)調測試階段的風險進行收集、分析以及回顧。風險的收集是定期的，一周一次會議討論，在會上對風險進行收集、分析。新增的風險需要維護到附件12-委內衛(wèi)生部接口平臺聯(lián)調測試風險跟蹤表中以便后續(xù)跟進。2、 風險需要及時跟進以避免轉化為問題而帶來不利影響，從而影響聯(lián)調測試，因此需要定期跟進風險處理進度，該工作由接口平臺負責組織。接口平臺每周會議對未關閉的風險進行跟進，

37、并及時維護更新附件12-委內衛(wèi)生部接口平臺聯(lián)調測試風險跟蹤表。6.2 聯(lián)調測試問題處理聯(lián)調測試過程中會產生各種各樣的問題，問題的產生可能會來自多個方面（服務程序bug、環(huán)境不一致導致的問題、系統(tǒng)設置不正確導致問題、數(shù)據(jù)準備錯誤導致的問題、服務使用不當導致的問題等等），需要對問題進行系統(tǒng)的管理。6.2.1 問題處理流程示意圖6.2.2 問題處理流程說明接口平臺的問題管理可以處理各階段發(fā)現(xiàn)的問題（準入測試階段、聯(lián)調測試階段、上線階段、運維階段），各階段的問題處理流程是一致的，本文檔重點集中在聯(lián)調測試階段的問題處理上。在聯(lián)調測試各階段，任何人（主要是服務消費方）都可進行問題識別和提交，包括通過接口平

38、臺管控平臺，正式或非正式的會議、郵件、風險關聯(lián)影響分析、問題關聯(lián)影響分析等各種問題識別方法。接口平臺接收到問題單之后，負責根據(jù)問題單描述的情況對問題進行初步分析，必要的時候需要和相應的服務提供方一起進行分析，確認問題初步責任方之后，將問題單轉交給對應的單位進行處理問題。負責處理問題的單位可以選擇處理問題，也可以拒絕，將問題單重新轉交給接口平臺以便重新指派。問題處理完畢之后，由處理問題的相關方將問題單提交給服務消費方進行問題驗證，待驗證通過之后，關閉該問題單。問題單關閉之后，接口平臺負責將問題納入接口平臺的問題庫當中以便今后使用。6.3 聯(lián)調測試協(xié)調管理6.3.1 協(xié)調管理流程示意圖6.3.1.

39、1 協(xié)調請求聯(lián)調測試過程中，當事人在處理任務、風險、問題，需要獲得服務提供方、服務消費方、接口平臺等的技術、業(yè)務、環(huán)境等各方的支持和協(xié)助時，識別這些協(xié)調的內容，及時提交協(xié)調申請。1) 協(xié)調單的屬性包括：協(xié)調序號、處理狀態(tài)、協(xié)調內容描述、協(xié)調類型、緊急程度、重要級別、申請人、申請日期、所在接口人、接口平臺接口人、受方接口人、處理人、預定解決日期、處理完成日期、處理結果描述、申請人確認、協(xié)調效率。2) 協(xié)調類型主要分為以下幾種類型：技術，人力，環(huán)境，進度，風險，質量，規(guī)章制度，生活習慣，語言行為。3) 協(xié)調狀態(tài)主要包括以下幾種狀態(tài)：協(xié)調申請，接口人審批，接口平臺審批，接口平臺駁回，受方接收，受方處

40、理，協(xié)調完成，協(xié)調失敗。需要確定內容2： 協(xié)調請求存在物理地址和管理工具。6.3.1.2 審核轉發(fā)協(xié)調請求協(xié)調申請所在接口人經(jīng)內部處理、或私下處理該協(xié)調無效后，轉發(fā)該協(xié)調內容至對應接口平臺接口人。6.3.1.3 審批協(xié)調請求接口平臺接口人對協(xié)調請求的內容進行審核，確認是需要他方處理，則予以通過，提交總部接口人審核；否則予以駁回；接口平臺接口人對協(xié)調請求的內容進行審核，確認是需要他方處理，則予以通過并統(tǒng)一協(xié)調；否則予以駁回；協(xié)調請求通過后，接口平臺召集協(xié)調請求方和可能處理方，予以統(tǒng)一協(xié)調。6.3.1.4 接受和處理協(xié)調請求協(xié)調處理方接受協(xié)調請求，并限定協(xié)調時限進行協(xié)調內容的處理；在協(xié)調時限達到后，如果沒有完成，則申請協(xié)調失敗，要求總部再次協(xié)調，重新定義協(xié)調時限。6.3.2 相關文檔模板聯(lián)調測試的相關人員信息使用如下模板：附件2-委內衛(wèi)生部接口平臺聯(lián)調測試人員信息該工件由接口平臺維護。