性能測試：如何評價系統的極限性能？
答：併發度，相應時間，單位時間吞吐量，系統穩定性，多場景。
性能測試是通過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行，通過負載測試，確定各種負載系統下的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接受的性能點，來獲得系統提供的最大服務器級別的測試。
軟件測試中，集成測試的步驟是什麼？
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程序可以在整個程序集成測試之前進行測試。
自頂向下沒有無法建立所有測試環境問題，如果驅動模塊看做一個探測指針的話，那麼將它直接放入被測模塊，不會受到中間模塊的影響，檢查自頂向下相關問題的其他問題，不會做出設計和測試重疊的不明智的決定。因爲自底向上的測試直到程序設計完成後纔開始，沒有測試完一個模塊之前就開始另一個問題也不會存在，這是因爲自底向上的測試不在有如何將數據綁定到樁模塊中去的煩惱。
| 自頂向下的測試 | |
| 優點 | 缺點 |
|
2.樁模塊比最初表現的更復雜 3.在引入I/O之前，向樁模塊引入測試用例比較困難 4創建測試用例的環境困難 5.觀察測試用例輸出困難 6誤解設計和測試可以交迭進行 7.導致模塊測試完成延後 |
| 自底向上 | |
| 優點 | 缺點 |
|
|