一、測試定義

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、創建測試用例，驗證是否所有的驗證工作都在被執行。

請關注 私信回複：“學習”就可以免費拿到軟件測試學習資料

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!