1、委內衛生部接口平臺聯調測試方案中興通訊股份有限公司2011年12月模板版本變更記錄（EPG更新模板時填寫）模板版本號擬制/修改日期擬制/修改人修改記錄批準人2011-12-3馮穎在新增工件版本變更記錄（工件作者或修改者更新工件時填寫）：版本號擬制/修改日期擬制/修改人修改記錄批準人1 編寫目的2 術語、定義和縮略語術語、定義縮略語3 適用范圍及預期讀者4 聯調測試概述聯調測試定義聯調測試范圍連通性測試功能性測試5 聯調測試流程及操作聯調測試總體流程聯調測試相關方及角色聯調測試階段劃分聯調測試總體流程圖聯調測試各階段詳細介紹聯調測試申請階段聯調測試環境準備階段聯調測試測試設計階段聯調測試應用設置

2、階段聯調測試測試執行階段聯調測試測試評估階段6 聯調測試質量保證聯調測試風險管理風險管理流程示意圖風險管理流程說明風險管理機制及操作指南聯調測試問題處理問題處理流程示意圖問題處理流程說明聯調測試協調管理協調管理流程示意圖相關文檔模板聯調測試溝通管理信息知會規則專家會審規則同行評審規則領導審核規則7 附錄附件1 編寫目的本文檔對委內衛生部接口平臺聯調測試階段的測試流程、操作步驟、測試內容、測試方法及質量保證等內容進行了詳細的闡述。2 術語、定義和縮略語2.1 術語、定義術語/定義說明連通性測試指服務消費方在聯調測試執行前，對所有需要調用服務的基本功能所進行的簡單測試。連通性測試強調服務能否被正常

3、調用，而不進行業務層面驗證。準入測試指當服務提供方完成接口服務開發之后，在集成部署到接口平臺之前，由接口平臺組織進行的測試工作。聯調測試指應用系統為通過接口平臺，實現與其他系統的業務交互，而需要在上線前進行的各系統間的協同測試。整體工作由接口平臺主導和組織，由接口平臺、服務消費方項目組、服務提供方項目組共同參與。2.2縮略語縮略語說明接口平臺委內衛生部接口平臺服務消費方消費接口平臺所提供服務的系統服務提供方通過接口平臺對外提供服務的系統服務消費方項目組消費接口平臺所提供服務的系統項目組，由服務消費方集成商人員和關鍵業務用戶組成服務提供方項目組通過接口平臺對外提供服務的系統項目組，由服務提供方集

4、成商人員和關鍵業務用戶組成聯調測試規范委內衛生部接口平臺聯調測試規范文檔3 適用范圍及預期讀者本文檔的適用范圍為：委內衛生部接口平臺聯調測試涉及到的各相關系統。本文檔的預期讀者為：委內衛生部接口平臺聯調測試涉及到的各相關方，包括：接口平臺、服務消費方項目組及服務提供方項目組等。4 聯調測試概述4.1 聯調測試定義聯調測試是指應用系統為通過接口平臺，實現與其他系統的業務交互，而需要在上線前進行的各系統間的協同測試。測試工作由接口平臺主導、組織和執行，由服務消費方項目組、服務提供方項目組共同參與。聯調測試等同于系統間接口的UAT測試，聯調測試中的服務提供方項目組和服務消費方項目組需包含接口平臺業務

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

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

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

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

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

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

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

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

13、務消費方和接口平臺的測試環境資料，并統計現狀，產出文檔附件3-委內衛生部接口平臺XX系統聯調測試環境。5.2.2.1 硬件環境準備硬件環境準備主要指服務提供方、服務消費方以及接口平臺三方各自進行的測試環境硬件準備工作，包括主機、存儲等。5.2.2.2 軟件環境準備軟件環境準備主要指服務提供方、服務消費方以及接口平臺三方各自進行的軟件環境的準備工作，包括操作系統、應用軟件、數據庫等。5.2.2.3 網絡開通網絡開通包括各系統訪問接口平臺，和接口平臺訪問各系統，需要開通雙向開通。5.2.2.4 服務及應用程序部署服務及應用程序部署是指服務消費方、服務提供方、接口平臺將各自的服務或應用程序部署到各自

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

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

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

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

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

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

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

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

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

