一、測試定義
a、什么是測試
測試是一個帶著找到錯誤的目的來運行程序或系統(tǒng)的過程。或者，它是任何旨在評估程序或系統(tǒng)屬性和性能的活動，通過這些活動來決定該程序或系統(tǒng)是否符合所要求的結(jié)果。
對于軟件來說，它并沒有不同于其他那些接收輸入、產(chǎn)出輸出的物理過程，它不同之處在于以何種方式運行失敗。大多數(shù)物理系統(tǒng)運行失敗在一個固定的（相當(dāng)小）設(shè)置方式上。相反的，軟件可以失敗在許多奇怪的方式上。要發(fā)現(xiàn)軟件所有不同的失敗方式通常是不太可能的。
b、測試目標(biāo)
要證明所提供的軟件產(chǎn)品達(dá)到了被要求的指標(biāo)。
軟件能正常運行，沒有任何錯誤或故障（功能上）。
產(chǎn)生高品質(zhì)的測試案例，進(jìn)行有效測試，發(fā)表正確有幫助的錯誤報告。
c、一個優(yōu)秀測試案例的特征
一個好的或者說一個成功的測試案例在于它具有很高的可能性來發(fā)現(xiàn)尚未發(fā)現(xiàn)的錯誤。
它容易找到程序失敗的方式。
它讓測試捕捉到錯誤的這種可能性變的合理。
它不是多余的。
它既不是太過簡單也不是太過復(fù)雜。
d、測試原則
1、測試是一個帶著找到錯誤的目的來運行程序的過程。測試不應(yīng)該把"不會有錯誤被發(fā)現(xiàn)"計劃在隱性假設(shè)中。
2、不僅使用有效的輸入條件進(jìn)行測試，還要使用無效和意想不到的輸入條件來測試。
3、當(dāng)遇到一個無效的測試時程序應(yīng)該產(chǎn)生正確的消息，當(dāng)遇到一個有效的測試時程序應(yīng)該產(chǎn)生正確的結(jié)果。
4、在一個或一組模塊中存在更多錯誤的可能性與已經(jīng)找到的錯誤數(shù)量，是成正比的。
5、測試時保持軟件靜態(tài)。
6、在設(shè)計的測試用例集被執(zhí)行的時候，不能修改程序。
7、使用文檔形式來記載測試案例和測試結(jié)果
8、如果可能的話提供預(yù)期的測試結(jié)果。
e、V過程模型總結(jié)
V模型是一個軟件開發(fā)的過程。V模型揭示了開發(fā)生命周期每個階段與測試的關(guān)系。
V模型部署了一個結(jié)構(gòu)良好的框架方法。按照這個框架，每個階段都能按照前一階段的詳細(xì)文檔來執(zhí)行。測試活動就像測試設(shè)計，開始于項目的最開端，放在編程之前，這樣就很有可能為工程進(jìn)度省下一大部分時間。
二、白盒測試與黑盒測試
f、白盒測試
白盒測試基于應(yīng)用程序代碼的內(nèi)部邏輯知識。測試基于代碼語句、分支、路徑、條件的覆蓋。
測試人員必須知道軟件內(nèi)部是怎么工作的，要知道軟件的結(jié)構(gòu)和程序語言，至少要知道程序語言的意義
白盒測試是在一個結(jié)構(gòu)性測試策略下進(jìn)行的，要求對對象結(jié)構(gòu)的完全訪問，也就是源代碼。
g、黑盒測試
黑盒測試不需要知道軟件內(nèi)部是如何工作的，也不需要知道軟件的結(jié)構(gòu)、設(shè)計、代碼或測試模塊的程序語言。黑盒測試，像其他大多數(shù)測試一樣，必須依據(jù)一個最終源文件，比如規(guī)格說明書或要求文件。"你看到的就是你測試的。"它基于需求和功能來測試。
h、白盒測試技術(shù)
白盒測試技術(shù)包括以下4種
I、代碼覆蓋
1、段覆蓋：確保對每一句代碼都測試一次。
2、分支覆蓋或節(jié)點測試：覆蓋所有可能的代碼分支。
3、復(fù)合條件覆蓋：對于多個條件，通過多個路徑測試每一個條件，并且通過不同路徑組合來達(dá)到這一條件。
II、基本路徑測試
代碼中每個獨立的路徑都要被測試過。數(shù)據(jù)流測試是一種方式，即你通過各種可能的計算來跟蹤特定變量，從而通過代碼定義中間路徑集。數(shù)據(jù)流測試往往反映相關(guān)性，它主要是通過數(shù)據(jù)序列來操作。簡言之即跟蹤每個數(shù)據(jù)變量，驗證其使用。這種方法往往會發(fā)現(xiàn)錯誤來源于變量使用而不是變量初始化，或者來源于變量聲明而不是使用，等等諸如此類。
III、路徑測試
路徑測試就是定義和覆蓋測試代碼中所有可能的路徑。這是一項費時的工作。
IV、回歸測試
測試思路涉及到測試單圈、串聯(lián)循環(huán)、和嵌套循環(huán)。通過這種方法測試獨立和非獨立代碼循環(huán)和代碼值。
i、黑盒測試技術(shù)
為便于理解，將在下面詳細(xì)給出黑盒測試主要技術(shù)。
I、等價類劃分
等價類劃分是一種軟件測試技術(shù)。將軟件單元的輸入數(shù)據(jù)范圍劃分成若干等價區(qū)域，每一個區(qū)域編寫一個測試案例。原則上，測試案例的編寫至少覆蓋每個分區(qū)一次。該技術(shù)試圖定義測試用例從而揭示錯誤類，這樣測試案例的總數(shù)就相應(yīng)減少了。
在極少數(shù)情況下，等價區(qū)域劃分也適用于軟件組件的產(chǎn)出軟件測試的來源，是具有代表性的，它適用于測試元件的輸入。等價區(qū)域劃分常常遵循于輸入屬性需求規(guī)格說明書，從而影響測試對象的處理。輸入具有一定的有效輸入范圍和無效輸入范圍。這里的無效輸入數(shù)據(jù)不是說數(shù)據(jù)類型是錯誤的，而是指該輸入數(shù)據(jù)在某個具體分區(qū)之外。
舉個等價區(qū)域劃分的例子，比如你想要測試范圍在1到10，000之間的某個輸入數(shù)字，你不需要一一測試每一個1到10，000之間的數(shù)字，你只需使用等價區(qū)域劃分的方法，將數(shù)字范圍劃分，比如劃分成一位數(shù)、兩位數(shù)、三位數(shù)和四位數(shù)，像5、15、555、5555。
II、邊界值分析
邊界值分析是等價區(qū)域劃分的擴(kuò)展，它是取等價區(qū)域上的邊界值來進(jìn)行測試。很多錯誤往往就是發(fā)生在輸入范圍的邊界值上而不是輸入范圍中間的地方，至于為什么會這樣還不是完全清楚。正是由于這個原因，邊界值分析發(fā)展成了一項測試技術(shù)。邊界值分析產(chǎn)生了測試用例的選擇，選擇使用邊界值來進(jìn)行測試。
邊界值分析是一個測試案例設(shè)計技術(shù)，是等價區(qū)域劃分的補(bǔ)充。邊界值分析不是選擇等價區(qū)域內(nèi)任意的數(shù)據(jù)，而是選擇區(qū)域邊界值作為測試案例。邊界值分析不僅僅關(guān)注輸入條件，還從輸出域中產(chǎn)生出測試用例。
舉個邊界值分析的例子，比如測試1到12月之間的某個月份，我們?nèi)∫粋€小于0的負(fù)數(shù)據(jù)，取一個1到12之間的有效數(shù)據(jù)，取一個大于12的數(shù)據(jù)來進(jìn)行測試，觀察是否是只有1到12之間的有效數(shù)據(jù)被輸入才是可接受的。
III、錯誤猜測
這是一個基于測試者綜合能力的一項軟件測試設(shè)計技術(shù)。在測試過程中，測試者根據(jù)他的經(jīng)驗、知識和直覺來預(yù)測軟件上的錯誤。一些典型的錯誤域常常會發(fā)生在空字符串、零實例、某些特殊值、字符串中的空字符、負(fù)數(shù)數(shù)據(jù)上。
盡管過去測試經(jīng)驗對錯誤猜測來說是很關(guān)鍵的基礎(chǔ)，但它們也可能會用不到。容易出錯的情況，有包括數(shù)據(jù)初始化（例如，重復(fù)某個過程，查看數(shù)據(jù)是否被正確刪除），錯誤類型數(shù)據(jù)（例如，負(fù)數(shù)數(shù)據(jù)、非數(shù)字對數(shù)字），真實數(shù)據(jù)處理（也就是，測試那些通過系統(tǒng)或真實記錄創(chuàng)建的使用數(shù)據(jù)，因為程序員往往會通過創(chuàng)建的數(shù)據(jù)來反映他們預(yù)期的設(shè)想），錯誤管理（例如，將多個錯誤進(jìn)行優(yōu)先排序，清除錯誤消息，當(dāng)遇到某個錯誤時需適當(dāng)進(jìn)行數(shù)據(jù)保存，錯誤過后程序應(yīng)當(dāng)能繼續(xù)處理）， 計算（例如，手工計算需比較的項目），重新啟動、恢復(fù)（也就是，強(qiáng)制終止一個批處理程序，并且測定重啟/恢復(fù)進(jìn)程是否能工作正常），妥善處理并發(fā)進(jìn)程（也就是，在事件驅(qū)動的應(yīng)用程序上，同時讓多個進(jìn)程運行，測試程序的處理情況）。
IV、決策表
決策表是一種精確且緊湊塑造復(fù)雜邏輯的方式。像if-then-else和-case語句那樣，通過條件來執(zhí)行相應(yīng)事件。不同于傳統(tǒng)編程語言里的控制結(jié)構(gòu)，決策表能通過一個直觀的方式將許多獨立的條件和事件關(guān)聯(lián)起來。
一個決策表通常被分成四個象限，如下圖所示。
每個決策對于一個變量、關(guān)系或表明滿足條件選項中的可能值。每一個動作執(zhí)行一個過程或操作，并且該項指定動作是否（或按什么順序）按照項目對應(yīng)的條件選項集執(zhí)行。
舉例：描述有限項決策表是最簡單的。條件選項是簡單的布爾值，并且動作項是檢查標(biāo)記，表明哪一個給定列中的動作將被執(zhí)行。一個技術(shù)支持公司編寫決策表來診斷打印機(jī)問題，問題的了解基于客戶通過電話向他們描述的癥狀。下面是一個平衡的決策表。
V、因果圖
在軟件測試中，因果圖是一個定向圖，由原因集映射到結(jié)果集上。原因可能被認(rèn)為是程序的輸入，結(jié)果可能被認(rèn)為是程序的輸出。通常，圖表顯示在左邊的節(jié)點代表原因，顯示在右邊的節(jié)點代表結(jié)果。中間可能有中間節(jié)點，使用邏輯運算符，如AND 和OR，將輸入結(jié)合起來。
三、測試類型
j、單元測試
單元測試的主要目標(biāo)是測試應(yīng)用程序中可測試的最小組成部分，可以獨立于軟件的其余代碼，測試其是否按照你所希望的在運行。在將每一個單元集合成模塊來測試模塊間的接口前，應(yīng)該先分別測試每一個單元。單元測試很重要，很大比例的錯誤都是在單元測試中發(fā)現(xiàn)的。
單元測試最常用的方法需要寫入驅(qū)動和存根。驅(qū)動模擬一個呼叫單元，存根模擬一個被呼叫單元。由于單元測試投資在開發(fā)時間上較長，有時會導(dǎo)致將單元測試放在較低的優(yōu)先級上，但這樣做往往是錯的。盡管編寫驅(qū)動和存根要耗費一定人力和時間，但單元測試展現(xiàn)了一些不可否認(rèn)的優(yōu)勢。單元測試允許測試過程自動化，降低了從更復(fù)雜的應(yīng)用程序塊中找到錯誤的難度。因為每個單元都被關(guān)注了，所以測試的覆蓋率也往往被提高了。
例如，如果你有兩個單元，想知道將他們集合在一起進(jìn)行測試所花的成本是否會偏低些，一開始就將它們作為一個整體單元進(jìn)行測試，錯誤的發(fā)生點可能會出現(xiàn)在很多地方：
單元一這里會出現(xiàn)錯誤嗎？
單元二這里會出現(xiàn)錯誤嗎？
兩個單元都會出現(xiàn)錯誤嗎？
兩個單元之間的地方會出現(xiàn)錯誤嗎？
會因為測試的缺陷出現(xiàn)錯誤嗎？
將模塊直接集合在一起進(jìn)行測試遠(yuǎn)比先獨立測試每一個單元模塊，然后再將它們集合在一起進(jìn)行測試要復(fù)雜的多。
驅(qū)動和存根可重復(fù)使用，在開發(fā)周期中不斷發(fā)生的變化可以經(jīng)常進(jìn)行重新測試，而無需編寫大量的額外測試代碼。事實上，這減少了每次編寫驅(qū)動和存根的成本，并且對重復(fù)測試的成本也更好控制。
k、集成測試
集成測試是單元測試邏輯上的延伸。最簡單的測試形式是，在完成了兩個單元的單元測試后，將這兩個單元組合成一個組件，測試兩單元之間的界面。這里組件的意思是指多個單元的綜合。在真實的場景中，很多單元被合并成組件，這些組件又被合并成更大的部分。這個想法是測試組合件，最終擴(kuò)大測試該組模塊與別組模塊的過程。最終所有模塊將并一起進(jìn)行測試。除此之外，如果程序是多個進(jìn)程組成，它們應(yīng)該成對測試，而不是一次性全部一起測試。
集成測試是在將單元結(jié)合在一起的時候發(fā)現(xiàn)錯誤。通過使用一個測試計劃，測試每一個單元，并在合并單元前確保每個單元的都是ok的。你就會知道在合并單元時發(fā)現(xiàn)的錯誤就可能和單元間的界面有關(guān)系。利用這種方法，可以將推測錯誤位置的可能性降低到一個簡單的多的分析水平上。
集成測試有很多種方法，以下三種是最常見的：
自上而下的方法：需要測試最高級別的模塊，并且先集成起來。這使得在過程中要先測試高層次的邏輯和數(shù)據(jù)流，往往最小化了驅(qū)動的需要。然而，存根的需求使測試管理復(fù)雜化。并且在軟件開發(fā)生命周期中，低級別的往往在后面測試。自上而下的集成測試另外個不好的地方在于它不支持有限功能的提前釋放。
自下而上的方法：需要測試最低級別的單元，并且先集成起來。這些單元常常被稱為公用模塊。通過使用這個方法，在開發(fā)過程早期測試公用模塊，存根的需要就被最小化了。不過這個方法的缺點就是驅(qū)動的需求使測試管理復(fù)雜化，并且高級別的邏輯和數(shù)據(jù)流往往在后面測試。像自上而下的方法一樣軟件測試的來源，自下而上的方法同樣不支持有限功能的提前釋放。
第三個方法，有時也被稱為傘方法，需要沿著函數(shù)數(shù)據(jù)和控制流路徑來測試。首先，函數(shù)的輸入是集成在上面討論的自下而上的模式中。然后，函數(shù)的輸出是集成在自上而下的模式中。該方法最主要的優(yōu)勢在于它支持有限功能的提前釋放。并且它將存根和驅(qū)動的需求最小化。該方法潛在的弱點是顯著的，它比其他兩種方法要欠缺系統(tǒng)性，導(dǎo)致需要更多的回歸測試。
l、驗收測試
用戶驗收測試常常是推出程序之前的最后一步測試。
通常，使用程序的最終用戶會在接受程序前對應(yīng)用程序進(jìn)行測試。這種形式的測試使最終用戶對交付到他們手上的應(yīng)用程序質(zhì)量更具有信心。該測試也能幫助發(fā)現(xiàn)程序在可用性上的缺陷。該測試有兩種測試類型，分別是Alpha測試和Beta測試。
Alpha和Beta測試
Alpha測試在開發(fā)員的站點上進(jìn)行，在發(fā)行給外面客戶使用前，先由內(nèi)部工作人員對業(yè)務(wù)系統(tǒng)進(jìn)行測試。
Beta測試在客戶的站點上進(jìn)行，在發(fā)行給別的客戶前，先由一組顧客在他們自己的站點上使用該系統(tǒng)對其進(jìn)行測試。后者通常被稱為"現(xiàn)場測試"。
m、系統(tǒng)測試
系統(tǒng)測試對軟件整體進(jìn)行測試。在一個有代表性的企業(yè)里，由程序員來做單元測試。這保證了每一個組件都正常工作。集成測試關(guān)鍵在于軟件各個部分的成功組合（組件或單元代碼）。一旦組件被組合到一塊，整個系統(tǒng)就需要進(jìn)行徹底的測試來保證它達(dá)到質(zhì)量標(biāo)準(zhǔn)。
因此系統(tǒng)測試建立在單元測試和集成測試的基礎(chǔ)上。通常一個專業(yè)的測試團(tuán)隊是有責(zé)任做系統(tǒng)測試的。系統(tǒng)測試在質(zhì)量管理過程中是關(guān)鍵性的一步。
為什么系統(tǒng)測試如此重要？
在軟件開發(fā)生命周期中，系統(tǒng)測試在系統(tǒng)作為一個整體進(jìn)行測試中是第一級的。通過測試系統(tǒng)來檢驗它是否達(dá)到功能和技術(shù)上的要求。應(yīng)用程序/系統(tǒng)是在一個很類似于生產(chǎn)環(huán)境的環(huán)境下進(jìn)行測試的，那里應(yīng)用程序最后要被釋放。系統(tǒng)測試讓我們測試、檢驗并確認(rèn)產(chǎn)品無論在業(yè)務(wù)需求還是體系結(jié)構(gòu)上是否都達(dá)到標(biāo)準(zhǔn)。
i、性能測試
性能測試是在程序運行下進(jìn)行的，從某個角度來講，是檢測系統(tǒng)在特定的負(fù)載下各方面的運行情況。它也可以用來驗證和核實系統(tǒng)其他質(zhì)量屬性，如可擴(kuò)展性，可靠性和資源使用率。性能測試是性能工程的一個子集，是一種新興的計算機(jī)科學(xué)實踐，為提高系統(tǒng)設(shè)計和體系結(jié)構(gòu)的性能而努力，做在實際的編碼工作之前。
性能測試可用于不同的目的。它可以證明該系統(tǒng)性能符合標(biāo)準(zhǔn)。它可以通過比較來發(fā)現(xiàn)哪個系統(tǒng)執(zhí)行地好。或者，它可以測量系統(tǒng)或負(fù)載的哪部分導(dǎo)致系統(tǒng)運行失敗。在診斷進(jìn)行中，軟件工程師使用工具，如廓線儀，來測量是設(shè)備或軟件的哪部分導(dǎo)致運行失敗，或者為維持可接受的響應(yīng)時間來創(chuàng)建吞吐量水平（和閥值）。對一個新系統(tǒng)來說，性價比是至關(guān)重要的。性能測試工作始于開發(fā)項目的啟動，并且擴(kuò)展到整個項目中。性能缺陷發(fā)現(xiàn)的越晚，修復(fù)的成本越高。這在功能測試中，情況屬實，性能測試更是如此，原因在于其終端到終端的范圍性質(zhì)。
ii、回歸測試
如果軟件的某一部分因為某個原因被修改了，就需要進(jìn)行測試，測試修正過后的軟件是否按照指定要求在工作，確保軟件沒有被影響并且之前的功能都俱全。這種測試就叫做回歸測試。
為什么回歸測試很重要？
因為任何軟件上的修改都能引起現(xiàn)有的功能遭破壞。軟件組件上的改變可能會影響到別的相關(guān)組件。軟件上的一個修正可能會引起其他錯誤，這是很常見的。所有這些都影響了系統(tǒng)的質(zhì)量和穩(wěn)定性。因為回歸測試的目的是為了驗證并確保這一切不會發(fā)生，所以是非常重要的。
四、測試過程
n、測試計劃
測試計劃是一個文件，詳細(xì)說明了測試一個系統(tǒng)，如一機(jī)器或一軟件的系統(tǒng)方法。該計劃通常包含最終工作流程會是什么樣子的詳細(xì)說明。
它是一份描述測試計劃的文件，換句話說，即如何執(zhí)行測試計劃。它通常包括測試對象的羅列、測試人員角色和責(zé)任分配、開始測試的前提條件、測試環(huán)境、假設(shè)、測試執(zhí)行成功后要做什么、測試執(zhí)行失敗后要做什么，等等。
一個測試計劃描述了如何驗證和確保產(chǎn)品或系統(tǒng)滿足其設(shè)計規(guī)范和其他要求的戰(zhàn)略步驟。通常，測試工程師會對測試計劃做大量準(zhǔn)備和投入。
i、測試計劃的目標(biāo)
測試計劃的目標(biāo)是提供一套工具，以各種方式來支持測試團(tuán)隊的工作。這些好處包括：
a、可以減少重要工作被忽略、被誤估計、被忘記的風(fēng)險
b、可以將工作按照重要性的高低來完成。
c、可以估計該項目（技術(shù)和程序性）的風(fēng)險，并確定是否可以緩解步驟。
d、可以組織安排測試的工作。
e、可以將測試工作的進(jìn)展情況和該項目作為一個整體來監(jiān)視。
五、單元測試
單元測試是一個驗證源代碼的個別單位是否正常工作的測試（通常是自動的）。單位是應(yīng)用程序中最小的可測試部分。在程序編程里，一個單位可能是一段指令、一個函數(shù)或者一段程序等等。而在面向?qū)ο蟮木幊汤铮瑔挝豢赡苁且粋€基數(shù)類/父類、抽象類或派生類/子類。
單元測試通常是由軟件開發(fā)商來操作，要確保他們編寫的代碼符合軟件的要求，并且按照開發(fā)員意想來運行。
單元測試該測試些什么呢？
這在很大程度上取決于程序或正在創(chuàng)建的單元的類型。它可能是一個畫面或一個組件或web服務(wù)。大致上從以下幾方面來考慮：
a、對于UI畫面，測試用例要能驗證所有需要顯示在屏幕上的屏幕元素。
b、對于UI畫面，測試用例要能驗證所有顯示在屏幕上的標(biāo)簽或文本的拼寫/字體/大小。
c、創(chuàng)建測試用例，保證單位每行代碼在一個測試周期中至少被測試一次。
d、創(chuàng)建測試用例，保證條件語句里每一個條件都被測試過。
e、創(chuàng)建測試用例，測試數(shù)據(jù)可輸入的最小和最大范圍。例如，參數(shù)傳遞，要測試數(shù)值型參數(shù)的最大輸入值或字符串型參數(shù)的最長輸入長度。
f、創(chuàng)建測試用例，查看遇到各種錯誤程序會如何處理。
g、創(chuàng)建測試用例，驗證是否所有的驗證工作都在被執(zhí)行。
請關(guān)注+私信回復(fù)：“學(xué)習(xí)”就可以免費拿到軟件測試學(xué)習(xí)資料