在剛聽到敏捷測試的時候做過一定的了解。但是實際專案中並沒有碰到過，就一直沒有系統的理解和調整過。前段時間接手乙個使用敏捷開發的專案，從產品設計到第一版上線的時間只有2個月的時間。這讓原有的測試流程飽受打擊。如何快速的面對敏捷制定符合自己的測試流程，更好的服務於專案成為團隊的首要任務。
通過思考與討論，對原有的測試流程做出了調整：
一. 測試產出調整：測試計畫，測試點，測試報告。
1. 測試計畫：修改原有word文件輸出，直接使用甘特圖展示測試計畫（同步與開發計畫）
二. 提測流程調整：開發節奏，提測節點
1.其實這個主要是爭對開發節奏的調整，其實在敏捷測試的概念是針對敏捷開發而來的。只有快速的開發節奏才能進行快速的測試節奏。模組式開發是常用的敏捷開發模式，那麼作為測試我們需要做的的就是模組化測試。
2。將產品（專案，需求）拆分成不同提測段，全部提測完成後進行整合測試。
1.原型討論：
2.測試點整理：
其實在原型討論的過程中就可以將大部分的測試點整理完成，至於測試點的整理方式就不多做介紹。主要說明一下需要額外整理的：1.系統結構，對系統結構上進行整理，主要目的是能夠對全域性有一定的了解，能夠系統的對專案就像管理與測試點的分析。2.系統規範，這個需要參考產品及ui的設計規範，對命名，互動，處理流程，字段屬性進行羅列，保證在測試過程中能夠下意識的找到這些非功能但是足夠影響體驗的問題。
3.資料庫測試：
主要分作兩部分：1.資料庫邏輯測試，主要是對業務與**進行對比分析，判斷**是否能夠滿足業務需求。中間表的刪除及更新機制。2.資料庫表測試，主要是爭對字段，索引。字段需要考慮包含：是否唯一主鍵，命名，長度，型別（小數字數，時間格式，中文，特殊字元，亂碼），是否支援為空，重複資料，是否包含索引等
4.**測試：
說到這裡可能在部分公司就無法進行了，主要是有兩方面的考慮：1.個人能力無法達到，2.涉及崗位許可權限制，無法拿到**許可權。
在這裡需要說明的就是萬事還是可以去爭取一下的，可以從三點進行說服：1.研發可以對非業務及機密**進行加密封裝（洩密問題）；2.對測試僅提供**獲取的許可權，單元測試另起目錄（影響研發**）；3.第三人的介入可以督促研發同學對自己的**規範及注釋規範，保障**的可閱讀性。（如有充足時間可以協助產品ui走查頁面，當然如果還有效能相關的需求基本上也可以開始了）
5.功能測試：
專案開始提測後就需要分別對提測模組進行測試了，對於跨模組的問題可以先記錄後面在整合測試中進行驗證。同時需要對測試點進行需改補充，保證測試點的可用性。
6.整合測試：
全部提測完成後就進入了不斷的回歸當中，主要關注點在模組間的數量，邏輯，操作等。
7.系統測試：
在不斷的修復與回歸過程中，缺陷也會穩定下來，排除已知不用修復及延期修復的問題外沒有問題了，就可以進行下部分的測試。模擬正式環境（有條件可以直接使用正式環境）對專案的進行覆蓋性測試，確保產品具備可移植性。
以上相關流程並不適合於所有團隊，還是需要更具不同團隊的人力及專案環境進行不同程度上的調整，才能夠保證團隊能夠高效的執行。建議閱讀到此處的人有想法進行團隊及專案管理的，可以系統的對pmp 進行學習。個人認位還是有一定幫助的。
軟體測試乾貨 敏捷測試流程
千鋒教育軟體測試 敏捷測試流程 千鋒教育的王曉軍老師在對敏捷測試做出介紹的時候與現行的瀑布式測試流程做出過對比 對於乙個三個月的專案說，產品把需求分析完了給開發，然後產品就沒事兒了 開發開發完成之後給測試，然後開發人員也不忙了。測試完成之後上線。那麼在產品分析的階段，開發和測試都是沒事幹的 這裡只對...
敏捷測試團隊的測試流程
一 接到專案後，ba明確客戶的需求，必要時可以帶上測試經理 開發經理 測試員 開發員，出乙份書面需求說明 二 測試人員初步學習 ba串講 測試人員提問題 ba給出回答 重新整理學習 測試人員反串講 評審 出乙個需求規格說明書 模組思維導圖 三 測試經理根據需求規格說明書制定測試計畫 此spirit共...
敏捷測試流程規範
1 立項與規劃階段 建立product backlog，確定整個專案的需求清單，同時完成需求 設計評審，並成立專案組，為後面迭代階段做準備 2 迭代階段 建立專案 需求評審 迭代計畫 分配任務 研發 測試階段 每日例會 驗收產品 發布產品 演示會 專案總結 1 立項與規劃階段 1 需求評審，進行需求...