【51CTO.com快譯】世界上沒有任何軟件能夠保證是無缺的。但是這不應當成為軟件缺陷的托詞。為了提高產品的質量，確保軟件應用的有效性、以及應用的平穩運行，我們需要進行各種有計劃有步驟的軟件測試。在本文中，我們將通過向您介紹有關軟件測試的基本方面，以幫助您把控軟件質量，并能交付出滿意的產品。

軟件測試簡介

從概念上說，軟件測試是一個評估已開發軟件的功能，審查應用是否滿足既定的要求，識別程序中任何潛在的缺陷，進而提高產品質量的過程。它的輸出是發現目標系統與實際需求之間的差距，以及自身存在的錯誤與缺失。

[[259673]]

在業界，我們通常將軟件測試稱為驗證和確證軟件產品的過程。因此，它關注軟件產品的如下三個方面：

1. 是否滿足那些指導其設計和開發的業務和技術需求
2. 是否能夠按需運行并提供穩定的服務
3. 既定的服務功能是否能夠重復實現

軟件開發生命周期

首先，我們來了解一下軟件開發生命周期(Software Development Life Cycle，SDLC)的概念。它是整個軟件行業用于設計、開發和測試高質量軟件的過程。SDLC旨在規定的時間和成本預算之內，生產出那些滿足甚至超出客戶期望的高質量軟件。下圖概括性地描繪了SDLC所涉及的各個階段。

要求階段

需求的收集和分析是軟件開發生命周期中最重要的階段。業務分析師們會從客戶和用戶處收集他們的業務需求，并在既有的業務需求規范(具體文檔名稱會因組織的不同而有所差異)中記錄這些需求要點。

分析階段

在完成對需求的收集和分析后，下一步就是要定義并記錄產品的規范需求，進而獲得客戶的確認。我們一般需要通過軟件需求規范(Software Requirement Specification，SRS)文檔來實現。SRS一般包含了在項目生命周期中，那些與設計和開發相關的所有產品需求。

設計階段

此階段分為兩個步驟：

1. 高級設計(High-Level Design，HLD)：有時也稱概要設計，它交付的是待開發軟件產品的體系結構，一般由架構師和高級資深開發人員來完成。
2. 低級設計(Low-Level Design，LLD)：有時也稱詳細設計，它描述的是產品的每一項功能、以及每一個組件應該如何運作。一般由高級資深開發人員來完成。

可見，此階段的輸出：高級文檔和低級文檔，將作為下一階段的輸入。

開發階段

所有級別的開發人員(從資深到初級)都參與到該階段當中，著手編寫并構建軟件的相關代碼。

測試階段

軟件在完成編碼之后，會被發送到測試部門，對可能出現的缺陷進行全面的測試。他們既可以手動測試軟件，又可以通過自動化測試工具，以確保軟件的每個組件都能夠正常工作。軟件只有通過了測試，才能得到質量保證，也才能進入下面的實施階段。

部署和維護階段

最終，軟件產品需要交付和部署，以供客戶使用。此階段通常是由部署與實施工程師來完成。而在客戶使用系統與服務的過程中，他們所碰到的任何實際問題，都需要在維護階段，得到持續并及時地解決。

