測試 - 測試方法


before

在之前的部分,我們簡單的介紹了關於測試方法都有哪些分類。

本小節主要來再深入的學習白盒、黑盒測試;靜態和動態測試;人工、自動化測試,以及它們是如何划分的。

測試方法的划分

一般的,從看不看代碼來划分黑、白盒測試。看代碼和內部接口稱為白盒測試,否則是黑盒測試方法。

而從軟件是否運行的角度來划分靜態和動態測試。不運行代碼是靜態測試,反之就是動態測試。

那么從我們人來參與的角度來看人工測試和自動化測試的。

黑、白、灰盒測試

剛才說了,我們從看不看代碼來划分黑、白盒測試。

那黑盒測試可以有靜態測試和動態測試,也可以有人工測試和自動化測試。

當然,白盒測試也是一樣的。

比如我們要測這個自動售貨機。

我們投幣然后得到飲料;或者刷卡、掃碼等都能得到想要的飲料。

我們做黑盒測試就是測試投幣相關的邏輯、選擇飲料相關的邏輯,找零或其他的邏輯。

這是我們不管內部結構,只是根據一些數據測試輸入輸出,比如投幣5毛錢,卻能得到一瓶2.5的飲料,這就是bug了。

等等等.....

除此之外,我們還需要看內部代碼的邏輯,比如如何處理銀行和第三方支付的接口邏輯,本地的飲料存儲、統計等,看看相關關聯的數據之間的交互。這些都是白盒測試范疇。

在測試之前,我們要搞清楚被測對象應該是什么樣的,然后實際做出來的和預期進行比較,這樣就能及時的發現缺陷;根據被測對象不同,而采用不同的測試方法。

白盒測試

白盒測試是依據被測軟件分析程序內部構造,並根據內部構造設計用例,來對內部控制流程進行測試,可完全不顧程序的整體功能實現情況。

白盒測試是基於程序結構的邏輯驅動測試。

白盒測試又可以被稱為玻璃盒測試、透明盒測試、開放盒測試、結構化測試、邏輯驅動測試。

白盒測試一般在測試前期進行,通過達到一定的邏輯覆蓋率指標,使得軟件內部邏輯控制結構上的問題能基本得到解決。

白盒測試能保證內部邏輯結構能達到一定的覆蓋程度,能夠給予軟件代碼質量更大的保證。

白盒測試發現問題后解決問題的成本較低,畢竟介入的早嘛。

白盒測試一般會用到靜態分析和動態分析兩類技術,常用的有:

  • 靜態分析:控制流分析、數據流分析、信息流分析;
  • 動態分析:邏輯覆蓋測試(分支測試、路徑測試等)、程序插樁等。

邏輯覆蓋率測試

根據覆蓋的對象不同,存在多種邏輯覆蓋測試:

  • 語句覆蓋;
  • 判定覆蓋;
  • 條件覆蓋;
  • 判定-條件覆蓋;
  • 路徑覆蓋;
  • ......

關於覆蓋率的介紹,后續我們再聊。

邏輯覆蓋率的統計是通過程序插樁來實現的。

程序插樁

程序插樁,最早是由J.C. Huang 教授提出的,它是在保證被測程序原有邏輯完整性的基礎上在程序中插入一些探針(又稱為“探測儀”,本質上就是進行信息采集的代碼段,可以是賦值語句或采集覆蓋信息的函數調用),通過探針的執行並拋出程序運行的特征數據,通過對這些數據的分析,可以獲得程序的控制流和數據流信息,進而得到邏輯覆蓋等動態信息,從而實現測試目的的方法。

簡單來說,程序插樁就是我們在調試程序時,常常要在程序中插入一些打印語句(想想我們在程序中常用的print語句),其目的是希望在程序執行中打印出我們最為關心的信息,然后進一步通過這些信息了解程序執行過程中程序的一些動態特性。

從這一思想發展出程序插樁技術能夠按照用戶的要求,獲取程序的各種信息,成為測試工作的有效測試手段。

我們往往通過借助被測程序中插入一些操作來實現測試目的的方法。

白盒測試的特點

  • 測試人員需要了解軟件的實現;
  • 可以檢測代碼中的每一條分支和路徑;
  • 揭示隱藏在代碼代碼中的錯誤;
  • 對代碼的測試相對徹底;
  • 實現代碼結構上的優化;
  • 白盒測試的投入較大,成本高;
  • 白盒測試不驗證(需求)規格的正確性;

綜上所述,白盒測試對測試人員的要求要高!

黑盒測試

黑盒測試把被測對象看成一個黑匣子,只考慮期整體的特性,不考慮期內部具體實現。

黑盒測試的被測對象可以是一個系統、一個子系統、一模塊、子模塊、一個函數等。

黑盒測試又可以被稱為基於規格的測試。

常見的黑盒測試類型

功能性測試:

  • 一種是順序測試每個程序特性或功能;
  • 另一種是一個模塊一個模塊的測試,即每個功能在其最先調用的地方被測試;

容量測試,檢測軟件在處理海量數據時的局限性,能發現系統效率方面的問題。

負載測試,檢測系統在短時間內處理巨大的數據量或執行許多功能調用上的能力。

恢復性測試,主要保證系統在崩潰后能回復外部數據的能力。

黑盒測試類型和質量模型

黑盒測試類型都來源於質量模型。

將軟件的特性和質量特性結合起來就得到了測試類型。

一個軟件特性可以和一個質量特性結合得到一個測試類型。

一個軟件特性可以和多個不同的質量特性結合得到多個不同的測試類型。

容量負載測試所測試軟件質量特性

黑盒測試的測試方法

常見的黑色測試方法有:

  • 等價類划分法。
  • 邊界值分析法。
  • 因果圖分析法。
  • 判定表法。
  • 狀態遷移法。
  • 輸入域。
  • 輸出域。
  • 錯誤猜測法。

當然,無論是采用什么測試方法,目的都是為了減少測試時的測試用例數,都是為了用較少的測試用例發現更多的問題。

灰盒測試

根據利用的被測對象的信息不同,會采用不同的方法進行測試,一般的:

  • 利用被測對象的整體特性信息,采用黑盒測試方法。
  • 利用被測對象的內部具體實現信息,采用白盒測試方法。
  • 如果既是利用被測對象的整體特性信息,又利用被測對象的內部具體實現信息,采用的就是灰盒測試方法。兩種信息占比不同,相應的灰度就不同,完全是整體特性信息,就是黑盒測試,完全是內部具體實現信息,就是白盒測試。

黑、白、灰盒測試方法總結

我們一般從以下五個維度來區分:

  • 測試階段不同:
    • 單元測試階段主要利用白盒測試方法。
    • 集成測試階段主要利用灰盒測試方法。
    • 系統測試階段主要利用黑盒測試方法。
  • 測試依據,因為測試階段的不同,采用的測試方法也不同,那它們的測試依據也不同:
    • 白盒測試主要依據詳細測試說明書(LLD)。
    • 黑盒測試主要依據需求規格(設計)說明書(SRS)。
    • 灰盒測試主要依據概要規格(設計)說明書(HLD)。
  • 測試方法:
    • 白盒測試方法可以有靜態和動態,控制流、信息流、數據流、各種覆蓋率、插樁處理。
    • 黑盒測試方法有各種測試類型(功能型、負載、恢復性),以及應用等價類、邊界值、流程圖法、正交法等。
    • 灰盒測試這里即用白盒的,也用黑盒的。
  • 評估基准:
    • 白盒根據邏輯覆蓋率來評估。
    • 黑盒主要看需求規格的覆蓋率。
    • 灰盒主要看接口覆蓋率。
  • 特點不一樣:
    • 白盒測試,特點是及早的發現問題,定位問題也很快,缺點是對接口、對設計、程序之間的調用、用戶感受也不是很好。
    • 黑盒解決問題的代價比較大,很大發現模塊內部的問題。

