驗收測試與單元測試示例

Question

好吧，所以我一直在試圖查看測試信息，不同的測試庫什麼不是等等。

在我看來，人們總是清楚地將這些測試的差異定義爲高水平和低水平。而這一個很好的測試出的應用程序將包含兩個風格測試以及集成測試，等等，等等

但似乎關於測試類型的每一篇文章的東西，如結束「在實踐中可能很難看到什麼差異實際上是「。我感到奇怪的是，人們看起來很樸素，你們必須同時進行測試，才能達到任何完整的代碼覆蓋率，同時也沒有任何關於每個可能的樣子的良好信息/示例。

我問，因爲我開始一個新項目，這有望成爲更大並且比任何我已經在過去所做的更多參與。我希望通過我的測試保持良好的工作流程，並確保我在測試中不會造成差距（以前的項目規模很小，而且我可能遇到的任何差距似乎都不會造成任何重大問題在生產中不是簡單的t0正確）

我知道，它似乎是一個很好的驗收測試，自然地引導你到你的單元測試，一旦你得到它，這是這個神奇的事情發生和你的發展生活，因爲只是那更加幸福。

無論如何，沒有人知道什麼好討論的上一個良好的測試工作流程，一個是談論你的接受/集成測試之間移動到你的單元測試，什麼不能起步。

例如，對於.NET將是巨大的，但由於大多數測試框架黃瓜（小黃瓜）/ rspec的等等都意味着是相當可讀的任何例子應該是不錯的。

Answer 1

"in practice it could be hard to see what the difference actually is"：

我只能給一般的測試建議。大型軟件項目通常涉及某種層次結構。

• 在開發階段，開發人員通常對小單元（單元測試）進行白盒測試。這裏可以使用內部知識來減少測試用例的數量（如果兩個函數是正交的，則不需要測試所有可能的組合）。這是測試層次結構中的較低端。
• 在集成軟件組件被放在一起，不同的人（測試人員）只測試接口的行爲（黑盒測試）。這些人不具有內部知識，只是接口的規格。
• 系統集成結合了更大的系統。
• 等等。

爲了使測試有效，每個級別都依賴於在較低級別上測試的完全預先測試的組件。否則，更高的測試級別將不得不包括其組件的基本功能，但只能使用黑盒測試（必須假設最壞的情況，即要測試的功能之間的依賴關係）。因此，測試案例的數量呈指數增長，使得全面覆蓋的測試成爲不可能。

分層法優化了這裏的測試工作。

Answer 2

請參閱video on different types of testing。不同類型的測試技術與表格進行比較。