23、詢結果返回給“服務消費方系統”。1.1.1.1.4 查詢類服務通過準則1) 服務消費方系統輸入的“查詢條件”和服務提供方系統中輸入顯示的“查詢條件”一致；2) 服務提供方的“查詢結果數據”與服務消費方平臺的“寫入后返回信息”一致；3) 服務消費方通過測試用例中驗證方法得到的“查詢預期數據”與服務提供方通過服務返回的“查詢結果數據”一致。5.2.5.2 聯調測試執行策略根據聯調測試規范和聯調測試設計策略，相應的，聯調測試執行也需要分步執行，操作步驟詳細描述如下：1)服務消費方“數據輸入”：服務消費方項目組測試人員在相關系統中執行聯調測試用例中業務測試用例的“功能操作”、“數據輸入”部分；如果不正

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

25、測試，則按照如下順序進行操作:操作順序步驟名稱1服務消費方“數據輸入”2服務消費方“預期輸出”驗證。5.2.5.3 聯調測試進度跟蹤及執行記錄聯調測試執行階段，接口平臺需匯總當天的聯調測試執行情況，填寫附件8-委內衛生部接口平臺聯調測試進度跟蹤表。服務消費方項目組需提交附件9-委內衛生部接口平臺XX系統聯調測試執行記錄，接口平臺將對全部服務消費方系統情況進行匯總形成附件10-委內衛生部接口平臺測試進度匯總表。其中，1）工作表“聯調測試執行記錄”中的聯調測試用例的內容是從聯調測試用例繼承而來，根據服務消費方所需聯調測試內容進行聯調測試用例內容的選擇和組合，每個服務消費方系統提交1份各自的聯調測試

26、執行記錄文檔；2) 測試結論a) 通過：所有操作步驟驗證都正確，才能填寫通過；以下的狀態，如果前者填寫了，后續的驗證失敗或成功都不需要填寫：b) 服務消費方系統驗證失敗：服務提供方與服務消費方系統之間的接口錯誤。說明：只要測試結果不為“通過”的狀態，就須填寫“bugID”。5.2.6聯調測試測試評估階段當聯調測試進度和完成情況顯示所有問題得到解決，接口平臺組織進行評估會議；服務消費方項目組提供聯調測試評估報告，接口平臺負責組織各方(接口平臺、服務消費方項目組、服務提供方項目)對該報告進行評審，評審通過后，接口平臺組織三方簽字確認。聯調測試的評估報告使用如下模板：附件11-委內衛生部接口平臺XX

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

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

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

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

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

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

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

34、動結束時風險狀態：無。2) 活動說明：風險預防成功，風險責任人及時對風險管理的整個過程進行總結，提交到風險庫中。活動結束時風險狀態：風險預防關閉。3) 風險應對成功，風險責任人及時對風險管理的整個過程進行總結，提交到風險庫中。活動結束時風險狀態：風險應對關閉。4) 在超過風險應對閥值后，風險責任人及時對風險管理的整個過程進行總結，提交到風險庫中。活動結束時風險狀態：風險轉問題。5) 當問題解決后，風險管理人將風險的最終狀態置為風險關閉。活動結束時風險狀態：風險關閉。風險總結時的屬性：風險關閉日期。6.1.3 風險管理機制及操作指南為了能夠最大限度的降低聯調測試的風險以及減少風險轉化為問題的可能