靜態、動態測試

軟件研發可以看成是一個生產過程,在此過程中會有產品輸出或者稱為工件輸出。

輸出的產品可以分為兩類:

  • 最終產品,如變編譯后的軟件、用戶手冊等。
  • 中間產品,如SRS、HLD、LLD、源代碼等。

無論是最終產品還是中間產品,都可以分成代碼和文檔。

文檔進一步細分還可以分為:

  • 開發文檔,如SRS、HLD、LLD。
  • 測試文檔,如測試計划、測試方案、測試用例等。

只要是軟件產品,都是測試對象。

靜態測試和動態測試的划分

靜態測試,不運行被測對象,而是采用其他手段和技術對被測對象進行檢測的一種測試技術。例如:代碼走讀、文檔評審、程序分析都是靜態測試的范疇,常用技術有靜態分析技術。

動態測試,按照預先設計的數據和步驟去運行被測對象,從而對被測對象進行檢測的一種測試技術,常用技術有動態分析技術。

靜態測試

靜態測試這里主要了解靜態分析技術。

定義:靜態分析是一種不通過執行程序而分析程序執行的技術。

功能:檢查軟件的表示和描述是否一致,沒有沖突或者沒有歧義,它的目標是糾正軟件系統在描述、表示和規格上的錯誤,因此是任何進一步測試執行的前提。

主要有三種不同的程序測試可能性:

  • 規格考慮,程序是否滿足編碼,語法上是否具有一致性和完整性。
  • 考慮文檔描述是否規范、准確、是否便於查閱,例如描述是否不清楚、出現歧義等。
  • 考慮程序和文檔之前的一致性,例如文檔要求某文件大於1M拋出錯誤,而程序則是大於等於1M諸如此類的問題。

關於規格考慮的可以參考下面示例。

def foo():
    l = [3, 5, 8, 10]
    if l[4] < 10:  # l[4]超出列表的索引下標3
        print("ok")
    while l[3] < 12:  # 死循環
        print("ok")

比如上例中的foo函數,第一個if條件是錯誤的,包括while循環都是有問題的,這些都是我們要考慮的問題,如這個函數語法問題,縮進問題、邏輯問題、是否有恰當的注釋。

靜態分析技術結構

手工靜態分析——同行評審

靜態分析技術中一個最重要的手工技術是同行評審,根據形式正規的程度分為:

  • 正規檢視,指定的人員參與、相關會議、相關文檔都是比較正規的。
  • 技術評審。
  • 走查。

同行評審的對象可以是計划、需求文檔、設計圖、源代碼等。

如下圖,在瀑布模型中,貫穿整個開發過程中的評審。

自動化靜態分析

靜態驗證檢測規格到程序實現之間的轉換上的問題,驗證器需要有形式化的規格和規格的形式化定義,靜態驗證比較程序提供的設計值和在規格文檔中被預先定義的目標值。

語法分析器是一個基本的自動化靜態分析工具,它把程序/文檔文本分解成獨立的語句,當在內部檢查程序/文本的時候,語句的一致性被進行了檢查。

符號執行器在符號短語中分析一個程序在給定的路徑上做了什么事情,它模擬程序的執行,計算在程序不同位置上變量的值,符號執行器非常適用於數學算法的分析。

動態測試

動態測試這里主要了解動態分析技術。

定義:對軟件系統運行行為進行分析,包含程序在受控的環境下使用特定的輸入進行正式的運行,然后和期望的結果比較以檢查系統運行時正確還是不正確。

常用的動態分析技術:

  • 路徑測試
  • 分支測試
  • 性能測試

常用動態分析工具功能

動態分析類 工具的功能
測試覆蓋率分析 測試對代碼的檢測范圍
跟蹤 跟蹤程序執行期間的所有路徑,例如所有變量的值等
調整 度量程序執行過程中使用的資源
模擬 模擬系統的一部分,例如無法獲得的代碼或者硬件
斷言檢查 測試在復雜邏輯結構中是否某個條件已被給出

常用黑盒動態測試工具

常用的黑盒動態測試主要測試內容包括:

  • 功能測試。
  • 性能測試。
  • 回歸測試。

在上述測試中,我們會用到:

  • QARun
  • Robot
  • QTP
  • SikTest
  • LoadRunner
  • SilkPerformer

上述這些工具各有特點,應用於不同的測試中,完成測試任務,比如性能測試。

人工測試、自動化測試

人工測試:測試活動(評審、測試設計、測試執行)由人來完成,狹義上是指測試執行由人工完成,這是最基本的測試形式。

自動化測試:一般指通過計算機模擬人的測試行為,替代人的測試活動,狹義上是指測試執行由計算機來完成。

適合自動化測試的活動

適合自動化的活動包括重復多次、機械是的測試,可以使用自動化來執行自動化的執行與檢查校驗。

自動化測試的意義

對於程序新版本運行前一版執行的測試,提高回歸測試效率。

可以運行更多更頻繁的測試,比如冒煙測試。

可以執行手工測試困難或者不可能做的測試,比如大量的重復操作或者集成測試。

更好的利用資源,比如測試儀器或者被測對象。

測試具有一致性和可重復性,即即自動化測試的步驟和結果是完全一致的。

測試的復用性,即自動化測試腳本可以拆分開給其他測試腳本使用。

可以更快的將軟件推向市場,軟件發布前進行高效的回歸測試,減少軟件發布的時間。

增加軟件信任度,通過自動化測試提高了測試效率,可以把節約的時間拿出來做更多的測試。

自動化測試的分類

  • 按照測試目的大致分為:功能自動化測試、性能自動化測試。
  • 按照測試對象可划分:web自動化測試、APP方向自動化測試、接口自動化測試、單元測試等。
  • 其他的包括代碼測試和數據測試等。

自動化測試解決了哪些問題

  • 回歸測試:項目在發布新版之后,對之前的功能進行驗證。
  • 壓力測試:統計軟件服務器處理並發的能力,比如能支持多少個用戶同時訪問。
  • 兼容性測試:不同的系統平台,或者不同的瀏覽器。
  • 提高測試效率,保證了產品的質量。

自動化測試具有提高任何軟件長期效率的特定優勢。測試自動化的主要優點是:

  • 長期以來,自動化測試一直被認為對大型軟件組織有益。雖然,小型公司通常認為實施起來太昂貴或困難。
  • 可以對自動化測試工具進行編程,以便在特定時間構建和執行測試腳本,而無需任何人為干預。例如,自動測試可以在一夜之間自動啟動,測試人員可以在第二天早上分析自動化結果。
  • 自動化測試工具能夠播放預先錄制和預定義的動作。
  • 自動化測試支持頻繁的回歸測試,這也是自動化測試的主要任務。
  • 它為開發人員提供快速反饋。
  • 它提供了無限次的測試用例執行迭代。
  • 它提供了有關測試用例的嚴格文檔。
  • 自動化測試生成定制的缺陷報告。
  • 與手動測試相比,更不容易出錯。
  • 可以執行更多繁瑣且枯燥的測試。
  • 可以執行一些手工測試困難或者不可進行的測試。
  • 更好的利用資源,在某些方面解放測試人員。
  • 讓具有一致性和可重復性的測試用例復用起來更加簡單。
  • 提高被測軟件的可靠性。

適合自動化測試的場景

  • 測試任務明確,不會頻繁變動。
  • 軟件需求變更較少。
  • 項目周期長,測試腳本可以復用。

自動化測試的限制

不能取代手工測試,自動化測試只能提高測試效率,不能提高測試有效性,即不可能發現更多缺陷。

手工測試比自動化測試發現的缺陷更多。

對測試設計依賴性極大,測試設計的不好會遺漏問題。

自動化測試對軟件開發具有很大的依賴性,開發上出現變更可能導致前面的自動化測試完全失效。

