什麼是軟體測試？入門測試需要具備的理論知識體系（個人總結）

一、測試定義

a、什麼是測試

測試是一個帶著找到錯誤的目的來執行程式或系統的過程。或者，它是任何旨在評估程式或系統屬性和效能的活動，透過這些活動來決定該程式或系統是否符合所要求的結果。

對於軟體來說，它並沒有不同於其他那些接收輸入、產出輸出的物理過程，它不同之處在於以何種方式執行失敗。大多數物理系統執行失敗在一個固定的（相當小）設定方式上。相反的，軟體可以失敗在許多奇怪的方式上。要發現軟體所有不同的失敗方式通常是不太可能的。

b、測試目標

要證明所提供的軟體產品達到了被要求的指標。

軟體能正常執行，沒有任何錯誤或故障（功能上）。

產生高品質的測試案例，進行有效測試，發表正確有幫助的錯誤報告。

c、一個優秀測試案例的特徵

一個好的或者說一個成功的測試案例在於它具有很高的可能性來發現尚未發現的錯誤。

它容易找到程式失敗的方式。

它讓測試捕捉到錯誤的這種可能性變的合理。

它不是多餘的。

它既不是太過簡單也不是太過複雜。

d、測試原則

1、測試是一個帶著找到錯誤的目的來執行程式的過程。測試不應該把“不會有錯誤被發現”計劃在隱性假設中。

2、不僅使用有效的輸入條件進行測試，還要使用無效和意想不到的輸入條件來測試。

3、當遇到一個無效的測試時程式應該產生正確的訊息，當遇到一個有效的測試時程式應該產生正確的結果。

4、在一個或一組模組中存在更多錯誤的可能性與已經找到的錯誤數量，是成正比的。

5、測試時保持軟體靜態。

6、在設計的測試用例集被執行的時候，不能修改程式。

7、使用文件形式來記載測試案例和測試結果

8、如果可能的話提供預期的測試結果。

e、V過程模型總結

V模型是一個軟體開發的過程。V模型揭示了開發生命週期每個階段與測試的關係。

V模型部署了一個結構良好的框架方法。按照這個框架，每個階段都能按照前一階段的詳細文件來執行。測試活動就像測試設計，開始於專案的最開端，放在程式設計之前，這樣就很有可能為工程進度省下一大部分時間。

二、白盒測試與黑盒測試

f、白盒測試

白盒測試基於應用程式程式碼的內部邏輯知識。測試基於程式碼語句、分支、路徑、條件的覆蓋。

測試人員必須知道軟體內部是怎麼工作的，要知道軟體的結構和程式語言，至少要知道程式語言的意義

白盒測試是在一個結構性測試策略下進行的，要求對物件結構的完全訪問，也就是原始碼。

g、黑盒測試

黑盒測試不需要知道軟體內部是如何工作的，也不需要知道軟體的結構、設計、程式碼或測試模組的程式語言。黑盒測試，像其他大多數測試一樣，必須依據一個最終原始檔，比如規格說明書或要求檔案。“你看到的就是你測試的。”它基於需求和功能來測試。

h、白盒測試技術

白盒測試技術包括以下4種

I、程式碼覆蓋

1、段覆蓋：確保對每一句程式碼都測試一次。

2、分支覆蓋或節點測試：覆蓋所有可能的程式碼分支。

3、複合條件覆蓋：對於多個條件，透過多個路徑測試每一個條件，並且透過不同路徑組合來達到這一條件。

II、基本路徑測試

程式碼中每個獨立的路徑都要被測試過。資料流測試是一種方式，即你透過各種可能的計算來跟蹤特定變數，從而透過程式碼定義中間路徑集。資料流測試往往反映相關性，它主要是透過資料序列來操作。簡言之即跟蹤每個資料變數，驗證其使用。這種方法往往會發現錯誤來源於變數使用而不是變數初始化，或者來源於變數宣告而不是使用，等等諸如此類。

III、路徑測試

路徑測試就是定義和覆蓋測試程式碼中所有可能的路徑。這是一項費時的工作。

IV、迴歸測試

測試思路涉及到測試單圈、串聯迴圈、和巢狀迴圈。透過這種方法測試獨立和非獨立程式碼迴圈和程式碼值。

i、黑盒測試技術

為便於理解，將在下面詳細給出黑盒測試主要技術。

I、等價類劃分

等價類劃分是一種軟體測試技術。將軟體單元的輸入資料範圍劃分成若干等價區域，每一個區域編寫一個測試案例。原則上，測試案例的編寫至少覆蓋每個分割槽一次。該技術試圖定義測試用例從而揭示錯誤類，這樣測試案例的總數就相應減少了。

