2010-09-08 79 views
0

是否按以下順序完成軟件測試?功能集成測試

  1. 單元測試
  2. 集成測試
  3. 功能測試

我想確認,如果功能測試集成測試後做或不該。

Thanx

+0

這是「應該怎麼做」或「它是如何做到的」?因爲我知道有太多的人在公司工作,一旦發現錯誤,他們只進行單元測試。 – wheaties 2010-09-08 19:00:37

+0

兩者都是......「應該怎麼做」以及「它是如何做到的」? – Mishthi 2010-09-08 19:03:53

回答

2

這是一個邏輯順序,是的。通常在用戶驗收測試之後進行,然後在發佈之前進行任何形式的公共Alpha/Beta測試(如果適用)。

1

在TDD編碼環境中,這些測試通過的順序通常遵循您的訂單;但是,它們通常以相反的順序被書寫。

當一個團隊得到一組要求時,他們應該做的第一件事就是將這些要求轉換成一個或多個自動驗收測試,這證明系統滿足所有定義的功能要求。當這個測試通過時,你就完成了(如果你寫得正確)。首次寫作時的測試顯然不應該通過。如果它引用了尚未定義的新對象類型,它甚至可能不會編譯。

一旦測試完成,團隊通常可以看到需要什麼才能讓它通過高層次,並沿着這些線路分解開發。一路上,寫入了集成測試(測試對象與對方的交互)和單元測試(測試與其他代碼幾乎完全隔離的小功能原子段)。使用ReSharper等重構工具,可以使用這些測試的代碼來創建對象,甚至是正在測試的功能的邏輯。如果你正在測試A + B的輸出是C,那麼斷言A + B == C,然後從測試夾具中的邏輯中提取一個方法,然後提取一個包含該方法的類。您現在擁有一個可以調用的方法的對象,可以產生正確的答案。

一路上,您還測試了要求:如果要求聲明給定A和B的答案必須是1 + 2 == 5的邏輯等價物,則需求具有不一致性,表明需要爲了進一步澄清(即有人忘記提及在A + B == C之前應將B = 2加到B上)或技術上的不可行性(即計算要求一天有25個小時或一個字節有9個比特) 。這可能是不可能的(並且通常被敏捷方法論認爲是不可行的),以毫無疑問地保證在任何開發開始之前你已經將所有這些不一致從需求中移除。