數(shù)據(jù)倉庫項目數(shù)據(jù)類測試流程

1、1編寫目的42角色與職責43過程活動描述53.1單元測試5單元測試活動流程圖5單元測試準備7單元測試計劃準備7目的7角色和職責7進入條件7輸入7任務描述7輸出7退出條件8單元測試數(shù)據(jù)和環(huán)境準備8目的8角色和職責8進入條件8輸入8任務描述8輸出9退出條件9單元測試9目的9角色和職責9進入條件9輸入9任務描述10測試目標及測試方法10模型腳本單元測試目標及測試方法10應用腳本單元測試目標及測試方法12輸出12退出條件133.2集成測試14集成測試活動流程圖14集成測試準備15集成測試計劃和方案準備15目的15角色和職責15進入條件15輸入15任務描述15輸出16退出條件16測試數(shù)據(jù)和環(huán)境準備16目

2、的16角色和職責16進入條件17輸入17任務描述17輸出17退出條件17集成測試（模型腳本）17目的17角色和職責18進入條件18輸入18任務描述18測試目標及測試方法19PDM、建表語句或?qū)?shù)語句測試目標19腳本測試目標19調(diào)度測試目標20輸出21退出條件21集成測試（應用腳本）21目的21角色和職責21進入條件21輸入22任務描述22輸出22退出條件233.3業(yè)務測試（只適用于應用腳本）23業(yè)務測試活動流程圖23業(yè)務測試準備24業(yè)務測試計劃24目的24角色和職責24進入條件24輸入24任務描述24輸出24退出條件25測試數(shù)據(jù)和環(huán)境準備25目的25角色和職責25進入條件25輸入25任務描述2

3、5輸出25退出條件26業(yè)務測試26目的26角色和職責26進入條件26輸入26任務描述26輸出27退出條件274變更控制275缺陷管理流程281 編寫目的為了規(guī)范項目的測試工作，給測試組及其與相關組的組間協(xié)調(diào)提供工作指導。數(shù)據(jù)倉庫項目組成員可依照本細則開展與測試相關的工作。2 角色與職責本部分列出了項目組成員日常工作中與測試相關的部分職責：角 色職責負責人1、協(xié)調(diào)測試資源；2、負責過程總體控制；3、確定整體的測試計劃和測試方案測試組1、準備集成測試用例，落實集成測試資源的準備；2、執(zhí)行集成測試用例、記錄測試結(jié)果、執(zhí)行驗證測試；匯報測試結(jié)果；3、參與測試計劃、測試用例等的評審4、協(xié)助進行業(yè)務測試開

4、發(fā)人員1、修正和總結(jié)缺陷，執(zhí)行系統(tǒng)上線；2、進行單元測試；3、必要時作為測試人員執(zhí)行測試；。配置管理員1、提取測試版本，負責版本維護；業(yè)務支持人員1、給測試組提供必要的業(yè)務支持；業(yè)務測試人員1、進行業(yè)務測試相關工作3 過程活動描述3.1 單元測試3.1.1 單元測試活動流程圖3.1.2 單元測試準備3.1.2.1 單元測試計劃準備3.1.2.1.1 目的明確單元測試的范圍、測試方法、規(guī)則，指導單元測試工作的正確執(zhí)行。3.1.2.1.2 角色和職責角 色職 責開發(fā)組長確定單元測試的范圍、規(guī)則、進度和人員安排等，編寫單元測試計劃測試組參與評審單元測試計劃3.1.2.1.3 進入條件Ø X

5、M_DW_P_XX項目計劃已完成Ø XM_DW_R_XX項目需求分析說明書和XM_DW_T_XX項目數(shù)據(jù)映射文檔初稿已完成3.1.2.1.4 輸入Ø XM_DW_P_XX項目計劃Ø XM_DW_R_XX項目需求分析說明書Ø XM_DW_T_XX項目數(shù)據(jù)映射文檔3.1.2.1.5 任務描述Ø 開發(fā)組長根據(jù)項目計劃，編寫單元測試計劃，包括測試相關方的工作安排和測試過程等； Ø 開發(fā)組長組織測試組和開發(fā)組對單元測試計劃進行評審，并形成評審記錄；3.1.2.1.6 輸出Ø XM_DW_P_XX項目單元測試計劃Ø XM_DW