如果您想深入了解上述軟件開發生命周期中有關測試環境的具體內容，請參閱軟件測試生命周期一文(https://www.edureka.co/blog/software-testing-life-cycle/)。下面我們來討論一下所謂的V模型。

驗證和確證模型

V模型是目前使用最為廣泛的軟件開發過程之一。實際上，V模型將測試環節貫穿到了從需求階段到開始實施的整個過程之中。在業界，V模型也稱為驗證和確證模型(verification and validation model)。那么到底什么是軟件測試中的驗證和確證呢?

1. 驗證：是一種靜態分析的技術。它是在不執行代碼的情況下，執行諸如：回顧、檢查、以及逐行審驗之類的測試。
2. 確證：是一種動態分析的技術，它是對代碼執行功能性和非功能性的測試。

在V模型中，測試并不是作為一個單獨離散的階段，而是跟隨著需求階段一起開始，與軟件開發的整個進程同步推進，分不同的步驟對產品開展驗證和確證活動。該模型的階段名稱如下圖所示：

由上圖可見，在V模型的左側是一系列開發活動，其中包括：用戶需求、軟件定義、概要設計、詳細設計、以及軟件編碼;而右側則是一系列對應的測試活動，其中包括：單元測試、集成測試、系統測試、以及驗收測試。因此，左右不同階段的聯系可以簡述為：單元測試著眼于開發出的代碼是否符合詳細設計的要求;集成測試檢查的是各組成組件能否協同工作;系統測試關注的是集成到一起的產品是否符合規格說明的要求;而驗收測試則注重的是產品能否讓最終用戶滿意。

軟件測試方法

通常而言，我們會采取如下三種方法開展軟件的相關測試，它們是：

1. 黑盒測試：測試人員并不知曉被測項目的內部結構、設計、以及實現原理。
2. 白盒測試：測試人員完全知曉被測項目的內部結構、設計、以及實現原理。
3. 灰盒測試：測試人員僅僅知曉被測項目有限的內部功能信息。

軟件測試階段

我們運用軟件測試的不同階段，來對目標軟件系統的每個單元或組件進行審驗。由于系統測試的主要目標就是評估其是否符合既定的開發需求。因此，這些不同的測試階段不但有助于檢查軟件的行為和性能，也能夠識別出其中的缺陷(bug)，以及在整個開發的生命周期中起到一定的協調作用。具體說來，軟件測試分為如下四個階段：

1. 單元測試：通過設定目標軟件的最小測試單位，盡快地找出各個模塊或組件中的明顯錯誤，以提高單塊程序代碼的質量、并減少后期返工的成本。
2. 集成測試：通過測試整個系統能否編譯和構建成功，以發現系統架構和模塊之間、模塊與模塊之間是否存在接口問題，并記錄下測試結果。
3. 系統測試：通過運行整個系統，來根據系統測試用例執行全面測試，驗證并確證系統的功能與性能是否符合需求規格說明中的要求。
4. 驗收測試：在系統安裝部署完成之后，通過邀請客戶參與進來，進而確認軟件系統能否按照既定的要求平穩運行。

軟件測試文檔化

將各項測試用例進行文檔化，將有助于我們評估測試的工作量，以及跟蹤測試的覆蓋率。那么，常用的軟件測試相關文檔包括如下四種：

    1.測試計劃：為目標應用程序提供測試大綱與策略。其中包括：測試的范圍、方法、資源和進度等。具體還會涉及到各階段的測試任務、時間進度安排、測試執行團隊、以及風險揭示等。

    2.測試場景：描述目標的特性、測試的方法、環境的要求、工具的選擇、以及測試的范圍。具體還會涉及到各階段的啟動、停止、完成標準等條件。

    3.測試用例：它是由一組條件或變量所組成，測試人員籍此確定被測系統是否滿足要求，以及能否正常工作。開發測試用例的過程，也有助于發現應用程序在代碼與設計中的問題。因此，在具體測試期間，我們可以設計出許多類型的測試用例。例如：

• 功能性測試用例
• 負面錯誤測試用例
• 邏輯測試用例
• 物理測試用例
• 用戶接口測試用例

     4. 追溯矩陣：也稱為需求追蹤矩陣(Requirement Traceability Matrix，RTM)，它是一張被用于在創建產品的SDLC模型時，草擬各種需求的表格。在實際應用中，我們既可以采取從設計到編碼的前向跟蹤方式，也可以采用相反的向后跟蹤方式。

缺陷管理流程

眾所周知，軟件開發是一個非常復雜的過程。它往往要求團隊成員在嚴格的時間期限內，每天都必須完成大量的代碼編寫工作，因此他們通常沒有太多的時間去考慮如何避免出現錯誤。因此，對于每個軟件開發項目來說，我們都需要有一個能夠檢測錯誤與缺陷，進而及時修復的缺陷管理過程。

缺陷管理，或稱錯誤跟蹤，通常是在產品的測試階段進行的。我們可以通過兩種不同的方式實現缺陷管理，即：開發人員自行測試他們的產品;或邀請用戶參與測試。雖然最終用戶能夠提供不同的視角來識別缺陷，但是他們的識別途徑往往不夠全面。

因此，缺陷管理通常會涉及到如下四個步驟：

1. 檢測與識別缺陷
2. 分析與定位缺陷，進而填寫并提交缺陷報告
3. 提請整改并修復缺陷
4. 驗證修改并記錄缺陷列表

缺陷生命周期

一般而言，缺陷的生命周期是從bug被發現開始，直至它被最終修復，并能確保不再復發為止。不過有時候，根據組織的策略，使用到的軟件開發模型(如敏捷或迭代)，項目的時間表，以及團隊的結構等因素的不同，缺陷的生命周期也可能有所差異?？偟恼f來，它所要經歷的步驟與過程，如下圖所示：

1. 新建：當缺陷被初次遞交時，它處于“新建”狀態。不過，該缺陷可能需要得到進一步的確認。
2. 分配：經由測試人員創建之后，其主管負責人會審核該缺陷的真實性，一旦確認，則會分配給相應的開發人員或團隊接手處理。
3. 打開：開發人員受理該缺陷，著手分析并研發缺陷的修復程序。
4. 修復：當開發人員完成了必要的代碼更改，并驗證了其修復效果之后，他會將缺陷狀態設置為“已修復”，并將缺陷的相關信息回傳給測試團隊。
5. 測試：在此階段，測試人員對開發人員傳回的已更改代碼進行測試，以檢驗缺陷是否已被修復。
6. 驗證：測試人員針對該缺陷展開新一輪的測試。如測試通過，他會將該缺陷的狀態變更為“已驗證”。
7. 重新打開：相反，如果測試未能通過，則測試人員將狀態更改為“重新打開”。該缺陷將再次經歷上述周期。
8. 關閉：如果測試人員最終認為目標軟件中不再存在此類缺陷，他會將錯誤狀態更改為“已關閉”。
9. 重復：如果同一個缺陷被重復提交、或者兩個缺陷屬于同一種錯誤，那么這個缺陷狀態會被設置為“重復提交”。
10. 拒絕：如果開發人員不認為這是一個缺陷，他會拒絕，然后將錯誤的狀態更改為“已拒絕”。
11. 延期：如果缺陷的狀態被置為“延期”，則意味著該缺陷將會在下一個版本中被修復。當然，將缺陷置為“延期”原因有許多，例如：該缺陷的優先級不高，或是時間緊迫，又或是對于軟件不會造成太大的影響。

手動測試與自動化測試

如果選擇手動測試，則意味著我們需要QA測試人員，對目標軟件的每一個測試用例，都采取手動執行的方式，人工提供不同的數據集，并且仔細地記錄下每一個環節的成功與失敗率。

由于需要人工進行測試結果的驗證和輸出的判斷，因此不但費時費力，而且難免會產生人為的疏忽。

不言而喻，自動化測試意味著更高的效率，更少的人力，更低的出錯幾率，以及適用于回歸和功能性測試環節的、更頻繁的執行次數。

例如：對于某個登錄頁面而言，如果我們需要驗證所有登錄嘗試的可能性及其結果，那么我們只需要通過編寫一段測試代碼，就能自行輸入所有可能的數據，執行各種類型的登錄方法，進而判斷并記錄所有登錄嘗試的成敗結果。

[[259674]]

此外，您也可以在不同系統環境，以及不同的瀏覽器中進行模擬測試。而且，您還可以指定在一天中的某個特定時間段，自動生成結果文件及報告。如今，市面上已有許多自動化的測試工具，例如：Selenium等。如果您有興趣，可以通過鏈接https://www.edureka.co/blog/selenium-tutorial，來進一步了解。

以上就是我想向您介紹的有關軟件測試的一些入門知識，希望能夠幫助您建立起相關的知識概念，并能指導您后繼的學習以及測試工作。

原文標題：Software Testing Life Cycle，作者：Sayantini Deb

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】