特別說明：本文雖歸類於原創，但並非原創，實收集整理於網絡！
一、 數據庫測試概論
隨着軟件業的迅猛發展，我們的開發也從以前的單層結構進入了三層架構甚至現在多層架構的設計，而數據庫從以前一個默默無聞的後臺倉庫，逐漸成爲了數據庫系統，而數據庫開發設計人員成爲了炙手可熱的核心人員。以前我們往往把數據庫操作寫在應用層，從而提高各個模塊的獨立性和易用性，而現在越來越多的數據庫操作被作爲存儲過程直接放在數據庫上進行執行來提高執行效率和提高安全性。因此，對數據庫進行系統完整的成爲了必然。
（一） 數據庫測試預備工作
1、 數據庫中的“CRUD”
C：創建——創建用戶。
R：檢索——執行檢索視圖操作。
U：更新——更新數據庫信息。
D：刪除——執行刪除數據庫操作。
2、 ACID屬性
ACID，指數據庫事務正確執行的四個基本要素的縮寫。包含：原子性(Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。在數據庫測試期間必須測試這四個要素，確保正確
3、 數據完整性
考慮到不同模塊的應用程序以不同的方式使用相同的數據，並執行對數據所有的CRUD操作。確保數據庫中包含的數據儘可能地準確和一致的數據性質，這就是數據完整性。
4、 業務準確性
數據庫發展至今，已不再是單純的用來存儲記錄。事實上，數據庫系統已經發展成爲強大的工具，爲開發者們提供了足夠的擴展支持。數據庫系統比以前具有了更多的強大功能，例如參考完整性，關係約束，觸發器和存儲過程。
5、
（二） 測試什麼
圖1展示了數據庫測試時應該考慮的事項。該圖是針對單一數據庫，其中虛線劃定了測試邊界，表示做數據庫測試時應該考慮到數據庫本身（白盒測試）和數據庫訪問接口（黑盒測試）。
（三） 怎樣測試
由於數據庫開發和應用開發並沒有實質上的區別，所以軟件測試的方法同樣適用於數據庫測試。從測試過程的角度來說我們也可以把數據庫測試分爲
1、 系統測試
傳統軟件系統測試的測試重點是需求覆蓋，而對於我們的數據庫測試同樣也需要對需求覆蓋進行保證。那麼數據庫在初期設計中也需要對這個進行分析,測試.例如存儲過程，視圖，觸發器，約束，規則等我們都需要進行需求的驗證確保這些功能設計是符合需求的.另一方面我們需要確認數據庫設計文檔和最終的數據庫相同，當設計文檔變化時我們同樣要驗證改修改是否落實到數據庫上。
這個階段我們的測試主要通過數據庫設計評審來實現。
2、 集成測試
集成測試是主要針對接口進行的測試工作，從數據庫的角度來說和普通測試稍微有些區別對於數據庫測試來說，需要考慮的是
·數據項的增刪改查操作
·數據表增加滿
·數據表刪除空
·刪除空表中的記錄
·數據表的併發操作
·針對存儲過程的接口測試
·結合業務邏輯做關聯表的接口測試
同樣我們需要對這些接口考慮採用等價類、邊界值、錯誤猜測等方法進行測試。
3、 單元測試
單元測試側重於邏輯覆蓋，相對對於複雜的代碼來說，數據庫開發的單元測試相對簡單些，可以通過語句覆蓋和走讀的方式完成。也可以從測試關注點的角度對數據庫進行分類。
針對每個聯機事務處理邏輯單元（一般爲一個訪問接口）測試細則具體如下：
1） 數據正確性驗證
輸入正確的參數應該返回正確的數據結果。這裏輸入的參數至少需包含兩端邊界值及一箇中間值。
2） 防錯處理能力測試
·非法參數處理測試（針對非法參數應該範圍約定標誌）
非法參數包括：兩端邊界值、指針類型傳NULL、其他錯誤參數。
·內存分配管理測試
若單元內涉及內存分配，需在單元外進行內存釋放測試（具體可引用單元內所分配內存以檢測）。
3）
4、 功能測試
對數據庫功能的測試我們可以依賴與工具進行
DBunit
一款開源的數據庫功能測試框架，可以使用類似與Junit的方式對數據庫的基本操作進行白盒的單元測試，對輸入輸出進行校驗
QTP
大名鼎鼎的自動測試工具，通過對對象的捕捉識別，我們可以通過QTP來模擬用戶的操作流程，通過其中的校驗方法或者結合數據庫後臺的監控對整個數據庫中的數據進行測試。個人覺得比較偏向灰盒。
DataFactory
一款優秀的數據庫數據自動生成工具，通過它你可以輕鬆的生成任意結構數據庫，對數據庫進行填充，幫助你生成所需要的大量數據從而驗證我們數據庫中的功能是否正確。這是屬於黑盒測試
5、 數據庫性能
雖然我們的硬件最近幾年進步很快，但是我們需要處理的數據以更快的速度在增加。幾億條記錄的表格在現在是司空見慣的，如此龐大的數據量在大量併發連接操作時，我們不能像以前一樣隨意的使用查詢，連接查詢，嵌套查詢，視圖，這些操作如果不當會給系統帶來非常巨大的壓力，嚴重影響系統性能
性能優化分4部分
1）物理存儲方面
2）邏輯設計方面
3）數據庫的參數調整
4）SQL語句優化.
通過數據庫系統的SQL語句分析工具，可以分析得到數據庫語句執行的瓶頸，從而優化SQL語句。
Loadrunner
可以通過對協議的編程來對數據庫做壓力測試
Swingbench（這是一個重量級別的feature，類似LR，而且非常強大，只不過專門針對oracle而已）。
Oracle11g已經提供了real application test，提供數據庫性能測試，分析系統的應用瓶頸。
還有很多第三方公司開發了SQL語句優化工具來幫助你自動的進行語句優化工作從而提高執行效率。
6、 安全測試
軟件日益複雜，而數據又成爲了系統中重中之重的核心，從以往對系統的破壞現在更傾向於對數據的獲取和破壞。而數據庫的安全被提到了最前端
自從SQL 注入攻擊被發現，冒失萬無一失的數據庫一下從後臺變爲了前臺，而一旦數據庫被攻破，整個系統也會暴露在黑客的手下，通過數據庫強大的存儲過程，黑客可以輕鬆的獲得整個系統的權限。而SQL的注入看似簡單缺很難防範，對於安全測試來說，如何防範系統被注入是測試的難點。
業界也有相關的數據庫注入檢測工具，來幫助用戶對自身系統進行安全檢測。
對於這點來說業界也有標準，例如ISO IEC 21827，也叫做SSE CMM 3.0，是CMM和ISO的集成的產物，專門針對系統安全領域的
另外一方面，數據庫的健壯性，容錯性和恢復能力也是測試的要點
二、 報表測試
報表測試根據項目的定義有大有小,有時只是作爲軟件的一個部分進行測試,有時整個項目都是測試各種報表.但不論如何,報表的作用始終都是將系統中已經存在的數據根據用戶的設置計算加工/整理彙總/最終以清晰的格式展示給用戶,以便用戶進一步做數據分析或統計。
軟件中的報表實現一般分爲定義報表的所需數據(一般可以通過選擇或手工輸入條件來縮小數據範圍)和定義報表格式兩個部分.報表格式除了如國家各行業標準中規定的報表使用固定格式外,大多是根據企業或用戶的需要定製報表。
所以,做報表測試時要注意以下方面:
(一) 數據統計方面
1、 數據的正確性
用戶使用報表就是期望通過一個簡單方便的平臺能快速的查找到他所需要的數據.所以在測試報表時首先就要檢查報表中的數據是不是用戶需要的數據,如果沒有加工的數據,是否保持了原貌;加工過的數據查看加工的結構是否和手工加工的結果一致，細則如下：
|
測試項目 |
測試要點 |
|
數據的來源 |
來源於哪張表,哪個字段,數據庫中的數值與界面數據的對應.如數據庫中性別的數據可能是0或1,但界面顯示爲男或女,這個對應關係是否正確. |
|
數據的範圍 |
是否只顯示了報表設置的對應範圍特別要注意邊界數據,要清楚報表的需求,是否需要過濾掉被選擇的數據.如時間選擇爲2006-9-27~2007-9-27,那麼是否應該包含9-27這天. |
|
數據的對應關係 |
數據庫中的字段是否與報表中的信息對應 |
|
數據的格式 |
小數位,千位符,四捨五入等是否與報表設置一致 單位或稅率轉換是否正確 組合顯示的數據是否合理 |
|
數據的排序 |
排序方式是否與報表設置一致(如果沒有設置,是否有一個清晰的默認排序方式,如按字母或數字排序) |
|
流水號 |
如報表有使用流水號,流水號的生成和格式是否正確. 取消操作是否會生成流水號. |
|
明細與合計的一致性 |
各部分明細或小節是否與最後總和一致 |
|
|
試這一部分內容需要對業務邏輯相當熟悉,對數據庫的設計也要非常瞭解.必要時可以通過自己寫查詢語句查看數據.
有些報表的條件有多有少,但測試方法都是一樣.根據條件通過等價類劃分和排列組合設置各種條件組合.千萬不要盲目的測試,否則會導致該測的沒測,多餘的測試做了一堆..一般來說有類別劃分的(一般界面表現爲下拉框),每個類別都要測試到,如性別中的男,女都要測試.輸入的可以用等價類來劃分要測試的數據。
2、 數據的完整性
3、 數據的合法性
(二) 報表格式
這一點主要是看報表的輸出格式是否符合要求，可以從以下幾方面來檢查：
|
測試項目 |
測試要點 |
|
報表的整體風格 |
報表是否符合規定的或用戶設置的格式 |
|
報表標題 |
報表的標題是否是正確的報表名稱 如報表中有嵌入的數據(會跟隨用戶的選擇而變化的).需要檢查數據是否正確,如XX企業9月份財務報表,這個9月就是用戶選擇的;或者XX公司2006-9-27~2007-9-27的網站訪問量,這個時間段也是用戶選擇的. |
|
公司的一些標誌 |
如logo,名稱,地址之類的是否正確 |
|
報表的頁首與頁尾 |
是否採用了一致的規則. |
|
分頁 |
當輸出的內容多時,分頁是否正確. 翻頁功能是否正確 |
|
友好性 |
數據或圖表是否清晰,一目瞭然, 數據的展示符合用戶的習慣 需要特別提醒的數據(如合計,異常數據)是否突出顯示 複雜算法處,用戶不明白或容易混淆處是否有註釋 一些默認的格式是否讓人感覺舒服,如對齊,邊界,間隔等 |
(三) 權限控制
對於有權限控制的系統,報表當然也應該和用戶所具有的權限相一致.需要從兩方面校驗權限的控制.
報表的條件定義:在條件選擇區域,有些下拉框中應該不能顯示用戶權限範圍外的數據.如普通文員在使用報表時,報表名稱下拉框中是不可以顯示管理者才能查看的報表的.有些以輸入的文本框有級別的劃分時,都應該要測試輸入超越權限的數據的相應.
注意這裏一定要測試每個條目.
報表內容:報表中的內容不能顯示用戶本沒有權限查看的數據.
(四) 報表輸出
細則如下：
1、預覽中的顯示完整性；
2、多頁情況下，第2頁的表頭顯示；
3、能否實現需求要求的特定印刷情況；（比如，印刷使用指定的模板）
4、預覽後印刷；
5、不預覽，直接印刷
6、需求規定各類打印機的測試
(五) 報表性能
用戶在設置好條件後都希望不要等待報表太長時間,當然有時數據量大時等待時間長些也是合理的.但是在做報表的開發時或測試人員可以提出一些意思來提高報表的性能.
報表的條件設置區域應該設置默認值以避免用戶不輸入任何條件直接生成報表所造成的長時間等待.例如開始和結束時間可以默認爲當前的一個月,一些輸入文本框可以根據用戶的身份默認一個數值.
生成報表時用類似進度條表現進度,避免用戶盲目的等待
提供讓用戶選擇每頁顯示多少條數據的選項, 默認爲最小的選項,這樣可以避免無謂的資源浪費.
生成報表的語句儘量採用最優的查詢語句,多調試幾遍,查看語句的性能.
注意:如果可以所有的條件爲空時,需要測試條件爲空時的性能.
(六) 一般性測試
測試報表條件選擇區域,主要需要注意如下問題:
每個字段的類型校驗
每個字段的長度校驗
每個字段中輸入特殊字符的校驗(包括空/空格)
通配符的測試(對信息量大的系統,建議最好作處理不支持通配符以避免性能的低下)
字段與字段之間的關係的測試(如約束關係或排斥關係)