測試的基本概念和分類

軟件測試階段分類

軟件測試按階段，可劃分以下幾類：

• 單元測試
• 集成測試
• 系統(tǒng)測試
• 回歸測試

單元測試、集成測試、系統(tǒng)測試的比較：

1、測試范疇不同

單元測試屬于白盒測試范疇

集成測試屬于灰盒測試范疇

系統(tǒng)測試屬于黑盒測試范疇

2、測試重點不一樣

單元測試主要測試內部數據結構、邏輯控制、異常處理等

集成測試主要測試模塊間的接口與接口數據傳遞關系，以及模塊組合后的整體功能

系統(tǒng)測試主要測試整個系統(tǒng)相對于需求的符合度

3、檢驗基準不一樣

單元測試主要通過邏輯覆蓋率來評估

集成測試主要通過接口覆蓋率來評估

系統(tǒng)測試主要通過測試用例對需求規(guī)格的覆蓋率來評估

測試人員要編寫的主要文檔有哪些？

• 測試計劃：測試范圍、方法、資源，以及相應測試活動的時間進度安排表的文檔；
• 測試方案：為完成軟件集成特性的測試而進行的設計測試方法的細節(jié)文檔；
• 測試用例：為完成一個測試項的測試輸入、預期結果、測試執(zhí)行條件等因素的文檔；
• 測試報告：執(zhí)行測試結果的文檔；
• 測試日報：每天測試執(zhí)行情況的記錄和總結。
• 用戶指導手冊：教用戶怎么使用軟件的文檔，用途與我們平常買家電的時候附帶的說明書類似，一般情況下這個不歸測試人員編寫，但是有一些小公司可能會讓測試寫這個文檔。

軟件測試過程的幾個模型，簡單了解一下：

V模型：左到右，描述了開發(fā)與測試過程之間的階段對應關系，缺點是不適用于需求變化，靈活性差。

雙V模型/W模型：

優(yōu)點：測試伴隨整個產品開發(fā)周期，測試對象不僅是程序還有需求、設計文檔測試介入較早，及早發(fā)現問題，降低修復成本

缺點：實施起來比較復雜，難度大，對于需求階段和設計階段的測試設計要求較高（計算機技術、業(yè)務知識、管理能力、測試素質等）

為什么要盡早進行測試工作？

按照被測對象的不同，可以分為：

• 白盒測試
• 灰盒測試
• 黑盒測試

白盒測試是依據被測軟件分析程序內部構造，并根據內部構造設計用例，來對內部控制流程進行測試，可完全不顧程序的整體功能實現情況。白盒測試是基于程序結構的邏輯驅動測試。白盒測試發(fā)現問題后解決問題的成本較低。

黑盒測試把被測對象看成一個黑盒，只考慮其整體特性，不考慮其內部具體實現。黑盒測試針對的被測對象可以是一個系統(tǒng)、一個子系統(tǒng)、一個模塊、一個子模塊等。測試人員不需要了解實現的細節(jié)，包括特定的編程語言；從用戶的視角進行測試，很容易被大家理解和接受；有助于暴露任何與規(guī)格不一致或有歧義的問題；壓力測試和負載測試都屬于黑盒測試。

灰盒測試就是介于白盒和黑盒之間的一種。既要關注整體特性，又要關注內部具體實現。

按照是否運行被測對象，可以劃分為：

• 靜態(tài)測試
• 動態(tài)測試

靜態(tài)測試：不運行被測試的軟件系統(tǒng)，而是采用其他手段和技術對被測試軟件進行檢測的一種測試技術。例如：代碼走讀、文檔評審、代碼掃描等都是靜態(tài)測試的范疇。

動態(tài)測試：按照預先設計的數據和步驟去運行被測軟件系統(tǒng)，從而對被測軟件系統(tǒng)進行檢測的一種測試技術。

按照是否借助工具劃分：

• 手工測試
• 自動化測試

人工測試：測試活動（如評審、測試設計、測試執(zhí)行等）由人來完成，狹義上是指測試執(zhí)行由人工完成，這是最基本的測試形式

自動化測試：一般是指通過計算機模擬人的測試行為，替代人的測試活動，狹義上是指測試執(zhí)行由計算機來完成

自動化測試的意義：

