測試類型
數據和資料庫完整性測試
數據與資料庫完整測試是指測試關係型資料庫完整性原則以及數據合理性測試。
資料庫完整性原則:
主碼完整性:主碼不能為空;
外碼完整性:外碼必須等於對應的主碼或者為空。
數據合理性指數據在資料庫中的類型,長度,索引等是否建的比較合理。
在項目名稱中,資料庫和資料庫進程應作為一個子系統來進行測試。在測試這些子系統時,不應將測試對象的用戶界面用作數據的接口。對於資料庫管理系統(DBMS),還需要進行深入的研究,以確定可以支持測試的工具和技術。
比如,有兩張表:部門和員工。部門中有部門編號,部門名稱,部門經理等欄位,主碼為部門編號;員工表中有員工編號,員工所屬部門編號,員工名稱,員工類型等欄位,主碼為員工編號,外碼為員工所屬部門編號,對應部門表。如果在某條部門記錄中部門編號或員工記錄員工編號為空,他就違反主碼完整性原則。如果某個員工所屬部門的編號為##,但是##在部門編號中確找不到,這就違反外碼完整性原則。
員工類型如下定義:0:職工,1:職員,2:實習生。但數據類型為Int,我們都知道Int占有4個位元組,如果定義成char(1).就比原來節約空間。
白盒測試
白盒測試是基於代碼的測試,測試人員通過閱讀程式代碼或者通過使用開發工具中的單步調試來判斷軟體的質量,一般白盒測試由項目經理在程式設計師開發中來實現。白盒測試分為動態白盒測試和靜態白盒測試
2.1靜態白盒測試
利用眼睛,瀏覽代碼,憑藉經驗,找出代碼中的錯誤或者代碼中不符合書寫規範的地方。比如,代碼規範中規定,函式必須為動賓結構。而白盒測試發現一個函式定義如下:
這是屬於不符合開發規範的錯誤。
有這樣一段代碼:
這段代碼交集為整個數軸,IF語句沒有必要
在循環體內沒有I的增加,bug產生。
2.2 動態白盒測試
利用開發工具中的調式工具進行測試。比如一段代碼有4個分支,輸入4組不同的測試數據使4組分支都可以走通而且結果必須正確。
看一段代碼
在調試中輸入I=-1,P1程式段通過, P2程式段未通過,屬於動態黑盒測試的缺陷
功能測試
功能測試指測試軟體各個功能模組是否正確,邏輯是否正確。
對測試對象的功能測試應側重於所有可直接追蹤到用例或業務功能和業務規則的測試需求。這種測試的目標是核實數據的接受、處理和檢索是否正確,以及業務規則的實施是否恰當。此類測試基於黑盒技術,該技術通過圖形用戶界面(GUI) 與應用程式進行互動,並對互動的輸出或結果進行分析,以此來核實應用程式及其內部進程。功能測試的主要參考為類似於功能說明書之類的文檔。
比如一個對電子商務系統,前台用戶瀏覽商品-放入購物車-進入結賬台,後台處理訂單,配貨,付款,發貨,這一系列流程必須正確無誤的走通,不能存在任何的錯誤。
UI測試
UI測試指測試用戶界面的風格是否滿足客戶要求,文字是否正確,頁面美工是否好看,文字,圖片組合是否完美,背景是否美觀,操作是否友好等等
用戶界面 (UI) 測試用於核實用戶與軟體之間的互動。UI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。另外,UI 測試還可確保 UI 中的對象按照預期的方式運行,並符合公司或行業的標準。包括用戶友好性,人性化,易操作性測試。UI測試比較主觀,與測試人員的喜好有關
比如:頁面基調顏色刺眼;用戶登入頁面比較難於找到,文字中出現錯別字,頁面圖片範圍太廣等都屬於UI測試中的缺陷,但是這些缺陷都不太嚴重。
性能測試
性能測試主要測試軟體測試的性能,包括負載測試,強度測試,資料庫容量測試,基準測試以及競爭測試
5.1負載測試
負載測試是一種性能測試指數據在超負荷環境中運行,程式是否能夠承擔。
在這種測試中,將使測試對象承擔不同的工作量,以評測和評估測試對象在不同工作量條件下的性能行為,以及持續正常運行的能力。負載測試的目標是確定並確保系統在超出最大預期工作量的情況下仍能正常運行。此外,負載測試還要評估性能特徵,例如,回響時間、事務處理速率和其他與時間相關的方面。
比如,在B/S結構中用戶並發量測試就是屬於負載測試的用戶,可以使用webload工具,模擬上百人客戶同時訪問網站,看系統回響時間,處理速度如何?
5.2強度測試
強度測試是一種性能測試,他在系統資源特別低的情況下軟體系統運行情況。這類測試往往可以書寫系統要求的軟硬體水平要求。
實施和執行此類測試的目的是找出因資源不足或資源爭用而導致的錯誤。如果記憶體或磁碟空間不足,測試對象就可能會表現出一些在正常條件下並不明顯的缺陷。而其他缺陷則可能由於爭用共享資源(如資料庫鎖或網路頻寬)而造成的。強度測試還可用於確定測試對象能夠處理的最大工作量。
比如:一個系統在記憶體366M下可以正常運行,但是降低到258M下不可以運行,告訴記憶體不足,這個系統對記憶體的要求就是366M。
5.3資料庫容量測試
資料庫容量測試指通過存儲過程往資料庫表中插入一定數量的數據,看看相關頁面是否能夠及時顯示數據。
資料庫容量測試使測試對象處理大量的數據,以確定是否達到了將使軟體發生故障的極限。容量測試還將確定測試對象在給定時間內能夠持續處理的最大負載或工作量。例如,如果測試對象正在為生成一份報表而處理一組資料庫記錄,那么容量測試就會使用一個大型的測試資料庫,檢驗該軟體是否正常運行並生成了正確的報表。做這種測試通常通過書寫存儲過程向資料庫某個表中插入一定數量的記錄,計算相關頁面的調用時間。
比如,在電子商務系統中,通過insert customer 往user表中插入10 000數據,看其是否可以正常顯示顧客信息列表頁面,如果要求達到最多可以處理100 000個客戶,但是顧客信息列表頁面不能夠在規定的時間內顯示出來,就需要調整程式中的SQL查詢語句;如果在規定的時間內顯示出來,可以將用戶數分別提高到20 000 , 50 000, 100 000進行測試。
5.4基準測試
基準測試與已知現有的系統進行比較,主要檢驗是否與類似的產品具有競爭性的一種測試。
如果你要開發一套財務系統軟體並且你已經獲得用友財務系統的性能等數據,你可以測試你這套系統,看看哪些地方比用友財務系統好,哪些地方差?以便改進自己的系統,也可為產品廣告提供數據。
5.5競爭測試
軟體競爭使用各種資源(數據紀錄,記憶體等),看他與其他相關係統對資源的爭奪能力。比如:一台機器上即安裝您的財務系統,又安裝用友財務系統。當CPU占有率下降後,看看是否能夠強過用友財務系統,而是自己的系統能夠正常運行?
安全性和訪問控制測試
安全性和訪問控制測試側重於安全性的兩個關鍵方面:
應用程式級別的安全性,包括對數據或業務功能的訪問
系統級別的安全性,包括對系統的登錄或遠程訪問。
6.1應用程式級別的安全性
可確保:在預期的安全性情況下,主角只能訪問特定的功能或用例,或者只能訪問有限的數據。例如,可能會允許所有人輸入數據,創建新賬戶,但只有管理員才能刪除這些數據或賬戶。如果具有數據級別的安全性,測試就可確保“用戶類型一”能夠看到所有客戶訊息(包括財務數據),而“用戶二”只能看見同一客戶的統計數據。
比如B/S系統,不通過登入頁面,直接輸入URL,看其是否能夠進入系統?
6.2系統級別的安全性
可確保只有具備系統訪問許可權的用戶才能訪問應用程式,而且只能通過相應的網關來訪問。
比如輸入管理員賬戶,檢查其密碼是否容易猜取,或者可以從資料庫中獲得?
故障轉移和恢複測試
故障轉移和恢複測試指當主機軟硬體發生災難時候,備份機器是否能夠正常啟動,使系統是否可以正常運行,這對於電信,銀行等領域的軟體是十分重要的。
故障轉移和恢複測試可確保測試對象能成功完成故障轉移,並能從導致意外數據損失或數據完整性破壞的各種硬體、軟體或網路故障中恢復。
故障轉移測試可確保:對於必須持續運行的系統,一旦發生故障,備用系統就將不失時機地“頂替”發生故障的系統,以避免丟失任何數據或事務。
恢複測試是一種對抗性的測試過程。在這種測試中,將把應用程式或系統置於極端的條件下(或者是模擬的極端條件下),以產生故障(例如設備輸入/輸出 (I/O) 故障或無效的資料庫指針和關健字)。然後調用恢復進程並監測和檢查應用程式和系統,核實應用程式或系統和數據已得到了正確的恢復。一定要注意主備定時備份
比如電信系統,突然主機程式發生當機,備份機器是否能夠啟動,使系統能夠正常運行,從而不影響用戶打電話?
配置測試
又叫兼容性測試。配置測試核實測試對象在不同的軟體和硬體配置中的運行情況。在大多數生產環境中,客戶機工作站、網路連線和資料庫伺服器的具體硬體規格會有所不同。客戶機工作站可能會安裝不同的軟體例如,應用程式、驅動程式等而且在任何時候,都可能運行許多不同的軟體組合,從而占用不同的資源。(如瀏覽器版本,作業系統版本等)
下面列出主要配置測試
8.1瀏覽器兼容性
測試軟體在不同產商的瀏覽器下是否能夠正確顯示與運行;
比如測試IE,Natscape瀏覽器下是否可以運行這套軟體?
8.2作業系統兼容性
測試軟體在不同作業系統下是否能夠正確顯示與運行;
比如測試WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以運行這套軟體?
8.3硬體兼容性
測試與硬體密切相關的軟體產品與其他硬體產品的兼容性,比如該軟體是少在並口設備中的,測試同時使用其他並口設備,系統是否可以正確使用.
比如在INTER,舒龍CPU晶片下系統是否能夠正常運行?
這樣的測試必須建立測試實驗室,在各種環境下進行測試。
安裝測試
安裝測試有兩個目的。第一個目的是確保該軟體在正常情況和異常情況的不同條件下: 例如,進行首次安裝、升級、完整的或自定義的安裝_都能進行安裝。異常情況包括磁碟空間不足、缺少目錄創建許可權等。第二個目的是核實軟體在安裝後可立即正常運行。這通常是指運行大量為功能測試製定的測試。
安裝測試包括測試安裝代碼以及安裝手冊。安裝手冊提供如何進行安裝,安裝代碼提供安裝一些程式能夠運行的基礎數據。
多語種測試
又稱本地化測試,是指為各個地方開發產品的測試,如英文版,中文版等等,包括程式是否能夠正常運行,界面是否符合當地習俗,快捷鍵是否正常起作用等等,特別測試在A語言環境下運行B語言軟體(比如在英文win98下試圖運行中文版的程式),出現現象是否正常。
本地化測試還要考慮:
當語言從A翻譯到B,字元長度變化是否影響頁面效果。比如中文軟體中有個按鍵叫“看廣告”,翻譯到英文版本中為 “View advertisement”可能影響頁面的美觀程度
要考慮同一單詞在各個國家的不同意思,比如football在英文中為足球,而美國人使用中可能理解為美式橄欖球。
要考慮各個國家的民族習慣,比如龍在美國被理解為邪惡的象徵,但翻譯到中國,中國人認為為吉祥的象徵。
文字測試
文字測試測試軟體中是否拼寫正確,是否易懂,不存在二義性,沒有語法錯誤;文字與內容是否有出入等等,包括圖片文字。
比如:“比如,請輸入正確的證件號碼!”何謂正確的證件號碼,證件可以為身份證,駕駛證,也可為軍官證,如果改為“請輸入正確的身份證號碼!”用戶就比較容易理解了。
解析度測試
測試在不同解析度下,界面的美觀程度,分為800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字型下測試。一個好的軟體要有一個極佳的解析度,而在其他解析度下也都能可以運行。
發布測試
主要在產品發布前對一些附帶產品,比如說明書,廣告稿等進行測試
13.1說明書測試
主要為語言檢查,功能檢查,圖片檢查
語言檢查:檢查說明書語言是否正確,用詞是否易於理解;
功能檢查:功能是否描述完全,或者描述了並沒有的功能等;
圖片檢查::檢查圖片是否正確
13.2宣傳材料測試
主要測試產品中的附帶的宣傳材料中的語言,描述功能,圖片
13.3幫助檔案測試
幫助檔案是否正確,易懂,是否人性化。最好能夠提供檢索功能。
13.4廣告用語
產品出公司前的廣告材料文字,功能,圖片,人性化的檢查
文檔審核測試
文檔審核測試目前越來越引起人們的重視,軟體質量不是檢查出來的,而是融進軟體開發中來。前置軟體測試發越來越受到重視。請看一個資料:
文檔審核測試主要包括需求文檔測試,設計文檔測試,為前置軟體測試測試中的一部分。
14.1需求文檔測試
主要測試需求中是否存在邏輯矛盾以及需求在技術上是否可以實現;
14.2設計文檔測試
測試設計是否符合全部需求以及設計是否合理。
總結
據美國軟體質量安全中心2000年對美國一百家知名的軟體廠商統計,得出這樣一個結論:軟體缺陷在開發前期發現比在開發後期發現資金,人力上節約90%;軟體缺陷在推向市場前發現比在推出後發現資金,人力上節約90%。所以說軟體的缺陷應該儘早發現。不是所有的軟體都要進行任何類型的軟體測試的,可以根據產品的具體情況進行組裝測試不同的類型。