資料庫和資料庫流程應該作為獨立的子系統來進行測試。這項測試應該在不以測試目標的使用者介面作為資料介面的情況下,測試子系統。另外,您還需要研究資料庫管理系統 (DBMS),以找出可用來支援下表所識別之測試的工具和技術。
技術目標:
|
在不用使用者介面的情況下,操作資料庫存取方法和流程,以便觀察和記載無法正確運作的目標行為或資料毀損。
|
技術:
|
呼叫每個資料庫存取方法和流程,在每個這些方法和流程中,加入有效和無效的資料或資料要求。
請視察資料庫,確定已依照預期移入資料,且所有資料庫事件都已適當出現,或檢視傳回的資料,確定已為了正確原因而擷取了正確的資料。
|
Oracle:
|
概述這項技術可用來精確觀察測試結果的一或多個策略。Oracle 會將可「用來進行觀察的方法」及「指示可能成功或失敗的特定輸出結果之特性」這兩者的元素結合起來。理想上,Oracle
會自我驗證,讓自動化測試能夠開始評量測試的成敗,不過,請小心,您要緩和自動化的結果判斷與生俱來的風險。
|
必要的工具:
|
這項技術需要下列工具:
測試 Script 自動化工具
基本配置繪圖器和修復器
備份及回復工具
安裝監視工具(登錄、硬碟、CPU、記憶體等)
資料庫 SQL 公用程式和工具
資料產生工具
|
成功準則:
|
這項技術支援測試所有主要資料庫存取方法和流程。
|
特殊考量:
|
測試可能會需要 DBMS 開發環境或驅動程式,以便進入資料庫,或直接在資料庫中修改資料。
流程應該以手動方式來呼叫。
應該利用小資料庫或最小資料庫(含有限記錄數目)來增加任何不可接受之事件的可見度。
|
測試目標的功能測試,焦點應該放在可直接追蹤到使用案例或商業功能和商業規則之測試的任何需求。這些測試的目標是驗證適當的資料驗收、處理和擷取,以及商業規則的適當實作。這類型的測試是以黑盒技術為基礎;也就是通過圖形使用者介面 (GUI)
與應用程式互動並分析輸出或結果來驗證應用程式及其內部流程。下表識別建議每個應用程式採用的測試概要。
技術目標:
|
操作測試目標功能,其中包括導覽、資料輸入、處理及擷取,以觀察和記載目標行為。
|
技術:
|
利用有效和無效的資料來操作每個使用案例情境的個別使用案例流程或功能和特性,以確認:
當使用有效的資料時,出現預期的結果
當使用無效的資料,顯示適當的錯誤或警告訊息
適當套用每個商業規則
|
Oracle:
|
概述這項技術可用來精確觀察測試結果的一或多個策略。Oracle 會將可「用來進行觀察的方法」及「指示可能成功或失敗的特定輸出結果之特性」這兩者的元素結合起來。理想上,Oracle
會自我驗證,讓自動化測試能夠開始評量測試的成敗,不過,請小心,您要緩和自動化的結果判斷與生俱來的風險。
|
必要的工具:
|
這項技術需要下列工具:
測試 Script 自動化工具
基本配置繪圖器和修復器
備份及回復工具
安裝監視工具(登錄、硬碟、CPU、記憶體等)
資料產生工具
|
成功準則:
|
這項技術支援下列各項測試:
所有主要使用案例情境
所有主要特性
|
特殊考量:
|
識別或說明影響功能測試之實作和執行的項目或問題(內部或外部)。
|
商業循環測試應該在一段時間內模擬在 <Project Name> 上執行的作業。時段應該明確識別出來,如一年,應該執行一年的時段內會發生的交易和作業。其中包括所有每日、每週和每月循環,以及對日期敏感的事件,如備忘錄。
技術目標:
|
根據必要的商業模型和排程來操作測試目標和背景處理流程,以觀察和記載目標行為。
|
技術:
|
測試會執行下列動作來模擬多個商業循環:
將修改或加強測試目標功能測試所用的測試來增加執行每個功能的次數,以在指定時段模擬幾個不同的使用者。
將利用有效或無效的日期或時段來執行所有對時間或日期敏感的功能。
將在適當的時間執行或啟動依週期性的排程而發生的所有功能。
測試將包括利用有效和無效的資料來驗證下列各項:
當使用有效的資料時,出現預期的結果。
當使用無效的資料,顯示適當的錯誤或警告訊息。
適當套用每個商業規則。
|
Oracle:
|
概述這項技術可用來精確觀察測試結果的一或多個策略。Oracle 會將可「用來進行觀察的方法」及「指示可能成功或失敗的特定輸出結果之特性」這兩者的元素結合起來。理想上,Oracle
會自我驗證,讓自動化測試能夠開始評量測試的成敗,不過,請小心,您要緩和自動化的結果判斷與生俱來的風險。
|
必要的工具:
|
這項技術需要下列工具:
測試 Script 自動化工具
基本配置繪圖器和修復器
備份及回復工具
資料產生工具
|
成功準則:
|
這項技術支援測試所有關鍵的商業循環。
|
特殊考量:
|
系統日期和事件可能需要特殊支援作業。
需要商業模型來識別適當的測試需求和程序。
|
使用者介面 (UI) 測試用來驗證使用者與軟體的互動。UI 測試的目標是確保 UI 可供使用者適當地存取和導覽測試目標的功能。另外,UI 測試也可確保 UI 內的物件能夠依照預期來運作,且符合公司或業界標準。
技術目標:
|
操作下列各項來觀察和記載符合標準的情況和目標行為:
導覽反映商業功能和需求的測試目標,其中包括視窗對視窗、欄位對欄位,以及使用存取方法(Tab 鍵、滑鼠移動、快速鍵)。
可以操作視窗物件和特性,如功能表、大小、位置、狀態和焦點。
|
技術:
|
建立或修改每個視窗的測試來驗證每個應用程式視窗和物件的適當導覽和物件狀態。
|
Oracle:
|
概述這項技術可用來精確觀察測試結果的一或多個策略。Oracle 會將可「用來進行觀察的方法」及「指示可能成功或失敗的特定輸出結果之特性」這兩者的元素結合起來。理想上,Oracle
會自我驗證,讓自動化測試能夠開始評量測試的成敗,不過,請小心,您要緩和自動化的結果判斷與生俱來的風險。
|
必要的工具:
|
這項技術需要測試 Script 自動化工具。
|
成功準則:
|
這項技術支援測試使用者將廣泛使用的每個主要畫面或視窗。
|
特殊考量:
|
自訂物件和協力廠商物件的內容,並非全部都可以存取。
|
效能評估是一項效能測試,在這項測試中,會測量和評估回應時間、交易率及其他對時間敏感的需求。效能評估的目標是驗證已達成效能需求。效能評估的實作和執行是要將測試目標的效能行為當作一個條件(如工作量或硬體配置)函數來概況和調整。
附註:下表中的交易是指「邏輯商業交易」。這些交易定義成系統參與者預計將利用測試目標來執行的特定使用案例,如新增或修改給定的合約。
技術目標:
|
在下列條件之下,操作指定功能交易或商業功能的行為,以觀察和記載目標行為及應用程式效能資料:
正常預期工作量
預期最糟情況的工作量
|
技術:
|
使用專為了功能或商業循環測試而開發的測試程序。
修改資料檔案來增加交易或 Script 的數目,以增加每次交易所發生的反覆次數。
Script 應該在單一機器上執行(最佳情況是以單一使用者、單一交易為基準),且應該針對多個用戶端來重複(虛擬或實際,請參閱下面的「特殊考量」)。
|
Oracle:
|
概述這項技術可用來精確觀察測試結果的一或多個策略。Oracle 會將可「用來進行觀察的方法」及「指示可能成功或失敗的特定輸出結果之特性」這兩者的元素結合起來。理想上,Oracle
會自我驗證,讓自動化測試能夠開始評量測試的成敗,不過,請小心,您要緩和自動化的結果判斷與生俱來的風險。
|
必要的工具:
|
這項技術需要下列工具:
測試 Script 自動化工具
應用程式效能評估工具,如 Rational Quantify
安裝監視工具(暫存器、硬碟、CPU、記憶體等)
資源限制工具;如 Canned Heat
|
成功準則:
|
這項技術支援下列各項測試:
單一交易或單一使用者:成功模擬交易 Script,不因測試實作問題而有任何失敗。
多項交易或多位使用者:成功模擬工作量,不因測試實作問題而有任何失敗。
|
特殊考量:
|
綜合性的效能測試包括含有伺服器的背景工作量。
您可以利用許多方法來執行這項測試,其中包括:
直接「驅動交易」使它進入伺服器,通常是採用結構化查詢語言 (SQL) 呼叫的形式。
建立「虛擬」使用者負荷來模擬許多用戶端,通常會有數百個。遠端終端機模擬工具用來達成這個負荷量。這項技術也可用來載入網路的「資料流量」。
使用多個實體用戶端,每個用戶端都執行測試 Script,以在系統上施加負荷。
效能測試應該在專用機器或專用時段執行。如此便有完整控制,能夠進行精確測量。
效能測試所用的資料庫應該是實際的大小或比例相當。
|
負荷測試也是一項效能測試,它讓測試目標接受各種工作量的支配來測量和評估測試目標在這些不同工作量之下繼續適當運作的效能行為和能力。負荷測試的目標是判斷和確保在超出預期的最大工作量時,系統仍能夠適當運作。另外,負荷測試還會評估各種效能特性,如回應時間、交易率和其他對時間敏感的問題。
附註:下表中的交易是指「邏輯商業交易」。這些交易定義成系統使用者預計將利用應用程式來執行的特定功能,如新增或修改給定的合約。
技術目標:
|
在各種工作量條件之下,操作指定交易或商業案例來觀察和記載目標行為和系統效能資料。
|
技術:
|
利用專為了功能或商業循環測試而開發的交易測試 Script 來作為基礎,但請記得移除不必要的互動和延遲。
修改資料檔案來增加交易的數目,或修改測試來增加每項交易的發生次數。
工作量應該包括例如每日、每週和每月的尖峰負荷。
工作量應該代表平均值和尖峰負荷。
工作量應該代表瞬間尖峰和持續尖峰。
工作量應該在不同測試環境配置之下執行。
|
Oracle:
|
概述這項技術可用來精確觀察測試結果的一或多個策略。Oracle 會將可「用來進行觀察的方法」及「指示可能成功或失敗的特定輸出結果之特性」這兩者的元素結合起來。理想上,Oracle
會自我驗證,讓自動化測試能夠開始評量測試的成敗,不過,請小心,您要緩和自動化的結果判斷與生俱來的風險。
|
必要的工具:
|
這項技術需要下列工具:
測試 Script 自動化工具
交易負荷排程和控制工具
安裝監視工具(登錄、硬碟、CPU、記憶體等)
資源限制工具;如 Canned Heat
資料產生工具
|
成功準則:
|
這項技術支援「工作量模擬」測試,它是不因測試實作問題而有任何失敗的成功模擬工作量。
|
特殊考量:
|
負荷測試應該在專用機器或專用時段執行。如此便有完整控制,能夠進行精確測量。
負荷測試所用的資料庫應該是實際的大小或規模相當。
|
壓力測試是為了瞭解系統會如何因為界限條件或在預期容忍範圍之外而失敗,因而實作和執行的一種效能測試類型。這通常包括低度資源或資源競爭。低度資源狀況顯示在正常狀況下並不明顯的測試目標失敗情況。其他問題也可能來自共用資源的競爭,如資料庫鎖定或網路頻寬,不過,這些測試有部分通常是在功能和負荷測試之下進行。
附註:下表所參照的交易是指邏輯商業交易。
技術目標:
|
在下列壓力條件之下操作測試目標功能,以觀察和記載目標行為,這個目標行為會識別及說明系統無法繼續正常運作的狀況:
伺服器的可用記憶體很少或沒有(RAM 和持續性儲存庫空間)
連接或模擬實際的最大用戶端數量,或具備用戶端功能的最大實體數量
多位使用者針對相同資料或帳戶來執行相同交易
「超載」交易量或混合交易(請參閱上面的「效能評估」)
|
技術:
|
請使用專為了效能評估或負荷測試而開發的測試。
如果要測試有限的資源,應該用單一機器來執行測試,伺服器的 RAM 和持續性儲存庫空間應該減少或受到限制。
對於其餘的壓力測試,您應該使用多個用戶端,讓它們執行相同或互補的測試,以產生最糟狀況下的交易數量或混合交易。
|
Oracle:
|
概述這項技術可用來精確觀察測試結果的一或多個策略。Oracle 會將可「用來進行觀察的方法」及「指示可能成功或失敗的特定輸出結果之特性」這兩者的元素結合起來。理想上,Oracle
會自我驗證,讓自動化測試能夠開始評量測試的成敗,不過,請小心,您要緩和自動化的結果判斷與生俱來的風險。
|
必要的工具:
|
這項技術需要下列工具:
測試 Script 自動化工具
交易負荷排程和控制工具
安裝監視工具(暫存器、硬碟、CPU、記憶體等)
資源限制工具;如 Canned Heat
資料產生工具
|
成功準則:
|
這項技術支援「壓力模擬」測試。您可以在一或多個定義為壓力狀況的條件下來成功模擬系統,並在模擬這個狀況期間或之後,擷取所產生之系統狀態的觀察結果。
|
特殊考量:
|
形成網路壓力可能需要利用網路工具,將訊息和封包載入網路中。
這時應該暫時削減系統所用的持續性儲存庫來限制資料庫的成長空間。
請使同時存取相同記錄或資料帳戶的用戶端同步作業。
|
容量測試會使測試目標接受大量資料的支配,以判斷是否會到達限制,造成軟體的失敗。容量測試也會識別測試目標在給定期間所能處理的連續最大負荷量。比方說,如果測試目標在處理一組資料庫記錄來產生一份報表,容量測試便會使用大的測試資料庫,且會檢查軟體行為是否正常並產生正確的報表。
技術目標:
|
在下列高容量情境之下操作測試目標功能,以觀察和記載目標行為:
連接或模擬最大用戶端數量(實際或具備這項功能的實體),且這些用戶端都長時間執行相同的最糟情況(效能)的商業功能。
已達到資料庫大小上限(實際上或比例上),且同時執行多項查詢或報告交易。
|
技術:
|
請使用專為了效能評估或負荷測試而開發的測試。
您應該使用多個用戶端,讓它們長時間執行相同或互補的測試,以產生最糟狀況下的交易數量或混合交易。
建立資料庫大小上限(實際、比例或填入代表資料),且利用多個用戶端來長時間同時執行查詢和報告交易(請參閱交易測試)。
|
Oracle:
|
概述這項技術可用來精確觀察測試結果的一或多個策略。Oracle 會將可「用來進行觀察的方法」及「指示可能成功或失敗的特定輸出結果之特性」這兩者的元素結合起來。理想上,Oracle
會自我驗證,讓自動化測試能夠開始評量測試的成敗,不過,請小心,您要緩和自動化的結果判斷與生俱來的風險。
|
必要的工具:
|
這項技術需要下列工具:
測試 Script 自動化工具
交易負荷排程和控制工具
安裝監視工具(暫存器、硬碟、CPU、記憶體等)
資源限制工具;如 Canned Heat
資料產生工具
|
成功準則:
|
這項技術支援「容量模擬」測試。可以在容量之下順利模擬大量使用者、資料、交易或系統的其他方面,且可以擷取容量測試期間對於系統狀態變更的觀察。
|
特殊考量:
|
哪個時段算是如上所述可接受高容量狀況的時間?
|
安全和存取控制測試焦點在兩個主要的安全區域:
應用程式層次安全,其中包括存取資料或商業功能
系統層次安全,其中包括登入系統或從遠端存取系統
以您想要的安全為基礎,應用程式層次安全可確保將參與者限制在特定功能或使用案例,或將它們限制在它們能夠取得的資料。例如,每個人都能輸入資料和建立新帳戶,但只有管理者能夠刪除它們。如果有資料層次的安全,測試可確保「使用者類型一」可以見到所有客戶資訊,其中包括財務資料,不過,「使用者類型二」只能見到相同用戶端的人口統計學資料。
系統層次的安全可確保只有獲授權存取系統的使用者能夠存取應用程式,且只能透過適當的閘道來存取。
技術目標:
|
在下列狀況之下操作測試目標來觀察和記載目標行為:
應用程式層次安全:參與者只能存取它們的使用者類型擁有許可權的功能或資料。
系統層次安全:參與者必須有權存取系統和應用程式,才能存取它們。
|
技術:
|
應用程式層次安全:請識別和列出每個使用者類型及各個類型有許可權的 功能或資料。
建立每個使用者類型專用的交易來建立各使用者類型的測試及驗證每個項許可權。
修改使用者類型,重新執行相同使用者的測試。在每個案例中,請確認能夠正確取得或拒絕其他功能或資料。
系統層次存取:請參閱下面的「特殊考量」。
|
Oracle:
|
概述這項技術可用來精確觀察測試結果的一或多個策略。Oracle 會將可「用來進行觀察的方法」及「指示可能成功或失敗的特定輸出結果之特性」這兩者的元素結合起來。理想上,Oracle
會自我驗證,讓自動化測試能夠開始評量測試的成敗,不過,請小心,您要緩和自動化的結果判斷與生俱來的風險。
|
必要的工具:
|
這項技術需要下列工具:
測試 Script 自動化工具
「駭客」安全漏洞和探測工具
OS 安全管理工具
|
成功準則:
|
這項技術支援針對每個已知的參與者類型來測試安全設定影響所及的適當功能或資料。
|
特殊考量:
|
系統的存取必須協同適當的網路或系統管理者來檢視或討論。這項測試不一定必要,因為它可能是網路或系統管理功能。
|
失效接手和回復測試可確保測試目標能夠成功地失效接手,以及從各種硬體、軟體或網路故障回復,且不會過度失去資料或資料完整性。
對於必須保持執行中的系統,失效接手測試可確保出現失效接手狀況時,替代或備份系統能夠適當地「接管」失敗的系統,且不會造成資料或交易的損失。
回復測試是一種對抗性測試流程,它使應用程式或系統暴露在極端狀況或模擬狀況下來造成失敗,例如,裝置輸入/輸出 (I/O) 失敗或資料庫指標和索引鍵無效等。這時會呼叫回復流程並監視和視察應用程式或系統,以確認適當回復了應用程式、系統或資料。
技術目標:
|
模擬失敗狀況,練習使資料庫、應用程式和系統還原到適當已知狀態的回復流程(手動和自動)。測試包括下列各類狀況,以便在回復之後觀察和記載行為:
用戶端電源中斷
伺服器電源中斷
網路伺服器通訊中斷
DASD(直接存取儲存裝置)和 DASD 控制器岔斷、通訊或電源中斷
不完整的循環(資料過濾流程岔斷、資料同步流程岔斷)
資料庫指標或索引鍵無效
資料庫中的資料元素無效或毀損
|
技術:
|
已為了功能和商業循環測試而建立好的測試,可用來作為建立交易序列的基礎,以便支援失效接手和回復測試,主要是定義要執行的測試來測試回復是否成功。
用戶端電源中斷:PC 關閉電源。
伺服器電源中斷:模擬或起始伺服器關閉電源的程序。
網路伺服器中斷:模擬或起始網路通訊中斷(實際切斷通訊線路或關閉網路伺服器或路由器的電源)。
DASD 和 DASD 控制器岔斷、通訊或電源中斷:模擬或實際刪除與一或多個 DASD 和 DASD 控制器的通訊。
在達成上述狀況或模擬狀況之後,便應該執行其他交易,到了這個第二測試點狀態時,應該呼叫回復程序。
不完整循環的測試會依照上面所說明來使用相同的技術,不過,資料庫流程本身應該捨棄或提早終止。
測試下列狀況需要達到已知的資料庫狀態。
您應該在資料庫內,直接以手動方式(用資料庫工具)來毀損若干資料庫欄位、指標和索引鍵。其他交易應該利用「應用程式功能」和「商業循環測試」中的測試來執行,且應該執行完整的循環。
|
Oracle:
|
概述這項技術可用來精確觀察測試結果的一或多個策略。Oracle 會將可「用來進行觀察的方法」及「指示可能成功或失敗的特定輸出結果之特性」這兩者的元素結合起來。理想上,Oracle
會自我驗證,讓自動化測試能夠開始評量測試的成敗,不過,請小心,您要緩和自動化的結果判斷與生俱來的風險。
|
必要的工具:
|
這項技術需要下列工具:
基本配置繪圖器和修復器
安裝監視工具(暫存器、硬碟、CPU、記憶體等)
備份及回復工具
|
成功準則:
|
這項技術支援下列各項測試:
多種模擬災難之一,其中包括應用程式、資料庫和系統的一或多個組合。
一或多項模擬的回復,以返回已知的所需狀態,其中包括應用程式、資料庫和系統的一或多個組合。
|
特殊考量:
|
回復測試的侵害性很強。切斷纜線的程序(模擬電源或通訊中斷)不一定適當或可行。您可能需要替代方法,例如診斷軟體工具。
需要系統(或電腦作業)、資料庫和網路群組的資源。
這些測試應該在幾小時之後執行,或在隔離的機器中執行。
|
配置測試用來驗證測試目標在不同軟硬體配置中的作業。在大部分正式作業環境中,用戶端工作站、網路連線和資料庫伺服器的特定硬體規格各不相同。用戶端工作站可能會載入不同的軟體(如應用程式、驅動程式等),隨時都可能有不同的組合在主動式,使用著不同的資源。
技術目標:
|
在所需軟硬體配置上操作測試目標來觀察和記載不同配置下的目標行為,以及識別配置狀態的變更。
|
技術:
|
使用功能測試 Script。
在測試之中,或在測試之前,開啟和關閉各種非測試目標相關軟體,如 Microsoft® Excel® 和 Microsoft® Word® 應用程式。
執行選取的交易來模擬與測試目標和非測試目標軟體互動的參與者。
重複上述流程,將用戶端工作站可用的傳統記憶體減到最少。
|
Oracle:
|
概述這項技術可用來精確觀察測試結果的一或多個策略。Oracle 會將可「用來進行觀察的方法」及「指示可能成功或失敗的特定輸出結果之特性」這兩者的元素結合起來。理想上,Oracle
會自我驗證,讓自動化測試能夠開始評量測試的成敗,不過,請小心,您要緩和自動化的結果判斷與生俱來的風險。
|
必要的工具:
|
這項技術需要下列工具:
基本配置繪圖器和修復器
安裝監視工具(登錄、硬碟、CPU、記憶體等)
|
成功準則:
|
這項技術支援測試「在預期的支援部署環境中執行之目標測試項目」的一或多項組合。
|
特殊考量:
|
需要、能夠取得以及在桌面上能夠存取哪個非測試目標軟體?
通常會使用哪些應用程式?
應用程式在執行哪些資料;例如,Excel 開啟了大型試算表,或 Word 開啟了 100 頁的文件?
這項測試的文件說明也必須包括整個系統的網路軟體、網路伺服器、資料庫等等。
|
安裝測試有兩個目的。首先是確保在正常和異常狀況下,能夠在不同條件下安裝軟體(如新的安裝、升級,以及完整或自訂安裝)。異常狀況包括磁碟空間不足、沒有建立目錄的專用權等。其次是確認安裝好軟體之後,軟體能夠正確運作。這通常表示執行許多專為了功能測試而開發的測試。
技術目標:
|
在下列條件下操作在各個必要的硬體配置上安裝測試目標的作業,以觀察和記載安裝行為和配置狀態的變更:
新的安裝:新機器,先前不曾以 <Project Name> 來進行安裝
更新:先前安裝了 <Project Name> 相同版本的機器
更新:先前安裝了 <Project Name> 舊版本的機器
|
技術:
|
開發自動或手動 Script 來驗證目標機器的狀況。
新:不曾安裝 <project Name>
已安裝相同版本或舊版的 <project Name>
啟動或執行安裝。
利用預定的測試 Script 子集來執行交易。
|
Oracle:
|
概述這項技術可用來精確觀察測試結果的一或多個策略。Oracle 會將可「用來進行觀察的方法」及「指示可能成功或失敗的特定輸出結果之特性」這兩者的元素結合起來。理想上,Oracle
會自我驗證,讓自動化測試能夠開始評量測試的成敗,不過,請小心,您要緩和自動化的結果判斷與生俱來的風險。
|
必要的工具:
|
這項技術需要下列工具:
基本配置繪圖器和修復器
安裝監視工具(登錄、硬碟、CPU、記憶體等)
|
成功準則:
|
這項技術支援在一或多個安裝配置中測試所開發之產品的安裝作業。
|
特殊考量:
|
應該選取哪些 <project Name> 交易來構成 <project Name> 應用程式已順利安裝且未遺漏任何主要元件的信任度測試?
|
|