資料庫的測試
⑴ 資料庫測試
新建一個資料庫,可以是ACCESS資料庫。
按上述每行的內容,建立數據表,基本欄位都在每行內容中。
對各表輸入數據。
建立各表之間的索引等,關鍵在於sql結構化查詢語言的編寫。
使用一定的編程軟體操控資料庫表。
⑵ 資料庫測試的系統測試
傳統軟體系統測試的測試重點是需求覆蓋,而對於我們的資料庫測試同樣也需要對需求覆蓋進行保證。那麼資料庫在初期設計中也需要對這個進行分析,測試.例如存儲過程,視圖,觸發器,約束,規則等我們都需要進行需求的驗證確保這些功能設計是符合需求的.另一方面我們需要確認資料庫設計文檔和最終的資料庫相同,當設計文檔變化時我們同樣要驗證該修改是否落實到資料庫上。
這個階段我們的測試主要通過資料庫設計評審來實現。
⑶ 測試資料庫
如果你有別人導出來的數據,就
imp進去;
如果沒有,慢慢
insert
into
吧..........
如果懶的insert
into
就如下:
oracle自帶的用戶
scott
和
sh
,裡面倒是有不少數據,具體用戶密碼為:
scott
/
tiger
sh
/
sh
必須先以DBA的身份進入資料庫給他們解鎖,不然你用不了的,解鎖為:
alter
user
scott
account
unlock;
alter
user
sh
account
unlock;
好了,2個用戶的數據,您老慢慢測吧...
⑷ 什麼是數據和資料庫完整性測試
數據完整性:存儲在資料庫中的所有數據值均正確的狀態。如果資料庫中存儲有不正確的數據值,則該資料庫稱為已喪失數據完整性。可確保資料庫中的數據質量。例如,如果輸入了 employee_id 值為 123 的職員,那麼該資料庫不應允許其他職員使用同一 ID 值。如果計劃將 employee_rating 列的值范圍設定為從 1 到 5,則資料庫不應接受 6。如果表有一 dept_id 列,該列存儲職員的部門編號,則資料庫應只允許接受公司中的有效部門編號。常用的測試方法:邊界值、等價值法
⑸ 資料庫測試的主要目的和方法是什麼
資料庫測試的主要目標是:確保資料庫訪問方法和進程正常運行,數據不會遭到損壞。測試方法: �6�1 分別測試記錄的新增、修改、刪除等操作,以驗證前台與後台數據的一致性為主。 �6�1 測試記錄的查找功能,檢查返回的數據是否正確,並測試相關功能。 �6�1 測試數據的不同顯示方式。 �6�1 測試有效和無效數據對資料庫的影響。完成標准:�0�2�0�2 �0�2所有的資料庫訪問方法和進程都按照設計的方式運行,數據沒有遭到損壞。
⑹ 用sql資料庫怎麼做軟體測試
不太明白你的意思!不知道你是說應用資料庫做測試還是做資料庫的測試?
前者通常來說,就是驗證前台操作與資料庫的一致性,比如你在前台刪除、增加、修改一條數據,資料庫相應的表內是否有相應的記錄變化,這是最基本的
如果你說是做資料庫測試,牽涉到很多,不過,對於我們測試人員做的哦比較多的資料庫的並發,打個比方說吧,我們對一個有5個欄位的表test進行基本測試,驗證兩種情況:一,某欄位order_no有索引;二,欄位order_no無所有,有無索引時做相同的測試驗證
測試驗證分同時並發和分鍾並發兩種情況驗證
,並發數從10、20、100、1000不等表中有50000條數據,通過比較響應時間得出測試結論。
做資料庫測試不多,也覺得三兩句說不清除!
⑺ 資料庫測試怎麼實現
要看你的測試需求。測試前,需要了解
1.檢查表結構,包括欄位名稱,欄位類型,主鍵,唯一鍵,索引,分區等。
2.檢查SQL。包括欄位是否正確,表名是否正確,where條件是否正確,union條件是否正確,join表是否正確(左連接,右連接,全連接)等。
3.檢查數據。檢查數據條數是否與預期一致,檢查數據內容是否有缺失或錯位,檢查數據內容是否有亂碼。
⑻ 軟體開發資料庫如何進行測試
比如:數據冗餘,功能和性能方面存在的問題已經嚴重影響應用軟體的使用。軟體測試人員往往重視對軟體功能和編碼的測試,而忽略對軟體性能,特別是資料庫訪問並發測試。因為,他們固有的思想中認為資料庫設計存在問題對系統性能影響不大,或從根本上忽略了資料庫在軟體開發中的地位,直到出現了問題,才想到對資料庫的測試,但往往也是僅僅通過對編碼的測試工作中捎帶對資料庫進行一定的測試,這遠遠是不夠的。目前,中鐵網上訂票系統在大用戶同時在線訂票中系統頻頻癱瘓,就是最好的佐證。 所以,在應用軟體的測試工作中,應該將資料庫作為一個獨立的部分進行充分的測試,這樣才可以得到應用軟體所需要的性能優化的資料庫。那麼,應該對哪些內容進行測試,如何進行測試呢? 2、資料庫設計的測試 資料庫是應用的基礎,其性能直接影響應用軟體的性能。為了使資料庫具有較好的性能,需要對資料庫中的表進行規范化設計。規范化的範式可分為第一範式、第二範式、第三範式、BCNF範式、第四範式和第五範式。一般來說,邏輯資料庫設計應滿足第三範式的要求,這是因為滿足第三範式的表結構容易維護,且基本滿足實際應用的要求。因此,實際應用中一般都按照第三範式的標准進行規范化。但是,規范化也有缺點:由於將一個表拆分成為多個表,在查詢時需要多表連接,降低了查詢速度。故資料庫設計的測試包括前期需求分析產生資料庫邏輯模型和後期業務系統開發中的測試兩部分(這里指的是後者),我在這里稱為實體測試。 資料庫是由若乾的實體組成的,包括(表,視圖,存儲過程等),資料庫最基本的測試就是實體測試,通過對這些實體的測試,可以發現資料庫實體設計得是否充分,是否有遺漏,每個實體的內容是否全面,擴展性如何。 實體測試,可以用來發現應用軟體在功能上存在的不足,也可以發現數據冗餘的問題。經過測試,測試人員對有異議的問題要及時和資料庫的設計人員進行溝通解決。 3、數據一致性測試 在進行實體測試後,應進一步檢查下面的內容以保障數據的一致性: 3.1 表的主鍵測試根據應用系統的實際需求,對每個表的主鍵進行測試,驗證是否存在記錄不唯一的情況,如果有,則要重新設置主鍵,使表中記錄唯一。 3.2 表之間主外鍵關系的測試資料庫中主外鍵欄位在名稱,數據類型,欄位長度上的一致性測試。 3.3 級聯表,刪除主表數據後,相應從報表數據應同時刪除的問題例如學生表和學生成績表,學生數據已經刪除,成績表中相應學生的成績記錄應同時刪除。 3.4 存儲過程和觸發器的測試存儲過程可以人工執行,但觸發器不能人工處理,所以在對存儲過程和觸發器執行的過程中針對SQL SERVER2005及以上版本可以使用Microsoft SQL Server Profiler性能測試工具進行測試。 Microsoft SQL Server Profiler 是 SQL 跟蹤的圖形用戶界面,用於監視資料庫引擎或 Analysis Services 的實例。測試人員可以捕獲有關每個事件的數據並將其保存到文件或表中供以後分析。例如:可以對生產環境進行監視,了解哪些存儲過程由於執行速度太慢影響了性能。 4、資料庫的容量測試 隨著資料庫系統的使用,數據量在飛速增長,如何在使用前對數據容量的增長情況進行初步估算,為最終用戶提供參考,這在資料庫使用和維護過程中,是非常重要的。可以通過對資料庫設計中基本表的數據大小,和每天數據表的數據產生量進行初步估算。 記錄數據量=各個欄位所佔位元組數的總和表的數據量=記錄數據量*記錄數資料庫大小=各表數據量的總和 當然,資料庫的大小不僅僅只是基本表的大小,還有系統表,視圖,存儲過程等其它實體所佔的容量,但最基本的數據是表的數據。另外,資料庫的容量還包括資料庫日誌文件的容量,一般應預留資料庫文件的2倍左右。 5、資料庫的性能測試 應用軟體除了功能外,很重要的一部分就是軟體的性能,而對於資料庫系統,資料庫性能的好壞會直接影響應用軟體的性能,這部分的測試,一般手工測試就顯得無能為力了,這時就要藉助自動化的測試軟體,例如:DataFactory,DataFactory是一種強大的數據產生器,它允許開發人員和測試人員很容易產生百萬行有意義的正確的測試資料庫,該工具支持DB2、Oracle、Sybase、SQL Server資料庫。這樣,就可以模擬出應用軟體長期使用後,海量數據存儲的資料庫的性能狀況。從而盡早發現問題,進行資料庫性能的優化。 這里要注意,進行性能測試的時候,一定要注意測試環境的一致性,包括:操作系統、應用軟體的版本以及硬體的配置等,而且在進行資料庫方面的測試的時候一定要注意資料庫的記錄數、配置等要一致,只有在相同條件下進行測試,才可以對結果進行比較。否則無法和用戶對軟體的性能的觀點達成一致。 6、資料庫的壓力測試 說起測試,我們首先想到的就是軟體正確性的測試,即常說的功能測試。軟體功能正確僅是軟體質量合格指標之一。在實際開發中,還有其它的非功能因素也起著決定性的因素,例如軟體的響應速度。影響軟體響應速度的因素有很多,有些是因為演算法不夠高效;還有些可能受用戶並發數的影響。 在眾多類型的軟體測試中,壓力測試正是以軟體響應速度為測試目標,尤其是針對在較短時間內大量並發用戶的訪問時,軟體的抗壓能力。但壓力測試往往是手工難以測試的,必須藉助自動化測試工具。常用的壓力測試有:Web測試、資料庫測試等。 資料庫在大多數軟體項目中是不可缺少的,對於它進行壓力測試是為了找出資料庫對象是否可以有效地承受來自多個用戶的並發訪問。這些對象主要是:索引、觸發器、存儲過程和鎖。通過對SQL語句和存儲過程的測試,自動化的壓力測試工具可以間接的反應資料庫對象是否需要優化。 這些自動化的測試工具很多,各有特點,基於Java的項目可以使用JMeter,.Net項目可以採用.Net集成開發環境中提供的測試方案。 7、結束語 總之,在應用系統的測試中,把資料庫應當作為獨立的系統來測試,這無疑會為應用軟體的質量增加可靠的保障,同時還必須結合應用軟體進行集成測試,只有二者有機結合起來,才能最大限度的發揮資料庫和應用軟體的功能。
⑼ 資料庫測試主要測試什麼內容
1、資料庫的基本概念,資料庫系統的構成。
2、數據模型概念和主要的數據模型5.軟體調試,測試方法、技術和用例。
6.軟體質量控制,軟體文檔。
7.軟體
⑽ 資料庫如何進行查詢,如何進行資料庫測試
對於今天測試方面的提高一直很模糊,但最近整理好了思路。今年重點還是在資料庫的測試方向上下手吧,因為我們公司的資料庫中數據准確性非常重要,希望能提高自己對這一方面的工作經驗吧。
前期一直進行資料庫的測試,大約3個月。也總結了一些測試經驗,拿出來與大家共享。
1、資料庫日誌查看測試法。這個方法是跟一個oracel DBA的老師學習的。呵呵。就是你在前台操作時,比如按一下新增按鈕。新增一條數據,這是觀察資料庫中的日誌,通過對日誌的查看來明確數據的流向。從而來測試數據的正確性。當然這種方法需要測試人員本人對oracle資料庫的日誌很熟悉,水平很高,對數據表結構也有大體的了解。目前我還沒有做到這一點,這是我今後的發展方向。
2、介面數據的測試方法。這個方法也是跟開發人員學習來的。當2個系統之間有介面時,介面傳輸中數據的正確性非常重要。這時候可以將系統1中與介面有關的數據提取出來形成臨時表;將系統2中與介面有關的數據提取出來形成臨時表。比對2個表的介面數據的一致性。通過這種方法可以發現介面數據是否一致。當然,直接在前台看2個系統的數據是否一致也是很好的方法之一。
3、數據測試的統計方法。這個方法可以同方法2組合使用,當一個系統試運行了一段時間後,可以統計系統一個月內或2個月內的數據,查看數據的正確性。因為由於數據流向的復雜性,導致我們測試數據正確性時很難能覆蓋到所有的情況。這時就可以採用統計法來測試。
4、對報表參數的整理測試法。對每個前台頁面需要呈現的或生成的參數,整理一個計算方法。即此參數與後台哪些表相關,是怎麼生成的。我們測試人員需要對前台呈現的每個參數都明白他的數據流向,但是有時候在文檔不起全的情況下,沒辦法明白整個的測試流程。所以需要我們自己進行每個參數的數據流向整理。
上面是總結的4條測試方法,可能還不齊全,希望大家一起來補充。還有一點是當頁面查詢沒有任何數據時,這時候一定要弄清楚為什麼沒有任何數據,是不是有bug才沒有數據的。好了,嘮叨這么多。希望大家多提建議吧。