工具本身並不具備想象力。

自動化用於功能自動化的測試工具

  • 由HP提供的Quick Test Professional。
  • Rational Robot,由IBM提供。
  • Coded UI,由Microsoft提供。
  • Selenium,開源軟件。
  • Auto It,開源軟件。

自動化測試生命周期

Web應用程序的測試自動化

如果我們看一下目前市場情況中普遍存在的軟件應用程序的類型,大多數軟件應用程序都是作為基於Web的應用程序編寫的,以便在互聯網瀏覽器中運行。基於Web的應用程序的測試策略在公司和組織之間差異很大。在高度交互和響應迅速的軟件過程的時代,許多組織正在使用某種形式的敏捷方法,測試自動化經常成為軟件項目的要求。

為Web應用程序執行測試自動化的最有效方式是采用金字塔測試策略。此金字塔測試策略包括三個不同級別的自動化測試。單元測試代表了此測試自動化金字塔的基數和最大百分比。 接下來是服務層或API測試。最后,GUI測試位於頂部。金字塔看起來像這樣:

自動化測試的誤區

不現實的期望,希望自動化能取代手工測試。

缺乏測試實踐經驗,手工測試都做不好,或者經驗積累不足,就嘗試自動化,很難成功。

期望自動化測試發現大量新缺陷,自動化只能保證測試執行效率,確保已有問題不會再發生,發現新缺陷不是器目的。

安全性錯覺,認為進行了自動化測試的軟件就是安全的,質量有保證的。

只有手工測試做好了,明確了測試觀察點,才能把自動化測試做好,所以手工測試是自動化測試的基礎。

進行自動化測試考慮因素

我們從以下六個方面來考慮是否進行自動化測試:

  • 進度要求:開發周期短,產品迭代快,這個時候,我們沒有時間來進行自動化,因為自動化需要大量的准備時間。
  • 人力要求:自動化的用例設計,執行、維護都需要大量的人力,這個時候,你是否有足夠的人類來展開自動化測試。
  • 版本穩定情況:如果開發不斷地迭代版本,那么你就要考慮自動化的維護成本了,是否值得自動化測試。
  • 版本應用情況:如果在相當長的時間內,軟件后續不在更新迭代,我們沒有必要進行自動化。
  • 版本規模:如果用例的規模本來就很小,比如說就百十來個,那就沒必要進行自動化測試。
  • 自動化率:加入測試用例是1000個,而其中只有十幾個或幾十個用例可以進行自動化測試,那么我們不考慮自動化,只有當可以自動化的用例占比超過20%的時候,我們才考慮進行自動化測試。

常見的黑盒測試方法

在編寫黑盒測試用例的時候,我們可以有以下幾種形式來完成:

  • 等價類划分法(5星)
  • 邊界值法(5星)
  • 場景法(5星)
  • 因果圖法
  • 判定表法
  • 正交(排列)法
  • 測試大綱法

我們至少要了解每種方法的使用場景(在哪用?)和使用步驟(怎么用?)。

除此之外,我們編寫測試用例,都有哪些可以參考的呢?

  • 需求文檔
  • 被測系統(已經開發出來的被測系統),一邊對照程序,一邊編寫用例,很多企業都采用這種方式,如果只對照需求文檔可能僅能完成測試的30~40%。
  • 開發(設計)文檔,當然,有可能也拿不到,比如說開發和測試分屬不同的公司,人家開發就不一定提供文檔。
  • 積極與開發、產品、客戶進行溝通

接下來,我們來了解各各方法都是怎么玩的。

等價類划分法

現在,進入討論時間,我們要對計算器進行測試的話,到底要輸入多少組測試數據才算測試完畢?

這個答案很難回答啊,一個一個測試的話, 那能測到天荒地老,媳婦懷孕......