在極少數情況下，等價區域劃分也適用於軟體元件的產出，是具有代表性的，它適用於測試元件的輸入。等價區域劃分常常遵循於輸入屬性需求規格說明書，從而影響測試物件的處理。輸入具有一定的有效輸入範圍和無效輸入範圍。這裡的無效輸入資料不是說資料型別是錯誤的，而是指該輸入資料在某個具體分割槽之外。

舉個等價區域劃分的例子，比如你想要測試範圍在1到10，000之間的某個輸入數字，你不需要一一測試每一個1到10，000之間的數字，你只需使用等價區域劃分的方法，將數字範圍劃分，比如劃分成一位數、兩位數、三位數和四位數，像5、15、555、5555。

II、邊界值分析

邊界值分析是等價區域劃分的擴充套件，它是取等價區域上的邊界值來進行測試。很多錯誤往往就是發生在輸入範圍的邊界值上而不是輸入範圍中間的地方，至於為什麼會這樣還不是完全清楚。正是由於這個原因，邊界值分析發展成了一項測試技術。邊界值分析產生了測試用例的選擇，選擇使用邊界值來進行測試。

邊界值分析是一個測試案例設計技術，是等價區域劃分的補充。邊界值分析不是選擇等價區域內任意的資料，而是選擇區域邊界值作為測試案例。邊界值分析不僅僅關注輸入條件，還從輸出域中產生出測試用例。

舉個邊界值分析的例子，比如測試1到12月之間的某個月份，我們取一個小於0的負資料，取一個1到12之間的有效資料，取一個大於12的資料來進行測試，觀察是否是隻有1到12之間的有效資料被輸入才是可接受的。

III、錯誤猜測

這是一個基於測試者綜合能力的一項軟體測試設計技術。在測試過程中，測試者根據他的經驗、知識和直覺來預測軟體上的錯誤。一些典型的錯誤域常常會發生在空字串、零例項、某些特殊值、字串中的空字元、負數資料上。

儘管過去測試經驗對錯誤猜測來說是很關鍵的基礎，但它們也可能會用不到。容易出錯的情況，有包括資料初始化（例如，重複某個過程，檢視資料是否被正確刪除），錯誤型別資料（例如，負數資料、非數字對數字），真實資料處理（也就是，測試那些透過系統或真實記錄建立的使用資料，因為程式設計師往往會透過建立的資料來反映他們預期的設想），錯誤管理（例如，將多個錯誤進行優先排序，清除錯誤訊息，當遇到某個錯誤時需適當進行資料儲存，錯誤過後程式應當能繼續處理）， 計算（例如，手工計算需比較的專案），重新啟動、恢復（也就是，強制終止一個批處理程式，並且測定重啟/恢復程式是否能工作正常），妥善處理併發程式（也就是，在事件驅動的應用程式上，同時讓多個程式執行，測試程式的處理情況）。

IV、決策表

決策表是一種精確且緊湊塑造複雜邏輯的方式。像if-then-else和switch-case語句那樣，透過條件來執行相應事件。不同於傳統程式語言裡的控制結構，決策表能透過一個直觀的方式將許多獨立的條件和事件關聯起來。

一個決策表通常被分成四個象限，如下圖所示。

每個決策對於一個變數、關係或表明滿足條件選項中的可能值。每一個動作執行一個過程或操作，並且該項指定動作是否（或按什麼順序）按照專案對應的條件選項集執行。

舉例：描述有限項決策表是最簡單的。條件選項是簡單的布林值，並且動作項是檢查標記，表明哪一個給定列中的動作將被執行。一個技術支援公司編寫決策表來診斷印表機問題，問題的瞭解基於客戶透過電話向他們描述的症狀。下面是一個平衡的決策表。

V、因果圖

在軟體測試中，因果圖是一個定向圖，由原因集對映到結果集上。原因可能被認為是程式的輸入，結果可能被認為是程式的輸出。通常，圖表顯示在左邊的節點代表原因，顯示在右邊的節點代表結果。中間可能有中間節點，使用邏輯運算子，如AND 和OR，將輸入結合起來。

三、測試型別

j、單元測試

單元測試的主要目標是測試應用程式中可測試的最小組成部分，可以獨立於軟體的其餘程式碼，測試其是否按照你所希望的在執行。在將每一個單元集合成模組來測試模組間的介面前，應該先分別測試每一個單元。單元測試很重要，很大比例的錯誤都是在單元測試中發現的。