6、_M_XX項目單元測試計劃評審記錄3.1.2.1.7 退出條件XM_DW_P_XX項目單元測試計劃評審通過3.1.2.2 單元測試數(shù)據(jù)和環(huán)境準備3.1.2.2.1 目的確定測試環(huán)境，并獲取測試數(shù)據(jù)，滿足測試需要。3.1.2.2.2 角色和職責角 色職 責開發(fā)組長確定并申請需要的測試環(huán)境和測試數(shù)據(jù)系統(tǒng)組按需求準備測試環(huán)境開發(fā)組對單元測試環(huán)境和測試數(shù)據(jù)進行驗證確認3.1.2.2.3 進入條件XM_DW_R_XX項目需求分析說明書和XM_DW_T_XX項目數(shù)據(jù)映射文檔初稿已完成3.1.2.2.4 輸入Ø XM_DW_R_XX項目需求分析說明書Ø XM_DW_T_XX項目數(shù)據(jù)映射文

7、檔3.1.2.2.5 任務描述 Ø 應用負責人在需求和映射文檔通過評審時，提出測試環(huán)境（包括單元測試、集成測試和用戶測試環(huán)境）申請；Ø 開發(fā)人員編寫單元測試案例，包括所需要的測試數(shù)據(jù)；Ø 如測試數(shù)據(jù)需要其他組協(xié)助準備，則提出測試數(shù)據(jù)申請；Ø 系統(tǒng)組根據(jù)申請進行測試環(huán)境的搭建，并以郵件形式將配置參數(shù)信息通知給開發(fā)組和測試組；Ø 開發(fā)組對已搭建的測試環(huán)境和準備好的測試數(shù)據(jù)進行確認；3.1.2.2.6 輸出Ø 測試環(huán)境Ø XM_DW_T_XX項目單元測試案例Ø XM_DW_M_XX項目單元測試案例評審記錄3.1.2.2.

8、7 退出條件Ø 測試環(huán)境已準備就緒Ø XM_DW_T_XX項目單元測試案例已通過評審3.1.3 單元測試3.1.3.1 目的Ø 對軟件各模塊進行單元測試，尋找并改正缺陷，保證產(chǎn)品質(zhì)量。單元測試一般由開發(fā)人員來完成。測試人員負責測試執(zhí)行情況的檢查和審計，確保單元測試執(zhí)行，并滿足進入Build和集成階段條件。根據(jù)業(yè)務不同，必要時也可以安排測試人員執(zhí)行單元測試。3.1.3.2 角色和職責角 色職 責開發(fā)組長制定單元測試計劃。開發(fā)人員編寫測試用例，執(zhí)行測試并記錄缺陷，修改錯誤。測試人員檢查和審計單元測試執(zhí)行情況，必要時執(zhí)行單元測試；3.1.3.3 進入條件Ø 按

9、測試計劃的安排，項目進行到單元測試階段。Ø 程序可進行測試。3.1.3.4 輸入Ø XM_DW_T_XX項目數(shù)據(jù)映射文檔Ø XM_DW_T_XX項目單元測試案例Ø 待測試的腳本或代碼3.1.3.5 任務描述Ø 根據(jù)總的測試計劃明確和細化單元測試的測試計劃；Ø 開發(fā)人員根據(jù)開發(fā)腳本的情況，完善單元測試案例；Ø 開發(fā)人員根據(jù)單元測試計劃和相應的測試用例來測試同伴或自己的代碼；Ø 在單元測試案例中記錄測試結(jié)果，分析測試結(jié)果，對Bug進行糾正并記錄；Ø 在單元測試結(jié)束時編寫單元測試報告；Ø 將單元測試時

10、使用的SQL整理成腳本，作為一個配置項，以便以后復用；Ø 測試組對單元測試進行抽樣檢查，并形成檢查記錄；3.1.3.6 測試目標及測試方法3.1.3.6.1 模型腳本單元測試目標及測試方法Ø 腳本成功運行檢查測試內(nèi)容：腳本能否成功運行，是否有錯誤測試方法：使用單元測試調(diào)度腳本（unit_checking.pl下同），腳本調(diào)度0200.pl腳本，隨后解析生成的日志，將解析的結(jié)果（日志中的錯誤個數(shù)）插入單元測試結(jié)果表（dwptemp. checking_data_quality下同）。存在缺陷：無Ø 腳本重運行檢查測試內(nèi)容：判斷同一個腳本加載相同的數(shù)據(jù)重復運行后結(jié)果是

