2011-03-01 45 views
25

如果一個人負責編寫測試,另一個負責完成測試,或者編碼人員和測試作者應該是同一個人,理想情況下會更好嗎?誰應該寫測試?

回答

19

單元測試是您在編寫代碼時所做的工作。這個測試是測試你的視圖應該如何工作(在類/方法/算法級別),它在開發時支持你,你可以在修改之前和之後運行測試,看看事情仍然依照測試你有沒有到位。看到這是將幫助他/她工作的程序員。此外,測試還將提供一種方法來查看應該如何處理任何查看代碼的人。 TDD並沒有改變這個概念,而是強調一個編碼需要首先考慮它應該如何工作以及期望什麼。

如果沒有看到自己的問題有問題,可以嘗試配對編程,代碼評論或其他方式來更多的眼睛和大腦來看待事物。我仍然堅信單元測試是程序員的工具,而不是其他任何人完成的工作。

來到其他類型的測試,像集成測試功能測試甚至(系統)性能測試,這可能是好事,有其他這樣做。特別是如果你想自動執行這個測試,它需要知道如何做事情,也可能是更高水平的業務知識測試什麼和如何。

回答你的問題,也取決於文化和您的組織如何運作,但是,我相信你在所有的情況下,想要做單元測試代碼開發的一部分。如果這會導致問題,那麼組織中可能會有其他問題,或者需要研究的問題。

更新

下面是我在組織看到了一些事情影響到單元測試的做法:

  • 有些人可能不想寫單元測試;
  • 有些人可能不知道如何編寫良好的單元測試,這可能會破壞這樣做的好處,並可能被用作「證據」單元測試是不好的;
  • ,該機構可能不會帶給人們一起工作,而有不同的責任,如編碼器的代碼,測試人員測試等,這可能會迫使某人單元測試;
  • 有些人可能會聘請編寫單元測試,因此,如果這個角色沒有改變它違背編寫單元測試你的代碼;
  • 可能會有一個非常小的組織,這可能暗指每個人都會做一些事情;
  • 整個組織不承認單元測試的好處,而是儘快實現代碼儘可能快的解決問題 - 後來,誰正在努力完成單元測試測試?它是一個人嗎?開發商?管理?
  • 是組織自由決定誰進行單元測試?

如果有一個單元測試的協議,上述事情可能是需要處理的問題,以便使組織進入自然狀態。如果您有擁有良好單元測試經驗和經驗的人,讓他們帶領事情帶領其他團隊看到魔法的單元測試

我個人認爲,如果人們看到單元測試的好處,能寫出好的單元測試,自動化他們建立的,如果球隊可以自己決定如何組織如何獲取單元測試的書面會都落在原地因此開發人員在開發代碼的同時編寫單元測試,任何人都可以隨時爲他們正在查看的任何代碼添加更多的單元測試。如果有測試,他們會專注於其他類型,如功能測試或探索性測試的測試。

+0

單元測試是單元測試代碼,功能原子是孤立的。 「測試你的觀點應該如何工作」可能適用於任何類型的測試。 – StuperUser 2011-03-01 13:16:27

+0

好吧,當然這有點貴,我假設我們知道單元測試在這裏。你想讀什麼? :) – murrekatt 2011-03-01 13:32:22

+0

你能否舉例說明可能出現的問題,可能被破壞或需要查看的問題? – Henno 2011-03-03 08:15:29

7

隨着TDD的發展單位(讀一個程序員或一雙)應該寫測試。 TDD(測試驅動開發) - 單元測試通常處於技術層面。開發單位應該在他們來實施課程時寫下它們。如果其他人寫測試,你可能遇到的問題是外力會影響設計。當開發人員進行設計時,TDD運行良好。

BDD/ATDD應該參與QA/PO。 (BDD)(行爲驅動開發)和ATDD(驗收測試驅動開發)測試通常以較小粒度級寫入。更好的測試是與利益相關者一起編寫的。因此,寫這些的更好的人是QA(質量保證),PO(產品所有者)或BA(業務分析員)。這並不是說開發人員無法撰寫他們,只需要進入該角色即可。

