每當一款産品或是産品中的一項功能在完成後都需要對其進行測試，去驗證該産品或該功能是否可以正确工作，達成使用者預期的效果；測試就是站在客戶的角度，以産品或是功能預期能夠達到的預期效果為模闆去對産品或是功能進行實際操作，操作的結果是衡量該産品或是該功能上線還是需要繼續完善的标準。
當根據客戶的需求完成開發之後，就需要按照客戶的需求去對開發完成的成果進行測試，以驗證開發出來的成果是否可以實作使用者的需求。本人在進行工作時，根據客戶的需求，對前期開發完成的流程進行了一定程度上的調整，調整之後對流程進行了功能測試，并整理成本篇文檔，以期後續在工作中有所遺忘時可以進行檢視。
1整體介紹
根據客戶的需求以及回報，對已經開發結束的流程進行了細節調整，同時由于項目即将上線，進行最後的流程聯測，為後續項目上線做好準備，在下面将會對本次進行測試的流程進行簡要介紹。
1.1整體架構
內建底座以IDM、MDM和ESB産品為核心搭建基礎的底座平台，打通資訊系統的壁壘，同時為後續企業資訊化的深度內建與建設提供支援。
內建底座在整個資訊化系統架構中是偏向于基礎的，一是通過MDM平台對接上下遊系統實作組織、崗位、人員等基礎資料的統一，為系統直接的對接以及後續的業務內建、單據內建、分析展現等提供基礎資料支援；二是通過IDM平台完成賬戶統一與統一認證，實作各個系統的單點登入，滿足建立統一、規範的應用中心的條件，進而奠定企業資訊化的基礎。
1.2業務流程
1.以HR系統為源頭，HR負責提供組織、崗位、人員的源頭資料；
2.HR系統在進行新增、修改、啟用、禁用等操作時進行送出，再調用技術底座的同步接口将資料以JSON的方式進行推送；
3.技術底座的同步流程接收HR系統的JSON資料後進行落地，同時自動生成資料分發的任務（增量，初始化需業務系統主動擷取），并産生任務辨別TaskId；
4.技術底座将TaskId推送至下遊業務系統的任務接收接口；
5.下遊系統接收TaskId後，先調用技術底座的擷取tokenId接口擷取tokenId，再調用技術底座提供的資料提供接口擷取任務中的JSON格式資料，并将資料寫入下遊業務系統中，寫入後調用技術底座的日志接口進行日志回寫。
1.3測試思路
由于項目即将上線，是以本次測試按照上線時的資料進行聯測，包含資料的初始化以及增量資料的同步，下面是本次整體的測試思路。
1.傳輸資料情況下驗證接口調用時間；
2.驗證組織層級關系是否處理正确；
3.傳輸後的資料以及參考資料可正常顯示；
4.傳輸大量資料時是否存在丢失的資料；
5.資料傳輸成功後檢視日志狀态是否更改。
2測試目的
測試是在一款産品在正式投入使用前，對産品功能進行最終複審，是一款産品品質保證的關鍵步驟，也是為了發現錯誤而執行的過程。僅就測試而言，它的目标是發現産品中的錯誤，但并不是我們的最終目的，測試的目的大緻分為兩種，一是暴露缺陷，二是樹立信心，這兩點将在本章節中進行具體闡述。
2.1發現缺陷
一次成功的測試是發現了曾經未發現的錯誤的測試。這句話其實也就對測試的其中一個目的進行了闡述：以最少的人力、物力和時間去尋找産品中潛在的各種錯誤和缺陷，并對發現的錯誤及缺陷進行處理，以此提高産品的品質，避免産品正式投入運作之後由于潛藏的缺陷而帶來商業風險。
2.2預防缺陷
每一款産品都不會是毫無缺陷的，那麼如何最大程度上地避免缺陷的産生就是産品測試存在的意義之一，上文提到測試是為了讓産品中的缺陷在産品未正式投入運作之前将其暴露出來并進行修複，在使産品暴露缺陷并修複的過程中吸取的經驗也會讓後續的産品開發去避免同樣缺陷出現的情況，進而提高産品的品質，這也是測試的主要目标之一。
2.3優化産品
使用者拿到經過測試的産品和沒經過測試的産品，對品質的信心是不一樣的。是以測試可以樹立使用者對産品的信心。同時，如果在測試過程中很少出現或是不出現産品問題，那麼會很大程度上提升開發者的信心乃至提升整個企業的信心，這種信心是隐性的一種特質，對自家産品有信心會使企業的銷售人員更便捷的推出去産品，是以在産品正式投入使用之前進行測試是非常有必要的。
3測試内容
本次主要項目上線前對人員組織崗位流程進行聯測，保證資料傳輸過程中的準确性以及完整性，以便後續項目能夠穩定上線。
3.1測試要點
本次測試内容主要測試各業務系統間的連通性，保證資料可以正常進行同步及分發；其次針對各業務系統的資料顯示情況進行測試，確定各業務系統中的資料顯示正常；最後測試各業務系統在資料傳輸過程中資料格式映射的正确性，確定資料以正确的格式傳輸到目标系統，不會出現在資料傳輸過程中出現資料丢失的情況。
1.檢查組織、人員、崗位的相關資料管控，檢視日志資訊是否回寫或修改完成。
2.MDM系統、IDM系統分發完畢後，檢查系統表組織和人員是否同步完畢。
3.檢查組織、崗位，人員的相關資料管控，檢視日志資訊是否回寫，資料是否已啟用。
4.檢查組織資料父節點類型是否跟源頭推送過來的結構保持一緻。
5.IDM系統分發完畢後，檢查系統表人員是否同步完畢。
3.2同步流程
同步流程主要用來讓客戶完成客戶資料的修改操作，或是在客戶資料集體錄入結束，産品正式上線之後讓客戶進行單條客戶的錄入操作。客戶在進行新增、修改、啟用、禁用等操作時進行送出，源頭系統自動調用ESB的同步流程，将資料以JSON的方式進行推送，完成客戶資料從源頭系統到主資料系統的字段映射處理，并調用主資料系統提供的資料同步接口将資料同步至主資料系統，後續通過主資料系統的自動送出接口将資料的任務ID送到目标系統，再由目标系統的流程進行一系列處理之後存儲到目标系統。
1.檢查組織、人員、崗位的相關資料管控。
2.檢查組織、人員、崗位檢視日志資訊是否回寫或修改完成。
3.檢查組織、人員、崗位資料狀态是否正确。
4.檢查組織、人員、崗位資料父節點類型是否跟源頭推送過來的結構保持一緻。
3.3分發流程
分發流程主要接收主資料源頭系統的組織、人員、崗位主資料，調用ESB的分發流程，根據TaskId調用資料提供接口擷取資料，再将資料寫入下遊系統。
1.檢查組織、崗位、人員的相關資料管控，檢視日志資訊是否回寫。
2.檢查組織、人員、崗位資料狀态是否正确。
3.檢查組織、人員、崗位資料父節點類型是否跟源頭推送過來的結構保持一緻。
4 效果展示
在完成流程的調整之後，本人對流程進行了測試操作，用以保證流程的可用性，暴露潛在的功能缺陷，在本章節中，将對本次測試的預期效果、測試過程以及測試完成的效果展示進行闡述。
4.1預期效果
HR系統在進行新增、修改、啟用、禁用、等操作時進行送出，調用技術底座的同步接口将資料以JSON的方式進行推送，在通過主資料系統的自動送出接口将資料的任務TaskId送到目标系統，推送成功後各業務系統互相間的調用正常、資料傳輸正常、傳輸字段無缺漏的問題，同步分發皆可傳輸至目标系統，并在目标系統正常顯示。
4.2測試過程
本次同步的資料源頭為HR業務系統，本次測試模拟HR進行業務操作，直接調用同步接口進行測試，通過Postman進行接口調用如下：
檢視剛才同步的任務效果如圖：
資料同步值主資料系統中效果如圖：
在主資料系統中選中一個資料，點選生成任務進行資料下發，如圖：
點選送出即可将資料分發至目标業務系統，如圖：
經驗證資料已分發至目标業務系統，如圖：
4.3 效果展示
在本文檔中，頁面展示以主資料系統為例，首先對層級關系資料進行驗證，以人員資料為例，檢視組織下是否有人員存在，以及是否挂載于正确的組織之下，如圖：
經驗證，人員與組織關聯關系正常，如圖：
經驗證，傳遞的參考資料顯示正常，傳遞的資料确為CODE值，如圖：
5心得體會
在本次同步分發流程開發工作中我學到了很多知識，對同步分發操作更加的熟練，加深了我對各個産品的認識，并且對各個産品的組合使用有了更清晰的了解，現将我在本次工作中的收獲進行總結。
5.1經驗收獲
在聯測過程中收獲了許多經驗，包括使用ESB方面和聯測方面等。這次聯測讓我在ESB使用方面變得更加熟練，學會以前不會使用的功能，還了解到許多在開發流程時需要注意的地方；認識到聯測時出現的問題不會隻是其中一方系統的問題，在處理這些問題的時候需要雙方都做系統調整來解決問題。