11、否一致測試方法：單元測試調(diào)度程序每次調(diào)度都重復調(diào)度任務兩次，數(shù)據(jù)質(zhì)量檢查腳本也會運行兩次，第一次運行后將目標表的數(shù)據(jù)進行備份，第二次判斷備份表和源表整體數(shù)據(jù)是否一致，將不一致數(shù)據(jù)的記錄數(shù)插入單元測試結(jié)果表。存在缺陷：無Ø 腳本規(guī)范性檢查測試內(nèi)容：腳本是否符合項目組腳本規(guī)范性要求測試方法：使用單元測試調(diào)度腳本，腳本調(diào)度腳本規(guī)范性檢查腳本，隨后解析生成的日志，將解析的結(jié)果（不符合規(guī)范性個數(shù)）插入單元測試結(jié)果表。存在缺陷：無Ø 主鍵重復檢查測試內(nèi)容：數(shù)據(jù)加載完成后目標表中是否存在主鍵重復的紀錄測試方法：使用單元測試調(diào)度腳本，腳本調(diào)度數(shù)據(jù)質(zhì)量檢查9000.pl腳本（下同），數(shù)據(jù)質(zhì)量

12、檢查腳本中的主鍵重復性檢查語句查詢目標表中主鍵重復的記錄數(shù)并將該數(shù)值插入單元測試結(jié)果表。存在缺陷：無Ø 主鍵中包含空格檢查測試內(nèi)容：數(shù)據(jù)加載完成后目標表的主鍵鍵值中是否存在空格測試方法：數(shù)據(jù)質(zhì)量檢查腳本中的主鍵鍵值是否包含空格邏輯查詢主鍵鍵值中包含空格（去除值尾空格）的記錄數(shù)并將該數(shù)值插入單元測試結(jié)果表。存在缺陷：無Ø PI是否偏測試內(nèi)容：檢查目標表數(shù)據(jù)分布情況測試方法：數(shù)據(jù)質(zhì)量檢查腳本查詢Teradata數(shù)據(jù)字典，計算數(shù)據(jù)分布偏值，將計算值插入單元測試結(jié)果表。存在缺陷：生產(chǎn)環(huán)境和測試環(huán)境的硬件差別導致數(shù)據(jù)分布情況也不一致，另外外測試的數(shù)據(jù)量不大的情況下測試也不充分，該結(jié)果

13、作為參考。Ø 源表目標表記錄數(shù)一致性（不充分）測試內(nèi)容：源表和目標表記錄數(shù)核對測試方法：數(shù)據(jù)質(zhì)量檢查腳本查詢源表記錄數(shù)和目標表記錄數(shù)，將查詢結(jié)果插入單元測試結(jié)果表。存在缺陷：當目標表所對應的源表是一個表的情況下測試比較充分，但源表有多個或者源表的取數(shù)規(guī)則比較復雜時，DMM映射模版生成的審核語句不準確，需要手工進行腳本修改，建議目前還是有測試組進行測試，待單元測試的其他內(nèi)容執(zhí)行順利后再和測試組溝通將該測試內(nèi)容完整的納入單元測試中。Ø 標準代碼轉(zhuǎn)換是否正確測試內(nèi)容：對選擇進行標準代碼轉(zhuǎn)換的字段判斷目標表該字段值是否在標準代碼表中測試方法：數(shù)據(jù)質(zhì)量檢查腳本查詢目標表中進行標準代碼

14、轉(zhuǎn)換的字段，取值不在標準代碼表中記錄個數(shù)插入單元測試結(jié)果表。存在缺陷：無Ø 拉鏈表拉鏈邏輯檢查測試內(nèi)容：歷史拉鏈表的拉鏈邏輯是否存在問題，是否有開鏈、斷鏈問題測試方法：數(shù)據(jù)質(zhì)量檢查腳本根據(jù)拉鏈表邏輯檢查拉鏈表是否存在問題，將查詢出存在拉鏈邏輯錯誤的記錄數(shù)插入單元測試結(jié)果表。存在缺陷：無Ø 字段是否發(fā)生截取檢查測試內(nèi)容：檢查當源表字段定義超過目標表定義情況下的字段值截取情況測試方法：DMM映射文檔的腳本生成器在生成質(zhì)量檢查腳本時判斷源表的字段定義是否超過目標表的字段定義，如果超過則生成審核語句判斷數(shù)據(jù)實際加載中源表該段的最大值是否超過目標表該字段的定義，將超過目標表字段定義的

