遊戲公司有各種的版本控制和軟體也有流程管理軟體，各種內部分享bbs,OA。

各種的各種也無法取代checklist表的重要性。

首先版本控制和內部分享bbs,OA是無法做缺陷統計的。雖然版本控制可以對應輸出bug記錄，但面向的是程式，是應對程式碼入庫後自動編譯。

穿插1個話題：為什麼版本控制首選不用cvs，而用svn。

首先cvs和Svn支援分支(branch)和基線(tag)，二者完全一致；

cvs不支援對檔案的"重新命名"(rename)，這個對於版本的過程化管理來說是很重要的一塊；
cvs雖然有樂觀鎖的概念，但是產業間大多實現虛擬服務，工作間已經不是都在版本控制上；
cvs不支援"移動"(move)，人為的移動需要更改cvs的儲存庫位置；
cvs只能是c/s結構的，而svn通過連線Apache，可以用http/https進行安全訪問；

繼續完成上次的：

隨著遊戲後期的玩法優化和修補內容，依賴測試用例和常規的測試方法雖然也可以完成測試部內部的工作。

但對於與專案組快速迭代溝通部分來說，無任何幫助。還是需要一項，通過打勾，不通過標紅，阻塞則為黃色的checklist（檢查表）

checklist表需要由QA提出，然後發給專案組，制定修復的時間。然後根據修復的時間，調整修復項的數量。（修復的時間和修復項有變更怎麼辦，這個比較正常也是正確的，因為節奏是需要隨時調整的，後文有提到）

檢查表的用法為：

首次：包含本期[新增][調整][高需求迴歸]，新增項部分由於出場為首次，這個也是用所有缺陷走查一次的bugview所做不到的。

第二次：首次未通過的內容+本期[新增][調整][高需求迴歸]，以上為小里程碑的做法，不適合非單一功能線的需求。

第三次：同第二次的內容，但不能讓這個雪球越滾越大，一般滾動這個快1個月了。月底在做一次總結。

關於表單的排序，可以以時間線和優先級別線來制定其中一項，為什麼不能二項，試下就明白了。除非只有2條，同1天提的，才可以二項。哪部分需要用表單，應該拆分到哪張表裡，按專案組來定。

好吧，讓回顧下多個時期的一些buglist的設計。如果是我的同事應該就會知道是哪個期和我共事，而我用的哪種了。（其中測試執行者和測試結果，QA備註這3項是不可缺少的，如果是大公司（這裡就是上面修復項變更需要關注的）權級變更推薦需要做，目標域因專案組來定，只支援單向，一個向是由專案對外介面人-非程式對於修復項，一個是測試根據專案組來調整級別。可以使用excel裡的函式來幫助）

2010前~~第三方的模板不提供，一些表還是比較幼稚的，畢竟buglist不能取代缺陷報告，而二者內容混淆。

buglist1：包含元素功能模組，開發者，缺陷編號目標%，重新開啟項標註，[新增][改進]，無法測試記錄。

buglist2: 包含元素功能模組，流水號，缺陷編號，缺陷內容，阻塞記錄，無法測試記錄，[新增][改進]驗收。

buglist3: 包含元素功能模組，流水號，修復率，最後驗收結果，新增改進，新增缺陷項，[新增][改進]驗收。

buglist4：包含元素功能模組，開發者，失效測試，[新增][改進]驗收，功能雷達圖，無法測試記錄，阻塞比例。

... ...

注意並不是功能越多越好。