等價類劃分
是把所有可能的輸入數據,即程序的輸入域劃分成若干部分(子集),然后從每一個子集中選取少數具有代表性的數據作為測試用例.該方法是一種重要的,常用的黑盒測試用例設計方法.
1) 劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.因此,可以把全部輸入數據合理劃分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.
有效等價類:是指對于程序的規格說明來說是合理的,有意義的輸入數據構成的集合.利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能.
無效等價類:與有效等價類的定義恰巧相反.
設計測試用例時,要同時考慮這兩種等價類.因為,軟件不僅要能接收合理的數據,也要能經受意外的考驗.這樣的測試才能確保軟件具有更高的可靠性.
2)劃分等價類的方法:下面給出六條確定等價類的原則.
①在輸入條件規定了取值范圍或值的個數的情況下,則可以確立一個有效等價類和兩個無效等價類.
②在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下,可確立一個有效等價類和一個無效等價類.
③在輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類.
④在規定了輸入數據的一組值(假定n個),并且程序要對每一個輸入值分別處理的情況下,可確立n個有效等價類和一個無效等價類.
⑤在規定了輸入數據必須遵守的規則的情況下,可確立一個有效等價類(符合規則)和若干個無效等價類(從不同角度違反規則).
⑥在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步的劃分為更小的等價類.
3)設計測試用例:在確立了等價類后,可建立等價類表,列出所有劃分出的等價類:
輸入條件 有效等價類 無效等價類
... ... ...
... ... ...
然后從劃分出的等價類中按以下三個原則設計測試用例:
①為每一個等價類規定一個唯一的編號.
②設計一個新的測試用例,使其盡可能多地覆蓋尚未被覆蓋地有效等價類,重復這一步.直到所有的有效等價類都被覆蓋為止.
③設計一個新的測試用例,使其僅覆蓋一個尚未被覆蓋的無效等價類,重復這一步.直到所有的無效等價類都被覆蓋為止.
邊界值分析法
邊界值分析方法是對等價類劃分方法的補充.
(1)邊界值分析方法的考慮:
長期的測試工作經驗告訴我們,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.
使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據.
(2)基于邊界值分析方法選擇測試用例的原則:
1)如果輸入條件規定了值的范圍,則應取剛達到這個范圍的邊界的值,以及剛剛超越這個范圍邊界的值作為測試輸入數據.
2)如果輸入條件規定了值的個數,則用最大個數,最小個數,比最小個數少一,比最大個數多一的數作為測試數據.
3)根據規格說明的每個輸出條件,使用前面的原則1).
4)根據規格說明的每個輸出條件,應用前面的原則2).
5)如果程序的規格說明給出的輸入域或輸出域是有序集合,則應選取集合的第一個元素和最后一個元素作為測試用例.
6)如果程序中使用了一個內部數據結構,則應當選擇這個內部數據結構的邊界上的值作為測試用例.
7)分析規格說明,找出其它可能的邊界條件.
錯誤推測法
基于經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.
因果圖方法
前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖(邏輯模型).
因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.
利用因果圖生成測試用例的基本步驟:
(1) 分析軟件規格說明描述中, 那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 并給每個原因和結果賦予一個標識符.
(2) 分析軟件規格說明描述中的語義.找出原因與結果之間, 原因與原因之間對應的關系. 根據這些關系,畫出因果圖.
(3) 由于語法或環境限制, 有些原因與原因之間,原因與結果之間的組合情況不不可能出現. 為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件.
(4) 把因果圖轉換為判定表.
(5) 把判定表的每一列拿出來作為依據,設計測試用例.
從因果圖生成的測試用例(局部,組合關系下的)包括了所有輸入數據的取TRUE與取FALSE的情況,構成的測試用例數目達到最少,且測試用例數目隨輸入數據數目的增加而線性地增加.
前面因果圖方法中已經用到了判定表.判定表(Decision Table)是分析和表達多邏輯條件下執行不同操作的情況下的工具.在程序設計發展的初期,判定表就已被當作編寫程序的輔助工具了.由于它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確.
判定表通常由四個部分組成.
條件樁(Condition Stub):列出了問題得所有條件.通常認為列出得條件的次序無關緊要.
動作樁(Action Stub):列出了問題規定可能采取的操作.這些操作的排列順序沒有約束.
條件項(Condition Entry):列出針對它左列條件的取值.在所有可能情況下的真假值.
動作項(Action Entry):列出在條件項的各種取值情況下應該采取的動作.
規則:任何一個條件組合的特定取值及其相應要執行的操作.在判定表中貫穿條件項和動作項的一列就是一條規則.顯然,判定表中列出多少組條件取值,也就有多少條規則,既條件項和動作項有多少列.
判定表的建立步驟:(根據軟件規格說明)
①確定規則的個數.假如有n個條件.每個條件有兩個取值(0,1),故有 種規則.
②列出所有的條件樁和動作樁.
③填入條件項.
④填入動作項.等到初始判定表.
⑤簡化.合并相似規則(相同動作).
B. Beizer 指出了適合使用判定表設計測試用例的條件:
①規格說明以判定表形式給出,或很容易轉換成判定表.
②條件的排列順序不會也不影響執行哪些操作.
③規則的排列順序不會也不影響執行哪些操作.
④每當某一規則的條件已經滿足,并確定要執行的操作后,不必檢驗別的規則.
⑤如果某一規則得到滿足要執行多個操作,這些操作的執行順序無關緊要.
軟件測試的14種類型
作者:啄木鳥(Sawin網站)
軟件測試是指使用人工或者自動的手段來運行或測定某個軟件產品系統的過程,其目的是在于檢驗是否滿足規定的需求或者弄清預期的結果與實際結果的區別。本文主要描述軟件測試的類型。
1 數據和數據庫完整性測試
數據與數據庫完整測試是指測試關系型數據庫完整性原則以及數據合理性測試。
數據庫完整性原即:
主碼完整性:主碼不能為空;
外碼完整性:外碼必須等于對應的主碼或者為空。
數據合理性指數據在數據庫中的類型,長度,索引等是否建的比較合理。
在項目名稱中,數據庫和數據庫進程應作為一個子系統來進行測試。在測試這些子系統時,不應將測試對象的用戶界面用作數據的接口。對于數據庫管理系統 (DBMS),還需要進行深入的研究,以確定可以支1持測試的工具和技術。
比如,有兩張表:部門和員工。部門中有部門編號,部門名稱,部門經理等字段,主碼為部門編號;員工表中有員工編號,員工所屬部門編號,員工名稱,員工類型等字段,主碼為員工編號,外碼為員工所屬部門編號,對應部門表。如果在某條部門記錄中部門編號或員工記錄員工編號為空,他就違反主碼完整性原則。如果某個員工所屬部門的編號為##,但是##在部門編號中確找不到,這就違反外碼完整性原則。
員工類型如下定義:0:職工,1:職員,2:實習生。但數據類型為Int,我們都知道Int占有4個字節,如果定義成char(1).就比原來節約空間。
2 白盒測試
白盒測試是基于代碼的測試,測試人員通過閱讀程序代碼或者通過使用開發工具中的單步調試來判斷軟件的質量,一般黑盒測試由項目經理在程序員開發中來實現。白盒測試分為動態白盒測試和靜態白盒測試
2.1 靜態白盒測試
利用眼睛,瀏覽代碼,憑借經驗,找出代碼中的錯誤或者代碼中不符合書寫規范的地方。比如,代碼規范中規定,函數必須為動賓結構。而黑盒測試發現一個函數定義如下:
Function NameGet(){
….
}
這是屬于不符合開發規范的錯誤。
有這樣一段代碼:
if (i<0) & (i>=0)
…
這段代碼交集為整個數軸,IF語句沒有必要
I=0;
while(I>100){
J=J+100;
T=J*PI;
}
在循環體內沒有I的增加,bug產生。
2.2 動態白盒測試
利用開發工具中的調式工具進行測試。比如一段代碼有4個分支,輸入4組不同的測試數據使4組分支都可以走通而且結果必須正確。
看一段代碼
if(I<0){
P1
}else{
P2
}
在調試中輸入I=-1,P1程序段通過, P2程序段未通過,屬于動態黑盒測試的缺陷
3.功能測試
功能測試指測試軟件各個功能模塊是否正確,邏輯是否正確。
對測試對象的功能測試應側重于所有可直接追蹤到用例或業務功能和業務規則的測試需求。這種測試的目標是核實數據的接受、處理和檢索是否正確,以及業務規則的實施是否恰當。此類測試基于黑盒技術,該技術通過圖形用戶界面 (GUI) 與應用程序進行交互,并對交互的輸出或結果進行分析,以此來核實應用程序及其內部進程。功能測試的主要參考為類似于功能說明書之類的文檔。
比如一個對電子商務系統,前臺用戶瀏覽商品-放入購物車-進入結賬臺,后臺處理訂單,配貨,付款,發貨,這一系列流程必須正確無誤的走通,不能存在任何的錯誤。
4.UI測試
UI測試指測試用戶界面的風格是否滿足客戶要求,文字是否正確,頁面美工是否好看,文字,圖片組合是否完美,背景是否美觀,操作是否友好等等
用戶界面 (UI) 測試用于核實用戶與軟件之間的交互。UI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。另外,UI 測試還可確保 UI 中的對象按照預期的方式運行,并符合公司或行業的標準。包括用戶友好性,人性化,易操作性測試。UI測試比較主觀,與測試人員的喜好有關
比如:頁面基調顏色刺眼;用戶登入頁面比較難于找到,文字中出現錯別字,頁面圖片范圍太廣等都屬于UI測試中的缺陷,但是這些缺陷都不太嚴重。
2 軟件測試的14種類型
文章來源于領測軟件測試網 http://www.k11sc111.com/