話單入庫後
1話單入庫後原表資料與話單資料對比，對比資料、條數、列數
2異常話單能否入庫及入庫後儲存樣式
3涉及到入庫原表的表，是否會定期刪除，刪除前，資料是否會正常轉移
4入庫表的屬性檢視（表結構定義與話單/預統計/預處理/etl等一致；表空間設定；分割槽設定；有無索引等）
表結構/表空間/分割槽/索引：plsql中右鍵表名，選擇view
表結構測試
1話單原表與話單結構一致
2入庫後資料會層層收斂，檢視1層、2層等表的結構是否與需求一致，是否與**的表一致
3檢視臨時表，是否按臨時表建立
臨時表：plsql中右鍵表明，選view，檢視是否臨時表
4建立資料庫物件時判斷資料物件是否存在
建立話單表一般先用函式f_sys_base_i***ists檢查物件是否存在
資料收斂過程
1表資料轉移、收斂的過程驗證（針對不同的版本資料收斂的過程不同）
2驗證收斂的儲存過程及被呼叫的其它物件（如檢視、函式、包等）
如merge語句，on條件字段是否完整，是否有空保護等
3驗證收斂後的表資料是否正確（特別重要，每一次收斂都有可能出錯，所以每一次資料轉移、收斂都要著重驗證）
4收斂後的表屬性（表空間、索引等）。這裡提到的屬性要與基礎版本的對比，如5月1號搭建基礎環境，5月3號公升級，公升級後表資料應該與1號的對比
表結構/表空間/分割槽/索引：plsql中右鍵表名，選擇view
5考量效能，在資料量大的表上有索引或其它措施提公升查詢速度
話單月表一定有索引，至少是時間列上索引
6是否有不正確的編碼導致索引失效
select * from user_indexes where lower(status) != 'valid'
7話單轉移到結果表，考慮utc時間轉本地時間，要關注話單說明中，時間欄位是本地時間還是utc時間（utc居多）
處理時需要有自定義函式載入在時間字段外層
8業務表轉移到結果表，要看有沒有時間字段，考慮utc時間轉本地時間
處理時需要有自定義函式載入在時間字段外層
其它情況
1時間跨日、周、月、年的話單入庫轉移後，資料是否收斂正常，日誌是否報錯
2臨時表呼叫前是否有刪除的操作（雖然臨時表會話級別）
truncate 臨時表
3儲存過程、函式等**裡特別關注時間的操作（date型，varchar型），有可能會varchar型時間進行加減運算。
時間型別加減，要看這個變數是否是時間型別（即date型）
4分割槽表的分割槽名稱是否正確，分割槽索引是否建立
select * from user_ind_partitions;
5編碼規範問題
st時就應該測試了
6每張表都有對應的儲存空間，是否正確
公升級指令碼中，建立表就不應該帶有表空間的字樣，除了索引表空間，其他表空間都預設是使用者表空間
7不能隨意使用以往版本配置表，會帶來效能和業務風險
舊版本有的配置表，修改、刪除資料或增加帶有編號類的資料，要確認好，現網是否有修改
8字串需要有大小寫保護
where lower(xx)=lower('a_b_c')；
decode(lower(serviceid),'abc',1,0)；
9多批話單入庫到不同的入庫表，也就是持續的入話單測試
資料維護
1文件中提及的維護任務需要在文件分析的時候檢視是否合理
刪除xx天前資料，要構造資料並測試；
有時需求中說的儲存天數不合理，如明細儲存30天，可以提出異議
2定時維護作業的測試（如多久刪除一次等）
user_jobs中刪除表資料的job
3定時維護後，物件是否存在、是否能釋放空間（如drop前先truncate），**站是否存在資料等
4話單或日誌維護
話單從etl採集後，是否有備份，備份的話單，刪除多少天前的；
日誌表是否維護？刪多久前的資料
job任務檢視
1檢視job任務是否每天正常執行，執行後相應表中是否有資料，資料是否正確
user_jobs中上次執行時間
報表返回過程
1注意話單表、業務表、配置表之間的外連線
2注意0.00的保留兩位(trim(to_char(,'99990.90')))
否則會出現.00的情況
3order by排序
檔案 資料庫索引原理（B B 樹）
急於了解檔案 資料庫的索引原理，本文不具有真正的參考價值，只是從乙個懶人的角度速成原理。但是跳過了對b 和b 樹的嚴格定義。因短暫記憶,容易失憶，一星期之後再來回顧。現講結果 檔案 資料庫索引用的是b 樹 1.二叉查詢樹 左節點比根節點小，右節點比根節點大，原理是類似二分法，具體根據樹的子節點 對該...
資料庫測試
對於資料庫部分，一般需要進行功能測試，容錯測試，效能測試，安全測試等，這個也要根據產品特性和需求決定，具體決定需要測試哪些方面，簡單說明如下，大家可以繼續補充。1.效能併發測試 例如之前updater討論會，有提到的資料庫的併發測試，結合響應時間的測試 1 與資料庫連線的服務程式採用多執行緒同時開啟...
資料庫測試
從測試過程的角度來說我們也可以把資料庫測試分為 系統測試 傳統軟體系統測試的測試重點是需求覆蓋，而對於我們的資料庫測試同樣也需要對需求覆蓋進行保證。那麼資料庫在初期設計中也需要對這個進行分析,測試.例如儲存過程，檢視，觸發器，約束，規則等我們都需要進行需求的驗證確保這些功能設計是符合需求的.另一方面...