單元測試最常用的方法需要寫入驅動和存根。驅動模擬一個呼叫單元，存根模擬一個被呼叫單元。由於單元測試投資在開發時間上較長，有時會導致將單元測試放在較低的優先順序上，但這樣做往往是錯的。儘管編寫驅動和存根要耗費一定人力和時間，但單元測試展現了一些不可否認的優勢。單元測試允許測試過程自動化，降低了從更復雜的應用程式塊中找到錯誤的難度。因為每個單元都被關注了，所以測試的覆蓋率也往往被提高了。

例如，如果你有兩個單元，想知道將他們集合在一起進行測試所花的成本是否會偏低些，一開始就將它們作為一個整體單元進行測試，錯誤的發生點可能會出現在很多地方：

單元一這裡會出現錯誤嗎？

單元二這裡會出現錯誤嗎？

兩個單元都會出現錯誤嗎？

兩個單元之間的地方會出現錯誤嗎？

會因為測試的缺陷出現錯誤嗎？

將模組直接集合在一起進行測試遠比先獨立測試每一個單元模組，然後再將它們集合在一起進行測試要複雜的多。

驅動和存根可重複使用，在開發週期中不斷髮生的變化可以經常進行重新測試，而無需編寫大量的額外測試程式碼。事實上，這減少了每次編寫驅動和存根的成本，並且對重複測試的成本也更好控制。

k、整合測試

整合測試是單元測試邏輯上的延伸。最簡單的測試形式是，在完成了兩個單元的單元測試後，將這兩個單元組合成一個元件，測試兩單元之間的介面。這裡元件的意思是指多個單元的綜合。在真實的場景中，很多單元被合併成元件，這些元件又被合併成更大的部分。這個想法是測試組合件，最終擴大測試該組模組與別組模組的過程。最終所有模組將並一起進行測試。除此之外，如果程式是多個程式組成，它們應該成對測試，而不是一次性全部一起測試。

整合測試是在將單元結合在一起的時候發現錯誤。透過使用一個測試計劃，測試每一個單元，並在合併單元前確保每個單元的都是ok的。你就會知道在合併單元時發現的錯誤就可能和單元間的介面有關係。利用這種方法，可以將推測錯誤位置的可能性降低到一個簡單的多的分析水平上。

整合測試有很多種方法，以下三種是最常見的：

自上而下的方法：需要測試最高階別的模組，並且先整合起來。這使得在過程中要先測試高層次的邏輯和資料流，往往最小化了驅動的需要。然而，存根的需求使測試管理複雜化。並且在軟體開發生命週期中，低階別的往往在後面測試。自上而下的整合測試另外個不好的地方在於它不支援有限功能的提前釋放。

自下而上的方法：需要測試最低階別的單元，並且先整合起來。這些單元常常被稱為公用模組。透過使用這個方法，在開發過程早期測試公用模組，存根的需要就被最小化了。不過這個方法的缺點就是驅動的需求使測試管理複雜化，並且高階別的邏輯和資料流往往在後面測試。像自上而下的方法一樣，自下而上的方法同樣不支援有限功能的提前釋放。

第三個方法，有時也被稱為傘方法，需要沿著函式資料和控制流路徑來測試。首先，函式的輸入是整合在上面討論的自下而上的模式中。然後，函式的輸出是整合在自上而下的模式中。該方法最主要的優勢在於它支援有限功能的提前釋放。並且它將存根和驅動的需求最小化。該方法潛在的弱點是顯著的，它比其他兩種方法要欠缺系統性，導致需要更多的迴歸測試。

l、驗收測試

使用者驗收測試常常是推出程式之前的最後一步測試。

通常，使用程式的終端使用者會在接受程式前對應用程式進行測試。這種形式的測試使終端使用者對交付到他們手上的應用程式質量更具有信心。該測試也能幫助發現程式在可用性上的缺陷。該測試有兩種測試型別，分別是Alpha測試和Beta測試。

Alpha和Beta測試

Alpha測試在開發員的站點上進行，在發行給外面客戶使用前，先由內部工作人員對業務系統進行測試。

Beta測試在客戶的站點上進行，在發行給別的客戶前，先由一組顧客在他們自己的站點上使用該系統對其進行測試。後者通常被稱為“現場測試”。

m、系統測試

系統測試對軟體整體進行測試。在一個有代表性的企業裡，由程式設計師來做單元測試。這保證了每一個元件都正常工作。整合測試關鍵在於軟體各個部分的成功組合（元件或單元程式碼）。一旦元件被組合到一塊，整個系統就需要進行徹底的測試來保證它達到質量標準。

因此係統測試建立在單元測試和整合測試的基礎上。通常一個專業的測試團隊是有責任做系統測試的。系統測試在質量管理過程中是關鍵性的一步。

為什麼系統測試如此重要？

