錯誤跟蹤軟件的核心基本功能是什麼？

Question

可能重複：
What should a good BugTracking tool be capable of?

雖然有一大套的功能，一個bug跟蹤系統可以有我覺得這是一個有點矯枉過正，並正在考慮推出自己的解決方案。據說我不想刪除可能經常用於現有解決方案的任何核心功能。

我能想到的迄今爲止的： - 創建錯誤 - 分配錯誤 - 關閉錯誤 - 添加描述錯誤

謝謝！

Answer 1

• 開發者和用戶之間的通信。
• 用戶可以分配特定位信息的能力，如嚴重性（錯誤與他們有多大關係）。
• 開發人員可以覆蓋該優先級，並在可能的情況下給出原因。
• 能夠將任務分配給開發人員。
• 能夠在錯誤，增強和功能請求之間進行排序。增強和功能請求之間的差異非常微小，但非常重要。
• 能夠附加文件（如截圖）
• 能夠自定義字段（如能夠選擇哪個操作系統，哪個服務包級別，應用程序版本等）。
• 能夠擁有自定義用戶配置文件，該配置文件還提供了有關其硬件的詳細信息。如果能夠獲得用戶的電話號碼（如果他們在您的LAN上），那麼您也可以在需要時提問。
• 隱私。一些項目，如安全漏洞利用或處理財務信息的信息，將需要保密。即使是OSS也會不時地做這件事，直到他們能夠準備好補丁爲止。每個人都有自己的規則。
• 能夠顯示修訂之間的變化，以便您可以通過電子郵件發送更改日誌，以便用戶知道您擁有和未完成的任務。
• 關於哪些項目未完成並且完全分配給您/未分配的提醒。

這是所有我能想到的...

Answer 2

定義錯誤。

想到這一點很可能會讓你意識到你會花很多時間「滾動你自己」。

Answer 3

錯誤跟蹤器只不過是需要完成的事情的列表。

它可以像軟件目錄中的文本文件一樣簡單到一個擁有數百個用戶的完全成熟的錯誤跟蹤器。

從您需要處理的內容開始，然後根據需要展開。

Answer 4

這可能超出了您的想法，但對我來說，與源代碼控制的集成是必須具備的。爲了能夠查看與錯誤/問題相關的版本之間的差異非常方便。

Answer 5

使用吉拉，你會很好的掌握。

Answer 6

對於大多數像錯誤跟蹤的系統，通常不會創建或編輯使系統有用的數據。這一切都歸結爲您只需收集數據即可輕鬆瀏覽信息以「增值」。

想想會使用系統的人，程序員，管理人員等等。對於每一羣人來說，什麼類型的信息會讓它值得他們一次又一次地回到系統。你如何讓他們更容易獲得這些信息？

收集信息很容易，增加價值是很難的部分。

Paul。

Answer 7

請請請不;噸花很多時間「滾動你自己的。」在研究和學習使用真實跟蹤系統時，你的時間會更好。

一些看看

Trac，Bugzilla和FogBugz。最後一個爲小型（一家或兩家男士商店？）公司提供免費託管解決方案。

SO有很多關於此主題的話題。

儘量不要自己滾動，除非它只是一個單詞文檔或電子表格。任何時候你花費自己的錢是一種總的浪費。

編輯

既然你將不會被勸阻的話，我也許會添加一些東西別人都沒有提到。

您需要報告功能 - 用戶需要能夠運行查詢，他們應該能夠選擇他們想要「查看」的字段。

缺陷的工作流程/生命週期也是一個很好的特性。 （基本上是缺陷將經過的狀態的狀態機）。實際上，這是一個有用的練習，可供您定義所有用例和功能。鑑於你在大學，並沒有開始作爲一個CS專業，我懷疑你會自己想出很多。花一些時間瀏覽現有產品的功能列表和演示。

電子郵件能夠發送給不同的利益相關方。

匿名用戶能看到他們進入

不同的訪問級別和權限（管理員，經理，開發人員，測試人員，最終用戶）

Answer 8

1. 創建一個錯誤
2. 關閉特定缺陷一個bug

這足以在'錯誤'實體的生命週期中關閉。是否有足夠的功能爲您的目的是另一回事。

看看的Mantis功能，選擇你需要的功能，計算它需要多長時間，你給他們寫，然後把時間花在更有用的東西除非你絕對要創建自己的。 ;-)

Answer 9

這裏有一些重要的特點：

• 分配優先級的錯誤（如緊急，重要，中，小規模的代碼）
• 分配錯誤的特定版本中，這將是固定
• 守望功能（這樣你就可以通過電子郵件發送時的狀態變化）
• 工作流（即誰是工作就可以了，有什麼地位）

Answer 10

