2008-09-07 81 views
8

每次我需要估計某個項目的時間(或查看其他人的估計)時,都會分配時間以進行測試/錯誤修復,這將在alpha和生產版本之間完成。我非常清楚,對未來規模未知的問題進行估計並不是成功估算的好方法。但是由於各種原因,一定數量的小時總是會在開始時分配給這部分工作。最初的估計值離真實的最終值越遠,調試涉及的人越多,在他們「超過」估計值時將不得不採取後續措施。需要多少時間才能完成測試和錯誤修復

所以我的問題是:你所看到的最佳策略是什麼?整體開發估計的百分比?設定小時數(期望它會上升)?還有別的嗎?

需要考慮的其他事情:如果客戶負責測試(與內部質量保證相對),您將如何回答這個問題,並且您必須分配一定的時間來響應可能或可能找不到的錯誤(所以你需要找出錯誤修復的時間估計值,但不能用於測試)

回答

9

這確實取決於很多因素。僅提到幾個:您正在使用的開發方法,您擁有的測試資源的數量,項目中此階段可用的開發人員數量(許多項目經理會在最後將人員推到新的地方)。

正如Rob Rolnick所說的,1:1是一個很好的經驗法則 - 但是在規範不好的情況下,客戶端可能會推送「錯誤」,這些錯誤實際上是嚴重錯誤的功能。我最近參與了一個項目,該項目使用了許多版本,但由於規格太糟,更多的時間花費在修復錯誤上而不是實際開發上。

確保良好的規格/設計和您的測試/錯誤修復時間將會減少,因爲測試人員可以更輕鬆地查看測試內容以及如何測試,並且任何客戶端都可以通過更少的途徑獲得更多功能。

6

也許我只是寫了錯誤代碼,但我喜歡devs和測試之間的比例爲1:1。我不等到alpha測試,而是在整個項目中進行測試。邏輯?根據您的發佈時間表,從開發開始到Alpha,Beta和發佈日期之間可能會有相當長的時間。此外,越早發現錯誤,他們要修復的就越容易(也更便宜)。

一個很好的測試人員,在每次簽到後很快發現錯誤,是非常寶貴的。 (或者,更好的是,在從PR或DPK簽入之前)簡而言之,我仍然非常熟悉我的代碼,因此大多數錯誤修復都變得非常簡單。採用這種方法,我傾向於將大約15%的開發時間留給bug修復。至少在我做估計的時候。所以在16周的運行中,我會離開2-3周左右。

4

以前的項目中只有大量的累計統計數據可以幫助您提供準確的估算值。如果你有一組明確的需求,你可以粗略計算你有多少用例。正如我所說,你需要爲你的團隊提供一些統計數據。您需要知道平均每個蝨子的錯誤數量來估計錯誤總數。如果你的團隊沒有這樣的號碼,你可以使用industry average numbers。在估算了LOC(用例數量* NLOC)和平均每行錯誤之後,您可以對釋放項目所需的時間做出或多或少的準確估計。

從我的實際經驗來看,花在修復bug上的時間等於或多於(在99%的情況下:))比花在原始實現上的時間更多。

5

從測試聖經:

Testing Computer Software Testing Computer Software

頁。 31:「測試佔產品初始開發的45%。」因此,一個好的經驗法則是在初始開發階段將大約一半的工作量分配給測試。

2

使用符合設計或「代碼合同」(前置條件,檢查斷言,後置條件,類不變量等)的語言使「測試」儘可能接近您的類和類特徵(方法和屬性)儘可能。然後使用TDD以合同測試您的代碼。

盡你所能使用盡可能多的自建代碼生成。生成的代碼被驗證,可預測,更易於調試,並且比全手編碼的代碼更容易/更快地修復。爲什麼寫下你能產生的東西?但是,請不要使用OPG(其他人)生成器!您生成的代碼是您控制並知道的代碼。

您可以期望在項目過程中花費翻轉比率 - 也就是說 - 您將在項目的開始階段(1:1)編寫大量手寫代碼和合同。當你看到模式時,教你編寫一個代碼生成器來爲你生成代碼並重用它。您生成得越多,設計,編寫,調試和測試的次數就越少。到項目結束時,你會發現你的方程已經顛倒過來:你的核心代碼少了,你的焦點轉移到了你的「葉代碼」(最後一英里)或專業化(相對於泛化和生成的)代碼。

最後 - 得到一個代碼分析器。一個好的,自動化的代碼分析規則系統和引擎將爲您節省大量時間,找到「愚蠢的錯誤」,因爲人們在如何使用特定語言編寫代碼方面存在衆所周知的問題。在艾菲爾,我們現在擁有埃菲爾督察,我們不僅使用了90多條規則,而且正在學習爲自己發現的「陷阱」編寫自己的規則。這樣的分析器不僅可以幫助您節省錯誤,而且可以提高您的設計 - 即使是綠色程序員也能「快速獲得它」,並儘早停止發現菜鳥錯誤並學習更快!

重寫現有系統的經驗法則是:「如果寫了10年,重寫需要10年。」在我們的案例中,我們使用艾菲爾,設計合同,代碼分析和代碼生成,在4年內重新編寫了14年系統,並將全部交付4/2。新系統比舊系統複雜約4倍至5倍,所以這就說了很多!

相關問題