2016-07-04 52 views
1

這樣的事情作爲單元測試計劃我在的Java/Java EE的項目的工作,我必須提供一個單元測試計劃,我已經在許多集成測試計劃的工作,這說明整合測試場景,但我從來沒有聽說過單元測試計劃。是否有在Java中

本單元測試計劃必須描述我已經完成的單元測試以及它們在規範中的相關規則。

Java項目生命週期中是否有這樣的事情?如果是,我可以在哪裏獲得示例如何製作一個

+1

閱讀:http://www.softwaretestinghelp.com/how-to-write-test-plan-document-software-testing-training-day3/ – Azodious

+0

沒有什麼特別的與Java和單元測試計劃有關 - 您的問題不是特定於Java或任何其他編程語言。 – Jesper

+0

「單元測試計劃」是一種人工製品,通常是90年代運行瀑布流程的項目的可交付成果。 –

回答

1

單元測試應該是自我解釋。

他們被程序員用來確保他們的代碼是正確的,不會影響現有的代碼。

任何程序員都應該可以自由添加新的測試,所以如果需要的話,維護一個文檔來定義單元測試的計劃是一個非常奇怪的方法。

從我的角度來看,應該使用測試計劃來定義驗收測試或集成測試,而不是單元測試。

請注意,單元測試在編程階段非常有用,並且在編程階段不可能準確知道將寫入哪些測試。因此可以想象,只有在不需要計劃的情況下,才能在工作結束時編寫單元測試計劃。

1

在一定程度上,你的問題聽起來更像是一個邀請的討論,但無論如何:

至少在他們stricter意義上說,單元測試是非常「開發企業」。作爲開發人員,您可以創建「白盒」測試,在編譯時運行以創建來自運行代碼的反饋。

當然,一些項目經理現在可以想出他/她需要您準確「計劃」您的單元測試活動的想法。

在我看來,這違反了敏捷所代表的任何東西。您會看到:在敏捷中,有人認爲功能可爲客戶帶來價值。作爲開發人員,您將創建實現功能的類,但所有這些「實現細節」只對您很重要。你的項目經理不應該關心你的設計是怎樣的,它包含了多少類。所以他真的不應該要求你在你的單元測試中制定一個計劃前期。哎:你在敏捷的基礎上創建類(並測試它們);但你應該知道前期你將會發展什麼?!

長話短說:PM應該考慮制定這些「客戶特徵」;因此當您的PM詢問關於該範圍的集成或系統測試計劃時,這是公平的;但你最好挑戰他的想法監督你的單元測試!

+0

我不反對你的發言。然而,單元測試涉及代碼測試覆蓋率分析的概念,這些分析在「開發人員業務」領域之外確實存在,因爲它是可交付成果整體質量的一部分。 – Gimby

+0

@Gimby當然;但是,如果你的下午開始告訴你你必須達到的覆蓋範圍,那麼有些事情是錯誤的。 TDD和單元測試可幫助您實現高覆蓋率;但是別人給你一個目標......再一次,在我眼中不是「敏捷」。 – GhostCat

+1

感謝您的迴應,我試圖讓他們對自動生成的Sonar和JavaDoc報告感到滿意,推進了在Java項目生命週期中沒有這樣的事情的論點,所以我想確保我的論證。 – dwa9ssa

0

我最近被一位新經理問及我們爲我們的軟件的最新版本提供了哪些測試計劃和測試報告。我的回答是:

  • 我們開發使用測試驅動開發我們的節目。這構成了我們的測試計劃。
  • 我們從未發佈任何自動化測試失敗的版本,因此釋放它意味着它已通過我們自動化測試的100%。這構成了我們的測試報告。

經理似乎很滿意。