15、記錄數(shù)插入單元測試結(jié)果表。存在缺陷：尚在開發(fā)中，由于只能根據(jù)實際處理的數(shù)據(jù)來最終判斷是否存在字段截取情況，因此當被截取數(shù)據(jù)出現(xiàn)在測試加載數(shù)據(jù)之外的情況將無法發(fā)現(xiàn)。Ø DMM映射完整性測試內(nèi)容：判斷開發(fā)組的開發(fā)內(nèi)容和模型組的設計內(nèi)容在范圍上是否一致，是否存在遺漏。模型組根據(jù)目標表的結(jié)構(gòu)進行模型設計并提交設計文檔，模型組設計的每一組映射都應該在開發(fā)組進行映射開發(fā)，不能存在模型組作了設計而開發(fā)組遺漏的情況。測試方法： 在DMM映射文檔的VB宏中增加統(tǒng)計映射個數(shù)的邏輯，分別統(tǒng)計模型組設計的映射個數(shù)和開發(fā)組開發(fā)的映射個數(shù)，不一致時提示錯誤。存在缺陷：需要模型組根據(jù)目標表進行設計，該流程梳理中，

16、VB宏尚未開發(fā)。3.1.3.6.2 應用腳本單元測試目標及測試方法Ø 腳本成功運行檢查測試內(nèi)容：腳本能否成功運行，是否有錯誤測試方法：手工編寫相應測試腳本進行測試。Ø 腳本重運行檢查測試內(nèi)容：判斷同一個腳本加載相同的數(shù)據(jù)重復運行后結(jié)果是否一致測試方法：手工編寫相應測試腳本進行測試。Ø 腳本規(guī)范性檢查測試內(nèi)容：腳本是否符合項目組腳本規(guī)范性要求測試方法：執(zhí)行腳本規(guī)范性檢查腳本，隨后分析生成的日志。Ø 主鍵重復檢查測試內(nèi)容：數(shù)據(jù)加載完成后目標表中是否存在主鍵重復的紀錄測試方法：手工編寫相應測試腳本進行測試。Ø 主鍵中包含空格檢查測試內(nèi)容：數(shù)據(jù)加載完成

17、后目標表的主鍵鍵值中是否存在空格測試方法：手工編寫相應測試腳本進行測試。Ø PI是否偏測試內(nèi)容：檢查目標表數(shù)據(jù)分布情況測試方法：手工編寫相應測試腳本進行測試。Ø 源表目標表記錄數(shù)一致性測試內(nèi)容：源表和目標表記錄數(shù)核對測試方法：手工編寫相應測試腳本進行測試。Ø 標準代碼轉(zhuǎn)換是否正確測試內(nèi)容：對選擇進行標準代碼轉(zhuǎn)換的字段判斷目標表該字段值是否在標準代碼表中測試方法：手工編寫相應測試腳本進行測試。Ø 拉鏈表拉鏈邏輯檢查測試內(nèi)容：歷史拉鏈表的拉鏈邏輯是否存在問題，是否有開鏈、斷鏈問題測試方法：手工編寫相應測試腳本進行測試。Ø 字段是否發(fā)生截取檢查測試內(nèi)

18、容：檢查當源表字段定義超過目標表定義情況下的字段值截取情況測試方法：手工編寫相應測試腳本進行測試。3.1.3.7 輸出Ø 單元測試結(jié)果記錄（在XM_DW_T_XX項目單元測試案例中記錄）Ø 單元測試腳本Ø XM_DW_M_XX項目單元測試報告Ø XM_DW_M_XX項目單元測試檢查記錄3.1.3.8 退出條件Ø 發(fā)現(xiàn)的缺陷均得到修正Ø 單元測試抽樣檢查通過3.2 集成測試3.2.1 集成測試活動流程圖3.2.2 集成測試準備3.2.2.1 集成測試計劃和方案準備3.2.2.1.1 目的明確集成測試的范圍、測試方法、規(guī)則，指導單元測試工

19、作的正確執(zhí)行。3.2.2.1.2 角色和職責模型腳本：角 色職 責模型開發(fā)負責人提供集成測試范圍，評審集成測試計劃/方案和測試需求測試組確定集成測試的范圍、規(guī)則、進度和人員安排等，編寫集成測試計劃和方案，提取測試需求 應用腳本：角 色職 責應用負責人提供集成測試范圍，評審集成測試計劃/方案和測試需求應用測試人員確定集成測試的范圍、規(guī)則、進度和人員安排等，編寫集成測試計劃和方案，提取測試需求3.2.2.1.3 進入條件Ø 項目計劃已完成Ø 需求分析規(guī)格和映射文檔初稿已完成3.2.2.1.4 輸入Ø XM_DW_P_XX項目計劃Ø XM_DW_R_XX項目需

