軟件測試階段分類
軟件測試按階段，可劃分以下幾類：
單元測試、集成測試、系統(tǒng)測試的比較：
1、測試范疇不同
單元測試屬于白盒測試范疇
集成測試屬于灰盒測試范疇
系統(tǒng)測試屬于黑盒測試范疇
2、測試重點不一樣
單元測試主要測試內(nèi)部數(shù)據(jù)結構、邏輯控制、異常處理等
集成測試主要測試模塊間的接口與接口數(shù)據(jù)傳遞關系，以及模塊組合后的整體功能
系統(tǒng)測試主要測試整個系統(tǒng)相對于需求的符合度
3、檢驗基準不一樣
單元測試主要通過邏輯覆蓋率來評估
集成測試主要通過接口覆蓋率來評估
系統(tǒng)測試主要通過測試用例對需求規(guī)格的覆蓋率來評估
測試人員要編寫的主要文檔有哪些？
- 測試計劃：測試范圍、方法、資源，以及相應測試活動的時間進度安排表的文檔；
- 測試方案：為完成軟件集成特性的測試而進行的設計測試方法的細節(jié)文檔；
- 測試用例：為完成一個測試項的測試輸入、預期結果、測試執(zhí)行條件等因素的文檔；
- 測試報告：執(zhí)行測試結果的文檔；
- 測試日報：每天測試執(zhí)行情況的記錄和總結。
- 用戶指導手冊：教用戶怎么使用軟件的文檔，用途與我們平常買家電的時候附帶的說明書類似，一般情況下這個不歸測試人員編寫，但是有一些小公司可能會讓測試寫這個文檔。
軟件測試過程的幾個模型，簡單了解一下：
V模型：左到右，描述了開發(fā)與測試過程之間的階段對應關系，缺點是不適用于需求變化，靈活性差。
雙V模型/W模型：
優(yōu)點：測試伴隨整個產(chǎn)品開發(fā)周期，測試對象不僅是程序還有需求、設計文檔測試介入較早，及早發(fā)現(xiàn)問題，降低修復成本
缺點：實施起來比較復雜，難度大，對于需求階段和設計階段的測試設計要求較高（計算機技術、業(yè)務知識、管理能力、測試素質等）
為什么要盡早進行測試工作？
按照被測對象的不同，可以分為：
- 白盒測試
- 灰盒測試
- 黑盒測試
白盒測試是依據(jù)被測軟件分析程序內(nèi)部構造，并根據(jù)內(nèi)部構造設計用例，來對內(nèi)部控制流程進行測試，可完全不顧程序的整體功能實現(xiàn)情況。白盒測試是基于程序結構的邏輯驅動測試。白盒測試發(fā)現(xiàn)問題后解決問題的成本較低。
黑盒測試把被測對象看成一個黑盒，只考慮其整體特性，不考慮其內(nèi)部具體實現(xiàn)。黑盒測試針對的被測對象可以是一個系統(tǒng)、一個子系統(tǒng)、一個模塊、一個子模塊等。測試人員不需要了解實現(xiàn)的細節(jié)，包括特定的編程語言；從用戶的視角進行測試，很容易被大家理解和接受；有助于暴露任何與規(guī)格不一致或有歧義的問題；壓力測試和負載測試都屬于黑盒測試。
灰盒測試就是介于白盒和黑盒之間的一種。既要關注整體特性，又要關注內(nèi)部具體實現(xiàn)。
按照是否運行被測對象，可以劃分為：
- 靜態(tài)測試
- 動態(tài)測試
靜態(tài)測試：不運行被測試的軟件系統(tǒng)，而是采用其他手段和技術對被測試軟件進行檢測的一種測試技術。例如：代碼走讀、文檔評審、代碼掃描等都是靜態(tài)測試的范疇。
動態(tài)測試：按照預先設計的數(shù)據(jù)和步驟去運行被測軟件系統(tǒng)，從而對被測軟件系統(tǒng)進行檢測的一種測試技術。
按照是否借助工具劃分：
- 手工測試
- 自動化測試
人工測試：測試活動（如評審、測試設計、測試執(zhí)行等）由人來完成，狹義上是指測試執(zhí)行由人工完成，這是最基本的測試形式
自動化測試：一般是指通過計算機模擬人的測試行為，替代人的測試活動，狹義上是指測試執(zhí)行由計算機來完成
自動化測試的意義：
提高回歸測試的效率，可以運行更多更頻繁的測試，比如冒煙測試?？梢詧?zhí)行手工測試困難或不可能做的測試，比如大量的重復操作或者集成測試。
自動化測試的限制：
不能取代手工測試，自動化測試只能提高測試效率，不能提高測試有效性，即不可能發(fā)現(xiàn)更多缺陷，手工測試比自動測試發(fā)現(xiàn)的缺陷更多；
對測試設計依賴性極大，測試設計的不好會遺漏問題；工具本身并不具備想象力，自動化測試對軟件開發(fā)具有很大的依賴性，開發(fā)上出現(xiàn)變更可能導致前面的自動化測試完全失效。
測試用例設計方法（等價類+邊界值）
常見的用例設計方法
- 等價類劃分法（適用于輸入項少，輸入項的屬性或者特性相同）
- 邊界值分析法（適用于有范圍約束的情況）
- 判定表法（適用于有明顯的條件及其對應的動作的情況）
- 因果圖法
- 狀態(tài)遷移圖法（適用于狀態(tài)隨事件而改變的情況）
- 場景分析法（適合于由事件觸發(fā)而形成的使用場景，同一事件不同的觸發(fā)邏輯形成不同的場景，從而形成不同的業(yè)務流程（路徑），根據(jù)覆蓋不同的路徑來設計測試用例）
- 正交實驗法（適用于多條件或多輸入情況）
- 異常分析法（適用于大多數(shù)軟件，從經(jīng)驗上判斷容易出現(xiàn)錯誤或缺陷的地方設計用例）
- 錯誤猜測法
等價類劃分法
是把所有可能的輸入數(shù)據(jù),即程序的輸入域劃分成若干部分子集,然后從每一個子集中選取少數(shù)具有代表性的數(shù)據(jù)作為測試用例。該方法是一種重要的,常用的黑盒測試用例設計方法。
- 有效等價類：有效等價類是程序規(guī)格說明有意義，合法的輸入數(shù)據(jù)
- 無效等價類：無效等價類是程序規(guī)格說明無意義，不合法的輸入數(shù)據(jù)。
等價類法設計測試用例的步驟:
1、為每個輸入劃分等價類，得到等價類表，為每個等價類規(guī)定一個唯一編號
2、設計一個測試用例，使其盡可能多的覆蓋所有尚未覆蓋的有效等價類。重 復這一步驟，使得有效等價類均被測試用例所覆蓋
3、設計一個測試用例，使其只覆蓋一個無效等價類。重復這一步驟使得所有無效等價類均被覆蓋
等價類劃分的原則
1、在輸入條件規(guī)定了取值范圍或值的個數(shù)的情況下,則可以確立一個有效等價類和兩個無效等價類.
2、在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”的條件的情況下,可確立一個有效等價類和一個無效等價類.
3、在輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類.
4、在規(guī)定了輸入數(shù)據(jù)的一組值假定n個,并且程序要對每一個輸入值分別處理的情況下,可確立n個有效等價類和一個無效等價類.
5、在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下,可確立一個有效等價類符合規(guī)則和若干個無效等價類從不同角度違反規(guī)則.
6、在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步的劃分為更小的等價類.
等價類表可以參考下圖所示：
等價類劃分法用例設計實戰(zhàn)：
根據(jù)下面給出的規(guī)格說明，進行測試用例的設計。
一個程序讀入3個整數(shù)，把這三個數(shù)值看作一個三角形的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 ；
最終輸出的場景如下：
邊界值分析法
邊值分析方法的理論基礎，是假定大多數(shù)的錯誤是發(fā)生在各種輸入條件的邊界上，如果在邊界附近的取值不會導致程序出錯，那么其它的取值導致程序錯誤的可能性也很小。
邊界值分析使用條件
輸入條件明確了一個值的取值范圍，或是規(guī)定了值的個數(shù)
邊值點的定義
上點：邊界上的點，不區(qū)分開閉區(qū)間。
離點：就是離上點最近的一個點，如果域的邊界是封閉的，離點就在域范圍外，如果域的邊界是開放的，離點就在域范圍內(nèi)
內(nèi)點：顧名思義，就是在域范圍內(nèi)的任意一個點
可通過下面這張圖更形象的理解：
再舉個案例：
- 正整數(shù)值域[66,88]：
上點就是66，88，并且都是在域內(nèi)。內(nèi)點就是域內(nèi)得任意點，離點是65，89。
- 正整數(shù)值域(66,88]
這種情況上點是66，88，其中一個是域內(nèi)，一個是域外，內(nèi)點就是域內(nèi)的任意點，離點是：67，89。
- 正整數(shù)值域(66,88)
這樣的情況上點還是66，88，只是都是在域外，內(nèi)點還是域內(nèi)的任意點，離點此時為：67，87。
邊界值分析的原則
1、如果輸入（輸出）條件規(guī)定了取值范圍，或是規(guī)定了值的個數(shù)，則應該以該范圍的邊界內(nèi)及邊界附近的值作為測試用例
2、如果輸入（輸出）條件規(guī)定了值的個數(shù)的取值范圍，則用最大個數(shù)，最小個數(shù)，比最小個數(shù)少一，比最大個數(shù)多一的數(shù)作為測試數(shù)據(jù)
3、如果程序規(guī)格說明中提到的輸入或輸出是一個有序的集合，應該注意選取有序集合的第一個和最后一個元素作為測試用例
4、如果程序中使用了一個內(nèi)部數(shù)據(jù)結構，則應當選擇這個內(nèi)部數(shù)據(jù)結構的邊界上的值作為測試用例
邊界值分析方法是對等價類劃分方法的補充。長期的測試工作經(jīng)驗告訴我們,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部。因此針對各種邊界情況設計測試用例,可以查出更多的錯誤。使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù)。
因果圖（Cause-Effect Graphing）提供了一個把規(guī)格轉化為判定表的系統(tǒng)化方法，從該圖中可以產(chǎn)生測試數(shù)據(jù)。其中情況，原因是表示輸入條件，結果是對輸入執(zhí)行的一系列計算后得到的輸出因果圖方法最終生成的就是判定表。它適合于檢查軟件輸入條件的各種組合。
因果圖法設計測試用例的步驟：
1、把大的系統(tǒng)規(guī)格劃分解成可以測試的規(guī)格片段
2、分析分解后待測的系統(tǒng)規(guī)格，找出哪些是原因，哪些是結果
3、畫出因果圖
4、把因果圖轉換成判定表
5、簡化判定表
6、用判定表中的每一項生成測試用例
缺點：
1、輸入條件與輸出結果的因果關系，有時難以從軟件需求規(guī)格說明書得到
2、即使得到了這些因果關系，也會因為因果關系復雜導致因果圖非常龐大，測試用例數(shù)目及其龐大
場景分析法
場景分析法是用例設計中比較常用的一種方法，它區(qū)別于等價類和邊界值的方法，是以列舉各種場景的方式去編寫測試用例。
異常分析法
系統(tǒng)異常分析法就是針對系統(tǒng)有可能存在的異常操作、軟硬件缺陷引起的故障進行分析，依此設計測試用例。主要針對系統(tǒng)的容錯能力、故障恢復能力進行測試。比如輸入特殊字符、斷網(wǎng)等操作。
錯誤猜測法
列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的場景。這個一般取決于測試人員的經(jīng)驗。
其他用例設計方法
還有一些相對復雜一些的用例設計方法，比如因果圖、判定表、正交實驗法等，大家可以先從網(wǎng)上找簡單的資料自行了解一下。
測試用例綜合設計策略1
1)在任何情況下都必須使用等價類分析方法，經(jīng)驗表明用這種方法設計出的測試用例，發(fā)現(xiàn)的問題比較多。
2)必要時用邊界值方法補充一些測試用例。
3)用錯誤推測法（異常分析法）再追加一些測試用例。
4)對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。
5)如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法。
測試用例綜合設計策略2
- 測試用例的設計步驟
1)構造根據(jù)設計規(guī)格得出的基本功能測試用例；
2)邊界值測試用例；
3)狀態(tài)轉換測試用例；
4)錯誤猜測測試用例；
5)異常測試用例；
6)性能、安全等專項測試用例；
- 優(yōu)化測試用例的方法
1)利用設計測試用例的幾種常用方法+經(jīng)驗，不斷的對測試用例進行分解與合并；
2)在測試時利用發(fā)散思維和根據(jù)以往測試經(jīng)驗，構造測試用例；
小伙伴看到這，是不是覺得這樣寫用例寫起來很麻煩呢？每次還要畫很多的圖表之類的，畫圖表只是一個分析的過程，等熟練之后，在實際工作中，可以根據(jù)自己的實際情況忽略某些步驟，只要在最終的測試點中能將這些測試點都考慮進去就行。詳細的編寫過程只是在初級測試找工作的時候，可能會在筆試題中考到，對相關的概念有個簡單的了解就行。
在工作中是如何編寫測試用例的？
我們學會了一些用例設計的常用用法，比如等價類、邊界值，以及場景法和錯誤推測法，這些是在日常工作中使用的比較多的方法。那么，學了用例設計方法之后，測試用例到底是什么呢？
測試用例是什么？
測試用例的話，可以理解為是一種針對軟件質量的檢查規(guī)則，經(jīng)過一系列規(guī)則的檢查后，最終評估一個軟件質量的好壞。（只是自己的一個解釋，僅供參考，不要拿來直接去背喔）
測試用例包含哪些要素呢？
經(jīng)常遇到很多人都在找測試用例的模板，我想說的是，模板其實網(wǎng)上一百度就可以找到一大堆，我們只需要弄清楚一條測試用例里面應該包含哪些內(nèi)容就可以了，至于模板的格式，可以根據(jù)自己的喜好去進行適當調整，一般在公司也都有自己的模板。
以禪道的用例模板為例，一條測試用例一般包含以下這些因素：
所屬產(chǎn)品、所屬項目、所屬模塊、用例類型、適用階段、相關需求鏈接、用例編號、用例標題、前置條件、操作步驟、用例等級/優(yōu)先級、預期結果、實際結果、關鍵詞等。（實際結果只有在執(zhí)行用例的時候才能確定）
用例設計注意事項
1、用例標題要描述清楚測試點，標題不宜過長，并且標題中不能明確體現(xiàn)出執(zhí)行結果，標題要盡可能的讓別人一看就知道這條用例要驗證的是哪一個場景
2、用例要設置優(yōu)先級，類似bug的嚴重程度一樣，用例要區(qū)分優(yōu)先級，標注哪些是冒煙測試的用例，這一部分用例在開發(fā)轉測的時候，需要冒煙驗證通過才能轉測。冒煙測試的用例數(shù)量不宜過多。
3、用例的預期結果要與操作步驟一一對應，如果操作步驟設計多個步驟時，在預期結果里面要用序號區(qū)分分別是第幾個步驟對應的預期結果。
4、一條完整的測試用例可能包含很多字段，有些是非必填的，必填字段的話要牢記，初級測試的話在面試的時候很容易被問到。一條用例最起碼應該包含用例標題、步驟、預期結果、模塊、優(yōu)先級和類型。至于那些用例編號、關鍵字之類的根據(jù)自己平常寫用例的風格可以自己進行斟酌。
在公司中一般用什么編寫用例？
在工作中的話，每個公司針對用例的管理都有不同的標準，但歸根結底無非就是錄入和存儲的位置和格式不一致罷了。一般看公司用什么樣的缺陷管理系統(tǒng)。常見的缺陷管理系統(tǒng)有：禪道、jira、TAPD等?？隙ㄟ€有一些其他的系統(tǒng)，這里我沒接觸過的就不列舉了。像禪道和jira上是都支持用例管理的，并且禪道上還支持用例的導入導出以及批量創(chuàng)建等功能。有的公司可能還會自己開發(fā)一套測試平臺，其中會有單獨的模塊去寫用例等。也有一些測開大佬搭建的平臺，直接在線用腦圖的形式寫用例。
一般具體寫用例的話，可以先用腦圖列舉一下一些常見的測試點，根據(jù)需求文檔進行測試點的分析和提取，然后再根據(jù)腦圖，將細化的用例錄入平臺或者excel中。
用例一般寫完之后，需要組織相關人員進行用例的評審，轉測后，需要將用例的執(zhí)行情況進行標注。如果只寫用例而不是執(zhí)行，那用例寫了也沒什么用。用例的細化程度要測試人員根據(jù)公司和項目的實際情況去衡量，比如測試時間短，那就可能沒這么多時間寫很細致的用例，這個時候可以就用腦圖代替。用例的作用主要是提醒測試人員有哪些測試點要注意，避免在測試的時候臨時去想測試點，容易造成場景漏測。
希望本文對你有所幫助~~如果對軟件測試、接口測試、自動化測試、性能測試、面試經(jīng)驗交流感興趣可以私聊我或關注公眾號“特斯汀軟件測試”。免費領取最新軟件測試大廠面試資料和Python自動化、接口、框架搭建學習資料！技術大牛解惑答疑，同行一起交流。
]]>