一、對開發人員的建議：
- 控制版本/補丁發布頻率（重要）
a) 版本交付間隔保證在2個工作日以上，盡量避免出現版本/補丁頻繁交付導致的測試不充分。
b) 控制版本補丁數量，原則上除緊急補丁外，多個補丁合並發送。這樣可以讓測試人員對交付版本提供一個更准確的質量狀況。
- 版本能按計划交付（重要）
a) 根據青銅器上填寫的版本交付計划或者約定的交付日期進行版本交付。
- 明確每個版本的送測內容（重要）
a) 含故障單、缺陷編號、具體功能修改等，避免出現模糊描述：如修改了用戶管理模塊--應描述修改的具體內容。
b) 補丁包也要有送測說明
c) SVN上注釋要標清楚，如改動的模塊
- 研發必須進行單元測試（重要）
a) 確保交付版本冒煙通過，冒煙測試用例由測試人員提供。
b) 配合必要的代碼漏洞掃描工具，APPScan，findbugs
c) 在項目特別緊張的情況下，我個人看法是開發和測試坐到一起，發現問題立刻修改，不需要錄入青銅器，開發人員若沒有時間可以不用自測，減少中間環節。
- 填寫版本發布文檔和安裝部署說明（一般）
a) 安裝部署手冊由開發（還是測試？）人員編寫。安裝部署說明也列入測試檢查范圍，避免工程部后續部署工作不順暢。
- 缺陷處理要求
a) 根據bug緊急重要程度優先解決
b) 缺陷是否修改存在爭議時，先跟測試溝通，若無法達成一致，再由指定的仲裁人（）決定。
c) 共通類和影響范圍比較大的bug，建議跟測試人員一起溝通，減少修改不全面的情況。
d) 版本發布時，確保本次修改的bug在青銅器上已修改狀態，這樣測試人員可以根據提交回歸的時間和狀態來迅速定位交付版本需要回歸的缺陷。
e) 測試人員定期匯報項目bug狀態，原則上每周五匯報，模板如下：
| 項目名稱XXX |
創建審核 |
修改中 |
回歸測試中 |
關閉 |
| 致命 |
|
|
|
|
| 嚴重 |
|
|
|
|
| 一般 |
|
|
|
|
| 輕微 |
|
|
|
|
| 合計 |
|
|
|
- 數據庫變更
a) 進入系統測試階段，數據庫結構更改用sql腳本
- 版本上線標准：
- 需求→設計→代碼能夠一致。
a) 以便於測試能夠在測試的同時識別可能存在的功能遺漏。
- 業務需求（變更）傳遞要基於文字
a) 不接受單個人口頭的業務傳遞，所有業務必須有相應的文字作為支撐。
b) 針對需求變更和互聯網繳費這類項目：開發跟測試員梳理完需求后，測試人員把自己的理解和測試點（風險）進行整理，發送項目團隊確認。
二、對測試人員的要求：
- 測試人員定期（如每個月)統計開發人員工作表現、發送項目經理
- Bug描述：
a) 提交BUG要描述清楚。注明操作步驟、測試環境、描述清楚正常現象和BUG現象的差異。
b) 某個問題若在多個頁面發現，提交到一個問題里，並在問題描述中把對應頁面描述清楚；
c) 盡量避免提出重復BUG，兩個不同頁面的相同問題應歸為一個BUG的兩次出現。更深層面的相同BUG原因，可以多和工程師溝通了解；
d) BUG級別嚴格按照最新標准執行；
e) 嘗試對bug產生的根源作分析；
f) 如果出現了某個bug修改不完整的情況，不要急於駁回，先溝通！
g) 程序員比較忌諱時間碎片化，尊重程序員的工作方式，不要一發現問題就找程序員，編碼過程中思路被打斷對程序員來說是很痛苦的事情。可以收集多個問題后統一找程序員處理，或是在即時通訊工具上留言，看程序員的時間安排，給他幾分鍾時間緩沖，在其方便的時候溝通；
h) 程序員很怕“一般BUG”和“重開”。設“一般”和設置“重開”時慎重一些，不確定的可以先和程序員溝通過再提。
i) 多和程序員溝通，了解開發思路。了解開發思路能夠幫助測試人員找到測試步驟的盲點，更容易測出真正的問題。這樣的溝通，也會幫助開發人員檢驗開發思路的正確性，更好的提高項目團隊的效率。
- 系統測試日報：
j) 測試報告包括《每日測試報告》、《階段性測試報告》和《版本測試報告》
k) 原則上有測試任務時，每天匯報《每日測試報告》，匯報bug狀態；
l) 原則上每個大版本出具《版本測試報告》，短期內連續發布多個小版本的情況可以出具《階段性測試報告》， 這個報告側重於多個版本的質量趨勢。
(0 0)
+------oOO---(_)------------+
| |
| 『歡迎關注』 |
| 張老師的小黑屋 |
+--------------------oOO-----+
|__|__|
|| ||
ooO Ooo