性能測試對戰單元測試

我讀Osherove的「單元測試的藝術，」雖然我還沒有見過他說的性能測試什麼，兩種思想仍然過我的腦海：性能測試對戰單元測試

性能測試一般不能是單元測試，因爲性能測試通常需要長時間運行。
性能測試通常不能進行單元測試，因爲性能問題通常在集成或系統級別出現（或者至少需要重新創建集成環境性能所需的單個單元測試的邏輯也是如此涉及到單元測試）。

特別是對於上面提到的第一個原因，我懷疑通過單元測試框架（如NUnit）來處理性能測試是有意義的。

我的問題是：我的發現/傾向是否符合社區的想法？

來源

2010-05-20 Brent Arias

我同意你的發現/學習。真正的單元測試只測試系統的一部分，忽略，嘲弄或根據需要僞造其餘部分。集成測試（或迴歸測試）測試大多數或所有單元一起工作，這是性能的真正衡量標準。

來源

2010-05-20 00:41:12

我經常稱系統範圍的測試爲「功能測試」。我不知道如何嘲笑「這個行業」，但在我的公司中，這個白話文被困住了。但是，要實現這一點有點棘手，因爲我們需要一些「外部」系統來驅動應用程序。該應用程序運行在專用硬件上，輸入來自自定義端口，這些端口不可直接從主機PC驅動。儘管如此，這絕對是值得的。 – 2010-05-20 02:39:21

性能測試很可能由單元測試組成。

例如，單元測試可能會向方法中拋出幾個不同的參數，並驗證該方法是否會返回預期的輸出。性能測試可能會執行該單元測試1000次（或任何適合您的值），同時記錄從CPU和內存計數器到每次測試花費的時間。

來源

2010-05-20 00:35:24 NotMe

在某些情況下，您可以使用單元測試來確保某個操作在特定時間段內完成。如果你想爲你的操作添加更多的功能，但你不想犧牲性能，你可以使用單元測試來斷言。當然，這些單元測試是依賴於機器的，但是你可以在方程中添加一些額外的變量或配置。

來源

2010-05-20 16:07:36 serega

所有這一切都取決於你所說的性能測試。當微優化特定代碼時，我通常使用與單元測試非常相似的東西（我應該稱之爲單元性能測試？）。這基本上就是我在這個question中做的事情（雖然不關心真正使用單元測試框架）。但是我也會在BOOST單元測試框架中做這種事情來優化我的C++生產代碼。

真的有不同層次和不同目的的各種性能測試（重負載壓力測試，性能分析，微觀優化）。您在您的問題中所談到的性能測試似乎處於功能測試級別。無論如何，你可能不會使用單元測試框架。

來源

2010-05-20 16:21:21 kriss

單元測試應該沒有時間執行，因爲您只是測試一個非常特定的單元/系統。就像被測系統是ClassA：IClassA一樣，你做你的模擬/存根，只測試ClassA的行爲，而不應該測試除ClassA以外的其他行爲，例如ClassA使用ClassB。你應該注入ClassB的模擬而不是具體來實現這一點。

在性能測試方面，仍然使用像NUnit/MBUnit/MavenThought這樣的測試框架是合理的，只要將這些測試保存在單獨的程序集中，並且不要將它們作爲單元測試的一部分調用。

所以，如果你用耙調用你的測試，你的一些任務可能是這樣的：所有的，一個成功的構建之後總是調用，那裏的測試：

Rake Test:All   #Run all unit tests 
Rake Test:Acceptance #Run all acceptance tests 
Rake Test:Performance #Run all performance tests 
Rake Test:Integration #Run all integration tests

與持續集成，測試

然後：表演每天早上12點啓動一次。

來源

2010-05-20 18:09:01

我喜歡你所說的話，但是我需要運行的性能測試實際上是集成測試 - 例如客戶端和服務器之間的通信速度。糾正我，但我認爲單元測試框架不準備部署客戶端和服務器代碼，分別啓動它們，並在服務器上跳動時給出客戶端看到的結果的結果。 – 2010-05-21 22:03:29

您可以將服務器實現構建並部署到指定位置（虛擬框或遠程服務器），然後將針對該位置執行所有性能/集成測試。有用於部署安裝的軟件包。 – 2010-05-21 23:07:30

我同意性能測試不能是單元測試，但沒有理由我們不能有另一組稱爲性能測試的測試。廣義測試分爲兩類

一）單元測試

B）集成測試

我們在內存中再次運行集成測試真實的數據庫（代替），以確保SQL腳本，休眠存儲庫按預期工作

我的想法是我們可以添加另一組測試，稱爲性能測試，這是每晚構建測試某些功能性能的一部分。這對於在代碼重新分解後追蹤統計數據或評估對某一部分應用程序的更改是否會對另一部分產生意想不到的結果很重要。

我碰到過JunitPerf這可能會幫助我實現這個目標。

來源

2012-01-23 16:12:45 vsingh

我記得幾年前，微軟主張程序員使用Visual Studio Net Application Center Test（ACT）測試他們各自的asp的性能。有（仍然可能在那裏）對個人asp進行交易成本分析（TCA）的整個方法。也就是說，可以使用網絡驅動程序和可能的模擬對象來測試這些asps，以隔離測試中的代碼（即如果未開發，則模擬DB訪問）。

這種方法可以跟隨任何單元測試，只要你有一個驅動程序，還可以選擇一個模擬對象框架來處理尚未寫入的任何依賴關係。這種方法也成爲SOAPUI \ LOADUI的流行。另外，我會建議隔離單個SQL語句，這些語句可以針對給定的數據庫設計進行測試（優化）。這個（DB）SQL單元性能測試可以在SDLC的早期完成，它將發現查詢優化機會。在成本和價值方面：我已經發現早期的UNIT性能測試，在適當的時候使用Mock Objects，將在SDLC的早期識別內存泄漏和過多的CPU使用率和磁盤IO，但是我會'櫻桃挑選'下的代碼測試更高風險的項目。

來源

2013-03-29 15:20:41

單元測試和性能測試存在對比差異。首先，單元測試是根據功能要求測試應用程序。例如，您要確保在單擊主頁選項卡時網頁導航到家，而性能測試是一種非功能測試。在此，您關注的是特定用戶負載下應用程序在一定時間內的穩定性和響應性。

來源

2016-02-08 07:40:43 yash

性能測試對戰單元測試

回答

相關問題