單元測試

性能測試：如何評價系統的極限性能？

答：併發度，相應時間，單位時間吞吐量，系統穩定性，多場景。

性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，二者能夠結合進行，經過負載測試，肯定各類負載系統下的性能，目標是測試當負載逐漸增長時，系統各項性能指標的變化狀況。壓力測試是經過肯定一個系統的瓶頸或者不能接受的性能點，來得到系統提供的最大服務器級別的測試。

軟件測試中，集成測試的步驟是什麼？

1.採用何種系統組裝方法來進行組裝測試。

2.組裝測試過程當中鏈接各個模塊的順序；

3.模塊代碼編制和測試進度是否與組裝順序有關；

4.測試過程當中是否須要專門的硬件設備；

5.集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。

（自頂向下和自底向上的集成測試方法）

模塊測試（單元測試）

模塊測試是針對程序中單個子程序，子程序或者過程進行測試的過程，也就是說，一開始並非對整個程序進行測試。1.將注意力集中在程序的較小單元上，所以它是一種管理組合測試元素的手段。

2.模塊測試減輕了調試（準肯定位並糾正某個已有錯誤的過程）的難度，這是由於一個某個錯誤被發現出來，就知道具體在哪一個模塊中。

3.模塊測試爲咱們提供同時測試多個模塊的可能，將並行工程引入軟件測試。

模塊測試的目的：將模塊的功能與定義模塊的功能規格說明或接口說明進行比較。

測試目標：不是爲了說明模塊符合其規格說明，而是爲了揭出模塊與規格說明存在矛盾。

測試用例的設計

模塊測試測試用例設計以下：使用一種或多種白盒測試用例方法分析模塊的邏輯結構，而後使用黑盒測試方法對照模塊規格說明以補充測試用例。

模塊測試過程當中，咱們有兩點要考慮：1.如何設計一個有效的測試用例集。2.將模塊組裝成工做程序的方式

非增量測試：軟件測試獨立地測試每一個模塊，而後將這些模塊組裝成完整的程序。

增量測試：將下一步要測試的模塊組裝到測試完成的模塊集合集合中。

測試單獨的一個模塊須要一個特殊的驅動模塊和一個或多個樁模塊。

另外一種選擇是增量測試，不一樣於獨立地測試每一個模塊，增量測試首先將下一個要測試的模塊組裝到前面已經測試過的模塊中去。

驅動模塊：是人們編寫的一個小模塊，模擬被測模塊的上一級模塊，用來將測試用例驅動或傳輸到被測模塊中（也能夠數測試工具代替）。驅動模塊還必須向測試人員展現被測模塊的結果。

樁模塊：是指被測模塊所調用的模塊，主模塊是「驅動模塊」，被測模塊編制一些模擬下級模塊功能的「替身」模塊，代替被測模塊接口，接受或傳遞被測模塊的數據。

結論

1.非增量測試所須要的工做量要多一些。自底向上的增量測試須要驅動模塊，但不須要樁模塊。自頂向下須要樁模塊，但不須要驅動模塊。增量測試所需的工做量要少一些，由於使用過了前面測試過的模塊來取代非增量中所須要的驅動模塊或樁模塊。

2.若是使用了增量測試，能夠較早地發現模塊中與不匹配接口，不正確假設相關的編程錯誤。這是因爲儘早地對模塊組合進行了集成測試，若是是非增量測試，只有到了測試過程的左後階段，模塊之間才能夠「互相看到」。

3.使用了增量測試，理由如2所述，若是使用了非增量測試，直到程序組裝後，這些錯誤才浮現出來，到了這個時候，就難以定位錯誤，由於他可存在程序的任何位置，很難定位。相反，若是是增量測試，這種錯誤就很容易發現，由於這個錯誤可能與最近添加的模塊有關。

4.增量測試會將測試進行的更完全，換言之，增量測試用先前測試過的模塊，取代了非增量測試中使用樁模塊或驅動模塊，所以，到最後一個模塊測試完成時，實際模塊受到了更多的校驗。

5.非增量測試所佔用的機器時間顯然少一些，由於一個被測模塊可能有多個子模塊，而一個子模塊可能只有一個驅動模塊，因此完成一次增量測試所須要的機器指令，顯然多餘採用非增量測試方法所須要的指令。

