單元測試

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

答：并發度，相應時間，機關時間吞吐量，系統穩定性，多場景。

性能測試是通過自動化的測試工具模拟多種正常、峰值以及異常負載條件來對系統的各項性能名額進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結合進行，通過負載測試，确定各種負載系統下的性能，目标是測試當負載逐漸增加時，系統各項性能名額的變化情況。壓力測試是通過确定一個系統的瓶頸或者不能接受的性能點，來獲得系統提供的最大伺服器級别的測試。

軟體測試中，內建測試的步驟是什麼？

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.導緻子產品測試完成延後

自底向上

主要缺陷發生在底層比較有利

測試環境比較容易實作

觀察測試輸出容易

必須開發驅動子產品

知道最後一個子產品添加進去，程式才是一個整體