A. 軟體開發資料庫如何進行測試
比如：數據冗餘，功能和性能方面存在的問題已經嚴重影響應用軟體的使用。軟體測試人員往往重視對軟體功能和編碼的測試，而忽略對軟體性能，特別是資料庫訪問並發測試。因為，他們固有的思想中認為資料庫設計存在問題對系統性能影響不大，或從根本上忽略了資料庫在軟體開發中的地位，直到出現了問題，才想到對資料庫的測試，但往往也是僅僅通過對編碼的測試工作中捎帶對資料庫進行一定的測試，這遠遠是不夠的。目前，中鐵網上訂票系統在大用戶同時在線訂票中系統頻頻癱瘓，就是最好的佐證。 所以，在應用軟體的測試工作中，應該將資料庫作為一個獨立的部分進行充分的測試，這樣才可以得到應用軟體所需要的性能優化的資料庫。那麼，應該對哪些內容進行測試，如何進行測試呢？ 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、結束語 總之，在應用系統的測試中，把資料庫應當作為獨立的系統來測試，這無疑會為應用軟體的質量增加可靠的保障，同時還必須結合應用軟體進行集成測試，只有二者有機結合起來，才能最大限度的發揮資料庫和應用軟體的功能。
B. 資料庫測試的具體測試方法
1. 分別測試記錄的新增、修改、刪除等操作，以驗證前台與後台數據的一致性為主。
2. 測試記錄的查找功能，檢查返回的數據是否正確，並測試相關功能。
3. 測試數據的不同顯示方式。
4. 測試有效和無效數據對資料庫的影響。完成標准：???? ??所有的資料庫訪問方法和進程都按照設計的方式運行，數據沒有遭到損壞。
C. 後台資料庫刪除了一個用戶,需要關注的測試點在哪裡
安全測試涵蓋的范圍很廣，在某種程度上你需要有比性能測試、自動化測試等更為廣泛的基礎知識。在這里我簡單給大家一個自學路線：
1. 掌握更多的軟體基本知識。例如http協議、http狀態碼、資料庫操作、中間件、伺服器、linux、python等基礎知識。
2. 學習了解安全漏洞的原理。各種注入、跨站、繞過等等黑客技術的原理和實現。
3. 學習安全漏洞的測試方法。基於原理，了解學習最簡單有效的安全漏洞測試方法，可以結合使用部分半自動化工具等。
4. 了解安全漏洞的防範知識。安全人員要知其然，還要知其所以然，不僅要知道如何去測，還要知道如何去改。教開發碼代碼，這才是你應該到達的境界。
5. 學會監控。更多時候不管是面對一個系統，還是一個蜜罐，你都要用監控的方式來查看「腳本小子」們到底在用什麼方式嘗試攻擊你的系統，從而採取最合理的方式去避免攻擊。
上面的自學路線說的比較寬泛，你可以閱讀安全測試自學路線(超鏈)來獲取更詳細的自學信息。當然除了自學外，也可以加入一些qq群等，與同行更多交流，互相學習。
D. 介面測試的測試點有哪些
介面測試是測試系統組件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
測試的策略：
介面測試也是屬於功能測試，所以跟我們以往的功能測試流程並沒有太大區別，測試流程依舊是：
評審測試介面文檔（需求文檔）
根據介面文檔編寫測試用例（用例編寫完全可以按照以往規則來編寫，例如等價類劃分，邊界值等設計方法）
執行測試，查看不同的參數請求，介面的返回的數據是否達到預期
介面的功能是否正確實現了
介面是否按照設計文檔中來實現（比如username參數寫為了user，那麼這就不符合，因為介面文檔在整個開發中都需要使用，所以介面實際的設計要與介面設計文檔中保持一致）
兼容性測試： 比如說今天介面進行了調整，但是前端沒有進行變更，這時候需要驗證新的介面是否滿足舊的調用方式
錯誤碼測試： 通用的錯誤碼與業務錯誤碼是否能夠清晰的說明調用問題，錯誤碼是否能夠盡可能的全的覆蓋所有的情況
返回值測試： 返回值除了內容需要是正確的，還需要類型也是正確的，保證調用方拿到這些參數能夠正確的解析
參數邊界值、等價類測試
json格式測試： 通常我們的介面一般設計的都是傳遞json串，那麼就需要去測試 如果傳遞非json的情況，這時候程序會不會正確的處理，返回相應的 error code
默認值測試： 很多情況一些非必填的參數會有默認值，比如說一個查詢的介面，參數count為返回查詢的結果數量， 默認為10，那麼就應該有一條case來測試，當然前置條件是資料庫裡面必須要存在這樣的數據超過10條。
是否有依賴業務，比如查看訂單，是需要用戶首先登錄的，所以肯定要保證登錄了或有相應的cookie
業務邏輯測試： 傳遞正確的參數，介面對資料庫進行查詢的操作，需要去驗證資料庫查詢是否正確，介面對資料庫進行 增刪改的操作，也需要看資料庫是否同步進行了這些操作
關鍵字參數：將參數寫為開發語言中的關鍵字
參數為空：比如去掉了username參數
多或少參數：多或者少參數的驗證，現在還不確定如果一個介面多了參數如果沒有報錯是否是合理的，或者是否需要優化，因為就目前開發給予的答案是，一般不對介面多了參數的處理
錯誤參數：比如將username參數寫為了user等看是否能返回相應的errorcode
關鍵字數據：將參數的值填為開發語言中的關鍵字
數據為空：將參數的額值填為空
長度不一致：因為資料庫中每個欄位都設置有欄位長度，填寫不符合的長度進行驗證
錯誤數據：就是將參數的值任意填寫，或填寫不存在的數值
異常類型測試： 比如count參數，這個參數的類型一定是可以轉換為int類型的，這時候我們需要測試如果傳的一些不可以 轉換為int類型值來測試代碼是否加入判斷
響應時間
吞吐量
並發用戶數
佔用內存，CPU等
敏感信息是否加密
必要參數是否後端也進行校驗（現在很多系統前後端架構是分離的，從安全層面來說，只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前端太容易了）， 需要後端同樣進行控制，在這種情況下就需要從介面層面進行驗證）
介面是否防惡意請求（SQL注入）
cookie：就是將header中的cookie修改或刪除後看是否能返回相應的errorcode
header：就是刪除或修改header中部分參數的值，看是否能返回相應的error code
唯一識別碼：刪除修改唯一識別碼測試
那麼設計測試用例時我們主要考慮如下幾個方面：
功能測試：
邏輯業務：
異常測試：
異常分為兩類，參數異常和數據異常
參數異常：
數據異常：
性能測試：
安全性測試：
E. 資料庫如何進行查詢，如何進行資料庫測試
對於今天測試方面的提高一直很模糊，但最近整理好了思路。今年重點還是在資料庫的測試方向上下手吧，因為我們公司的資料庫中數據准確性非常重要，希望能提高自己對這一方面的工作經驗吧。
前期一直進行資料庫的測試，大約3個月。也總結了一些測試經驗，拿出來與大家共享。
1、資料庫日誌查看測試法。這個方法是跟一個oracel DBA的老師學習的。呵呵。就是你在前台操作時，比如按一下新增按鈕。新增一條數據，這是觀察資料庫中的日誌，通過對日誌的查看來明確數據的流向。從而來測試數據的正確性。當然這種方法需要測試人員本人對oracle資料庫的日誌很熟悉，水平很高，對數據表結構也有大體的了解。目前我還沒有做到這一點，這是我今後的發展方向。
2、介面數據的測試方法。這個方法也是跟開發人員學習來的。當2個系統之間有介面時，介面傳輸中數據的正確性非常重要。這時候可以將系統1中與介面有關的數據提取出來形成臨時表；將系統2中與介面有關的數據提取出來形成臨時表。比對2個表的介面數據的一致性。通過這種方法可以發現介面數據是否一致。當然，直接在前台看2個系統的數據是否一致也是很好的方法之一。
3、數據測試的統計方法。這個方法可以同方法2組合使用，當一個系統試運行了一段時間後，可以統計系統一個月內或2個月內的數據，查看數據的正確性。因為由於數據流向的復雜性，導致我們測試數據正確性時很難能覆蓋到所有的情況。這時就可以採用統計法來測試。
4、對報表參數的整理測試法。對每個前台頁面需要呈現的或生成的參數，整理一個計算方法。即此參數與後台哪些表相關，是怎麼生成的。我們測試人員需要對前台呈現的每個參數都明白他的數據流向，但是有時候在文檔不起全的情況下，沒辦法明白整個的測試流程。所以需要我們自己進行每個參數的數據流向整理。
上面是總結的4條測試方法，可能還不齊全，希望大家一起來補充。還有一點是當頁面查詢沒有任何數據時，這時候一定要弄清楚為什麼沒有任何數據，是不是有bug才沒有數據的。好了，嘮叨這么多。希望大家多提建議吧。
F. 剛接觸資料庫，一般企業資料庫中的生產庫，查詢庫以及測試庫有什麼區別
》測試DB：測試程序正確性用的DB。
-程序正式上線前，需要嚴格測試，避免因bug造成生產系統出問題或者生產數據錯誤。因此需要使用「測試DB」來測試你的系統。
-存貯了模擬數據（有時用生產DB的數據恢復而來，保證數據的真實性與數據量）
》生產DB：正式使用的DB。
-存貯了大量的正式數據，
-有很多用戶並發訪問。
》查詢DB：通常用作數據查詢、統計，只讀。
- 由於「查詢」通常會訪問大量數據，為了減輕生產DB的壓力，將「查詢、統計」功能分離出來，針對本庫進行
-通常是生產DB的鏡像，
-或者是最近時間點生產DB的一個備份（如當日凌晨的 -- 此時統計結果不包含當日新產生的數據）
G. MySql資料庫測試
去mysql.com下載相應的版本。
然後導入數據，自己測試就行。
H. 資料庫測試
新建一個資料庫，可以是ACCESS資料庫。
按上述每行的內容，建立數據表，基本欄位都在每行內容中。
對各表輸入數據。
建立各表之間的索引等，關鍵在於SQL結構化查詢語言的編寫。
使用一定的編程軟體操控資料庫表。
I. 資料庫知識在軟體測試過程中有哪些方面作用
回答這個問題我想可能得考慮多個方面
資料庫本身作用是什麼？我想，簡單的說就是：存儲、管理數據，為前台程序提供支持。
測試掌握資料庫可以：
1、方便使用測試管理軟體，因為管理軟體是要以數據做支撐的，必然有自己的資料庫，你要懂基本的維護、簡單的備份還原操作，同時，最好能簡單了解數據調用。
2、軟體測試工作本身，是做什麼？測試軟體對吧？那在你測試軟體的時候，絕大多數的軟體都是有其資料庫的，光是在前台點點、操作一下，那是最最基礎的軟體測試；深入點測試，你必須把前台操作和後台資料庫數據變動關聯起來考慮，這樣才能做到功能測試的全面性要求。
3、軟體測試種類有哪些？
功能、性能、壓力、驗收等等
在做性能、壓力測試時，必須對資料庫性能分析等有較為深入的了解；
在做驗收測試時，必須會搭建用戶環境、恢復備份資料庫。
白盒、灰盒、黑盒測試
白盒即知曉所有代碼路徑，這時，對資料庫相關語句必須非常了解，才能寫出有效測試用例並執行。當然，一般公司白盒測試都是程序員自己完成了。
自動化測試、手工測試
自動化測試時，你必須編寫測試腳本，使用測試工具，而腳本、工具都和資料庫息息相關
4、測試支撐，測試工程師必須要學會測試環境的搭建，而環境中一般都包含資料庫；
5、其他，為了自己的職業發展，更要多了解、深入學習資料庫知識！！！
總之，資料庫對測試，很重要！
J. 資料庫中視圖怎麼進行軟體測試
從測試過程的角度來說我們也可以把資料庫測試分為：
系統測試
傳統軟體系統測試的測試重點是需求覆蓋，而對於我們的資料庫測試同樣也需要對需求覆蓋進行保證。那麼資料庫在初期設計中也需要對這個進行分析，測試。例如存儲過程，視圖，觸發器，約束，規則等我們都需要進行需求的驗證確保這些功能設計是符合需求的.另一方面我們需要確認資料庫設計文檔和最終的資料庫相同，當設計文檔變化時我們同樣要驗證改修改是否落實到資料庫上。
這個階段我們的測試主要通過資料庫設計評審來實現。
集成測試
集成測試是主要針對介面進行的測試工作，從資料庫的角度來說和普通測試稍微有些區別對於資料庫測試來說，需要考慮的是數據項的修改操作、數據項的增加操作、數據項的刪除操作、數據表增加滿、數據表刪除空、刪除空表中的記錄、數據表的並發操作、針對存儲過程的介面測試、結合業務邏輯做關聯表的介面測試。
同樣我們需要對這些介面考慮採用等價類、邊界值、錯誤猜測等方法進行測試。
單元測試
單元測試側重於邏輯覆蓋，相對對於復雜的代碼來說，資料庫開發的單元測試相對簡單些，可以通過語句覆蓋和走讀的方式完成。
系統測試相對來說比較困難，這要求有很高的資料庫設計能力和豐富的資料庫測試經驗。而集成測試和單元測試就相對簡單了。
而我們也可以從測試關注點的角度對資料庫進行分類：
功能測試
對資料庫功能的測試我們可以依賴與工具進行：
DBunit：一款開源的資料庫功能測試框架，可以使用類似與Junit的方式對資料庫的基本操作進行白盒的單元測試，對輸入輸出進行校驗。
QTP：大名鼎鼎的自動測試工具，通過對對象的捕捉識別，我們可以通過QTP來模擬用戶的操作流程，通過其中的校驗方法或者結合資料庫後台的監控對整個資料庫中的數據進行測試。個人覺得比較偏向灰盒。
DataFactory：一款優秀的資料庫數據自動生成工具，通過它你可以輕松的生成任意結構資料庫，對資料庫進行填充，幫助你生成所需要的大量數據從而驗證我們資料庫中的功能是否正確。這是屬於黑盒測試。
資料庫性能雖然我們的硬體最近幾年進步很快，但是我們需要處理的數據以更快的速度在增加。幾億條記錄的表格在現在是司空見慣的，如此龐大的數據量在大量並發連接操作時，我們不能像以前一樣隨意的使用查詢，連接查詢，嵌套查詢，視圖，這些操作如果不當會給系統帶來非常巨大的壓力，嚴重影響系統性能。
性能優化分4部分：
1、物理存儲方面
2、邏輯設計方面
3、資料庫的參數調整
4、SQL語句優化
性能測試：
我們如何對性能方面進行測試呢，業界也提供了很多工具通過資料庫系統的SQL語句分析工具，我們可以分析得到資料庫語句執行的瓶頸，從而優化SQL語句。
Loadrunner：這個不用多說，我們可以通過對協議的編程來對資料庫做壓力測試。
Swingbench：(這是一個重量級別的feature，類似LR，而且非常強大，只不過專門針對oracle而已)資料庫廠商也意識到這點，例如oracle11g已經提供了real applicationtest，提供資料庫性能測試，分析系統的應用瓶頸。
還有很多第三方公司開發了SQL語句優化工具來幫助你自動的進行語句優化工作從而提高執行效率。
安全測試：
軟體日益復雜，而數據又成為了系統中重中之重的核心，從以往對系統的破壞現在更傾向於對數據的獲取和破壞。而資料庫的安全被提到了最前端自從SQL 注入攻擊被發現，冒失萬無一失的資料庫一下從後台變為了前台，而一旦資料庫被攻破，整個系統也會暴露在黑客的手下，通過資料庫強大的存儲過程，黑客可以輕松的獲得整個系統的許可權。而SQL的注入看似簡單缺很難防範，對於安全測試來說，如何防範系統被注入是測試的難點。
業界也有相關的資料庫注入檢測工具，來幫助用戶對自身系統進行安全檢測。
對於這點來說業界也有標准，例如ISO IEC 21827，也叫做SSE CMM 3.0，是CMM和ISO的集成的產物，專門針對系統安全領域的另外一方面，資料庫的健壯性，容錯性和恢復能力也是我們測試的要點
我們也可以發現功能測試，性能測試，安全測試，是一個由簡到繁的過程，也是資料庫測試人員需要逐步掌握的技能，這也是以後公司對資料庫測試人員的要求。