所以,我們要采用分類測試:

  • 整數,比如在范圍(-100~100)內取最大、最小、中間值
  • 小數,比如在范圍(-100~100)內取最大、最小、中間值
  • 符號,各種符號(!@#\(、%,^&?*()、_+\)
  • 漢字或其他語言、字母
  • 空格
  • 空值,也就是什么都不輸入

通過上面的分類,我們發現用戶所有可能輸入的數據,划分為了若干份(或稱為不同的子集),然后從每個子集中選取少數具有代表性的數據作為測試用例,這種測試用例我們稱為等價類(類別)划分法

等價類划分法是一種重要的、常用的黑盒測試方法,無需考慮程序的內部結構,只需要考慮程序的輸入規格即可,它將不能窮舉的測試過程進行合理的分類,從而保證設計出來的測試用例具有完整性和代表性。

在有限的測試資源的情況下,用少量有代表性的數據得到比較好的測試效果。

等價類划分分為(基本概念):

  • 有效等價類,指符合《需求規格說明書》,輸入合理的數據集合。
  • 無效等價類,指不符合《需求規格說明書》,輸入不合理的數據集合。

等價類思考步驟:

  • 首先確定有效等價類和無效等價類
  • 有效等價類就是一目了然的題目條件(比如在0~20之間測試),要考慮到兩端的極值(邊界值)和中間值。
  • 無效等價類先划分與條件相反的情況(比如不在0~20范圍內),再去找特殊情況,如中英文,符號、空格、空等。

示例1:計算整數

計算1 ~ 20的整數之和(包括1和20)。

新建一個Excel表格,在Excel表格中建立等價類的划分:

用例編號 所屬等價類 輸入值1 輸入值2 預期結果 是否提bug
1 有效 1~20整數 8 正確
2 有效 8 1~20整數 正確
3 無效 小於1 8 錯誤
4 無效 8 小於1 錯誤
5 無效 大於20 8 錯誤
6 無效 8 大於20 錯誤
7 無效 中文 8 錯誤
8 無效 8 中文 錯誤
9 無效 英文 8 錯誤
10 無效 8 英文 錯誤
11 無效 特殊符號 8 錯誤
12 無效 8 特殊符號 錯誤
13 無效 空格 8 錯誤
14 無效 8 空格 錯誤
15 無效 8 錯誤
16 無效 8 錯誤
17 無效 小數 8 錯誤
18 無效 8 小數 錯誤

注意:一般的,我們在輸入測試時,一個值是正確的,另一個值是錯誤的,而不是兩個值都是錯誤的,因為這樣更容易確定到底哪個值是錯誤的。如果不符合預期,那么就要提交bug了。另外,一定要根據需求來判斷結果到底是錯誤的還是正確的。

我們也可以通過Python代碼來實現一個最簡單的計算器:

import os

print('計算1~20內的兩數之和,包含1和20')

def add(x, y):
    return int(x) + int(y)

while True:
    try:
        num1 = input('請輸入一個值或輸入 q 退出: ').strip()
        if num1.upper() == 'Q':
            break
        num2 = input('再次輸入一個值: ').strip()
        os.system('cls')
        print('{} + {} = {}'.format(num1, num2, add(num1, num2)))
    except Exception as e:
        print(e)

也可以使用pyinstaller將Python文件轉成可執行文件:

# 首先要先下載pyinstaller
pip install installer
# 將指定文件轉換為可執行文件
pyinstaller -F t1.py

示例2:測試QQ賬號

要求是賬號必須是6~10位數的正整數。

所以,我們分析來分析有效等價類和無效等價類:

  • 有效等價類:長度在6~10位之間的正整數
  • 無效等價類:
    • 長度小於6
    • 長度大於10
    • 負數
    • 小數
    • 中文
    • 英文字母
    • 空格
    • 特殊字符

按照老套路來,我們在Excel中進行等價類的划分。

用例編號 等價類划分 賬號框 預期結果 是否提bug
1 有效 6~10位正整數 正確
2 無效 小於6位 錯誤
3 無效 大於10位 錯誤
4 無效 負數 錯誤
5 無效 小數 錯誤
6 無效 中文 錯誤
7 無效 英文 錯誤
8 無效 空格 錯誤
9 無效 特殊字符 錯誤
10 無效 錯誤

上例是以qq賬號為例,並沒有提密碼的事情,所以,我們僅關注輸入的值是否符合題意要求,與預期不符則提交bug。

用Python代碼實現如下:

import os

print('QQ賬號測試,要求是必須是6~10位正整數')

while True:
    try:
        num1 = input('請輸入一個值或輸入 q 退出: ').strip()
        if num1.upper() == 'Q':
            break
        if num1.isdigit():
            if 6 <= len(num1) <= 10:
                print('輸入 {} 正確,長度為 {}'.format(num1, len(num1)))
            else:
                print('輸入的 {} 長度為 {} 位,不符合題意要求'.format(num1, len(num1)))
        else:
            print('輸入的 {} 不符合題意要求'.format(num1))
        os.system('cls')

    except Exception as e:
        print(e)

示例3:測試電話號碼

某電話號碼由3部分組成,分別是:

  • 地區碼:空白或者3位數字
  • 前綴:非0且非1開頭的三位數
  • 后綴:4位數字
用例編號 等價類划分 電話組成 輸入內容 預期結果 是否提交bug
1 有效 地區碼 空白或3位數字 正確
2 無效 地區碼 大於3位 錯誤
3 無效 地區碼 小於3位 錯誤
4 無效 地區碼 中文 錯誤
5 無效 地區碼 英文 錯誤
6 無效 地區碼 空格 錯誤
7 無效 地區碼 特殊字符 錯誤
8 無效 地區碼 小數 錯誤
9 有效 前綴 0且非1開頭的三位數 正確
10 無效 前綴 0開頭 錯誤
11 無效 前綴 1開頭 錯誤
12 無效 前綴 大於3位 錯誤
13 無效 前綴 小於3位 錯誤
14 無效 前綴 中文 錯誤
15 無效 前綴 英文 錯誤
16 無效 前綴 空格 錯誤
17 無效 前綴 特殊字符 錯誤
18 無效 前綴 小數 錯誤
19 有效 后綴 4位數字 正確
20 無效 后綴 大於4位 錯誤
21 無效 后綴 小於4位 錯誤
22 無效 后綴 中文 錯誤
23 無效 后綴 英文 錯誤
24 無效 后綴 空格 錯誤
25 無效 后綴 特殊字符 錯誤
26 無效 后綴 小數 錯誤

示例4:用戶登錄

要求:

  • 用戶名(昵稱)長度為3~19,以字母開頭
  • 登錄名稱:非空
  • 密碼:非空
  • 確認密碼:值和密碼相同

接着打開Excel表格,來羅列測試用例:

用例編號 等價類划分 用戶輸入文本框 輸入內容 預期結果 是否提bug
1 有效 用戶名、昵稱 以字母開頭,長度3~19位 正確
2 無效 用戶名、昵稱 小於3位 錯誤
3 無效 用戶名、昵稱 大於19位 錯誤
4 無效 用戶名、昵稱 數字 錯誤
5 無效 用戶名、昵稱 小數 錯誤
6 無效 用戶名、昵稱 中文、特殊符號 錯誤
7 無效 用戶名、昵稱 空格 錯誤
8 無效 用戶名、昵稱 錯誤
9 無效 用戶名、昵稱 被和諧掉的詞 錯誤
10 有效 登錄名稱 非空 正確
11 無效 登錄名稱 錯誤
12 有效 密碼 非空 正確
13 無效 密碼 錯誤
14 有效 確認密碼 與密碼相同 正確
15 無效 確認密碼 與密碼不一致 錯誤

小結,在等價類划分中,我們可以從以下幾個角度考慮

  • 文本框要求輸入的長度
  • 輸入的類型
  • 組成規則
  • 是否為空
  • 是否重復
  • 區分大小寫
  • 是否去空格

等價類划分法的應用場景

  • 有數據輸入的地方
  • 從大量的數據中挑選少量有代表性的數據進行測試

等價類划分發的測試思想

  • 窮舉測試:把所有可能的數據全部測試一遍稱為窮舉測試,雖然窮舉測試是最全面的測試,但是很明顯不現實,因為測試效率太低了,數據量巨大,根本測不過來(思考前面計算器的例子)。但又因為沒有做過窮舉測試,所以會有遺漏缺陷的風險,如果時間允許,盡可能的做補充測試(覺得有風險有問題的做補充測試)。
  • 理想的測試思想,使用最少的測試數據,達到最好的測試質量,畢竟性價比還是要追求的嘛。
  • 而等價類划分法則是從大量的數據中,划分范圍(或分類),每個范圍內的數據測試效果是等價的,所以每個范圍是一個等價類,然后從每個范圍內挑選出具有代表性的數據,這些代表數據能反映這個范圍內的測試結果。
  • 等價類划分法的基本思想是:
    • 有效等價類,對於程序來說,是有意義的,合理的輸入數據集合,然后測試功能是否符合預期。
    • 無效等價類,對於程序來說,是無意義的,不合理的輸入數據集,用來測試程序是否具有強大的異常處理能力,也就是測試程序的健壯性。

邊界值

什么是邊界值?

邊界是指對於輸入等價類和輸出等價類而言,稍高於邊界值和稍低於邊界值的一些特定情況,邊界值分析法常應用於黑盒測試中。邊界值也可以稱為極值。

根據以往的經驗來看:大量的錯誤是發生在輸入或者輸出范圍的邊界上,而不是再輸入范圍的內部。所以,為了保證測試質量,我們需要重點關注測試邊界。

讓我們通過示例來加深理解。

示例:輸入的值必須在大於0且小於100的整數

我們通過一個簡單示例來觀察:

res = input('輸入0~100內的整數: ').strip()
if res.isdigit():
    res = int(res)
    if 0 <= res <= 100:  # 程序員可能會因為疏忽將大於寫成大於等於
        print('輸入的值必須大於0且小於100,你輸入的是 {}'.format(res))
    else:
        print('輸入錯誤')
else:
    print('非法輸入')

上例中,程序員把邊界值條件設置錯了,把>寫成了>=,把<寫成了<=

注意:有效數據和無效數據的分界點,往往作為程序員編寫程序的判斷點,所以,這也是程序員最容易犯錯的地方(他很有可能聽着歌,腦子里想着是大於小於,結果手比腦子動的快,寫成小於等於等等情況),所以,邊界值這里是我們測試人員重點測試的地方

那么如何解決這類問題?

  • 找到測試數據的邊界點,也就是有效等價類和無效等價類的邊界點,對於邊界點數據專門進行測試。
  • 一般的,測試人員需要對邊界值及邊界值兩邊的數分別進行測試。

示例:完善用戶登錄

讓我們來完善之前等價類划分發中的用戶登錄示例。僅拿出一個要求進行分析。用戶名、昵稱這里要求是3~19位。

用例編號 等價類划分 用戶輸入文本框 輸入內容 預期結果 是否提bug
1 有效 用戶名、昵稱 以字母開頭,長度3~19位 正確
2 無效 用戶名、昵稱 小於3位 錯誤
3 無效 用戶名、昵稱 大於19位 錯誤

通過上表可以看到,我們之前僅判斷了邊界值,但是不夠精細,我們來完善一下。就是對邊界值及邊界值兩邊的數據進行測試。那么邊界值3,就要測試2, 3, 4;而邊界值19,就要測試18,19,20。

用例編號 等價類划分 用戶輸入文本框 輸入內容 預期結果 是否提bug
1 有效 用戶名、昵稱 以字母開頭,長度3~19位 正確
2 無效 用戶名、昵稱 等於2 錯誤
3 有效 用戶名、昵稱 等於3 正確
4 有效 用戶名、昵稱 等於4 正確
5 有效 用戶名、昵稱 等於18 正確
6 有效 用戶名、昵稱 等於19 正確
7 無效 用戶名、昵稱 等於20 錯誤

通過對邊界值及邊界值兩邊的數據都進行測試,提高測試質量。

確定邊界值的一般思路

  • 確定邊界情況,也就是確定輸入或者輸出等價類的邊界
  • 選取正好等於、剛剛大於、剛剛小於邊界值作為測試數據
  • 邊界值的取值依據輸入范圍區間不同而有所不同,但是都需要把上點值、離點值、和內點值取到。如下表所示:
區間 上點 內點 離點
閉區間,如[1, 10] 1,10 5 0,11
開區間,如(1, 10) 1,10 5 2,9
半開半閉區間,如(1, 10] 1,10 5 2,11

示例1:標題

使用邊界值的方法設計添加標題的測試用例,要求是:標題長度大於0,標題長度小於等於30

用例編號 輸入值 預期輸入 是否提交bug 備注
1 空白 錯誤 0字節
2 等於30 正確 30字節
3 大於30 錯誤 大於30字節
4 小於30 正確 1~29字節
5 小於等於0 錯誤 0字節

示例2:成績測試

輸入一個學生的成績,判斷是否及格(0~100間的整數):

  • 確定有效區域和無效區域。
  • 臨界點:0、60、100。
  • 取值:-1、0、1、59、60、61、99、100、101。

來搞測試用例:

用例編號 等價類划分 成績 預期結果 是否提交bug
1 有效 0 不及格
2 有效 1 不及格
3 有效 59 不及格
4 有效 60 及格
5 有效 61 及格
6 有效 99 及格
7 有效 100 及格
8 無效 101 錯誤
9 無效 -1 錯誤
10 無效 小於0 錯誤
11 無效 大於100 錯誤
12 無效 錯誤
13 無效 中、英文 錯誤
14 無效 特殊符號、小數 錯誤

有了上表,我們能一目了然的觀察出有效無效等價類,並在其中應用了邊界值。

示例3:密碼

修改手機某軟件登錄密碼框,要求:

  • 密碼必須由字母數字組成。
  • 密碼長度在8~24之間(包含8和24)。
用例編號 等價類划分 輸入框 預期結果 是否提交bug
1 有效 8位數字和字母組合 正確
2 有效 9位數字和字母組合 正確
3 有效 23位數字和字母組合 正確
4 有效 24位數字和字母組合 正確
5 無效 7位數字和字母組合 錯誤
6 無效 25位數字和字母組合 錯誤
7 無效 小於8位數字和字母組合 錯誤
8 無效 大於24位數字和字母組合 錯誤
9 無效 中文 錯誤
10 無效 特殊符號 錯誤
11 無效 空格 錯誤
12 無效 錯誤
13 無效 8位數字 錯誤
14 無效 9位數字 錯誤
15 無效 23位數字 錯誤
16 無效 24位數字 錯誤
17 無效 7位數字 錯誤
18 無效 25位數字 錯誤
19 無效 8位字母 錯誤
20 無效 9位字母 錯誤
21 無效 23位字母 錯誤
22 無效 24位字母 錯誤
23 無效 7位字母 錯誤
24 無效 25位字母 錯誤

邊界值的方法思考:

  • 如果輸入條件規定了范圍,則應該取這個范圍的邊界值,比如1~100,邊界值應該取0 1 100 101
  • 如果輸入條件規定了輸入值的個數。比如密碼長度為8~24,邊界值應該取7 8 9 23 24 25位字符來判斷。
  • 邊界值和等價類的區別,邊界值分析不是從等價類中隨便找一個作為代表,而是整個等價類的每個邊界都要作為測試條件。
  • 邊界值的思想是在結合實際環境,應該選出到邊界和剛超過的值作為測試依據。邊界值和等價類是相輔相成的,共同使測試用例更加完善。

常見的邊界值:

  • 循環中的第1、2次和倒數第1、2次。
  • 數值元素的第一個和最后一個值。
  • 報表的第一行和最后一行。
  • 文本框接收字符個數,用戶名長度啊,密碼長度等。

在這些長度、個數什么的,要多考慮邊界值。

see also :測試用例--等價類划分、邊界值法

因果圖

因果圖(Cause-Effect Graph)法是一種利用圖解法分析輸入的各種組合情況,從而設計測試用例的方法,它適用於檢查程序輸入條件的各種組合情況。
因果圖法的特點

  • 考慮輸入條件的相互制約及組合關系
  • 考慮輸出條件對輸入條件的依賴關系

因果圖法產生的背景

  • 等價類划分法和邊界值分析方法都是着重的考慮輸入條件,但是極少的考慮輸入條件的各種組合、輸入條件之間的相互制約關系,這樣雖然各種輸入條件可能出錯的情況已經測試到了,但是多個輸入條件組合起來可能出錯的情況卻很難發現。
  • 如果在測試的時候,必須考慮輸入條件的組合情況,那么可能的組合情況將非常的多,導致測試任務繁重。因此,我們必須考慮一種適合於描述多種條件的組合,相應產生多個動作的形式來進行測試用例的設計,這就用到了因果圖,也就是設計邏輯模型。

因果圖的核心

  • 因果圖法適用於輸入條件較多的情況,測試所有輸入條件的排列組合。因果圖所謂的就是輸入,而就是輸出。
    • 因果圖之,即輸入條件。
    • 因果圖之,即輸出結果。

因果圖法要注意考慮的要點

  • 所有輸入/輸出條件的相互制約關系及組合關系。
  • 輸出結果對輸入條件的依賴關系,也就是什么樣的輸入組合會產生怎樣的輸出結果,即因果關系

因果圖中的基本符號
通常在因果圖中,用C表示原因,用E表示結果,各節點表示狀態,可取值010表示某狀態不出現,1表示某狀態出現。

  • 恆等,若原因出現,則結果出現,若原因不出現,結果也不出現。

    • c1 = 1,則e1 = 1
    • c1 = 0,則e1 = 0

    例如ATM機取錢,打印憑條。

  • 非(~),若原因出現,則結果不出現,若原因不出現,則結果出現。

    • c1 = 1,則e1 = 0
    • c1 = 0,則e1 = 1

    搜索QQ好友,如果有就不提示錯誤,如果沒有就提示錯誤。

  • 或(∨),若幾個原因中有一個出現,則結果出現,若幾個原因都不出現,則結果不出現。

    • c1 = 1 or c2 = 1 or c3 = 1,則e1 = 1
    • c1=c2=c3=0,則e1 = 0

    暖寶寶 + 熱心 + 細心滴,好人卡!

  • 與(∧),若幾個原因都出現,則結果才出現,若其中一個原因不出現,則結果不出現。

    • c1 = 1 and c2 = 1,則e1 = 1
    • c1 = 0 or c2 = 0,則e1 = 0

    暖男 + 熱心 + 細心滴,爛好人!

小結:

  • 恆等,有因有果,無因無果。
  • 與(且),條件都為真,結果才為真,如果其中一個條件為假,則結果為假。
  • 或,有一個條件為真,則結果為真,條件都為假,結果才為假。
  • 非,取反的意思,有因無果,無因有果。

因果圖中的約束條件(了解)

因果圖法基本步驟

利用因果圖導出測試用例需要經過以下幾個步驟:

  • 找出所有的原因,原因即是輸入條件或輸入條件的等價類。
  • 找出所有的結果,結果即輸出條件。
  • 明確所有輸入條件之間的制約關系及組合關系。比如,哪些條件可以組合到一起,哪些條件不能組合到一起。
  • 明確所有輸出條件之間的制約關系以及組合關系。比如,哪些輸出結果可以同時輸出,哪些輸出結果不能同時輸出。
  • 找出什么樣的輸入條件組合會產生哪種輸出結果。
  • 把因果圖轉換成判定表/決策表。
  • 為判定表/決策表中的每一列表示的情況設計測試用例。

示例:一卡通自動充值系統

要求:

  • 系統只接收50或100元紙幣,一次只能使用一張紙幣,一次充值金額只能為50元或者100元。
  • 若輸入50元紙幣,並選擇充值50元,完成充值后退卡,提示充值成功。
  • 若輸入50元紙幣,並選擇充值100,提示輸入金額不足,並退出50元。
  • 若輸入100元紙幣,並選擇充值50元,完成充值后退卡,提示充值成功,找零50元。
  • 若輸入100元紙幣,並選擇充值100元,完成充值后退卡,提示充值成功。
  • 若輸入紙幣后在規定的時間內不選擇充值按鈕,退出輸入的紙幣,並提示錯誤。
  • 若選擇充值按鈕后不輸入紙幣,提示錯誤。

根據需求,分析

  • 找出所有輸入條件編號
  • 找出所有輸出條件編號
  • 找出所有輸入、輸出的制約關系

先來看輸入的條件:

  • 條件1:輸入50元。
  • 條件2:輸入100元。
  • 條件3:選擇充值50元。
  • 條件4:選擇充值100元。

由圖可以看到,條件12之間的關系是互斥的,條件34也是互斥的。
PS:這個圖實際中不用畫,只是在這里便於大家理解。

再來看都有哪些輸出:

  • a. 完成充值、退卡。
  • b. 提示充值成功。
  • c. 找零(包括退錢,比如投50,充100,要把錢吐出來)。
  • d. 提示錯誤。

再來看它們的組合情況:

  • 輸入可以組合的情況:
    • 條件1和條件3可以組合。可以得出輸出a和b組合。
    • 條件1和條件4可以組合。
    • 條件2和條件3可以組合。
    • 條件2和條件4可以組合。
    • 條件1、2、3、4可以單獨出現。
  • 輸入不可以組合的情況:
    • 條件1和條件2不能組合。
    • 條件3和條件4不能組合。
  • 輸出可以組合的情況:
    • 輸出a和b必須組合。
    • 輸出a、b、c可以組合。
    • 輸出c、d可以組合。
    • 輸出d可以單獨存在。
  • 輸出不可以組合的情況:
    • 輸出a和d不能組合。
    • 輸出b和d不能組合。

由上面的分析得出,哪些條件可以組合在一起,哪些條件不能組合在一起。並且根據上面的輸入輸出組合,可以畫出它們的關系圖:

  • 條件1和條件3可以組合,得出輸出a和b組合。


根據上面的圖可以制作出對應的表格

表格的每一列都是一條測試用例。
PS:其實,這個表格才是我們想要的,只是通過圖更能直觀感受它們之間的因果關系,重復:因果圖只是中間產品,我們借助圖來完成表格,其實你不必畫這個圖。

  • 條件1和條件4可以組合,得出輸出c和d組合。

表格及后續的表格,我就不一一貼出來了。

  • 條件2和條件3可以組合,得出a、b、c組合。

  • 條件2和條件4可以組合,得出輸出a和b組合。

  • 條件1單獨出現,得出c和d組合。

  • 條件2單獨出現,得出c和d組合。

  • 條件3單獨出現,得出d組合。

  • 條件4單獨出現,得出d組合。

上述各因果圖匯總如下:

看着是不是瘋了?所以,這種因果圖只是輔助我們理解,不是必須要畫出來的。當我們熟悉了之后,這個圖就出現在我們心里了,所謂的手中無圖在心中(mmp,我連我自己都騙!)。

最終的表格就是這個樣子了。

判定表

因果圖只是一種輔助工具,我們通過因果圖分析出一個表,這個表就是判定表,然后通過判定表編寫測試用例。但是有的時候,畫因果圖非常麻煩,影響測試效率,所以,我們很多時候都是直接寫判定表,進而編寫測試用例。

判定表的組成

  • 條件樁:問題的所有條件,即所有的條件組合。
  • 動作樁:問題的所有輸出,即所有的輸出組合。
  • 條件項:針對條件樁的取值。
  • 動作項:條件項的各種取值情況下的輸出結果。

判定表制作步驟

  • 列出所有的條件樁和動作樁。
  • 填入條件項與動作項,得到初始判定表。
  • 簡化判定表(合並相似規則(相同動作))。

示例:好學生判定

在遵紀守法的前提下:

  • 學習好是好學生。
  • 品德好是好學生。
  • 只要違法亂紀就是絕對不是好學生;成績和品德只有要有一項,再加上遵紀守法也是好學生。

我們根據條件列出判定表:

當然,還可以合並一些條件,比如說,只要遵紀守法再加學習和成績二選一都算是好學生;另外,只要不遵紀守法,學習再好,品德再高也不算好學生。所以,我們可以合並整理一下:

注意:合並使用-,表示無關條件,選什么都不影響結果。雖然在一定程度上,減少了表格列舉數量,但是-帶來了條件模糊的情況(比如用例5、6、7、8中,在編寫用例的時候,還是要查詢-代表的條件),所以,盡量還是按照原來的表格一一列舉,這有助於用例的編寫。

場景法

場景法就是模擬用戶操作軟件時的場景,主要用於測試系統的業務流程。

  • 當接到一個測試任務時,我們並不關注某個控制的邊界值,等價類是否滿足要求。而是要關注它的主要功能和業務流程是否正確實現,這就需要使用場景法來完成測試。
  • 當業務流程沒問題時,即軟件的主要功能沒有問題時,我們再重新從邊界值、等價類方面對軟件進行測試。

在冒煙測試時也主要采用場景法進行測試。

用例場景定義

在場景法中有兩個重要的概念:

  • 基本流:按照正確的業務流程來實現一條操作路徑,即模擬正確的操作流程。
  • 備選流:導致程序出現錯誤的操作流程,即模擬錯誤的操作流程。

用例場景使用來描述流經用例路徑的過程,這個過程從開始到結束遍歷用例中所有的基本流和備選流。

用例場景產生的背景

現在的軟件幾乎都是由事件觸發來控制流程的,事件觸發時的情景便形成了場景,而同一事件因不同的觸發順序和處理結果形成事件流。

將這種在軟件設計方面的思想引入到軟件測試中,生動的描繪出時間觸發時的情景,有利於測試設計者測試用例,同時測試用例也更容易得到理解和執行。

  • 在使用場景法設計測試用例時,需要覆蓋系統用例中的主成功場景擴展場景。並且需要適當補充各種正反面的測試用例和考慮出異常場景的情形。
  • 當使用場景測試軟件沒有問題時,可以再使用邊界值、等價類划分法等測試方法對軟件進行更加細致、完整的測試。

案例:測試QQ登錄功能

QQ登錄有以下情景:

  • 賬號、密碼無誤,點擊登錄,程序能正常登錄。
  • 賬號正確、密碼錯誤,點擊登錄,程序給出錯誤提示。
  • 賬號正確、不輸入密碼,點擊登錄,程序給出錯誤提示。
  • 不輸入賬號和密碼,點擊登錄,程序給出錯誤提示:“請您輸入賬號后登陸”。
  • 不輸入賬號,輸入正確的密碼,點擊登錄,程序給出錯誤提示。
  • 輸入錯誤的賬號,正確的密碼,點擊登錄,程序給出錯誤提示。

其實,場景法很簡單,我們只需要將每一個業務需求,當成測試用例就可以了。

我們來實現相應的用例:

用例編號 場景(條件) 賬號 密碼 預期結果 是否提bug
1 賬號、密碼無誤 Y Y 程序正常登錄
2 賬號正確、密碼錯誤 Y N 程序給出錯誤提示
3 賬號正確、不輸入密碼 Y 程序給出錯誤提示
4 不輸入賬號和密碼,點擊登錄 請您輸入賬號后登陸
5 不輸入賬號,輸入正確的密碼 Y 程序給出錯誤提示
6 輸入錯誤的賬號,正確的密碼 N Y 程序給出錯誤提示

總結:只要把需求一條一條的列出來,當成測試用例。再增加寫注意事項,當然,一般產品經理也會提供這些注意事項。

流程分析法

流程分析法主要是針對測試場景類型,屬於流程測試場景的測試項下的一個測試子項進行設計。是從白盒測試設計方法中的路徑覆蓋分析法借鑒過來的一種方法。

  • 在白盒測試中,路徑就是指函數代碼的某個分支組合,路徑覆蓋法需要構造足夠的用例,以覆蓋函數的所有代碼路徑。
  • 在黑盒測試中,若將軟件系統的某個流程看成路徑的話,則可以針對該路徑使用路徑分析法設計測試用例。

優點

  • 降低了測試用例的設計難度,只要搞清楚各種流程,就可以設計出高質量的測試用例來,而不需要太多測試方面的經驗。
  • 在測試時間較為緊迫的情況下,可以有的放矢的選擇測試用例,而不用完全根據經驗來取舍。

流程分析法的實施步驟

  • 詳細了解需求。
  • 根據需求說明或界面原型,找出業務流程的各個頁面以及各個頁面之間的流轉關系。
  • 畫出業務流程,由產品經理使用Axure軟件制作。
  • 寫用例,覆蓋所有的路徑分支。

示例:ATM機取款

我們按照剛才的實施步驟來:

  • 詳細了解需求。
  • 找出業務流程的各個頁面以及各個頁面之間的流轉關系。
    • 用戶向ATM機插入銀行卡。
    • 用戶輸入銀行卡密碼。
    • 用戶輸入取款金額。
    • 銀行服務器響應ATM機......點鈔......扣除用戶的余額.....出鈔.....
    • 用戶取款,退卡
  • 畫出業務流程:

  • 用例設計,寫用例,覆蓋所有的路徑分支。
    • 需求描述及流程圖中,ATM取款機的提示信息對應於測試用例中的預期輸出部分,用戶的操作對應測試用例中的測試步驟部分。原則是一條有效路徑使用一個測試用例覆蓋。
    • 依據業務流程圖確定測試路徑,即需要測試的業務流程。其主要包含三個方面:
      • 正常流程,取款成功(基本流程):對應一次性取款成功。
      • 異常流程,取款失敗(分支流程):對應取款失敗,包括退卡、吞卡。
      • 異常流程,取款成功(循環流程):對應取款中間出現意外,比如密碼輸入錯誤,但是最終成功取錢的情況。

流程分析法總結

  • 流程分析法適用於有先后順序的測試。常用於業務流程測試、安裝流程測試等。
  • 流程分析法重點在於測試流程。因此,一般每個流程用一個測試用例驗證。
  • 流程測試沒有問題並不能說明系統功能沒有問題,還需要針對每步功能進行測試。對於包含復雜流程的系統,只有功能點和處理流程都進行測試覆蓋,才算是比較充分的測試。

錯誤推測法(經驗法)

錯誤推測法是指利用直覺經驗猜測出出錯的可能類型,有針對性的列舉出程序中所有可能的錯誤和容易發生錯誤的地方。它是骨灰級測試大佬喜歡使用的一種測試用例設計方法。

基本思想

基本思想是列舉出可能犯的錯誤或錯誤易發生的清單,然后根據清單編寫測試用例;這種方法很大程度上是憑經驗進行的,即憑人們對過去所作測試結果的分析,對所揭示缺陷的規律性作直覺的推測來發現缺陷。

采用錯誤推測法,最重要的是要思考和分析測試對象的各個方面,多參考以前發現的Bug的相關數據、總結的經驗,個人多考慮異常的情況、反面的情況、特殊的輸入,以一個攻擊者的態度對待程序,才能夠設計出比較完善的測試用例。

正交測試法

現在講述一個真實的故事:

1992 年AT&T發表了一篇講述在測試過程中使用正交表一個案例研究。它描述了對PC(IBM格式)和StarMail(基於局域網的電子郵件軟件)做回歸測試:

  • 最初制定的測試計划是用18周的的時間執行1500個測試用例。但是,開發推遲了,測試時間被壓縮到僅僅8周時間。
  • 測試負責人采取另外一個測試方案和計划,即2個人8周的時間測試1000個測試用例,但是他不敢保證測試的質量,對這些用例檢測缺陷的能力不放心。
  • 為了減輕這種不確定性的問題,他用正交表法重新設計了測試用例,此時測試用例只有422個。用這422個測試用例去測試發現了41個缺陷,開發人員修復缺陷,然后軟件就發布了。
  • 在使用的兩年時間內,凡被測試到的領域都沒有再發現缺陷,因此在發現缺陷這方面,此測試計划是100%有效。
  • 據測試負責人估計,如果AT&T采用1000個測試用例的測試計划,可能僅僅只發現這些缺陷中的32個。

與最初的計划相比,用正交表設計測試用例執行工作量不到50%,但卻多發現28%的缺陷,而且測試人員個人的效率也增加了。

先來看需求。

例如,我們測試字體屬性設置程序。

上圖所示,在字體設置的窗口中,由若干個控件(字體、字形、字體顏色、字號),每個控件中有多個取值。比如:

  • 字體:仿宋、黑體、楷體。
  • 字形:常規、加粗、傾斜。
  • 字號:12、14、16。
  • 字體顏色:紅色、綠色、藍色。

在測試時,要考慮這些控件的組合情況,它們會有3的4次方種(81)組合。

由於組合量太大,不可能為每一種組合都創建測試用例。如何采用最少的測試用例集合獲得最大的測試覆蓋率——采用正交排列法。

什么是正交表?

在正式介紹正交測試法,我們先來了解兩個概念:

  • 什么是因素(Factor):在一項實驗中,凡欲考察的變量稱為因素(變量)。
  • 什么是水平(位級,Level):在實驗范圍內,因素被考察的值稱為水平(變量的取值)。

正交表是一個二維表格,它的構成如下:

  • 行數(Runs):正交表中行的個數,即實驗的次數(用例)。

  • 因素數(Factors):正交表中列的個數。

  • 水平數(Levels):任何單個因素能夠取得的值的最大個數。正交表中包含的值為從0到水平數減一從1到水平數

  • 正交表的的表示形式:

    \[L_n(m^k) \]

    • n是表的行數,也就是需要測試組合的次數。

    • k是表的列數,表示控件的個數(因素數或因子數)。

    • m是每個控件包含的取值個數(各因素的水平數,即各因素的狀態數)。

    • 例如我們之前的字體屬性程序的需求中,可以這么列:

\[L_9(3^4) \]

  • 有4個控件。

  • 每個控件有3個取值。

  • 9為需要測試的組合個數。

  • 也稱為4因素3水平。

什么是正交表測試法?

正交測試源於正交實驗設計方法。

正交試驗設計方法是一種研究多因素多水平的實驗設計方法,它根據正交性從全面實驗中挑選出部分有代表性的點進行試驗,這些有代表性的點具備了均勻分散,齊整可比的特點。

正交試驗設計方法一般使用已經造好了的正交表格來安排實驗並進行數據分析。

正交測試法與正交實驗設計方法類似,也使用了已經造好的正交表格來生成測試用例。它簡單易行,應用性較好。

正交表測試法的適用范圍

正交表測試法適用於輸入條件相互獨立,並且需要對輸入的各種組合進行測試的場合。

正交表的正交性

  • 整齊可比性:在同一張正交表中,每個因素的每個水平出現的次數是完全相同的。由於在實驗中每個因素的每個水平與其它因素的每個水平參與實驗的幾率是完全相同的,這就保證了在各水平中最大程度的排除了其他因素水平的干擾。因而能有效的進行比較和作出展望。
  • 均衡分散性:在同一張正交表中,任意兩列(兩個因素)的水平搭配(橫向形成的數字對)是完全相同的。這就保證了實驗條件均衡的分散在因素水平的完全組合中,因而具有很強的代表性。

查詢正交表

當然,我們無需自己去設計正交表,可以使用人家羅列好的正交表,我們只需根據被測程序選擇相應的正交表。

地址1:https://www.cnblogs.com/Neeo/articles/11315875.html

地址2:https://www.york.ac.uk/depts/maths/tables/orthogonal.htm

地址3:http://support.sas.com/techsup/technote/ts723_Designs.txt

ps:正交表是經過嚴格的數學推理得來的!

正交測試用例設計步驟

  • 根據所測程序中控件的個數(因素)以及每個控件的取值個數(水平),選取一個合適的正交排列表。
  • 將控件及其取值列舉出來,並對其進行編號。
  • 將控件及其取值映射到正交排列表中。
    • 把正交排列表中的ABCD(因子)分別替換成4個控件。
    • 把每列中的1,2,3(狀態)分別換成這個控件的3個取值(水平),排列順序要按照表中給出的順序。
  • 根據映射好的正交排列表編寫測試用例。

示例1:字體屬性設置程序

現在,讓我們使用正交表完成剛才的需求:

  • 步驟1,根據被測程序中的控件個數以及每個控件的取值個數,選取一個合適的正交表。

    • 由剛才的需求我們分析出:

      • 有4個控件(因素):字體、字形、字體顏色、字號。
      • 每個控件有3個取值(水平)。
      • 所以我們選擇

      \[L_9(3^4) \]

我們自己整理的控件表:

編號 字體 字形 字體顏色 字號
1 仿宋 常規 紅色 12
2 黑體 加粗 綠色 14
3 楷體 傾斜 藍色 16
  • 步驟2,把控件及其取值列舉出來,並對取值進行編號。也就將我們手動整理的控件表與正交表建立映射:
列號 1 2 3 4
試驗號
1 1 1 1 1
2 1 2 2 2
3 1 3 3 3
4 2 1 2 3
5 2 2 3 1
6 2 3 1 2
7 3 1 3 2
8 3 2 1 3
9 3 3 2 1
  • 步驟3,把控件及其取值映射到正交表中:
用例號↓ 字體 字形 字體顏色 字號 預期結果 是否提bug
1 仿宋 常規 紅色 12
2 仿宋 加粗 綠色 14
3 仿宋 傾斜 藍色 16
4 黑體 常規 綠色 16
5 黑體 加粗 藍色 12
6 黑體 傾斜 紅色 14
7 楷體 常規 藍色 14
8 楷體 加粗 紅色 16
9 楷體 傾斜 綠色 12

依次類推,把映射好的正交排列表中的每一行,轉換成一條測試用例。

這是進行測試的最少組合數量,但是,在測試中有72種(81-9)組合沒有測試到。當然,如果時間允許,應該再補充一些用例。因為遺漏的組合越多,存在缺陷的可能性就越大。(時間問題!內測、公測)

示例2:114系統查詢企業單位

我們再來看一個示例,114系統查詢企業單位。

由上圖可以發現,有5個因素,每個因素有個兩個水平:

  • 音形碼:填(1)、不填(1)
  • 拼音碼:填(1)、不填(1)
  • 路名碼:填(1)、不填(1)
  • 行業類別:填(1)、不填(1)
  • 特征碼:填(1)、不填(1)

手動整理一下:

編號 音形碼 拼音碼 路名碼 行業類別 特征碼
1
2 不填 不填 不填 不填 不填

選擇正交表:

  • 表中的因素數>=5
  • 每個因素數的水平數>=2
  • 那么得到的公式就是

\[L_8(2^5)---L_8(2^7) \]

  • 我們去查詢正交表,會發現沒有一個2的5次方的正交表,所以我們選擇稍微大一級別的。
列號 1 2 3 4 5 6 7
試驗號
1 1 1 1 1 1 1 1
2 1 1 1 2 2 2 2
3 1 2 2 1 1 2 2
4 1 2 2 2 2 1 1
5 2 1 2 1 2 1 2
6 2 1 2 2 1 2 1
7 2 2 1 1 2 2 1
8 2 2 1 2 1 1 2

兩個表都有了,我們建立映射關系:

列號 音形碼 拼音碼 路名碼 行業類別 特征碼 6 7
1 1 1
2 不填 不填 2 2
3 不填 不填 2 2
4 不填 不填 不填 不填 1 1
5 不填 不填 不填 1 2
6 不填 不填 不填 2 1
7 不填 不填 不填 2 1
8 不填 不填 不填 1 2

至於多出來的兩列,我們直接刪掉就可以了。

混合正交表

使用正交法的局限性

  • 目前常見的正交(排列)表只有前面介紹的幾種。
  • 即使是已有的正交表,基本都要求每個控件中取值的個數要相等,這在實際軟件中很少遇到。

沒有現成的正交排列表怎么辦?

通過正交測試法的學習,我們更多的應該學習到一種測試思想,也就是在從所有組合集合中選取測試數據時,應該均勻的選取其中的組合作為測試用例,而不要只在某個局部選取數據。

而類似下面這種情況,也比較常見,我們利用之前的正交表,就不好使了:

體型 年齡段 性別
老人
適中 青年
兒童

如上的實例中,有三個因素(體型、年齡段、性別)。但各自的水平並不一致。這該怎么辦?找不到現成的正交表。那只好用工具來生成了。

正交表生成工具allpairs

install allpairs

該軟件下載參見:https://www.cnblogs.com/Neeo/articles/11318346.html

使用步驟

  • 制作取值表(只列出數據即可,不用編號)
體型 年齡段 性別
老人
適中 青年
兒童
  • 復制取值表的數據,保存到普通的(txt)文檔中,比如t1.txt。注意,每個水平之間以tab做間隔,不要用空格,否則執行會報錯:
Error: The first line of the file must be a tab-delimited list of labels with more than one label in it, and no blank labels.
  • 將文本文件放在allpairs目錄中。然后在該目錄Shift + 鼠標右鍵打開命令行,在命令行中執行:
allpairs.exe t1.txt > t2.txt
allpairs.exe t1.txt > t3.xls

可以生成txt和Excel文件(在allpairs目錄下),生成的文件就是我們想要的測試組合用例了。

用例 體型 年齡段 性別
1 老人
2 青年
3 適中 老人
4 適中 青年
5 兒童
6 老人
7 兒童
8 適中 兒童 ~男
9 青年 ~男

上例中的~男表示填男填女不影響最終結果。

總結

介紹了這么幾個測試方法。我們在實際的測試中,有的放矢的選擇測試方法。

測試方法選擇
通常在確定測試方法時,有以下幾條參考原則:

  • 拿到一個測試任務時,先關注它的主要功能和業務流程、業務邏輯是否正確實現,考慮使用場景法。
  • 需要輸入數據的地方,考慮采用等價類划分法,包括輸入條件和輸出條件的等價划分,將無限測試變成有限測試。
  • 在任何情況下都必須采用邊界值分析法。這種方法設計出的測試用例發現程序錯誤的能力最強。
  • 如果程序的功能說明中含有輸入條件的組合情況,則一開始就應考慮選用因果圖和判定表法。
  • 對於參數配置類的軟件,需要考慮參數之間的組合情況,考慮使用正交排列法選擇較少的組合方式(最少的測試用例獲得最大的的測試覆蓋率)。
  • 對照程序邏輯,檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標准,則應當再補充更多的測試用例。
  • 采用錯誤推斷法再追加測試用例——依靠測試工程師的經驗和智慧。

歡迎斧正,that's all


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM