爲什麼我們要寫測試用例？

所以我知道你可能會說，這不是一個好問題，簡單的搜索可以給我我的答案，但事實並非如此。我已經閱讀了很多關於測試及其重要性的內容。我知道編寫測試用例有助於在編程時發現潛在的錯誤。當你讀書時，他們都只是重複相同的抽象定義。但是在寫了大量的測試案例之後，我得出這樣的結論，即不能避免潛在的錯誤，也不能提高產品質量。爲什麼我們要寫測試用例？

那麼試想一下，我們有一個測試情況如下超過了一堆我們的功能：

Assert.IsTrue(divideNumbers(4,3) == 1); 
Assert.IsTrue(divideNumbers(4,2) == 2); 
Assert.AreEqual(divideNumbers(8, 4), 2); 
Assert.That(divide(10,2), Eq(5))

所以，一邊寫測試用例，通常我們試圖斷言一堆非常基本的真實性像兩個方程是真的嗎？這個函數的結果是否等於期望的結果？他們是平等的嗎？它失敗了嗎？對象是指定類的實例嗎？，......

我曾在很多軟件開發團隊工作過。幾乎在所有時間和所有團隊中，在編寫了一些測試用例之後，我們遇到了一種情況，在這種情況下，我們看到的功能。因爲它們非常基本，而斷言類不能幫助我們，不是真的，等同的，不是空的，......

那麼，爲什麼真的寫測試用例呢？爲什麼我們真的需要它們以及它們如何幫助我們提高產品質量並減少潛在的錯誤？

來源

2015-04-28 Amir Jalilifard

如果您的測試用例無用，請編寫更好的測試！ –

你是問爲什麼寫單元測試而不是集成測試或爲什麼寫測試呢？ –

如何？什麼是好的測試用例？ –

編寫單元測試的原因是組合語言。將您的函數設想爲圖中的節點，並在函數之間調用邊作爲邊。 main是源節點，終止程序的功能是目標節點。您的程序可以展現的不同行爲的數量等於從源節點到任何目標節點的路徑數量。這是節點和邊的數量的指數。這意味着不可能測試您的程序可以顯示的所有不同行爲。這就是單元測試進來的地方。每個單元測試都會測試一個節點（調用一個具有特定輸入的函數產生期望的輸出），或者一個邊（調用具有特定輸入的函數生成對相鄰函數的函數調用）。然後需要的測試數量僅爲O(|V|+|E|)。

這具有限制，您將無法捕獲僅在執行特定路徑時才表達的錯誤，並且在調用單個函數時不會表達錯誤。這個限制就是爲什麼用其他函數儘可能少的耦合來編寫自包含的函數是很重要的。

來源

2015-04-28 23:17:14

幾乎在所有時間和所有的球隊，編寫一些測試案例之後，我們遇到的情況是，我們看到斷言類的功能並不能幫助我們，因爲他們是非常基本的，而正常的錯誤在一個特定的情況下提出，這不是一個真實，平等，不是空的問題。......

你自己說過了。基本的Asserts通常用於單元測試或簡單測試或任何你稱之爲的東西。也就是說，它們通常用於驗證一些簡單方法的輸出，或者確保那裏的變量保持在最小和最大允許值之間。如果某個Web服務結果包含您想要的數據，您無法期望從Assert中驗證。

的誤差通常會把在不被真正的，平等的，不是空

健康測試，直接關係到你的代碼的模塊性事項的具體情況。在設計正確的代碼中，測試會容易得多，並且您最終不會試圖找到測試特定代碼部分的解決方法。也許你遇到的問題可以通過更好的軟件設計方法來解決。

那麼，爲什麼真正的編寫測試用例？爲什麼我們真的需要它們以及它們如何幫助我們提高產品質量並減少潛在的錯誤？

你不必來測試你的程序。沒有一個測試就可以編寫這麼多的代碼，他們也可以完成這項工作。雖然適當的測試代碼能使人感到快樂的原因很明顯是在萬噸測試方面的書籍中提到，教程等

來源

2015-04-28 23:22:24

當你沒有測試編寫代碼，你會怎麼做？在幾乎每次更改之後，您都會運行整個應用程序，然後等待直到它開始，您轉到剛剛更改的頁面，輸入了一些數據，然後按按鈕，然後檢查...如果答案正確，彈出窗口，郵件發送等。你做測試。但你只需手動完成。並且在每次更改後重復所有這些測試。如果你不重複他們，那麼你會發現生產中的錯誤，你將不得不在壓力下糾正它們，你將不得不再次檢查你是否正確地修復了它們。你將不得不手動執行它...

因此，不要在每次更改後重復它，只需編寫VALUABLE測試，快速運行它們，修復錯誤並儘早回家。

這種方式或其他你做試驗。在開始時，似乎自動測試需要更多時間，因爲您必須編寫更多代碼

來源

2015-04-29 01:40:04 piotrek

爲什麼我們要寫測試用例？

回答

相關問題