一、測試人員在釋出或主題計劃階段的工作

 1. 制定計劃：短期計劃更好。（優先順序變化 、環境的不穩定，長期計劃很難實現。）

 2. story卡處：需要做、開發中、待驗證、已完成。

 3. 評估story：工作量（小中大）。集體評估，再調整。

 4. story測試評估：

解決什麼問題？客戶怎麼用這個功能？最壞的結果是什麼？有關聯絡統嗎？安全嗎？效能有要求嗎？

從未接觸過的業務，會不會影響測試？第三方產品需要額外時間。

用法、使用場景、實用價值。

瞭解測試報告中需要的內容。（測試結果持久化工具，測試證明截圖。）

 享受敏捷，讓會議有趣。（站會發言定時打斷。）

開發：先實現最基本的功能。Story分開。線下任務可以不做。儘早完成影響系統其它功能的story。

測試資料：去掉敏感資訊，如銀行卡、身份證等。

 測試計劃：

1. 輕量級：測試裝置需求、測試人員，投入時間。假設、風險、效能、UAT。

2. 使用測試矩陣：

條件1條件2

功能1

功能2

可以被當作測試覆蓋率。顏色區分狀態。

3. 測試表格、白板

4. 自動化的測試列表。

傳達測試結果：

1. 已通過測試數：如功能25個測試，共100個用例通過。

2. 測試覆蓋率：包、類、方法、可執行程式碼行。測試覆蓋數/總數。95%

缺陷度量：

二、迭代前的準備

如果迭代前的活動不能為迭代中省時間，果斷放棄。

1. 迭代需求討論會：sprint開始前。（事先明確，客戶意見一致。瞭解story對不同角色的人員意味著什麼。基於現實的用例討論story。）

2. 迭代開始時編寫使用者驗收測試-高層次。（對於複雜story，至少編寫一個常用路徑，一個非常用路徑。）

3. 測試策略：考慮何時開始測試它們。

三、迭代開始

1. 迭代計劃：分解story，評估工作量。（參考UAT測試用例、通過條件。）--------通過原型例項理解story。

可以不做功能去掉。站在不同角度考慮：使用者、程式設計師、產品，文件編寫人員。考慮關聯到的系統功能影響，儘早暴露不確定因素。

當別人不同意時：建議先加一部分功能，試一個迭代。

 測試策略選擇：大部分的子功能用"剛好夠用"的資料，而資料全集用於驗證全部的功能。

確定工作量：計算總的時間估值，或卡片數量。備選story。學習新工作時：新增風險時間。

2. 可測試story：

1. 整個團隊參與可測試性問題

2. 如系統時間：通過增加執行時伺服器屬性。（job：修改執行時間。）

3. 高層次測試和示例

1. 一圖勝千言。修改功能時：列印現有功能，筆標註。

2. 需求=story+交流+使用者場景+導向圖

4. 測試用例審查

你覺得  有什麼遺漏嗎？哪塊最可能有風險？重點關注哪裡？

測試用例作為文件儲存起來：用例易於維護。測試程式碼匯出API，類結構圖。

四、編碼和測試

1. 驅動開發：

從簡單入手：先寫基本流---->異常場景構建。再增加複雜度：探索性測試。

評估風險：條目  影響  * 發生概率  = 風險。複雜功能，列出潛在風險。

編碼和測試同時進行，讓所有團隊成員都參與其中，放棄那些可能基本不會發生的極端情況。

分歧時，尋找第三方力量，確定不要重複討論這一問題。

一次只完成一個story。

自我展示：大聲說出自己的想法：放一隻小小鴨子提醒自己：提問前多思考。

展示給客戶：

2. 完成測試任務

在訪問真實服務的資料完成之前，可以使用Mock或硬編碼資料測試。

迭代無法完成時：放棄一個story。立即通知開發人員。協助測試。

缺陷0容忍。

3. 哪些問題需要記缺陷

a.開發確認是問題 b.開發不能立即修復 。嘗試為每個story預留2小時或半天修復缺陷。（立即修補，以後修補，不修補。）

團隊原則：必須在迭代內修復缺陷，讓整個團隊看到缺陷。

缺陷數量不能超過10。

多個缺陷考慮組合缺陷。

4. 確保快速構建

a. 不需要在迴歸測試中包括所有邊界情況和類似情況。

5. 迭代度量

進度度量、缺陷度量。

記錄測試時間：

單表的CRUD。

複雜業務邏輯。

缺陷重現時間，缺陷驗證時間。記錄缺陷型別。

靜態分析工具：findbugs，找到sprint優先順序最高問題的增長。

度量：

story測試執行數量。

自動化狀態。

測試通過/失敗折線圖。

每個story的總結、狀態。

缺陷度量。

迭代結束時的收尾工作

1. 迭代回顧會：30分鐘內。演示新功能。

哪些做得好，不好，下個迭代的嘗試。

”開始、停止、繼續“清單。設定一個檢驗點，驗證是否有改進。

執行單測程式碼覆蓋率工具。迭代開始的第4天前，完成所有story的高層次的測試用例。開發在迭代第4天前交付一個story給測試。維護一份待辦列表。

花時間慶祝，讓團隊暫停腳步，重新整理視角。

2. 成功的交付

培訓、文件。

定期做一個重構迭代，減少技術債務，提高測試覆蓋率。總有些測試不值得自動化。

自動化迴歸測試，至少每天執行。

可靠性測試、容錯、復原測試、安全性。

儘早使用外部第三方測試，降低風險。

用DB指令碼處理資料轉換，向後相容的問題。資料庫修改後，在資料庫上執行diff。

設定任務提醒功能。

3. 考慮文件是給誰的，他們用它做什麼，如果沒有答案，則考慮是否放棄寫文件。

4. 釋出標準：效能指標、測試覆蓋率、沒有重大缺陷、讓客戶明確新功能，比如現場演示。