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