35、，需要建立聯調測試階段的風險管理機制。接口平臺聯調階段的風險管理機制是在標準的CMMI管理基礎之上演變而來，總的來說，主要強調兩個方面的工作和機制：1、 接口平臺要定期對聯調測試階段的風險進行收集、分析以及回顧。風險的收集是定期的，一周一次會議討論，在會上對風險進行收集、分析。新增的風險需要維護到附件12-委內衛生部接口平臺聯調測試風險跟蹤表中以便后續跟進。2、 風險需要及時跟進以避免轉化為問題而帶來不利影響，從而影響聯調測試，因此需要定期跟進風險處理進度，該工作由接口平臺負責組織。接口平臺每周會議對未關閉的風險進行跟進，并及時維護更新附件12-委內衛生部接口平臺聯調測試風險跟蹤表。6.2 聯

36、調測試問題處理聯調測試過程中會產生各種各樣的問題，問題的產生可能會來自多個方面（服務程序BUG環境不一致導致的問題、系統設置不正確導致問題、數據準備錯誤導致的問題、服務使用不當導致的問題等等），需要對問題進行系統的管理。6.2.1 問題處理流程示意圖6.2.2 問題處理流程說明接口平臺的問題管理可以處理各階段發現的問題（準入測試階段、聯調測試階段、上線階段、運維階段），各階段的問題處理流程是一致的，本文檔重點集中在聯調測試階段的問題處理上。在聯調測試各階段，任何人（主要是服務消費方）都可進行問題識別和提交，包括通過接口平臺管控平臺，正式或非正式的會議、郵件、風險關聯影響分析、問題關聯影響分析等

37、各種問題識別方法。接口平臺接收到問題單之后，負責根據問題單描述的情況對問題進行初步分析，必要的時候需要和相應的服務提供方一起進行分析，確認問題初步責任方之后，將問題單轉交給對應的單位進行處理問題。負責處理問題的單位可以選擇處理問題，也可以拒絕，將問題單重新轉交給接口平臺以便重新指派。問題處理完畢之后，由處理問題的相關方將問題單提交給服務消費方進行問題驗證，待驗證通過之后，關閉該問題單。問題單關閉之后，接口平臺負責將問題納入接口平臺的問題庫當中以便今后使用。6.3 聯調測試協調管理6.3.1 協調管理流程示意圖6.3.1.1 協調請求聯調測試過程中，當事人在處理任務、風險、問題，需要獲得服務提供

38、方、服務消費方、接口平臺等的技術、業務、環境等各方的支持和協助時，識別這些協調的內容，及時提交協調申請。1) 協調單的屬性包括：協調序號、處理狀態、協調內容描述、協調類型、緊急程度、重要級別、申請人、申請日期、所在接口人、接口平臺接口人、受方接口人、處理人、預定解決日期、處理完成日期、處理結果描述、申請人確認、協調效率。2) 協調類型主要分為以下幾種類型：技術，人力，環境，進度，風險，質量，規章制度，生活習慣，語言行為。3) 協調狀態主要包括以下幾種狀態：協調申請，接口人審批，接口平臺審批，接口平臺駁回，受方接收，受方處理，協調完成，協調失敗。需要確定內容2：協調請求存在物理地址和管理工具。6

39、.3.1.2 審核轉發協調請求協調申請所在接口人經內部處理、或私下處理該協調無效后，轉發該協調內容至對應接口平臺接口人。6.3.1.3審批協調請求接口平臺接口人對協調請求的內容進行審核，確認是需要他方處理，則予以通過，提交總部接口人審核；否則予以駁回；接口平臺接口人對協調請求的內容進行審核，確認是需要他方處理，則予以通過并統一協調；否則予以駁回；協調請求通過后，接口平臺召集協調請求方和可能處理方，予以統一協調。6.3.1.4 接受和處理協調請求協調處理方接受協調請求，并限定協調時限進行協調內容的處理；在協調時限達到后，如果沒有完成，則申請協調失敗，要求總部再次協調，重新定義協調時限。6.3.2 相關文檔模板聯調測試的相關人員信息使用如下模板：附件2-委內衛生部接口平臺聯調測試人員信息該工件由接口平臺維護。6.4 聯調測試溝通管理6