提高回歸測試的效率，可以運行更多更頻繁的測試，比如冒煙測試?？梢詧?zhí)行手工測試困難或不可能做的測試，比如大量的重復操作或者集成測試。

自動化測試的限制：

不能取代手工測試，自動化測試只能提高測試效率，不能提高測試有效性，即不可能發(fā)現更多缺陷，手工測試比自動測試發(fā)現的缺陷更多；

對測試設計依賴性極大，測試設計的不好會遺漏問題；工具本身并不具備想象力，自動化測試對軟件開發(fā)具有很大的依賴性，開發(fā)上出現變更可能導致前面的自動化測試完全失效。

測試用例設計方法（等價類+邊界值）

常見的用例設計方法

• 等價類劃分法（適用于輸入項少，輸入項的屬性或者特性相同）
• 邊界值分析法（適用于有范圍約束的情況）
• 判定表法（適用于有明顯的條件及其對應的動作的情況）
• 因果圖法
• 狀態(tài)遷移圖法（適用于狀態(tài)隨事件而改變的情況）
• 場景分析法（適合于由事件觸發(fā)而形成的使用場景，同一事件不同的觸發(fā)邏輯形成不同的場景，從而形成不同的業(yè)務流程（路徑），根據覆蓋不同的路徑來設計測試用例）
• 正交實驗法（適用于多條件或多輸入情況）
• 異常分析法（適用于大多數軟件，從經驗上判斷容易出現錯誤或缺陷的地方設計用例）
• 錯誤猜測法

等價類劃分法

是把所有可能的輸入數據,即程序的輸入域劃分成若干部分子集,然后從每一個子集中選取少數具有代表性的數據作為測試用例。該方法是一種重要的,常用的黑盒測試用例設計方法。

• 有效等價類：有效等價類是程序規(guī)格說明有意義，合法的輸入數據
• 無效等價類：無效等價類是程序規(guī)格說明無意義，不合法的輸入數據。

等價類法設計測試用例的步驟:

1、為每個輸入劃分等價類，得到等價類表，為每個等價類規(guī)定一個唯一編號

2、設計一個測試用例，使其盡可能多的覆蓋所有尚未覆蓋的有效等價類。重 復這一步驟，使得有效等價類均被測試用例所覆蓋

3、設計一個測試用例，使其只覆蓋一個無效等價類。重復這一步驟使得所有無效等價類均被覆蓋

等價類劃分的原則

1、在輸入條件規(guī)定了取值范圍或值的個數的情況下,則可以確立一個有效等價類和兩個無效等價類.

2、在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”的條件的情況下,可確立一個有效等價類和一個無效等價類.

3、在輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類.

4、在規(guī)定了輸入數據的一組值假定n個,并且程序要對每一個輸入值分別處理的情況下,可確立n個有效等價類和一個無效等價類.

5、在規(guī)定了輸入數據必須遵守的規(guī)則的情況下,可確立一個有效等價類符合規(guī)則和若干個無效等價類從不同角度違反規(guī)則.

6、在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步的劃分為更小的等價類.

等價類表可以參考下圖所示：

等價類劃分法用例設計實戰(zhàn)：

根據下面給出的規(guī)格說明，進行測試用例的設計。

一個程序讀入3個整數，把這三個數值看作一個三角形的3條邊的長度值。程序輸出：說明這個三角形是普通的、是等腰的、還是等邊的。

等價類劃分如下：

3條邊分別為A，B，C。滿足：A>0，B>0，C>0，且A+B>C，B+C>A，A+C>B；

等腰需滿足A=B，或B=C，或A=C ；

等邊需滿足A=B，且B=C，且A=C ；

最終輸出的場景如下：

邊界值分析法

邊值分析方法的理論基礎，是假定大多數的錯誤是發(fā)生在各種輸入條件的邊界上，如果在邊界附近的取值不會導致程序出錯，那么其它的取值導致程序錯誤的可能性也很小。

邊界值分析使用條件

輸入條件明確了一個值的取值范圍，或是規(guī)定了值的個數

邊值點的定義

上點：邊界上的點，不區(qū)分開閉區(qū)間。

離點：就是離上點最近的一個點，如果域的邊界是封閉的，離點就在域范圍外，如果域的邊界是開放的，離點就在域范圍內

