- before
- 黑、白、灰盒測試
- 白盒測試
- 黑盒測試
- 灰盒測試
- 黑、白、灰盒測試方法總結
- 靜態、動態測試
- 靜態測試
- 動態測試
- 人工測試、自動化測試
- 常見的黑盒測試方法
- 等價類劃分法
- 示例1：計算整數
- 示例2：測試QQ賬號
- 示例3：測試電話號碼
- 示例4：使用者登入
- 邊界值
- 示例1：標題
- 示例2：成績測試
- 示例3：密碼
- 因果圖
- 判定表
- 場景法
- 流程分析法
- 錯誤推測法（經驗法）
- 正交測試法
- 什麼是正交表？
- 什麼是正交表測試法？
- 示例1：字型屬性設定程式
- 示例2:114系統查詢企業單位
- 混合正交表
- 正交表生成工具allpairs
- 總結
- 等價類劃分法
- 返回測試目錄
- 返回隨筆目錄
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表示結果，各節點表示狀態，可取值0或1，0表示某狀態不出現，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元。
由圖可以看到，條件1和2之間的關係是互斥的，條件3和4也是互斥的。
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到水平數。
-
正交表的的表示形式：
Ln(mk)Ln(mk)-
n是表的行數，也就是需要測試組合的次數。
-
k是表的列數，表示控制元件的個數（因素數或因子數）。
-
m是每個控制元件包含的取值個數（各因素的水平數，即各因素的狀態數）。
-
例如我們之前的字型屬性程式的需求中，可以這麼列：
-
-
有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個取值（水平）。
- 所以我們選擇
L9(34)L9(34)
-
我們自己整理的控制元件表：
| 編號 | 字型 | 字形 | 字型顏色 | 字號 |
|---|---|---|---|---|
| 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
- 那麼得到的公式就是
- 我們去查詢正交表，會發現沒有一個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 + 滑鼠右鍵開啟cmd終端，注意，只能是cmd，我測試的powershell執行，生成的結果亂碼，但cmd沒事兒：
allpairs.exe t1.txt > t2.txt
allpairs.exe t1.txt > t3.xls
可以生成txt和Excel檔案（在allpairs目錄下），生成的檔案就是我們想要的測試組合用例了。
| 用例 | 體型 | 年齡段 | 性別 |
|---|---|---|---|
| 1 | 胖 | 老人 | 男 |
| 2 | 胖 | 青年 | 女 |
| 3 | 適中 | 老人 | 女 |
| 4 | 適中 | 青年 | 男 |
| 5 | 瘦 | 兒童 | 男 |
| 6 | 瘦 | 老人 | 女 |
| 7 | 胖 | 兒童 | 女 |
| 8 | 適中 | 兒童 | ~男 |
| 9 | 瘦 | 青年 | ~男 |
上例中的~男表示填男填女不影響最終結果。
總結#
介紹了這麼幾個測試方法。我們在實際的測試中，有的放矢的選擇測試方法。
測試方法選擇
通常在確定測試方法時，有以下幾條參考原則：
- 拿到一個測試任務時，先關注它的主要功能和業務流程、業務邏輯是否正確實現，考慮使用場景法。
- 需要輸入資料的地方，考慮採用等價類劃分法，包括輸入條件和輸出條件的等價劃分，將無限測試變成有限測試。
- 在任何情況下都必須採用邊界值分析法。這種方法設計出的測試用例發現程式錯誤的能力最強。
- 如果程式的功能說明中含有輸入條件的組合情況，則一開始就應考慮選用因果圖和判定表法。
- 對於引數配置類的軟體，需要考慮引數之間的組合情況，考慮使用正交排列法選擇較少的組合方式（最少的測試用例獲得最大的的測試覆蓋率）。
- 對照程式邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，則應當再補充更多的測試用例。
- 採用錯誤推斷法再追加測試用例——依靠測試工程師的經驗和智慧。