成對工作的美妙之處在於,如果您的雙人寫測試,測試寫入時會自動完成測試。

+0

我很好奇這個話題,但不知道的術語。您是否願意擴展'TDD','BDD','ATDD','QA'和'PO'? – 2011-03-01 12:17:32

+0

@Delan - TDD和BDD之間的區別:http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd – 2011-03-01 12:25:22

+0

@Liutauras和@John,謝謝你! – 2011-03-01 12:25:48

10

這個問題將邀請許多不同的答案,一些基於組織的工作方式,一些是基於規劃和測試的資格。組織測試有很多不同的方式,尤其是因爲組織規模不同,可能有或沒有資源聘用不同的團隊。

有不同類型的測試:

  • 單元測試
  • 集成測試
  • 功能測試
  • 非功能性測試 - 壓力,滲透等多種類型
  • 用戶驗收測試

I ñ我的經驗:
單元測試(孤立功能的原子例如一個控制器動作)和集成測試(這些原子一起工作,例如與域層對象一起工作的控制器,與數據層對象一起工作的域層對象)應由開發人員完成。

功能測試(系統功能規範狀態),應該由一個獨立的QA團隊來完成。

非功能性測試可以由QA團隊或架構師/技術主管完成。

UAT(系統是適合的目的)應該由客戶來完成。

這背後的原因是,自動化單元測試和集成測試是白盒(你可以看到應用程序如裏面的代碼),他們將需要由開發人員(不neccessarily開發商負責的完成代碼在測試中)。
功能測試和UAT是黑盒子(你不能看到應用程序內部),所以更有可能由非技術人員完成,但熟練的測試分析。
根據測試內容和整體策略,非功能測試可以是黑色或白色方框。

重要的是要指出,通過測試另一個人的工作來發現更多的缺陷,而不是測試自己的工作。 測試人員會以不同的方式進行思考,因此尋找/嘗試在開發過程中沒有考慮到的事情,而人們自然會保護自己的代碼(無論客觀化程度如何)。

如果沒有獨立的測試團隊,讓開發人員測試彼此的代碼是很好的。

爲了回答您的問題,當我是測試人員時,我負責測試分析(決定測試規範需要進行哪些功能測試)並編寫測試腳本並手動執行測試。一旦編寫了這些腳本,任何測試人員都可以執行它們,但重要的是,測試分析是獨立於開發人員在應用程序上的工作完成的。

+0

+1,責任方與測試類型有關。軟件測試不是一個單一的過程。 – mcyalcin 2011-03-01 12:34:07

+0

@mcyalcin,你能評論你的評論嗎? :-) – Henno 2011-03-03 08:03:24

+0

@Henno,不太適合評論,但是:單元測試關注微模塊,是開發人員的責任;集成測試可以是開發者(複數),架構師;功能測試分析師或測試人員(閱讀具有領域知識但不是程序員的人員);非功能測試具有各種組件,與離散專家f.e.安全分析師的安全性和系統測試人員的負載測試(閱讀可將功能測試移植到負載測試工具的人員)。 UAT基本上是客戶進行的最後兩項。其他類型/級別存在.. – mcyalcin 2011-03-03 08:37:51

1

在我的開發團隊的非正式政策是

每個人做每件事。

也就是說,沒有測試人員,程序員或架構師。每個人都應該做一些所有的活動。

這是爲了避免瀑布過程。如果一項活動是一個人唯一的保護,那麼發展就可以成爲順序化的過程,人們處理下來的工作並且不知道他們所做決定的全部後果。

這並不意味着每個人都在同時工作。這意味着每個人在某個時間點上執行各種任務

+0

這是一個很好的政策 – Morten 2011-03-04 09:34:42

+0

這是一個不可擴展的解決方案。當你有一個由10多個開發人員組成的團隊和一個龐大的應用程序(並非所有東西都是Todo列表示例應用程序)時,不僅推薦分離工作,而且還需要。 – 2014-11-24 17:57:20

+0

@SSHThis絕對。請注意,通信路徑的數量隨着團隊中的少數人快速失去控制:(n *(n-1))/ 2。 – BryanH 2015-11-16 19:58:48