內點：顧名思義，就是在域范圍內的任意一個點

可通過下面這張圖更形象的理解：

再舉個案例：

• 正整數值域[66,88]：

上點就是66，88，并且都是在域內。內點就是域內得任意點，離點是65，89。

• 正整數值域(66,88]

這種情況上點是66，88，其中一個是域內，一個是域外，內點就是域內的任意點，離點是：67，89。

• 正整數值域(66,88)

這樣的情況上點還是66，88，只是都是在域外，內點還是域內的任意點，離點此時為：67，87。

邊界值分析的原則

1、如果輸入（輸出）條件規(guī)定了取值范圍，或是規(guī)定了值的個數，則應該以該范圍的邊界內及邊界附近的值作為測試用例

2、如果輸入（輸出）條件規(guī)定了值的個數的取值范圍，則用最大個數，最小個數，比最小個數少一，比最大個數多一的數作為測試數據

3、如果程序規(guī)格說明中提到的輸入或輸出是一個有序的集合，應該注意選取有序集合的第一個和最后一個元素作為測試用例

4、如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界上的值作為測試用例

邊界值分析方法是對等價類劃分方法的補充。長期的測試工作經驗告訴我們,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內部。因此針對各種邊界情況設計測試用例,可以查出更多的錯誤。使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據。

因果圖（Cause-Effect Graphing）提供了一個把規(guī)格轉化為判定表的系統(tǒng)化方法，從該圖中可以產生測試數據。其中情況，原因是表示輸入條件，結果是對輸入執(zhí)行的一系列計算后得到的輸出因果圖方法最終生成的就是判定表。它適合于檢查軟件輸入條件的各種組合。

因果圖法設計測試用例的步驟：

1、把大的系統(tǒng)規(guī)格劃分解成可以測試的規(guī)格片段

2、分析分解后待測的系統(tǒng)規(guī)格，找出哪些是原因，哪些是結果

3、畫出因果圖

4、把因果圖轉換成判定表

5、簡化判定表

6、用判定表中的每一項生成測試用例

缺點：

1、輸入條件與輸出結果的因果關系，有時難以從軟件需求規(guī)格說明書得到

2、即使得到了這些因果關系，也會因為因果關系復雜導致因果圖非常龐大，測試用例數目及其龐大

場景分析法

場景分析法是用例設計中比較常用的一種方法，它區(qū)別于等價類和邊界值的方法，是以列舉各種場景的方式去編寫測試用例。

異常分析法

系統(tǒng)異常分析法就是針對系統(tǒng)有可能存在的異常操作、軟硬件缺陷引起的故障進行分析，依此設計測試用例。主要針對系統(tǒng)的容錯能力、故障恢復能力進行測試。比如輸入特殊字符、斷網等操作。

錯誤猜測法

列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的場景。這個一般取決于測試人員的經驗。

其他用例設計方法

還有一些相對復雜一些的用例設計方法，比如因果圖、判定表、正交實驗法等，大家可以先從網上找簡單的資料自行了解一下。

測試用例綜合設計策略1

1)在任何情況下都必須使用等價類分析方法，經驗表明用這種方法設計出的測試用例，發(fā)現的問題比較多。

2)必要時用邊界值方法補充一些測試用例。

3)用錯誤推測法（異常分析法）再追加一些測試用例。

4)對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。

5)如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法。

測試用例綜合設計策略2

• 測試用例的設計步驟

1)構造根據設計規(guī)格得出的基本功能測試用例；

2)邊界值測試用例；

3)狀態(tài)轉換測試用例；

4)錯誤猜測測試用例；

5)異常測試用例；

6)性能、安全等專項測試用例；

• 優(yōu)化測試用例的方法

1)利用設計測試用例的幾種常用方法+經驗，不斷的對測試用例進行分解與合并；

2)在測試時利用發(fā)散思維和根據以往測試經驗，構造測試用例；

小伙伴看到這，是不是覺得這樣寫用例寫起來很麻煩呢？每次還要畫很多的圖表之類的，畫圖表只是一個分析的過程，等熟練之后，在實際工作中，可以根據自己的實際情況忽略某些步驟，只要在最終的測試點中能將這些測試點都考慮進去就行。詳細的編寫過程只是在初級測試找工作的時候，可能會在筆試題中考到，對相關的概念有個簡單的了解就行。

