2017-04-04 351 views
1

我們如何測試我們編寫的junit測試用例?我認爲手動測試,即創建測試數據,斷言預期和實際值沒問題。但是最近我遇到了junit測試通過的情況,但是在UI測試期間特定的SUT代碼失敗了(這意味着junit測試無法防範bug)。如何測試junit測試

+1

[測試驅動開發(https://開頭en.wikipedia.org/wiki/Test-driven_development)。事後並沒有什麼幫助,但是在編寫生產代碼之前編寫測試可以確保測試正在測試你認爲他們正在測試的內容。 –

+3

如果您發現需要測試您的測試,某些事情已經絕望地錯誤。 – Makoto

+4

測試軟件的第一條規則:測試只能顯示出現錯誤,而不是缺少錯誤。測試軟件的第二條規則是:除非軟件執行簡單的邏輯操作,否則詳盡的測試實際上是不可行的.http://www.testingexcellence.com/seven-principles-of-software-testing/ – jrook

回答

-1

我遇到了一個情況,即junit測試通過但 特定的SUT代碼失敗。

您的單元測試不應該忽略任何方法的功能或其副作用的覆蓋範圍。這就是代碼覆蓋率工具如Cobertura發揮作用的地方,並不是測試通過,但我們需要確保每個方法及其副作用都經過了單元測試/正確覆蓋。

不,代碼覆蓋率和安慰劑一樣糟糕。你可以有100%的線路覆蓋率,但仍然與OP在同一個修復程序中?

像Cobertura這樣的工具至少可以找到我們正在做的代碼覆蓋率有多少百分比,但是如果您不關心測試覆蓋率,您會得到更多的錯誤。

重點是這些覆蓋工具不會告訴您您的內部業務需求是否真正達到。

+5

不,代碼覆蓋率只是這是一個壞的安慰劑。你可以有100%的線路覆蓋率,但仍然與OP在同一個修復程序中。 – Makoto

+0

我同意你的意見,但是,如果你不關心覆蓋範圍,你會得到更多的錯誤 – developer

+1

我不一定同意哲學。代碼覆蓋作爲柺杖表示冗長而複雜的代碼。意圖和設計更簡單的代碼沒有很多行或分支代碼。 – Makoto

3

如果你的測試都通過,但實際代碼這些測試被用來支付是失敗,那麼兩種情況之一發生:

  • 測試套件已不適應覆蓋該具體用例,或
  • 爲覆蓋該特定用例而編寫的測試不足。

無論如何,你需要重寫你的測試。有一個不允許你防止特定異常行爲的測試套件會使你的測試套件毫無價值。

你也提到它在UI測試期間顯式失敗。這可能是由於用戶界面和後端測試之間斷開了期望。在這種情況下,可以將後端測試與UI的實際輸入進行對齊,或者考慮實施涵蓋UI工作流程的集成測試。

+0

不應該得到一個downvote,但upvote。 – davidxxx

1

我們如何測試我們編寫的junit測試用例?

您不應該。
單元測試不是絕對可靠的,但測試測試沒有意義。

您應該將自動測試視爲可執行規範。
一般來說,如果你的規格有誤,你會被卡住。 對於自動測試,它是完全一樣的東西。

爲了避免這種問題,或至少減少它,我喜歡:代碼

  • 審查,並與開發團隊的同行測試代碼。

  • 完成由業務團隊驗證的集成和業務測試的單元測試。

  • 自動測試的持續改進。

    很簡單:只要在UI手動測試中檢測到一個洞,應該更新自動測試,如果測試存在但缺少一些檢查,或者如果缺少測試應該創建新測試。

+0

@Makoto對不起,我還沒有完成。 – davidxxx

+0

不夠公平,但是你可以不使用HTML換行符嗎?有點扔掉東西。 – Makoto

1

要驗證的單元測試的質量,我個人使用以下技術:

  1. 覆蓋度量。擁有良好的線路和分支機構覆蓋率是個好主意。但通常不可能有100%的線路覆蓋率,而覆蓋本身並不能保證代碼實際上被測試,而只是從測試類中調用。

  2. 測試代碼審查。我個人更喜歡用清晰的結構「設置 - 運行 - 斷言」編寫測試。如果缺少「運行」或「斷言」步驟,則測試出現問題。

  3. Mutation testing。有一些框架允許你以一種簡單的方式修改你的生產代碼(在代碼上應用mutators),然後在修改的代碼上運行你的單元測試,如果沒有測試失敗,這個代碼沒有被測試或測試不好。對於Java我使用PIT Mutation Testing

此外,有時是有意義的應用不僅僅是單元測試,但也有一些其他的測試技術 - 手動測試,集成測試,負載測試等