20、求分析說明書Ø XM_DW_T_XX項目數(shù)據(jù)映射文檔3.2.2.1.5 任務描述模型腳本：Ø 測試組根據(jù)項目計劃，編寫測試計劃，包括測試相關方的工作安排和測試過程等；Ø 測試組組織模型開發(fā)組對測試計劃/方案進行評審，并形成評審記錄；Ø 測試組成員熟悉需求，理解業(yè)務規(guī)則，編寫測試需求，為測試做好準備； Ø 測試組組織模型開發(fā)負責人和相關人員對測試計劃/方案進行評審，并形成評審記錄；Ø 測試組組織模型開發(fā)負責人和相關人員對測試需求和案例進行評審，并形成評審記錄。應用腳本：Ø 應用負責人根據(jù)項目計劃，編寫測試計劃，包括測試相關方的

21、工作安排和測試過程等；Ø 應用負責人根據(jù)項目的特性確定測試方案；Ø 應用測試成員熟悉需求，理解業(yè)務規(guī)則，編寫測試需求，為測試做好準備；Ø 應用負責人組織相關人員對測試計劃/方案進行評審，并形成評審記錄；Ø 應用負責人組織相關人員對測試需求和案例進行評審，并形成評審記錄。3.2.2.1.6 輸出Ø XM_DW_P_XX項目模型/應用腳本集成測試計劃/方案Ø XM_DW_T_XX項目模型/應用腳本集成測試需求Ø XM_DW_T_XX項目模型腳本測試案例（體現(xiàn)在MQC上）Ø XM_DW_T_XX項目應用腳本測試案例3.2

22、.2.1.7 退出條件XM_DW_P_XX項目模型/應用腳本集成測試計劃/方案、XM_DW_T_XX項目模型/應用腳本測試需求、XM_DW_T_XX項目模型/應用腳本集成測試案例評審通過3.2.2.2 測試數(shù)據(jù)和環(huán)境準備3.2.2.2.1 目的確定測試環(huán)境，并獲取測試數(shù)據(jù)，滿足測試需要。3.2.2.2.2 角色和職責角 色職 責模型開發(fā)/應用開發(fā)負責人確定并申請需要的測試環(huán)境（一般在單元測試階段一起申請）和測試數(shù)據(jù)ODS接口組/系統(tǒng)組按需求申請和準備測試數(shù)據(jù)和環(huán)境測試組對測試環(huán)境和測試數(shù)據(jù)進行驗證確認3.2.2.2.3 進入條件Ø XM_DW_R_XX項目需求分析說明書和XM_DW_

23、T_XX項目數(shù)據(jù)映射文檔初稿已完成3.2.2.2.4 輸入Ø XM_DW_R_XX項目需求分析說明書Ø XM_DW_T_XX項目數(shù)據(jù)映射文檔3.2.2.2.5 任務描述Ø 應用負責人在測試需求通過評審時，確定測試數(shù)據(jù)范圍，提交測試數(shù)據(jù)需求，申請測試數(shù)據(jù)；Ø 測試負責人根據(jù)模型開發(fā)負責人確定測試數(shù)據(jù)范圍，提交測試數(shù)據(jù)需求，申請測試數(shù)據(jù)；Ø 測試組對已搭建的測試環(huán)境和準備好的測試數(shù)據(jù)進行確認；Ø 數(shù)據(jù)組對測試數(shù)據(jù)進行數(shù)據(jù)質(zhì)量分析（在有現(xiàn)成規(guī)則的情況下）。3.2.2.2.6 輸出Ø 測試環(huán)境Ø XM_DW_T_XX項目測

24、試數(shù)據(jù)需求Ø 測試數(shù)據(jù)3.2.2.2.7 退出條件Ø 測試環(huán)境和測試數(shù)據(jù)已準備就緒3.2.3 集成測試（模型腳本）3.2.3.1 目的對系統(tǒng)接口、PDM、調(diào)度依賴配置文檔、建表和導數(shù)語句或腳本進行集成測試，以滿足上線演練的需求。3.2.3.2 角色和職責角 色 職 責模型設計組提供可供集成測試PDM、建表DDL語句及導數(shù)腳本給模型開發(fā)人員模型開發(fā)負責人監(jiān)控測試結(jié)果確保缺陷得到解決模型開發(fā)人員提供可供集成測試腳本、調(diào)度配置文檔、PDM、建表DDL語句及導數(shù)腳本給測試組，修改缺陷測試組編寫測試案例，篩選測試數(shù)據(jù)與測試用例綁定，執(zhí)行測試、記錄缺陷，補充、維護測試用例。3.2.3.