FWIW：當我們推出我們自己的請求跟蹤系統，我們建立了它周圍的procmail和我們現有的內部網絡認證系統，因爲我們希望它是非常不顯眼的使用：我們只是發送電子郵件給開發人員（使用，如果我們組的別名想要）並添加一個「[t]」到主題以打開票證。收件人得到修改的電子郵件與原始請求和一個額外的鏈接，該網頁顯示的車票，並允許他們以1次鼠標點擊關閉。所以最常見的任務是通過電子郵件客戶端（打開，請求更多信息，回覆......）進行，雖然也有用於搜索等

只花了幾個小時到一個簡單的Web界面寫後7年左右超過34000張請求的門票，我想聲稱它只有基本核心功能，它的確定：

• 創建票證（由具有顯着的主題電子郵件）
• 收票（點擊電子郵件中的鏈接，然後點擊「完成」點擊）
• 所有通信都通過電子郵件，而不是通過（！）的Web界面誰是收件人或原始郵件的發件人
• 人（打開票）通知有關封閉門票（：+鏈接票「主題<老主題>通過<有人>關閉」身體，足夠的信息，對於大多數人來說，這樣他們就不必去看看這票/錯誤，是等）
• 一個簡單的Web界面提供的搜索功能爲自己/開/發送/團隊票

這可能需要一個更大的開發團隊/更激烈的軟件開發

沒有顯着的特點：

• 取票（欺騙，wontfix，重開等靈活狀態）
• 優先
• 重新分配門票明確（在我們的開發團隊，電子郵件只是被重新發送到倒黴的傢伙誰擁有這樣做）
• 添加註釋的票不被髮送給大家
• 分配錯誤的軟件

因人而異的特定版本，但它一直對我們非常好，到目前爲止，無論是對錯誤和發送者想要跟蹤的簡單的請求。

Answer 11

我們的bug跟蹤系統是我公司與客戶（「活」的產品評論，其中鼓勵現有客戶提出改進意見和用戶界面的調整是其他）之間的兩個基本環節之一。

一個bug跟蹤系統必須首先是鼓勵可追蹤的「對話」與您的客戶。它必須回答這個問題：「你是否已經解決了我一直存在的問題（廣義地定義）？」

它必須有（沒有特定的順序）：

1. 問題或功能請求的簡短描述（標題）
2. 間延長的描述
3. 附加文件的能力/圖像（截圖）
4. 優先錯誤的能力/功能
5. 歸類條目錯誤，特徵，查詢的能力，等等​​
6. 分配錯誤/功能區（UI，數據庫，文檔等）的能力
7. 他分配錯誤/功能的產品（我們跟蹤的五種款產品的bug）的能力
8. 分配錯誤/功能的能力以發行（「被固定在5.1版本」）
9. 分配錯誤/功能能力的人（開發商/作家）
10. 分配錯誤/功能給客戶的能力（記者）
11. 的能力，重新分配給不同的人（開發商）
12. 到解決的bug /功能（它們標記的能力爲完成並準備測試）
13. ，以紀念解決狀態（固定，不會解決，不能複製等）的能力
14. 到&分辨率後，關閉錯誤/功能（把他們趕走列表的功能測試）
15. 能夠重新打開錯誤/功能（如果測試失敗，還原爲「打開」）
16. 能夠通知客戶錯誤已得到解決（例如，通過電子郵件）
17. 每個步驟的日期和時間戳（打開，解決，關閉，重新打開）
18. 能夠報告打開的錯誤數量！ （我們有多接近發佈）
19. 能夠顯示錯誤報告與分辨率
20. 能夠按日期，優先級，產品，人等搜索錯誤/功能
21. 能夠列出和排序錯誤，以便於掃描！

這些是我們通常在我們的系統（FogBugz）中使用的東西。雖然這可能看起來像一個很長的列表，但我們確實使用了我在此列出的所有功能！

Answer 12

分類，優先化和標準化。

和簡單的方法來查詢它使您可以收穫上述三個辛勤工作的回報。

此外，請確保您所做的任何事情都是可擴展！我們總是決定在項目期間根據需要/火災添加/編輯我們的錯誤模板。

這裏有很多很棒的解決方案，你可能不需要自己推出。但是不管怎樣，你都必須做出相同的決定。我們使用的解決方案允許我們推出自己的模板，因此在每個項目開始時我們都會重新討論這個相同的討論。

Answer 13

一個很好的搜索引擎。

令人驚訝的是，有多少錯誤跟蹤產品花費數千美元就會出現這種可怕的錯誤。

沒有一個真正體面的搜索你的錯誤跟蹤更像是一個「錯誤日誌記錄」 - 日誌和遺忘 - 幾乎沒用的系統。