軟體工程/測試簡介
軟體測試是指為了向利益相關者提供有關被測產品或服務的質量資訊而進行的調查。[1] 軟體測試還提供了一個客觀、獨立的軟體檢視，使企業能夠了解和理解軟體實施的風險。測試技術包括但不限於以查詢軟體錯誤為目的執行程式或應用程式的過程。
軟體測試也可以表述為驗證和確認軟體程式/應用程式/產品
- 滿足指導其設計和開發的業務和技術需求；
- 按預期工作； 以及
- 可以以相同的特性實現。
軟體測試，根據所採用的測試方法，可以在開發過程中的任何時間進行。但是，大部分測試工作是在定義了需求並完成了編碼過程之後進行的。因此，測試方法受採用軟體開發方法的支配。
不同的軟體開發模型將在開發過程的不同階段集中測試工作。較新的開發模型，例如敏捷，通常採用測試驅動開發，並在軟體到達正式測試團隊之前將更多測試工作交給開發人員。在更傳統的模型中，大多數測試執行發生在定義需求和完成編碼過程之後。
測試永遠無法完全識別軟體中的所有缺陷。相反，它提供了一種批評或比較，將產品的狀態和行為與先驗資訊（即人們可能識別問題的原則或機制）進行比較。這些先驗資訊可能包括（但不限於）規範、合同、[2]可比產品、同一產品的先前版本、對預期或預期目的的推斷、使用者或客戶期望、相關標準、適用法律或其他標準。
每個軟體產品都有一個目標受眾。例如，影片遊戲軟體的受眾與銀行軟體的受眾完全不同。因此，當一個組織開發或投資軟體產品時，它可以評估軟體產品是否可以被其終端使用者、目標受眾、購買者和其他利益相關者接受。軟體測試是試圖進行這種評估的過程。
NIST 在 2002 年進行的一項研究報告稱，軟體錯誤每年給美國經濟造成 595 億美元的損失。如果進行更好的軟體測試，可以避免超過三分之一的成本。[3]
除錯與測試的分離最初是由 Glenford J. Myers 在 1979 年提出的。[4] 雖然他關注的是破壞性測試（“成功的測試是能夠發現錯誤的測試”[4][5]），但它說明了軟體工程界希望將基本開發活動（如除錯）與驗證活動分離。Dave Gelperin 和 William C. Hetzel 在 1988 年將軟體測試的階段和目標分為以下幾個階段：[6]
- 直到 1956 年 - 以除錯為導向[7]
- 1957-1978 年 - 以演示為導向[8]
- 1979-1982 年 - 以破壞為導向[9]
- 1983-1987 年 - 以評估為導向[10]
- 1988-2000 年 - 以預防為導向[11]
測試的主要目的是檢測軟體故障，以便發現並糾正缺陷。這是一項非平凡的任務。測試不能確定產品在所有條件下都正常執行，只能確定它在特定條件下無法正常執行。[12] 軟體測試的範圍通常包括檢查程式碼以及在各種環境和條件下執行該程式碼，以及檢查程式碼的各個方面：它是否按預期工作，以及它是否需要工作。在當前的軟體開發文化中，測試組織可能與開發團隊分離。測試團隊成員有各種角色。從軟體測試中獲得的資訊可用於糾正軟體開發過程。[13]
功能測試是指驗證程式碼特定操作或功能的活動。這些通常可以在程式碼需求文件中找到，儘管一些開發方法從用例或使用者故事中工作。功能測試傾向於回答“使用者可以這樣做嗎”或“這個特定功能是否有效”的問題。
非功能測試是指與特定功能或使用者操作無關的軟體方面，例如可擴充套件性或安全性。非功能測試傾向於回答諸如“一次可以登入多少人”之類的問題。
缺陷和故障
[edit | edit source]並非所有軟體缺陷都是由編碼錯誤引起的。昂貴缺陷的一個常見來源是需求差距，例如未識別的需求，導致程式設計人員遺漏錯誤。[14] 需求差距的常見來源是非功能性需求，例如可測試性、可擴充套件性、可維護性、可用性、效能和安全性。
軟體故障透過以下過程發生。程式設計師犯了一個錯誤（錯誤），導致軟體原始碼中出現缺陷（故障，錯誤）。如果執行了此缺陷，在某些情況下系統會產生錯誤的結果，從而導致故障。[15] 並非所有缺陷都一定會導致故障。例如，死程式碼中的缺陷永遠不會導致故障。當環境發生變化時，缺陷可能會變成故障。這些環境變化的示例包括在新的硬體平臺上執行軟體、源資料更改或與不同軟體互動。[15] 一個缺陷可能會導致各種各樣的故障症狀。
儘早發現故障
[edit | edit source]人們普遍認為，發現缺陷越早，修復缺陷的成本就越低。[16] 下表顯示了修復缺陷的成本，具體取決於發現缺陷的階段。[17] 例如，如果在釋出後才發現需求中的問題，那麼修復它的成本將是需求評審中發現它時的 10-100 倍。
| 修復缺陷的成本 | 檢測時間 | |||||
|---|---|---|---|---|---|---|
| 需求 | 架構 | 構建 | 系統測試 | 釋出後 | ||
| 引入時間 | 需求 | 1× | 3× | 5–10× | 10× | 10–100× |
| 架構 | - | 1× | 10× | 15× | 25–100× | |
| 構建 | - | - | 1× | 10× | 10–25× | |
相容性
[edit | edit source]軟體故障（真實或感知）的一個常見原因是與其他應用程式軟體、作業系統（或作業系統版本，舊或新）或與原始目標環境有很大差異的目標環境缺乏相容性（例如，打算在桌面上執行的終端或 GUI 應用程式現在需要成為 Web 應用程式，它必須在 Web 瀏覽器中呈現）。例如，在缺乏向後相容性的情況下，這可能會發生，因為程式設計師只在目標環境的最新版本上開發和測試軟體，而並非所有使用者都可能執行該版本。這導致了一個意外的結果，即最新工作可能無法在目標環境的早期版本或在目標環境的早期版本能夠使用的舊硬體上執行。有時可以透過主動地將作業系統功能抽象到單獨的程式模組或庫中來解決此類問題。
輸入組合和前提條件
[edit | edit source]軟體測試的一個非常基本的問題是，即使對於簡單的產品，也不可能在所有輸入和前提條件（初始狀態）組合下進行測試。[12][18] 這意味著軟體產品中的缺陷數量可能非常大，並且在測試中很難找到很少發生的缺陷。更重要的是，質量的非功能維度（它應該是什麼與它應該做什麼）——可用性、可擴充套件性、效能、相容性、可靠性——可能是高度主觀的；對一個人來說足夠有價值的東西，對另一個人來說可能是不可接受的。
靜態測試與動態測試
[edit | edit source]軟體測試有很多方法。審查、演練或檢查被認為是靜態測試，而使用給定的一組測試用例實際執行已程式設計程式碼被稱為動態測試。靜態測試可以（並且不幸的是在實踐中經常被）省略。當程式本身首次使用時（這通常被認為是測試階段的開始），就會進行動態測試。為了測試程式碼的特定部分（模組或離散函式），動態測試可以在程式 100% 完成之前開始。此方法的典型技術是使用存根/驅動程式或從偵錯程式環境執行。例如，電子表格程式本質上是在很大程度上以互動方式（“動態”）進行測試的，結果在每次計算或文字操作後立即顯示。
軟體驗證和確認
[edit | edit source]軟體測試與驗證和確認相關聯：[19]
- 驗證：我們是否正確構建了軟體？（即，它是否與規範相匹配）。
- 確認：我們是否構建了正確的軟體？（即，這是客戶想要的嗎）。
術語驗證和確認在業界通常互換使用；在行業中也常見到這兩個術語被錯誤定義。根據 IEEE 軟體工程術語標準詞彙表
- 驗證是評估系統或元件以確定給定開發階段的產品是否滿足該階段開始時施加的條件的過程。
- 確認是評估系統或元件在開發過程期間或結束時以確定其是否滿足指定要求的過程。
軟體測試團隊
[edit | edit source]軟體測試可以由軟體測試人員完成。直到 1980 年代，“軟體測試人員”一詞被普遍使用，但後來它也被視為一個獨立的職業。關於軟體測試的時期和不同的目標，[20] 已經確立了不同的角色：經理、測試主管、測試設計師、測試人員、自動化開發人員和測試管理員。
軟體質量保證 (SQA)
[edit | edit source]雖然有爭議，但軟體測試是軟體質量保證 (SQA) 過程的一部分。[12] 在 SQA 中，軟體流程專家和審計人員關心的是軟體開發流程，而不是像文件、程式碼和系統這樣的工件。他們檢查和改變軟體工程流程本身，以減少最終交付的軟體中的故障數量：所謂的缺陷率。
什麼是“可接受的缺陷率”取決於軟體的性質；飛行模擬器影片遊戲比實際飛機的軟體具有更高的缺陷容忍度。
雖然與 SQA 關係密切，但測試部門通常獨立存在，並且一些公司可能沒有 SQA 功能。
軟體測試是一項旨在透過對比計算機程式的預期結果與其針對給定一組輸入的實際結果來檢測軟體缺陷的任務。相比之下，QA（質量保證）是實施旨在從一開始就防止缺陷發生的政策和程式。
軟體測試方法傳統上分為白盒測試和黑盒測試。這兩種方法用來描述測試工程師在設計測試用例時所持的觀點。
白盒測試是指測試人員可以訪問內部資料結構和演算法，包括實現這些演算法的程式碼。
- 白盒測試的型別
- 以下列出了幾種白盒測試的型別：
- API 測試（應用程式程式設計介面） - 使用公共和私有 API 測試應用程式
- 程式碼覆蓋率 - 建立測試以滿足程式碼覆蓋率的某些標準（例如，測試設計人員可以建立測試，以使程式中的所有語句至少執行一次）
- 故障注入方法 - 透過引入故障來測試程式碼路徑，從而提高測試覆蓋率
- 變異測試方法
- 靜態測試 - 白盒測試包括所有靜態測試
- 測試覆蓋率
- 白盒測試方法還可以用來評估使用黑盒測試方法建立的測試套件的完整性。這使軟體團隊能夠檢查系統中很少測試的部分，並確保已測試了最重要的功能點。[21]
- 兩種常見的程式碼覆蓋率形式是：
- 函式覆蓋率，報告執行的函式
- 語句覆蓋率，報告為完成測試執行的程式碼行數
它們都返回程式碼覆蓋率指標，以百分比形式度量。
黑盒測試將軟體視為一個“黑盒子”，不瞭解內部實現。黑盒測試方法包括：等價類劃分、邊界值分析、全對測試、模糊測試、基於模型的測試、探索性測試和基於規格的測試。
- 基於規格的測試：基於規格的測試旨在根據適用的需求測試軟體的功能。[22] 因此，測試人員只向測試物件輸入資料，並且只能看到輸出。這種級別的測試通常需要提供完整的測試用例給測試人員，然後測試人員只需驗證對於給定的輸入，輸出值（或行為）是否與測試用例中指定的預期值相同。
- 基於規格的測試是必要的，但不足以防範某些風險。[23]
- 優點和缺點：黑盒測試人員與程式碼沒有任何“關聯”，測試人員的觀點非常簡單：程式碼必須有 bug。利用“問，就會得到”的原則，黑盒測試人員會發現程式設計師沒有發現的 bug。另一方面，黑盒測試被稱為“像在黑暗的迷宮中沒有手電筒一樣”，因為測試人員不知道正在測試的軟體是如何構建的。因此，在某些情況下，（1）測試人員會編寫許多測試用例來檢查本可以只用一個測試用例測試的東西，和/或（2）某些後端部分根本沒有得到測試。
因此，黑盒測試一方面具有“不相關意見”的優點，另一方面具有“盲目探索”的缺點。[24]
灰盒測試是黑盒測試和白盒測試的結合。灰盒測試（美國拼寫：gray box testing）是指利用內部資料結構和演算法來設計測試用例，但在使用者或黑盒級別進行測試。操縱輸入資料和格式化輸出不屬於灰盒，因為輸入和輸出明顯地位於我們稱為測試系統的“黑盒子”之外。當對兩個不同開發人員編寫的兩個程式碼模組進行整合測試時，這種區別尤為重要，因為只有介面會暴露出來進行測試。但是，修改資料倉庫屬於灰盒，因為使用者通常無法更改測試系統之外的資料。灰盒測試可能還包括逆向工程，以確定邊界值或錯誤訊息。
測試通常根據它們在軟體開發過程中的新增位置，或根據測試的具體程度進行分組。
單元測試是指驗證特定程式碼段功能的測試，通常在函式級別。在面向物件的環境中，這通常是在類級別，最小的單元測試包括建構函式和解構函式。[25]
這些型別的測試通常由開發人員在編寫程式碼時（白盒風格）編寫，以確保特定函式按預期工作。一個函式可能有多個測試，以捕捉邊界情況或程式碼中的其他分支。僅靠單元測試無法驗證軟體的功能，而是用來確保軟體使用的構建塊彼此獨立地工作。
單元測試也稱為元件測試。
整合測試是指任何型別的軟體測試，旨在驗證元件之間的介面是否符合軟體設計。軟體元件可以以迭代的方式整合，也可以全部整合在一起（“大爆炸”）。通常，前者被認為是更好的做法，因為它允許更快速地定位和修復介面問題。
整合測試旨在暴露整合元件（模組）之間的介面和互動中的缺陷。逐步將對應於架構設計元素的更大組的測試過的軟體元件整合在一起並進行測試，直到軟體作為一個系統工作。[26]
系統測試測試一個完全整合的系統，以驗證它是否滿足其需求。[27]
系統整合測試驗證系統是否已整合到系統需求中定義的任何外部或第三方系統。[需要引用]
迴歸測試側重於在發生重大程式碼更改後查詢缺陷。具體來說，它試圖發現軟體迴歸或舊的 bug 再次出現。這種迴歸發生在先前正常工作的軟體功能不再按預期工作時。通常，迴歸作為程式更改的意外後果而發生，當新開發的軟體部分與先前存在的程式碼發生衝突時。迴歸測試的常用方法包括重新執行之前執行的測試，並檢查之前修復的故障是否重新出現。測試的深度取決於釋出過程中的階段和新增功能的風險。它們可以是完整的，對於在釋出後期新增的或被認為有風險的更改，也可以是淺層的，如果更改在釋出早期或被認為風險較低，則僅包含每個功能的正向測試。
驗收測試可以指兩種意思之一：
- 冒煙測試是在將新版本引入主要測試流程之前（即在整合或迴歸測試之前）進行的一種驗收測試。
- 客戶在自己的實驗室環境中使用自己的硬體進行的驗收測試稱為使用者驗收測試 (UAT)。驗收測試可以在開發的任何兩個階段之間進行，作為交接過程的一部分。 [需要引用]
Alpha 測試是由潛在使用者/客戶或開發人員現場的獨立測試團隊進行的模擬或實際操作測試。Alpha 測試通常用於現成軟體，作為內部驗收測試的一種形式，在軟體進入 Beta 測試之前進行。 [28]
Beta 測試在 Alpha 測試之後進行，可以被視為一種外部使用者驗收測試。軟體版本（稱為 Beta 版本）會發布給程式設計團隊之外的有限受眾。軟體會發布給多個群體，以便透過進一步測試確保產品幾乎沒有錯誤或缺陷。有時，Beta 版本會向公眾開放，以將反饋範圍擴大到儘可能多的未來使用者。 [需要引用]
存在一些專門的方法來測試軟體的非功能方面。與功能測試（用於確定軟體的正確操作，即與設計要求中定義的預期行為匹配）相比，非功能測試驗證軟體在接收無效或意外輸入時也能正常執行。軟體故障注入（以模糊測試的形式）是非功能測試的一個例子。非功能測試，尤其是針對軟體的測試，旨在確定被測裝置是否能夠容忍無效或意外輸入，從而確定輸入驗證例程和錯誤處理例程的健壯性。軟體故障注入頁面連結了各種商業非功能測試工具；還有一些可用的開源和免費軟體工具可以執行非功能測試。
執行效能測試是為了確定系統或子系統在特定工作負載下的執行速度。它還可以用於驗證和確認系統的其他質量屬性，例如可擴充套件性、可靠性和資源使用情況。負載測試主要關注的是測試在特定負載下能否繼續執行，無論負載是大量資料還是大量使用者。這通常稱為軟體可擴充套件性。當負載測試作為非功能性活動執行時，相關的負載測試活動通常稱為耐力測試。
容量測試是一種測試功能的方法。壓力測試是一種測試可靠性的方法。負載測試是一種測試效能的方法。關於負載測試的具體目標，人們的意見並不一致。負載測試、效能測試、可靠性測試和容量測試等術語通常可以互換使用。
穩定性測試檢查軟體是否可以在可接受的時間段內或超過可接受的時間段內持續良好地執行。這種非功能性軟體測試活動通常稱為負載（或耐力）測試。
可用性測試是用來檢查使用者介面是否易於使用和理解。它是一種針對應用程式使用的方式。
安全測試對於處理機密資料的軟體至關重要，可以防止駭客入侵系統。
軟體的國際化和本地化的一般能力可以透過使用偽本地化來自動測試，而無需實際翻譯。它將驗證應用程式即使在翻譯成新語言或針對新文化（例如不同的貨幣或時區）進行調整後也能正常執行。 [29]
實際翻譯成人類語言也必須進行測試。可能的本地化故障包括
- 軟體通常透過翻譯脫節的字串列表來進行本地化，翻譯人員可能會為含糊的源字串選擇錯誤的翻譯。
- 如果多個人翻譯字串，技術術語可能會不一致。
- 逐字翻譯可能在目標語言中聽起來不合適、生硬或過於技術化。
- 源語言中的未翻譯訊息可能在原始碼中被硬編碼。
- 一些訊息可能在執行時自動建立，結果字串可能不符合語法、功能不正確、誤導性或令人困惑。
- 軟體可能使用源語言鍵盤佈局中沒有功能的鍵盤快捷鍵，但用於在目標語言佈局中鍵入字元。
- 軟體可能不支援目標語言的字元編碼。
- 源語言中合適的字型和字型大小在目標語言中可能不合適；例如，如果字型過小，CJK 字元可能變得無法閱讀。
- 目標語言中的字串可能比軟體能夠處理的字串更長。這可能會導致使用者無法看到部分字串，或導致軟體出現故障。
- 軟體可能缺乏對雙向文字讀取或寫入的適當支援。
- 軟體可能顯示帶有未本地化的文字的影像。
- 本地化後的作業系統可能具有不同命名的系統配置檔案和環境變數，以及不同的日期和貨幣格式。
為了避免這些和其他本地化問題，瞭解目標語言的測試人員必須執行程式，測試所有可能的翻譯用例，以檢視訊息是否可讀、在上下文中是否翻譯正確，並且不會導致故障。
破壞性測試試圖導致軟體或子系統出現故障，以測試其健壯性。
軟體測試的常見做法是，在功能開發完成後，在交付給客戶之前，由獨立的測試人員小組進行測試。 [30]這種做法通常會導致測試階段被用作專案緩衝區，以彌補專案延遲，從而影響了用於測試的時間。 [31]
另一種做法是在專案開始的同時開始軟體測試，並且這是一個持續的過程，直到專案結束。[32]
敏捷或極限開發模型
[edit | edit source]相反，一些新興的軟體學科，如極限程式設計和敏捷軟體開發運動，堅持“測試驅動軟體開發”模型。在這個過程中，單元測試首先由軟體工程師編寫（在極限程式設計方法中通常使用結對程式設計）。當然，這些測試最初會失敗；正如預期的那樣。然後，隨著程式碼的編寫，它會逐步透過測試套件的更大部分。測試套件隨著新故障條件和極端情況的發現而不斷更新，並將它們與開發的任何迴歸測試整合在一起。單元測試與其餘軟體原始碼一起維護，通常整合到構建過程中（將固有互動式測試降級為部分手動構建驗收過程）。這個測試過程的最終目標是實現持續部署，即軟體更新可以頻繁地釋出到公眾。[33] [34]
一個示例測試周期
[edit | edit source]儘管組織之間存在差異，但測試通常有一個週期。[35] 以下示例在採用瀑布開發模型的組織中很常見。
- 需求分析：測試應該從軟體開發生命週期的需求階段開始。在設計階段，測試人員與開發人員一起確定設計的哪些方面是可測試的，以及這些測試的哪些引數有效。
- 測試計劃：測試策略、測試計劃、測試平臺建立。由於測試期間將進行許多活動，因此需要一個計劃。
- 測試開發：測試程式、測試場景、測試用例、測試資料集、用於測試軟體的測試指令碼。
- 測試執行：測試人員根據計劃和測試文件執行軟體，然後將發現的任何錯誤報告給開發團隊。
- 測試報告：測試完成後，測試人員會生成指標並生成有關其測試工作以及測試的軟體是否已準備好釋出的最終報告。
- 測試結果分析：或缺陷分析，通常由開發團隊與客戶一起完成，以確定哪些缺陷應該處理、修復、拒絕（即發現軟體工作正常）或延遲到以後處理。
- 缺陷重測：開發團隊處理完缺陷後，測試團隊會對其進行重測。又稱解決測試。
- 迴歸測試：通常會針對每次新的、修改的或修復的軟體整合構建一個小的測試程式，其中包含一組測試，以確保最新的交付沒有破壞任何東西，並且整個軟體產品仍在正常執行。
- 測試關閉：一旦測試滿足退出標準，與專案相關的關鍵輸出、經驗教訓、結果、日誌、文件等活動將被存檔，並用作未來專案的參考。
自動化測試
[edit | edit source]許多程式設計組越來越依賴自動化測試，特別是那些使用測試驅動開發的組。有許多框架可以編寫測試，持續整合軟體將在每次將程式碼簽入版本控制系統時自動執行測試。
雖然自動化不能複製人類可以做的一切（以及他們想到的所有做事方式），但它對於迴歸測試非常有用。但是，它確實需要一個完善的測試套件，以便真正有用。
測試工具
[edit | edit source]程式測試和故障檢測可以透過測試工具和偵錯程式得到很大程度的幫助。測試/除錯工具包括以下功能
- 程式監視器，允許完全或部分監視程式程式碼，包括
- 指令集模擬器，允許完全指令級別監視和跟蹤設施
- 程式動畫，允許逐步執行並在原始碼級別或機器程式碼中設定條件斷點
- 程式碼覆蓋率報告
- 格式化轉儲或符號除錯，允許檢查程式變數以出錯或在選定的點
- 自動化功能 GUI 測試工具用於透過 GUI 重複系統級測試
- 基準測試，允許進行執行時效能比較
- 效能分析（或效能分析工具）可以幫助突出顯示熱點和資源使用情況
其中一些功能可能已整合到整合開發環境 (IDE) 中。
- 迴歸測試技術是使用一組標準測試，這些測試涵蓋現有的功能，併產生持久的表格資料，並使用 diffkit 等工具將更改前資料與更改後資料進行比較，其中不應該存在差異。檢測到的差異表明意外的功能更改或“迴歸”。
軟體測試中的度量
[edit | edit source]通常，質量僅限於諸如正確性、完整性、安全性等主題，[citation needed]但也可能包括 ISO 標準 ISO/IEC 9126 中描述的更技術性要求，例如能力、可靠性、效率、可移植性、可維護性、相容性和可用性。
有許多常用的軟體度量，通常稱為指標，用於幫助確定軟體的狀態或測試的充分性。
測試工件
[edit | edit source]軟體測試過程可以產生幾個工件。
- 測試計劃
- 測試規範稱為測試計劃。開發人員清楚地知道將執行哪些測試計劃，並將此資訊提供給管理層和開發人員。目的是使他們在開發程式碼或進行額外更改時更加謹慎。一些公司擁有更高層次的文件，稱為測試策略。
- 可追溯性矩陣
- 可追溯性矩陣是一個表，它將需求或設計文件與測試文件相關聯。它用於在源文件更改時更改測試，或驗證測試結果是否正確。
- 測試用例
- 測試用例通常包含唯一識別符號、來自設計規範的需求引用、前提條件、事件、一系列要遵循的步驟（也稱為操作）、輸入、輸出、預期結果和實際結果。臨床定義的測試用例是輸入和預期結果。[36] 這可以像“對於條件 x，您的推導結果為 y”一樣務實，而其他測試用例則更詳細地描述了輸入場景以及可能預期的結果。它有時可能是一系列步驟（但步驟通常包含在一個單獨的測試過程中，該過程可以經濟地針對多個測試用例進行練習），但只有一個預期結果或預期結果。可選欄位是測試用例 ID、測試步驟或執行順序號、相關需求、深度、測試類別、作者以及測試是否可自動化以及是否已自動化的複選框。較大的測試用例還可能包含先決條件或步驟，以及描述。測試用例還應包含一個用於放置實際結果的位置。這些步驟可以儲存在文字處理文件、電子表格、資料庫或其他常用儲存庫中。在資料庫系統中，您還可以檢視以前的測試結果、誰生成了這些結果以及用於生成這些結果的系統配置。這些過去的結果通常儲存在單獨的表中。
- 測試指令碼
- 測試指令碼是測試用例、測試程式和測試資料的組合。最初，該術語源自自動化迴歸測試工具建立的工作產品的產物。如今，測試指令碼可以是手動的、自動化的或兩者的結合。
- 測試套件
- 測試用例集合最常見的術語是測試套件。測試套件通常還包含每個測試用例集合的更詳細說明或目標。它肯定包含一個部分，測試人員在其中識別測試期間使用的系統配置。一組測試用例還可能包含先決條件或步驟，以及對後續測試的描述。
- 測試資料
- 在大多數情況下，使用多組值或資料來測試特定功能的相同功能。所有測試值和可變環境元件都收集在單獨的檔案中並存儲為測試資料。將此資料提供給客戶以及產品或專案也很有用。
- 測試平臺
- 軟體、工具、資料輸入和輸出示例以及配置統稱為測試平臺。
認證
[edit | edit source]現有多個認證專案，旨在支援軟體測試人員和質量保證專家的職業發展。目前沒有任何認證要求申請者證明他們有測試軟體的能力。也沒有任何認證是基於廣泛接受的知識體系的。這導致一些人宣稱測試領域還沒有準備好進行認證。[37] 認證本身不能衡量一個人的生產力、技能或實踐知識，也不能保證他們作為測試人員的能力或專業性。[38]
- 軟體測試認證型別
-
- 考試型：需要透過的正式考試；也可以透過自學學習[例如，ISTQB 或 QAI][39]
- 教育型：講師主導的課程，每門課程都需要透過[例如，國際軟體測試學院 (IIST)]。
- 測試認證
-
- 質量保證研究所 (QAI) 提供的軟體測試認證助理 (CAST)[40]
- 國際軟體測試學院提供的 CATe[41]
- 質量保證研究所 (QAI) 提供的軟體測試認證經理 (CMST)[40]
- 質量保證研究所 (QAI) 提供的認證軟體測試人員 (CSTE)[40]
- 國際軟體測試學院提供的認證軟體測試專業人士 (CSTP)[41]
- K. J. Ross & Associates提供的 CSTP (TM)（澳大利亞版）[42]
- 資訊系統考試委員會提供的 ISEB
- 國際軟體測試資格委員會提供的 ISTQB 認證測試員，基礎級 (CTFL) [43][44]
- 國際軟體測試資格委員會提供的 ISTQB 認證測試員，高階級 (CTAL) [43][44]
- 資訊科學考試研究院提供的 TMPF TMap Next 基礎級[45]
- 資訊科學考試研究院提供的 TMPA TMap Next 高階級[45]
- 質量保證認證
爭議
[edit | edit source]軟體測試的一些主要爭議包括
- 敏捷 vs. 傳統
- 測試人員應該學習在不確定性和持續變化的環境中工作，還是應該以流程"成熟度"為目標？自 2006 年以來，敏捷測試運動在商業領域越來越受歡迎，[49][50]而政府和軍事[51]軟體供應商使用這種方法，但也使用傳統的最後測試模型（例如在瀑布模型中）。[citation needed]
- 探索性測試 vs. 指令碼測試[52]
- 應該在執行測試時同時設計測試，還是應該事先設計測試？
- 手動測試 vs. 自動化測試
- 一些作者認為，測試自動化相對於其價值而言過於昂貴，因此應該謹慎使用。[53] 更具體地說，測試驅動開發指出，開發人員應該在編寫功能程式碼之前編寫 XUnit 型別的單元測試。然後可以將測試視為捕獲和實現需求的一種方式。
- 軟體設計 vs. 軟體實現
- 應該只在最後進行測試，還是在整個過程中進行測試？
- 誰來監督監督者？
- 這個想法是，任何形式的觀察都是一種互動——測試的行為也會影響被測試的物件。[54]
參考文獻
[edit | edit source]- ↑ 探索性測試，Cem Kaner，佛羅里達理工學院，質量保證研究所全球軟體測試年會，奧蘭多，佛羅里達州，2006 年 11 月
- ↑ Leitner，A.，Ciupa，I.，Oriol，M.，Meyer，B.，Fiva，A.，"契約驅動開發 = 測試驅動開發 - 編寫測試用例"，ESEC/FSE'07 論文集：2007 年歐洲軟體工程大會和 ACM SIGSOFT 軟體工程基礎研討會，(杜布羅夫尼克，克羅埃西亞)，2007 年 9 月
- ↑ 軟體錯誤每年給美國經濟造成 595 億美元損失，NIST 報告
- ↑ a b Myers, Glenford J. (1979). 軟體測試的藝術. John Wiley and Sons. ISBN 0-471-04328-1.
- ↑ 公司，人民電腦 (1987). "面向專業程式設計師的軟體工具的 Dr. Dobb's 雜誌". 面向專業程式設計師的軟體工具的 Dr. Dobb's 雜誌. M&T Pub. 12 (1–6): 116.
- ↑ Gelperin, D. (1988). "軟體測試的成長". CACM. 31 (6). ISSN 0001-0782.
{{cite journal}}: 未知引數|coauthors=被忽略 (|author=建議) (幫助) - ↑ 直到 1956 年，它處於以除錯為導向的時期，當時測試通常與除錯相關聯：測試和除錯之間沒有明確的界限。 Gelperin, D. (1988). "軟體測試的成長". CACM. 31 (6). ISSN 0001-0782.
{{cite journal}}: 未知引數|coauthors=被忽略 (|author=建議) (幫助) - ↑ 從 1957 年到 1978 年，出現了以演示為導向的時期，除錯和測試現在被區分開來 - 在這一時期，證明了軟體滿足了需求。 Gelperin, D. (1988). "軟體測試的成長". CACM. 31 (6). ISSN 0001-0782.
{{cite journal}}: 未知引數|coauthors=被忽略 (|author=建議) (幫助) - ↑ 1979 年至 1982 年間，宣佈為以破壞為導向的時期，其目標是查詢錯誤。 Gelperin, D. (1988). "軟體測試的成長". CACM. 31 (6). ISSN 0001-0782.
{{cite journal}}: 未知引數|coauthors=被忽略 (|author=建議) (幫助) - ↑ 1983 年至 1987 年被歸類為以評估為導向的時期：這裡的意圖是在軟體生命週期中提供產品評估和質量衡量。 Gelperin, D. (1988). "軟體測試的成長". CACM. 31 (6). ISSN 0001-0782.
{{cite journal}}: 未知引數|coauthors=被忽略 (|author=建議) (幫助) - ↑ 從 1988 年開始，它被視為以預防為導向的時期，測試旨在證明軟體滿足其規範，檢測故障並預防故障。 Gelperin, D. (1988). "軟體測試的成長". CACM. 31 (6). ISSN 0001-0782.
{{cite journal}}: 未知引數|coauthors=被忽略 (|author=建議) (幫助) - ↑ a b c Kaner, Cem (1999). 測試計算機軟體，第二版. 紐約等：John Wiley and Sons, Inc. pp. 480 頁。 ISBN 0-471-35846-0.
{{cite book}}: 未知引數|coauthors=被忽略 (|author=建議) (幫助) 無效的<ref>標記；名稱 "Kaner1" 定義了多次，內容不同 - ↑ Kolawa, Adam (2007). 自動化缺陷預防：軟體管理最佳實踐. Wiley-IEEE 計算機協會出版社. pp. 41–43. ISBN 0470042125.
{{cite book}}: 未知引數|coauthors=被忽略 (|author=建議) (幫助) - ↑ Kolawa, Adam (2007). 自動化缺陷預防：軟體管理最佳實踐. Wiley-IEEE 計算機協會出版社. p. 86. ISBN 0470042125.
{{cite book}}: 多於一個|pages=和|page=指定 (幫助)； 未知引數|coauthors=被忽略 (|author=建議) (幫助) - ↑ a b 第 1.1.2 節，認證測試員基礎級別大綱，國際軟體測試資格委員會
- ↑ Kaner, Cem (2001). 軟體測試中汲取的教訓：一種以情景為導向的方法. John Wiley & Sons. p. 4. ISBN 0-471-08112-4.
{{cite book}}: 文字 "Wiley" 被忽略 (幫助) - ↑ McConnell, Steve (2004). 程式碼大全 (第 2 版). Microsoft Press. p. 960. ISBN 0-7356-1967-0.
- ↑ 原則 2，第 1.3 節，認證測試員基礎級別大綱，國際軟體測試資格委員會
- ↑ Tran, Eushiuan (1999). "驗證/確認/認證". 在 Koopman, P. (編輯) 中。可靠嵌入式系統主題. 美國：卡內基梅隆大學. 檢索自 2008-01-13.
{{cite book}}: 未知引數|chapterurl=被忽略 (|chapter-url=建議) (幫助) - ↑ 參見 D. Gelperin 和 W.C. Hetzel
- ↑ 簡介，程式碼覆蓋率分析，Steve Cornett
- ↑ Laycock, G. T. (1993). "基於規範的軟體測試的理論與實踐" (PostScript). 英國謝菲爾德大學計算機科學系. 檢索於 2008-02-13.
{{cite journal}}: Cite journal requires|journal=(help) - ↑ Bach, James (1999). "基於風險和需求的測試" (PDF). Computer. 32 (6): 113–114. 檢索於 2008-08-19.
{{cite journal}}: Cite has empty unknown parameter:|coauthors=(help); Unknown parameter|month=ignored (help) - ↑ Savenkov, Roman (2008). 如何成為一名軟體測試人員. Roman Savenkov 諮詢. p. 159. ISBN 978-0-615-23372-7.
- ↑ Binder, Robert V. (1999). 面向物件系統的測試：物件、模式和工具. Addison-Wesley 專業版. p. 45. ISBN 0-201-80938-9.
- ↑ Beizer, Boris (1990). 軟體測試技術 (第二版). 紐約: Van Nostrand Reinhold. pp. 21, 430. ISBN 0-442-20672-0.
- ↑ IEEE (1990). IEEE 標準計算機詞典：IEEE 標準計算機詞彙彙編. 紐約: IEEE. ISBN 1559370793.
- ↑ van Veenendaal, Erik. "軟體測試中使用的術語標準詞彙表". 檢索於 2010 年 6 月 17 日.
- ↑ 全球化循序漸進：面向世界的測試方法。微軟開發者網路
- ↑ e) 軟體測試中的測試階段:-
- ↑ Myers, Glenford J. (1979). 軟體測試的藝術. 約翰·威利父子公司. pp. 145–146. ISBN 0-471-04328-1.
- ↑ Dustin, Elfriede (2002). 有效的軟體測試. Addison Wesley. p. 3. ISBN 0-20179-429-2.
- ↑ Marchenko, Artem (2007 年 11 月 16 日). "XP 實踐：持續整合". 檢索於 2009-11-16.
{{cite web}}: Cite has empty unknown parameter:|coauthors=(help) - ↑ Gurses, Levent (2007 年 2 月 19 日). "敏捷 101：什麼是持續整合？". 檢索於 2009-11-16.
{{cite web}}: Cite has empty unknown parameter:|coauthors=(help) - ↑ Pan, Jiantao (1999 年春季). "軟體測試 (18-849b 可靠嵌入式系統)". 可靠嵌入式系統主題. 卡內基梅隆大學電氣與計算機工程系.
- ↑ IEEE (1998). IEEE 軟體測試文件標準. 紐約: IEEE. ISBN 0-7381-1443-X.
- ↑ Kaner, Cem (2001). "NSF 資助提案“為顯著改善軟體測試學術和商業課程的質量奠定基礎”" (pdf).
- ↑ Kaner, Cem (2003). "測量軟體測試人員的有效性" (pdf).
- ↑ Black, Rex (2008年12月). 高階軟體測試- 第2卷：ISTQB高階認證作為高階測試經理的指南. 聖巴巴拉：Rocky Nook 出版社. ISBN 1933952369.
- ↑ a b c d e 質量保證協會
- ↑ a b 國際軟體測試協會
- ↑ K. J. Ross & Associates
- ↑ a b "ISTQB".
- ↑ a b "ISTQB在美國".
- ↑ a b EXIN：資訊科學考試協會
- ↑ a b 美國質量協會
- ↑ context-driven-testing.com
- ↑ 關於在沒有敏捷方法的情況下采用敏捷特性的文章。
- ↑ “我們都是故事的一部分” 由 David Strom 撰寫，2009 年 7 月 1 日
- ↑ IEEE 關於經驗豐富的經理與專案管理協會的年輕學生在採用敏捷趨勢方面差異的文章. 另見 2007 年的敏捷採用研究
- ↑ Willison, John S. (2004年4月). "敏捷軟體開發，打造敏捷部隊". CrossTalk. STSC (2004年4月). 存檔於 原始地址 於 2005-10-29.
{{cite journal}}: Check date values in:|archivedate=(help) - ↑ IEEE 關於探索性測試與非探索性測試的文章
- ↑ 例如 Mark Fewster, Dorothy Graham：軟體測試自動化. Addison Wesley, 1999, ISBN 0-201-33140-3.
- ↑ Microsoft 開發網路關於此主題的討論