25、3 進入條件Ø 按測試計劃的安排，項目進行到集成測試階段。Ø 測試數(shù)據(jù)已準備好Ø 腳本、調(diào)度配置文檔、PDM、建表DDL語句及導數(shù)腳本的版本可提交測試Ø 單元測試已經(jīng)通過，滿足“集成測試準入檢查單”的條件。3.2.3.4 輸入Ø XM_DW_P_XX項目集成測試計劃Ø XM_DW_M_XX項目單元測試報告Ø XM_DW_T_XX項目映射文檔Ø 準備好的測試數(shù)據(jù)和環(huán)境Ø 已準備好進行集成測試的腳本、調(diào)度配置文檔、PDM、建表DDL語句或?qū)?shù)腳本3.2.3.5 任務描述Ø 測試組編寫集成測試用例，編

26、寫時要參考之前項目在生產(chǎn)環(huán)境發(fā)現(xiàn)的問題，以便在以后的應用中進行針對性的測試；Ø 測試組從開發(fā)負責人提取要測試的各腳本、調(diào)度配置文檔PDM、建表DDL語句及導數(shù)腳本的版本來進行測試；Ø 測試人員在MQC中記錄發(fā)現(xiàn)的缺陷，如可確定是誰負責修復的可直接分配缺陷；反之則由開發(fā)負責人分配缺陷。缺陷修改后，由開發(fā)負責人發(fā)布下一個測試版本，測試人員進行回歸測試；Ø 在集成測試的里程碑點，測試負責人根據(jù)測試記錄提交集成測試報告；Ø 最終上線演練的版本由測試組提供。3.2.3.6 測試目標及測試方法3.2.3.6.1 PDM、建表語句或?qū)?shù)語句測試目標Ø 驗證建

27、表語句DDL與前一版本PDM的差異；Ø 新舊模型字段的差異性，驗證模型字段是否出現(xiàn)刪減情況，如果出現(xiàn)該情況需要向設計人員確認；Ø PDM與腳本之間的相互驗證，驗證相應的腳本在新的PDM上運行是否正確，一般空跑即可；Ø 驗證導數(shù)語句是否正確，驗證目標表與源表的結(jié)構(gòu)、數(shù)據(jù)是否一致。3.2.3.6.2 腳本測試目標Ø 源表目標表數(shù)據(jù)量核對測試內(nèi)容：源系統(tǒng)的記錄數(shù)與進入倉庫的記錄數(shù)是否一致（剔除根據(jù)需求不需要進入倉庫的數(shù)據(jù)）測試方法：Select count(*) from table where ?Ø 機構(gòu)撤并測試內(nèi)容：檢查機構(gòu)撤并的相關腳本運行結(jié)果

28、是否準確，主要是系統(tǒng)帳號與客戶賬戶的對應關系是否正確。測試方法：根據(jù)對照關系表進行數(shù)據(jù)的驗證。Ø 金額相關內(nèi)容核對測試內(nèi)容：檢查腳本運行后金額相關字段的值是否準確，主要是幣種是否關聯(lián)正確和完整以及金額的數(shù)值是否正確。測試方法：根據(jù)實際的業(yè)務規(guī)則對數(shù)據(jù)進行核對驗證。Ø 總分關系延續(xù)性測試內(nèi)容：總分約束關系主要是針對在源系統(tǒng)中存匯總表與明細表之間必須保持一致的關系。具體表現(xiàn)為：匯總表中的總數(shù)值要與明細表中該類數(shù)據(jù)的合計保持一致。在銀行的賬戶類數(shù)據(jù)中存在著大量這樣的情況。對于這列關系的處理也是通過對比數(shù)據(jù)來實現(xiàn)對腳本的檢測。測試方法：Select filed，sum（field）

29、as sum from table_a A Left join (select field,sum(field) as sum from table_b group by field) b On a. filed =b. fieldwhere a.sum <> b.sumØ 復雜算法的正確性測試內(nèi)容：對于復雜的數(shù)據(jù)處理原則，測試需要對其算法進行驗證。這種算法需要從需求出發(fā)，提煉算法規(guī)則，并將符合此類規(guī)則的數(shù)據(jù)提取出來，運用算法加工這部分數(shù)據(jù)并將結(jié)果與腳本結(jié)果進行對比。測試方法：此類檢查由于出來比較復雜，所以不需要全量檢驗，只需按照規(guī)則獲取符合規(guī)則的部分數(shù)據(jù)進行驗證。3.2