6.模塊開始時，若是採用非增量測試，就會有更多的機會進行並行操做。

自頂向下測試和自底向上測試

注：「自頂向下測試」，「自頂向下開發」和「自頂向下設計」經常使用做近義詞，「自頂向下測試」和「自頂向下開發」確實是同義詞，但「自頂向下設計」則是獨立的概念，在自頂向下設計模式下的程序既可以使用自頂向下的方式也可使用自底向上的增量測試。

注：自底向上的測試常被錯誤地當作非增量測試，緣由在於自底向上的測試的開展方式與非增量測試是相同的（即對底層或終端的模塊進行測試），可是自底向上是一種增量測試。

最後：兩種方法都是增量測試。

自頂向下測試

自頂向下測試從程序的頂部或初始模塊開始，測試開始以後，選取哪個後續模塊進行測試沒有惟一正確的方法。

1.惟一原則是：要成爲合乎條件的下一個模塊，至少是一個該模塊的從屬模塊事先通過了測試。

2.若是樁模塊只是返回了控制，或顯示出一條信息確卻沒有返回一個有意義的結果，主模塊就會發生失效。這並非主模塊存在錯誤而是由於樁模塊未能模擬出相應的模塊。此外，樁模塊僅僅返回一個「已經連通」的結論是不夠的。

3.另外一個須要考慮的是採起什麼樣的形式將測試用例提交給程序？（由於頂部模塊既不傳入參數，也不執行輸入、輸出操做）

解決方法：

1）編寫樁模塊的多個版本，每一個版本將不一樣的有效測試數據返回給主模塊。

2）將測試數據放在外部文件中，由樁模塊讀取並返回給主模塊。

測試完頂部模塊以後，接下來可能的測試序列有不少。總的來講，不存在最佳模塊序列，但有兩項參考指南

1.若是存在程序的關鍵部分，那麼在設計模塊序列中應當把這些關鍵的模塊今早地添加進去。所謂「關鍵模塊」，多是複雜的模塊，某個採用新算法的模塊，或不被懷疑容易發生錯誤的模塊。

2.在設計模式中應該把I/O模塊儘量早地添加進來。

自底向上測試

大多數狀況下，自底向上測試與自頂向下測試是對立的，一方的優勢是另外一方的缺點。一方的缺點又是另外一方的優勢。自底向上的策略開始於程序的終端模塊，測試完這些模塊以後，沒有最佳的方法挑選下一個測試的模塊。惟一的原則是：要成爲合乎條件的下一個模塊。有別於使用樁模塊，因爲驅動模塊能夠交迭地調用被測模塊，所以不須要驅動模塊提供多個版本，大多數狀況下，開發驅動模塊要比開發樁模塊容易些。

自底向上的不足之處是：它沒有早起程序框架的概念，事實上，直到最後一個模塊被添加進來，才造成可工做的程序，它就是完整的程序。儘管I/O程序能夠在整個程序集成測試以前進行測試。

自頂向下沒有沒法創建全部測試環境問題，若是驅動模塊看作一個探測指針的話，那麼將它直接放入被測模塊，不會受到中間模塊的影響，檢查自頂向下相關問題的其餘問題，不會作出設計和測試重疊的不明智的決定。由於自底向上的測試直到程序設計完成後纔開始，沒有測試完一個模塊以前就開始另外一個問題也不會存在，這是由於自底向上的測試不在有如何將數據綁定到樁模塊中去的煩惱。

自頂向下的測試
優勢	缺點
主要是缺陷發生在程序頂層很是有利 一旦引入I/O功能，提交測試用例會很是容易 早起程序框架能夠演示，並可激發積極性	必須開發樁模塊 2.樁模塊比最初表現的更復雜 3.在引入I/O以前，向樁模塊引入測試用例比較困難 4建立測試用例的環境困難 5.觀察測試用例輸出困難 6誤解設計和測試能夠交迭進行 7.致使模塊測試完成延後
自底向上
優勢	缺點
主要缺陷發生在底層比較有利 測試環境比較容易實現 觀察測試輸出容易	必須開發驅動模塊 知道最後一個模塊添加進去，程序纔是一個總體