在工作中是如何編寫測試用例的？

我們學會了一些用例設計的常用用法，比如等價類、邊界值，以及場景法和錯誤推測法，這些是在日常工作中使用的比較多的方法。那么，學了用例設計方法之后，測試用例到底是什么呢？

測試用例是什么？

測試用例的話，可以理解為是一種針對軟件質量的檢查規(guī)則，經過一系列規(guī)則的檢查后，最終評估一個軟件質量的好壞。（只是自己的一個解釋，僅供參考，不要拿來直接去背喔）

測試用例包含哪些要素呢？

經常遇到很多人都在找測試用例的模板，我想說的是，模板其實網上一百度就可以找到一大堆，我們只需要弄清楚一條測試用例里面應該包含哪些內容就可以了，至于模板的格式，可以根據自己的喜好去進行適當調整，一般在公司也都有自己的模板。

以禪道的用例模板為例，一條測試用例一般包含以下這些因素：

所屬產品、所屬項目、所屬模塊、用例類型、適用階段、相關需求鏈接、用例編號、用例標題、前置條件、操作步驟、用例等級/優(yōu)先級、預期結果、實際結果、關鍵詞等。（實際結果只有在執(zhí)行用例的時候才能確定）

用例設計注意事項
1、用例標題要描述清楚測試點，標題不宜過長，并且標題中不能明確體現出執(zhí)行結果，標題要盡可能的讓別人一看就知道這條用例要驗證的是哪一個場景

2、用例要設置優(yōu)先級，類似bug的嚴重程度一樣，用例要區(qū)分優(yōu)先級，標注哪些是冒煙測試的用例，這一部分用例在開發(fā)轉測的時候，需要冒煙驗證通過才能轉測。冒煙測試的用例數量不宜過多。

3、用例的預期結果要與操作步驟一一對應，如果操作步驟設計多個步驟時，在預期結果里面要用序號區(qū)分分別是第幾個步驟對應的預期結果。

4、一條完整的測試用例可能包含很多字段，有些是非必填的，必填字段的話要牢記，初級測試的話在面試的時候很容易被問到。一條用例最起碼應該包含用例標題、步驟、預期結果、模塊、優(yōu)先級和類型。至于那些用例編號、關鍵字之類的根據自己平常寫用例的風格可以自己進行斟酌。

在公司中一般用什么編寫用例？

在工作中的話，每個公司針對用例的管理都有不同的標準，但歸根結底無非就是錄入和存儲的位置和格式不一致罷了。一般看公司用什么樣的缺陷管理系統(tǒng)。常見的缺陷管理系統(tǒng)有：禪道、jira、TAPD等?？隙ㄟ€有一些其他的系統(tǒng)，這里我沒接觸過的就不列舉了。像禪道和jira上是都支持用例管理的，并且禪道上還支持用例的導入導出以及批量創(chuàng)建等功能。有的公司可能還會自己開發(fā)一套測試平臺，其中會有單獨的模塊去寫用例等。也有一些測開大佬搭建的平臺，直接在線用腦圖的形式寫用例。

一般具體寫用例的話，可以先用腦圖列舉一下一些常見的測試點，根據需求文檔進行測試點的分析和提取，然后再根據腦圖，將細化的用例錄入平臺或者excel中。

用例一般寫完之后，需要組織相關人員進行用例的評審，轉測后，需要將用例的執(zhí)行情況進行標注。如果只寫用例而不是執(zhí)行，那用例寫了也沒什么用。用例的細化程度要測試人員根據公司和項目的實際情況去衡量，比如測試時間短，那就可能沒這么多時間寫很細致的用例，這個時候可以就用腦圖代替。用例的作用主要是提醒測試人員有哪些測試點要注意，避免在測試的時候臨時去想測試點，容易造成場景漏測。

希望本文對你有所幫助~~如果對軟件測試、接口測試、自動化測試、性能測試、面試經驗交流感興趣可以私聊我或關注公眾號“特斯汀軟件測試”。免費領取最新軟件測試大廠面試資料和Python自動化、接口、框架搭建學習資料！技術大牛解惑答疑，同行一起交流。