30、.3.6.3 調(diào)度測試目標Ø 調(diào)度是否能正常運行；測試方法：每個應用的CONTROL-M調(diào)度都有一個開始作業(yè)pre_job,右鍵點擊作業(yè)pre_job,在彈出的菜單中選擇'Free',本應用的調(diào)度解除了鎖定,調(diào)度開始執(zhí)行，中間不進行其它操作,觀察調(diào)度能否正常跑完；Ø 任務的命名是否合乎規(guī)范，與腳本名是否一致；測試方法：根據(jù)倉庫規(guī)范，調(diào)度任務名和原Perl腳本名稱要保持一致，否則任務將執(zhí)行錯誤，根據(jù)出錯的任務，可檢查出任務的命名是否符合規(guī)范；Ø 廢棄任務是否被剔除；測試方法：檢查調(diào)度模板中type類型為delete的任務，查找該任務在CONTROL-

31、M調(diào)度是否中還存在，如存在，即調(diào)度配置錯誤；Ø 任務的依賴是否正確、是否覆蓋完全；測試方法：分析系統(tǒng)腳本，得出一份腳本的依賴關系列表，再與調(diào)度進行核對，每個腳本在調(diào)度中都有一個任務名，首選從主腳本開始查找腳本在該調(diào)度中的任務名稱，在依賴關系列表中進行記錄，如果在調(diào)度中無法查到，說明該依賴被遺漏。然后再查找該腳本在調(diào)度中的依賴是否與關系中的依賴相同，用這種方法逐個腳本的往下核對，可以測試出調(diào)度依賴是否正確、覆蓋是否完全；Ø 調(diào)度運行頻率、翻牌是否符合設計；測試方法：在某一業(yè)務日期的調(diào)度全部執(zhí)行完畢后，并能正確進行下一業(yè)務日期的執(zhí)行，則表明調(diào)度的翻牌符合設計要求。目前CONTR

32、OL-M調(diào)度按照腳本運行頻率分組設計，讓調(diào)度多翻牌幾次，查看運行日志，檢查調(diào)度的業(yè)務日期與腳本的執(zhí)行日期是否一致，如一致則表明運行頻率正確Ø 任務出錯時是否影響調(diào)度的正常運行；測試方法：CONTROL-M調(diào)度在運行時，作業(yè)會因庫空間不足、SPOOL空間不足、數(shù)據(jù)質(zhì)量、腳本問題等原因?qū)е聢?zhí)行失敗。針對此類情況，可以用人為干預的方法導致要測試的作業(yè)執(zhí)行失敗，例如可以在腳本中設置語法錯誤、修改測試數(shù)據(jù)等，用來測試在該任務失敗后，后續(xù)依賴任務是否可以繼續(xù)執(zhí)行，調(diào)度是否能夠翻牌。調(diào)度執(zhí)行完畢后，檢查結(jié)果數(shù)據(jù)是否符合要求：調(diào)度正常執(zhí)行完并翻牌一次后，可用集成測試的案例的執(zhí)行來檢驗結(jié)果數(shù)據(jù)是否符合

33、要求。此類檢查不要求執(zhí)行全部的案例，只需選擇優(yōu)先級高或者測試范圍大的案例來執(zhí)行，須盡量保持檢驗的粗粒度。通過查看日志（日志產(chǎn)生的時間先后，日志內(nèi)容）來確定調(diào)度運行時間、調(diào)度依賴是否正確。Ø 調(diào)度是否重復配置。測試方法：CONTROL-M調(diào)度的任務寫入后臺數(shù)據(jù)庫調(diào)度表def_job，可以用查找調(diào)度表的方法,來檢查任務是否重復配置,例如: select * from def_job where job_name='T05_EVENT_DETAIL_DC_A,查詢結(jié)果為兩條或以上,表明此任務已經(jīng)重復配置,調(diào)度配置錯誤。3.2.3.7 輸出Ø XM_DW_T_XX項目模型腳

34、本集成測試用例Ø XM_DW_M_XX項目模型腳本集成測試用例評審記錄Ø XM_DW_M_XX項目模型腳本集成測試報告Ø 缺陷庫（MQC）3.2.3.8 退出條件Ø 集成測試中發(fā)現(xiàn)的缺陷得到糾正。Ø 過程要求的所有文檔完成。3.2.4 集成測試（應用腳本）3.2.4.1 目的對系統(tǒng)接口或腳本進行集成測試，以滿足業(yè)務測試的準入條件。3.2.4.2 角色和職責角 色 職 責應用負責人監(jiān)控測試結(jié)果確保缺陷得到解決。開發(fā)人員提供要測試的代碼版本或腳本，修改缺陷測試組篩選測試數(shù)據(jù)與測試用例綁定，執(zhí)行測試、記錄缺陷，補充、維護測試用例。3.2.4.3 進入

