TD是開發，測試人員協同工作的工具。缺陷報告本身應該具有清晰的指引性。
當資訊不明確時，意味著資訊傳匯出現問題，失真或者通道斷裂。

TD的最根本的使用者是開發人員，他們據此處理程式中發現的問題。
開發人員處理問題時需要關心的資訊應該在缺陷報告記錄中體現：
。讓開發人員快速理解問題的資訊：眾多功能和用例中的哪一個
---什麼功能出的錯
。讓開發人員能瞭解或想象到捕獲此問題時的場景：開發人員能夠在除錯環境下還原或者能夠進行程式碼邏輯分析
---具體的操作步驟，甚至驅動資料，系統環境(這個不常需要)
。誰報告的：
知道具體的報告者，在上述資訊不明確的情況下，開發人員可以知道找誰詢問。

誰能決定Assigned To?
。測試人員並不一定知道（甚至通常不知道）該分配給誰
分配給誰需要一定的專案開發資訊，功能的開發者，如果涉及多個模組和多個開發者，則不容易分辨出來。那相當於測試人員在診斷問題了。
專業的測試人員相對可能比較容易決定，與開發更接近，但參與測試的客服人員則無法決定。
在不清楚分配給誰的情況下，分配給專案經理（具體的人或者建立一個抽象帳戶）


最近發現TD報告經常不符合上面基本的預期。
---Detected By：很多是admin. (是測試人員沒有自己的帳戶嗎？)
---描述過於簡單：開發人員需要憑藉聯想才能估計到問題所指

原因可能有：
。沒有要求
。沒有培訓
。個人工作習慣：報告可能來自個人工作的記錄，直接貼上到TD的
。規格化操作可能更費時：嫌慢


以下是2個示例：

1.bug1280
Summary:基本屬性
Details:
1：顯示資訊不完整排程引數下面的解釋說明沒有完全顯示


。基本屬性？是哪個模組的功能，操作導航呢？
。配上截圖更一目瞭然

2.bug1279
Summary:資料字典→修改屬性
Detials:
1、修改屬性後資料庫中屬性無法更改、例如：在介面中修改tb_10028_1117表中的dest_mis_id欄位的長度及欄位名稱，在TB_1031中的長度發生變化，對應TB_10028_1117中的欄位長度未發生變化，修改dest_mis_id為dest_mis_id_1在表TB_0044中的名字仍為dest_mis_id，更改屬性後需重新開啟後，在其他規則中才能看到有更改


。如果能把Details的內容精簡到Summary，並且提供更多的資訊，似乎考驗我們的歸納能力了
Summary該是什麼樣子的？
---介面配置工具資料字典維護,修改屬性不起作用
（沒有絕對的指標，參考指標是：更多的重要資訊，準確）
。我猜測這是客服人員報告的：內容非常淳樸，以一個純粹的使用者的角度：他能簡單地告訴你做的根本不對。如果以這種目標審視我們的程式，並最終符合，則程式會比較完美。

----------------------------------------------------------
這是我的回覆：（我的習慣是直接在Description中回覆處理描述）

字典資訊維護的基本邏輯應該是：從現有物件獲取，而非孤立指定。

說明這種編輯式的操作是錯誤的。（缺少先期定義）

在已開啟規則配置的情況下，使資料字典的變化即時生效，需要不那麼容易的程式實現（事件響應，規則的編輯狀態控制）。
----從軟體完美的角度，確實應該這樣。
（退而其次，提示一下使用者，資料字典更新只有在重新啟動程式後才生效）
理論上，除非不得已，你才需要重新啟動程式，有時重新啟動是簡化實現的手段。---但可能惹使用者抱怨。