在軟體開發生命週期中，系統測試在系統作為一個整體進行測試中是第一級的。透過測試系統來檢驗它是否達到功能和技術上的要求。應用程式/系統是在一個很類似於生產環境的環境下進行測試的，那裡應用程式最後要被釋放。系統測試讓我們測試、檢驗並確認產品無論在業務需求還是體系結構上是否都達到標準。

i、效能測試

效能測試是在程式執行下進行的，從某個角度來講，是檢測系統在特定的負載下各方面的執行情況。它也可以用來驗證和核實系統其他質量屬性，如可擴充套件性，可靠性和資源使用率。效能測試是效能工程的一個子集，是一種新興的電腦科學實踐，為提高系統設計和體系結構的效能而努力，做在實際的編碼工作之前。

效能測試可用於不同的目的。它可以證明該系統效能符合標準。它可以透過比較來發現哪個系統執行地好。或者，它可以測量系統或負載的哪部分導致系統執行失敗。在診斷進行中，軟體工程師使用工具，如廓線儀，來測量是裝置或軟體的哪部分導致執行失敗，或者為維持可接受的響應時間來建立吞吐量水平（和閥值）。對一個新系統來說，價效比是至關重要的。效能測試工作始於開發專案的啟動，並且擴充套件到整個專案中。效能缺陷發現的越晚，修復的成本越高。這在功能測試中，情況屬實，效能測試更是如此，原因在於其終端到終端的範圍性質。

ii、迴歸測試

如果軟體的某一部分因為某個原因被修改了，就需要進行測試，測試修正過後的軟體是否按照指定要求在工作，確保軟體沒有被影響並且之前的功能都俱全。這種測試就叫做迴歸測試。

為什麼迴歸測試很重要？

因為任何軟體上的修改都能引起現有的功能遭破壞。軟體元件上的改變可能會影響到別的相關元件。軟體上的一個修正可能會引起其他錯誤，這是很常見的。所有這些都影響了系統的質量和穩定性。因為迴歸測試的目的是為了驗證並確保這一切不會發生，所以是非常重要的。

四、測試過程

n、測試計劃

測試計劃是一個檔案，詳細說明了測試一個系統，如一機器或一軟體的系統方法。該計劃通常包含最終工作流程會是什麼樣子的詳細說明。

它是一份描述測試計劃的檔案，換句話說，即如何執行測試計劃。它通常包括測試物件的羅列、測試人員角色和責任分配、開始測試的前提條件、測試環境、假設、測試執行成功後要做什麼、測試執行失敗後要做什麼，等等。

一個測試計劃描述瞭如何驗證和確保產品或系統滿足其設計規範和其他要求的戰略步驟。通常，測試工程師會對測試計劃做大量準備和投入。

i、測試計劃的目標

測試計劃的目標是提供一套工具，以各種方式來支援測試團隊的工作。這些好處包括：

a、可以減少重要工作被忽略、被誤估計、被忘記的風險

b、可以將工作按照重要性的高低來完成。

c、可以估計該專案（技術和程式性）的風險，並確定是否可以緩解步驟。

d、可以組織安排測試的工作。

e、可以將測試工作的進展情況和該專案作為一個整體來監視。

五、單元測試

單元測試是一個驗證原始碼的個別單位是否正常工作的測試（通常是自動的）。單位是應用程式中最小的可測試部分。在程式程式設計裡，一個單位可能是一段指令、一個函式或者一段程式等等。而在物件導向的程式設計裡，單位可能是一個基數類/父類、抽象類或派生類/子類。

單元測試通常是由軟體開發商來操作，要確保他們編寫的程式碼符合軟體的要求，並且按照開發員意想來執行。

單元測試該測試些什麼呢？

這在很大程度上取決於程式或正在建立的單元的型別。它可能是一個畫面或一個元件或web服務。大致上從以下幾方面來考慮：

a、對於UI畫面，測試用例要能驗證所有需要顯示在螢幕上的螢幕元素。

b、對於UI畫面，測試用例要能驗證所有顯示在螢幕上的標籤或文字的拼寫/字型/大小。

c、建立測試用例，保證單位每行程式碼在一個測試周期中至少被測試一次。

d、建立測試用例，保證條件語句裡每一個條件都被測試過。

e、建立測試用例，測試資料可輸入的最小和最大範圍。例如，引數傳遞，要測試數值型引數的最大輸入值或字串型引數的最長輸入長度。

f、建立測試用例，檢視遇到各種錯誤程式會如何處理。

g、建立測試用例，驗證是否所有的驗證工作都在被執行。

加我VX：ww-51testing   回覆關鍵詞“測試”領取限量軟體測試學習資料哦~~