35、條件Ø 按測試計劃的安排，項目進行到集成測試階段。Ø 測試數(shù)據(jù)已準備好Ø 版本可提交測試Ø 單元測試已經(jīng)通過，滿足“集成測試準入檢查單”的條件。3.2.4.4 輸入Ø XM_DW_P_XX項目應用腳本集成測試計劃Ø XM_DW_M_XX項目應用腳本單元測試報告Ø XM_DW_T_XX項目映射文檔Ø 準備好的測試數(shù)據(jù)Ø 已準備好進行集成測試的代碼或腳本3.2.4.5 任務描述Ø 測試組編寫集成測試用例，編寫用例時要參考之前項目在生產(chǎn)環(huán)境發(fā)現(xiàn)的問題，以便在以后的應用中進行針對性的測試；Ø

36、測試組根據(jù)測試用例在已有測試數(shù)據(jù)范圍內(nèi)篩選測試數(shù)據(jù)，與測試用例綁定；Ø 組織設計人員和開發(fā)組對測試用例進行評審，并形成評審記錄，納入CC進行管理；Ø 測試人員根據(jù)集成測試計劃和通過評審的集成測試用例，從CC的集成測試流上提取要測試的版本來進行測試，配置管理員對集成測試流上的版本進行嚴格控制；Ø 測試人員在MQC中記錄發(fā)現(xiàn)的缺陷，開發(fā)組長對缺陷進行分析，如是缺陷則分配給開發(fā)人員進行修改，如需要其他組（設計組等）進行解決，則通過項目組的協(xié)同工單進行缺陷的解決，缺陷修改后，由配置管理員發(fā)布下一個測試版本，測試人員進行回歸測試。 Ø 在集成測試的里程碑點，測試組

37、長根據(jù)測試記錄提交集成測試報告。3.2.4.6 輸出Ø XM_DW_T_XX項目應用腳本集成測試用例Ø XM_DW_M_XX項目應用腳本集成測試用例評審記錄Ø XM_DW_M_XX項目應用腳本集成測試報告Ø 缺陷庫（MQC）3.2.4.7 退出條件Ø 集成測試中發(fā)現(xiàn)的缺陷得到糾正。過程要求的所有文檔完成。3.3 業(yè)務測試（只適用于應用腳本）3.3.1 業(yè)務測試活動流程圖3.3.2 業(yè)務測試準備3.3.2.1 業(yè)務測試計劃3.3.2.1.1 目的明確業(yè)務測試的范圍、測試方法、規(guī)則，指導業(yè)務測試工作的正確執(zhí)行。3.3.2.1.2 角色和職責角 色職

38、 責應用負責人確定業(yè)務測試的范圍、規(guī)則、進度和人員安排等，編寫業(yè)務測試計劃業(yè)務人員、測試組參與評審業(yè)務測試計劃3.3.2.1.3 進入條件Ø XM_DW_P_XX項目計劃已完成Ø XM_DW_R_XX項目需求分析說明書和XM_DW_T_XX項目映射文檔初稿已完成3.3.2.1.4 輸入Ø XM_DW_P_XX項目計劃Ø XM_DW_R_XX項目需求分析說明書Ø XM_DW_T_XX項目映射文檔3.3.2.1.5 任務描述Ø 應用負責人根據(jù)項目計劃，編寫業(yè)務測試計劃，包括測試相關方的工作安排和測試過程等；Ø 應用負責人組織業(yè)務人員和測試組對測試計劃進行評審，并形成評審記錄；3.3.2.1.6 輸出Ø XM_DW_P_XX項目業(yè)務測試計劃Ø XM_DW_M_XX項目業(yè)務測試計劃評審記錄3.3.2.1.7 退出條件XM_DW_P_XX項目業(yè)務測試計劃評審通過3.3.2.2 測試數(shù)據(jù)和環(huán)境準備3.3.2.2.1 目的確定測試環(huán)境，并獲取測試數(shù)據(jù)，滿足測試需要。3.3.2.2.2 角色和職責角 色職 責業(yè)務人員確定并申請需要測試數(shù)據(jù)，并對業(yè)務測試環(huán)境和數(shù)據(jù)進行確認3.3.2.2.3 進入條件Ø XM_DW_R_XX項目需求分析說明書和XM_