應用程式設計/測試
軟體測試中有多種方法可用。審查、演練或檢查被稱為靜態測試，而使用給定的一組測試用例執行已程式設計的程式碼則被稱為動態測試。[1][2]
靜態測試通常是隱式的，例如校對，以及當程式設計工具/文字編輯器檢查原始碼結構或編譯器（預編譯器）檢查語法和資料流作為靜態程式分析時。動態測試是在程式本身執行時進行的。為了測試程式碼的特定部分，動態測試可以在程式 100% 完成之前開始，並應用於離散函式或模組。[1][2] 這些的典型技術是使用存根/驅動程式或從偵錯程式環境執行。[2]
靜態測試涉及驗證，而動態測試還涉及確認。[2]
被動測試是指在不與軟體產品進行任何互動的情況下驗證系統行為。與主動測試相反，測試人員不提供任何測試資料，而是檢視系統日誌和跟蹤。他們挖掘模式和特定行為以做出某種決定。[3] 這與離線執行時驗證和日誌分析有關。
探索式測試是一種軟體測試方法，簡要描述為同時學習、測試設計和測試執行。Cem Kaner 在 1984 年創造了這個詞，[4]:2 將探索式測試定義為“一種軟體測試風格，強調個人測試人員的自由和責任，透過將與測試相關的學習、測試設計、測試執行和測試結果解釋視為在整個專案中相互支援的並行活動來不斷最佳化其工作質量”。[4]:36
軟體測試方法傳統上分為白盒測試和黑盒測試。這兩種方法用於描述測試人員在設計測試用例時所持的觀點。一種稱為灰盒測試的混合方法也可以應用於軟體測試方法。[5][6] 隨著灰盒測試（從特定設計元素開發測試）的概念日益突出，黑盒測試和白盒測試之間的“任意區分”在一定程度上消失了。[7]
白盒測試（也稱為清晰盒測試、玻璃盒測試、透明盒測試和結構測試）驗證程式的內部結構或工作原理，而不是暴露給終端使用者的功能。在白盒測試中，使用對系統的內部視角（原始碼）以及程式設計技能來設計測試用例。測試人員選擇輸入來練習程式碼中的路徑並確定適當的輸出。[5][6] 這類似於測試電路中的節點，例如線上測試（ICT）。
雖然白盒測試可以在軟體測試過程的單元、整合和系統級別應用，但它通常是在單元級別完成的。[7] 它可以測試單元內的路徑、整合期間單元之間的路徑以及系統級別測試期間子系統之間的路徑。雖然這種測試設計方法可以發現許多錯誤或問題，但它可能無法檢測到未實現的規範部分或缺失的要求。
- API 測試 - 使用公共和私有 API（應用程式程式設計介面）測試應用程式
- 程式碼覆蓋率 - 建立測試以滿足程式碼覆蓋率的某些標準（例如，測試設計人員可以建立測試以導致程式中的所有語句至少執行一次）
- 故障注入方法 - 有意地引入故障以衡量測試策略的有效性
- 變異測試方法
- 靜態測試方法
程式碼覆蓋率工具可以評估使用任何方法（包括黑盒測試）建立的測試套件的完整性。這使軟體團隊能夠檢查很少測試的系統部分，並確保測試了最重要的功能點。[9] 程式碼覆蓋率作為軟體指標，可以報告為以下內容的百分比：[5][9][10]
- 函式覆蓋率，它報告執行的函式
- 語句覆蓋率，它報告執行完成測試的行數
- 判定覆蓋率，它報告給定測試的 True 和 False 分支是否都已執行
100% 語句覆蓋率確保所有程式碼路徑或分支（在控制流方面）至少執行一次。這有助於確保功能正確，但還不夠，因為相同的程式碼可能會正確或錯誤地處理不同的輸入。[11] 偽測試的函式和方法是那些被覆蓋但未指定的函式和方法（可以刪除其主體而不會破壞任何測試用例）。[12]
黑盒測試（也稱為功能測試）將軟體視為“黑盒”，在不知道內部實現的情況下檢查功能，不檢視原始碼。測試人員只知道軟體應該做什麼，而不是它如何做。[13] 黑盒測試方法包括：等價類劃分、邊界值分析、全對測試、狀態轉換表、決策表測試、模糊測試、基於模型的測試、用例測試、探索性測試和基於規範的測試。[5][6][10]
基於規範的測試旨在根據適用的需求測試軟體的功能。[14] 這種級別的測試通常需要提供詳細的測試用例給測試人員，然後測試人員可以簡單地驗證，對於給定的輸入，輸出值（或行為）是否與測試用例中指定的預期值相同。測試用例圍繞規範和需求構建，即應用程式應該做什麼。它使用軟體的外部描述，包括規範、需求和設計來推匯出測試用例。這些測試可以是功能性的或非功能性的，儘管通常是功能性的。
基於規範的測試可能需要確保功能正確，但不足以防範複雜或高風險情況。[15]
黑盒技術的一個優點是它不需要任何程式設計知識。無論程式設計師可能有什麼偏見，測試人員可能擁有不同的偏見，並且可能強調不同的功能區域。另一方面，有人說黑盒測試“就像在沒有手電筒的黑暗迷宮中行走”。[16] 因為他們不檢查原始碼，所以有些情況下，測試人員會編寫許多測試用例來檢查某些東西，而這些東西本來可以用一個測試用例來測試，或者會留下程式的某些部分未經測試。
這種測試方法可以應用於所有級別的軟體測試：單元、整合、系統和驗收。[7] 它通常包括大多數（如果不是全部）較高級別的測試，但也可能主導單元測試。
元件介面測試
元件介面測試是黑盒測試的一種變體，重點是資料值，而不僅僅是子系統元件的相關操作。[17] 元件介面測試的實踐可用於檢查在各個單元或子系統元件之間傳遞的資料處理，超出了這些單元之間的完全整合測試。[18][19] 傳遞的資料可以被認為是“訊息包”，可以檢查資料範圍或資料型別，對於從一個單元生成的資料，在傳遞到另一個單元之前測試其有效性。介面測試的一種選擇是為傳遞的資料項保留一個單獨的日誌檔案，通常還會記錄時間戳，以便分析數天或數週內在單元之間傳遞的資料的數千個案例。測試可以包括檢查一些極端資料值在其他介面變數作為正常值傳遞時的處理方式。[18] 介面中的異常資料值可以幫助解釋下一個單元中的意外效能。
視覺測試
[edit | edit source]視覺測試的目的是讓開發人員能夠透過以開發人員可以輕鬆找到所需資訊的方式呈現資料來檢查軟體故障發生時的狀況，並且資訊表達清晰。[20][21]
視覺測試的核心思想是，向某人展示一個問題（或測試失敗），而不是僅僅描述它，這會大大提高畫質晰度和理解力。因此，視覺測試需要記錄整個測試過程——以影片格式捕獲測試系統上發生的所有內容。輸出影片透過畫中畫網路攝像頭提供的即時測試人員輸入和麥克風提供的音訊評論進行補充。
視覺測試提供了許多優勢。溝通質量大大提高，因為測試人員可以向開發人員展示問題（以及導致問題的事件），而不是僅僅描述它，並且在許多情況下，不再需要複製測試失敗。開發人員將擁有所有她或他需要的測試失敗的證據，並且可以專注於故障的原因以及如何修復它。
隨機測試和探索性測試是檢查軟體完整性的重要方法，因為它們需要更少的準備時間來實施，而重要錯誤可以很快找到。[22] 在隨機測試中，測試以即興、即興的方式進行，測試人員能夠根據記錄的方法進行測試，然後即興發揮這些測試的變體，從而對缺陷修復進行更嚴格的檢查。[22] 然而，除非嚴格記錄程式，否則隨機測試的侷限性之一就是缺乏可重複性。[22]
灰盒測試
[edit | edit source]灰盒測試（美式拼寫：gray-box testing）是指了解內部資料結構和演算法，以便設計測試，同時在使用者或黑盒級別執行這些測試。測試人員通常可以訪問“原始碼和可執行二進位制檔案”。[23] 灰盒測試還可以包括逆向工程（使用動態程式碼分析）來確定邊界值或錯誤訊息等。[23] 操作輸入資料和格式化輸出不屬於灰盒測試，因為輸入和輸出顯然位於我們稱為被測系統的“黑盒”之外。這種區別在對兩個不同開發人員編寫的兩個程式碼模組進行整合測試時尤其重要，在這種情況下，只有介面暴露給測試。
通過了解軟體工作原理的基本概念，測試人員在從外部測試軟體時可以做出更明智的測試選擇。通常情況下，灰盒測試人員被允許設定一個隔離的測試環境，進行諸如播種資料庫之類的活動。測試人員可以觀察測試產品的狀態，在執行某些操作（例如，對資料庫執行 SQL 語句，然後執行查詢以確保反映了預期的更改）後，測試人員可以觀察測試產品的狀態。灰盒測試基於有限的資訊實施智慧測試場景。這將特別適用於資料型別處理、異常處理等。[24]
測試級別
[edit | edit source]軟體測試中主要有 4 個級別：[25]
1. 單元測試 - 這檢查軟體元件是否滿足功能。它是系統或應用程式中最小的可測試部分，可以編譯、連結、載入和執行。這種測試有助於分別測試每個模組。目標是透過分離來測試軟體的每個部分。它檢查元件是否滿足功能。這種測試由開發人員執行。
2. 整合測試 - 這檢查資料從一個模組到另一個模組的流程。整合意味著組合。例如，在這個測試階段，不同的軟體模組被組合在一起並作為一個組進行測試，以確保整合後的系統已準備好進行系統測試。整合測試檢查資料從一個模組到另一個模組的流程。這種測試由測試人員執行。
3. 系統測試 - 這評估測試的功能需求和非功能需求。系統測試是在完整的整合系統上執行的。它允許檢查系統是否符合要求。它測試元件的整體互動。它包括負載、效能、可靠性和安全性測試。系統測試通常是驗證系統是否滿足規範的最終測試。它評估測試的功能需求和非功能需求。
4. 驗收測試 - 這檢查規格或合同的要求是否按其交付方式滿足。驗收測試是為找出規格或合同的要求是否按其交付方式滿足而進行的測試。驗收測試通常由使用者或客戶進行。但是，其他利益相關者也可以參與此過程。
測試技術和策略
[edit | edit source]有 5 種重要的軟體測試技術和策略：[26]
1. 邊界值分析 (BVA) - 基於對分割槽邊界進行測試。它包括最大值、最小值、邊界內或邊界外、典型值和錯誤值。通常認為，在定義的輸入值的邊界處比在中心處出現更多錯誤。它也稱為 BVA，並提供了一組用於測試邊界值的測試用例。這種黑盒測試技術是對等價類劃分的補充。這種軟體測試技術基於以下原則：如果系統對這些特定值執行良好，那麼它將對這兩個邊界值之間的所有值執行良好。
邊界值分析指南
- 如果輸入條件限制在值 x 和 y 之間，則應設計包含值 x 和 y 以及高於和低於 x 和 y 的值的測試用例。
- 如果輸入條件是大量值，則應開發需要測試最小值和最大值的測試用例。在此，還測試了最小值和最大值之上的值和之下的值。
- 將指南 1 和 2 應用於輸出條件。它提供反映最小值和最大值的預期輸出。它還測試了以下值或以上值。
2. 等價類劃分 - 這使您可以將測試條件集劃分為應被視為相同的分割槽。這種軟體測試方法將程式的輸入域劃分為資料類別，從中應設計測試用例。這種技術背後的概念是，每個類別的代表值的測試用例等同於同一類別任何其他值的測試。它允許您識別有效和無效的等價類。
3. 基於決策表的測試 - 也稱為因果表。這種軟體測試技術用於響應輸入或事件組合的功能。例如，如果使用者已輸入所有必填欄位，則應啟用提交按鈕。第一步是識別輸出取決於輸入組合的功能。如果輸入組合集很大，則將其劃分為較小的子集，這有助於管理決策表。對於每個函式，您都需要建立一個表並列出所有型別的輸入組合及其相應的輸出。這有助於識別測試人員忽略的條件。
以下是建立決策表的步驟
- 在行中列出輸入。
- 在列中輸入所有規則。
- 用不同的輸入組合填充表格。
- 在最後一行，記下與輸入組合對應的輸出。
4. 狀態轉換 - 這種技術在輸入條件更改時更改被測應用程式 (AUT) 的狀態。這種測試技術允許測試人員測試 AUT 的行為。測試人員可以透過按順序輸入各種輸入條件來執行此操作。在狀態轉換技術中，測試團隊提供正負輸入測試值來評估系統行為。
狀態轉換指南
- 當測試團隊為有限的輸入值集測試應用程式時，應使用狀態轉換。
- 當測試團隊想要測試被測應用程式中發生的事件序列時，應使用該技術。
5. 錯誤猜測 - 這是一種軟體測試技術，基於猜測程式碼中可能存在的錯誤。該技術嚴重依賴經驗，其中測試分析師利用他們的經驗來猜測測試應用程式存在問題的部分。因此，測試分析師必須熟練且經驗豐富才能更好地進行錯誤猜測。該技術統計了可能發生的錯誤或容易出錯情況的列表。然後測試人員編寫一個測試用例來暴露這些錯誤。為了根據這種軟體測試技術設計測試用例，分析師可以使用過去的經驗來識別條件。
錯誤猜測指南
- 測試應使用以前測試類似應用程式的經驗。
- 瞭解被測系統。
- 瞭解典型的實現錯誤。
- 記住以前出現問題的區域。
- 評估歷史資料和測試結果。
測試流程
[edit | edit source]單元測試
[edit | edit source]優點和侷限性
[edit | edit source]- 驗證您的工作 - 透過編寫測試，您可以仔細檢查您所做的事情。單元測試在開發週期的早期發現問題。這包括程式設計師實現中的錯誤以及單元規範中的缺陷或缺失部分。編寫完整的測試集的過程迫使作者考慮輸入、輸出和錯誤條件，從而更清晰地定義單元的預期行為。
- 將程式碼中的關注點分離 - 對程式碼進行單元測試需要您使其可測試。使程式碼可測試通常意味著預先宣告依賴項。這種程式碼結構通常會導致更簡潔的設計和更好的關注點分離。對於未經測試的程式碼，更容易錯過隱式依賴關係，並且類會默默地承擔多種責任。
- 始終最新的文件 - 雖然文件會過時，除非您更新它，但與程式碼一起執行並透過的測試不會過時。如果您編寫乾淨的測試，這些測試可以作為程式碼的常青文件。單元測試提供了系統的一種“活文件”。想要了解單元提供了哪些功能以及如何使用它的開發人員可以檢視單元測試，以瞭解單元介面 (API) 的基本知識。
- 更少的迴歸 - 只要單元測試在程式碼庫中，它們就能有效地捕獲迴歸。
- 重構的安全網 - 雖然單元測試可以捕獲小更改的迴歸，但它們在大型重構中大放異彩。在具有高測試覆蓋率和良好測試的程式碼庫中，重構的工作具有更高的信心。單元測試允許程式設計師在以後重構程式碼或升級系統庫，並確保模組仍然正常工作（例如，在迴歸測試中）。該過程是為所有函式和方法編寫測試用例，以便每當更改導致錯誤時，都可以快速識別它。單元測試檢測可能破壞設計契約的更改。
以下是使用單元測試的侷限性或缺點：[29]
- 使用單元測試，您必須增加需要編寫的程式碼量。通常，您需要編寫一個或多個單元測試，具體取決於事物有多複雜。建議至少要有三個，這樣您就不會只得到相互矛盾的“是”和“否”。對於編寫的每一行程式碼，程式設計師通常需要 3 到 5 行測試程式碼。這顯然需要時間，並且投資可能不值得付出努力。雖然測試程式碼應該相當簡單，但這種測試方法仍然需要更多工作和更多程式碼，這意味著更多時間和更多成本。
- 單元測試不能也不會捕獲程式中的所有錯誤。它不可能測試每條執行路徑或發現整合錯誤和完整的系統問題。單元測試應該與其他軟體測試活動一起完成，因為它們只能顯示特定錯誤的存在或不存在；它們不能證明完全不存在錯誤。為了保證每個執行路徑和每個可能輸入的正確行為，並確保不存在錯誤，需要其他技術，即應用形式方法來證明軟體元件沒有意外行為。
- 單元測試必須是現實的。您希望您正在測試的單元能夠像它作為完整系統的一部分那樣起作用。如果這種情況沒有發生，則測試值和準確性就會受到損害。
應用
[edit | edit source]測試驅動開發
[edit | edit source]測試驅動開發 (TDD) 使用測試作為設計程式碼的方式，先建立測試，然後再編寫任何實際的生產程式碼。然後，您嘗試透過建立滿足測試的生產程式碼來使測試透過。這通常是一個五步過程
- 編寫測試（有些人也稱其為規範）。
- 執行測試並顯示它失敗。（紅色）
- 編寫滿足測試需求的最少生產程式碼。
- 執行測試直到它透過。（綠色）
- 重構。
此過程有時稱為紅綠重構。紅色象徵著失敗，綠色代表透過。[[30]]
優點和侷限性
[edit | edit source]活動
[edit | edit source]關鍵詞
[edit | edit source]驗收測試 - 檢查規範或合同的要求是否按其交付方式滿足。[31]
Alpha 測試 - 在開發結束時進行的測試，專注於模擬真實使用者的體驗。
斷言 - 一個謂詞……與程式中的一個點相關聯，在程式碼執行的該點始終應評估為真。[32]
Beta 測試 - 由軟體應用程式的“真實使用者”在“真實環境”中執行。[33]
夥伴測試 - 兩個夥伴相互合作，在同一個模組中識別缺陷。通常，一個夥伴來自開發團隊，另一個來自測試團隊。夥伴測試有助於測試人員開發更好的測試用例，而開發團隊也可以儘早進行設計更改。這種測試通常在單元測試完成後進行。[34]
覆蓋率 - 用於描述在特定測試套件執行時程式原始碼執行程度的度量。[35]
整合測試 - 檢查資料從一個模組到其他模組的流動。[31]
手動測試 - 一種軟體測試型別，其中測試用例由測試人員手動執行，不使用任何自動化工具。[36]
Pytest - 一個測試框架，允許使用者使用 Python 程式語言編寫測試程式碼。[37]
Pytest 覆蓋率 - PyTest 的一個覆蓋率外掛，用於衡量 Python 程式的程式碼覆蓋率。
重構 - 重構現有程式碼。
迴歸測試 - 重新執行功能性和非功能性測試，以確保在更改後先前開發和測試的軟體仍然可以正常執行。[38]
系統測試 - 評估測試的功能性和非功能性需求。[31]
單元測試 - 檢查軟體元件是否滿足功能要求。[31]
- ↑ a b Graham, D.; Van Veenendaal, E.; Evans, I. (2008). 軟體測試基礎. Cengage Learning. pp. 57–58. ISBN 9781844809899.
- ↑ a b c d Oberkampf, W.L.; Roy, C.J. (2010). 科學計算中的驗證和確認. Cambridge University Press. pp. 154–5. ISBN 9781139491761.
- ↑ Lee, D.; Netravali, A.N.; Sabnani, K.K.; Sugla, B.; John, A. (1997). "被動測試及其在網路管理中的應用". 1997 年國際網路協議會議論文集. IEEE Comput. Soc: 113–122. doi:10.1109/icnp.1997.643699. ISBN 081868061X. S2CID 42596126.
- ↑ a b Cem Kaner (2008), 探索性測試教程 (PDF)
- ↑ a b c d Limaye, M.G. (2009). 軟體測試. Tata McGraw-Hill Education. pp. 108–11. ISBN 9780070139909.
- ↑ a b c d Saleh, K.A. (2009). 軟體工程. J. Ross Publishing. pp. 224–41. ISBN 9781932159943.
- ↑ a b c Ammann, P.; Offutt, J. (2016). 軟體測試入門. Cambridge University Press. p. 26. ISBN 9781316773123.
- ↑ Everatt, G.D.; McLeod Jr., R. (2007). "第七章：功能測試". 軟體測試：貫穿整個軟體開發生命週期的測試. John Wiley & Sons. pp. 99–121. ISBN 9780470146347.
- ↑ a b Cornett, Steve (c. 1996). "程式碼覆蓋率分析". Bullseye Testing Technology. 簡介. 檢索於 2017 年 11 月 21 日.
- ↑ a b Black, R. (2011). 實用軟體測試：成為高效且有效的測試專業人員. John Wiley & Sons. pp. 44–6. ISBN 9781118079386.
- ↑ 舉個簡單的例子，C 函式
int f(int x){return x*x-6*x+8;}只有一個語句。所有針對規範f(x)>=0的測試都將成功，除非恰好選擇了x=3。 - ↑ Vera-Pérez, Oscar Luis; Danglot, Benjamin; Monperrus, Martin; Baudry, Benoit (2018). "偽測試方法的全面研究". Empirical Software Engineering. 24 (3): 1195–1225. arXiv:1807.05030. Bibcode:2018arXiv180705030V. doi:10.1007/s10664-018-9653-2. S2CID 49744829.
- ↑ Patton, Ron (2005). 軟體測試 (第二版). Indianapolis: Sams Publishing. ISBN 978-0672327988.
- ↑ Laycock, Gilbert T. (1993). 基於規範的軟體測試的理論與實踐 (PDF) (論文). 計算機科學系, 謝菲爾德大學. 檢索於 2018 年 1 月 2 日.
- ↑ 巴赫，詹姆斯 (1999 年 6 月). "基於風險和需求的測試" (PDF). Computer. 32 (6): 113–114. 檢索於 2008 年 8 月 19 日.
- ↑ Savenkov, Roman (2008). 如何成為一名軟體測試人員. Roman Savenkov Consulting. p. 159. ISBN 978-0-615-23372-7.
- ↑ Mathur, A.P. (2011). 軟體測試基礎. Pearson Education India. p. 63. ISBN 9788131759080.
- ↑ a b Clapp, Judith A. (1995). 軟體質量控制、錯誤分析和測試. p. 313. ISBN 978-0815513636. 檢索於 2018 年 1 月 5 日.
- ↑ Mathur, Aditya P. (2007). 軟體測試基礎. Pearson Education India. p. 18. ISBN 978-8131716601.
- ↑ Lönnberg, Jan (2003 年 10 月 7 日). 軟體的視覺測試 (PDF) (碩士). 赫爾辛基理工大學. 檢索於 2012 年 1 月 13 日.
- ↑ Chima, Raspal. "視覺測試". TEST Magazine. 存檔自 原文 於 2012 年 7 月 24 日. 檢索於 2012 年 1 月 13 日.
- ↑ a b c Lewis, W.E. (2016). 軟體測試和持續質量改進 (第三版). CRC Press. pp. 68–73. ISBN 9781439834367.
- ↑ a b Ransome, J.; Misra, A. (2013). 核心軟體安全：從源頭開始的安全. CRC出版社. pp. 140–3. ISBN 9781466560956.
- ↑ "SOA測試工具：黑盒、白盒和灰盒" (白皮書). Crosscheck網路. 存檔自 原始版本 於2018年10月1日. 檢索於 2012年12月10日.
- ↑ https://www.guru99.com/levels-of-testing.html
- ↑ https://www.guru99.com/software-testing-techniques.html
- ↑ https://blog.pragmaticengineer.com/unit-testing-benefits-pyramid/
- ↑ 單元測試
- ↑ https://theqalead.com/topics/unit-testing/
- ↑ https://testguild.com/unit-tdd-and-bdd-testing-whats-the-difference/
- ↑ a b c d Guru99 - 測試級別
- ↑ w:斷言_(軟體開發)
- ↑ Guru99 - Alpha/Beta 測試
- ↑ Guru99 - 隨機測試
- ↑ w:程式碼覆蓋率
- ↑ Guru99 - 手動測試
- ↑ Guru99 - PyTest
- ↑ w:迴歸測試