敏捷測試中縮短測試周期的小tips

　　如今公司用的是敏捷開發，即功能是以用戶的需求爲核心，以版本迭代的方式逐步完善的。從測試的角度出發，這種開發模式極大地緩解了傳統開發模式中，最後工做量壓積在測試身上的狀況，至關於將一整個系統的功能拆分紅幾個版本分批次測試。可是若是公司配備的測試人員較少，而又有多個系統的新版本要一塊兒上線，仍是會存在新版原本不及測試，全部工做壓在測試身上的狀況。

　　通過思考，我發現如下2個tips能夠必定程度上縮短測試周期：

　　1）用Xmind思惟導圖羅列功能點的形式來替代詳盡的測試用例；

　　　　測試用例自己就是寫給測試看的，在團隊中只有1個測試人員，而項目時間又十分緊湊的狀況下，能夠用思惟導圖列出本期的功能點，包含冒煙測試、異常測試和大數量測試等。固然文字描述要儘可能清晰，保證本身之後能夠看懂；

　　2）使用4輪測試的方法來測試；

　　　　第一輪：冒煙測試。即：將新版本中全部的功能進行一遍基本功能測試，若是基本功能都不能知足應立刻打回給開發；這個過程最好控制在半個工做日之內；

　　　　第二輪：詳細測試。根據測試用例或思惟導圖的功能點進行詳盡測試，這一輪測試和普通的測試同樣，須要考慮各類異常操做和歷史數據的處理等；當開發人員將bug後修復後,對修復的功能進行驗證;

　　　　第三輪：總體功能的迴歸測試。上線前對整個系統確認一遍,是否由於開發修復了bug而引發新的問題。按照經驗來說，開發在修復bug後須要着重對該bug涉及的業務流程進行一遍測試，每每業務邏輯相關的地方容易引起新缺陷；

　　　　（在第三輪和第四輪之間有產品驗收環節，若是產品對最終功能沒有異議便可上線）

　　　　第四輪：線上環境確認。生產環境每每是不容許有測試數據的，這一步的重點在於校驗功能是否已經上線，關注點通常爲如下2點：

　　　　　　1）新功能上線後，生產環境是否對相關角色的權限進行了配置，是否存在遺漏；

　　　　　　2）新功能若是涉及到歷史數據的處理，務必要確認生產環境的歷史數據是否被處理穩當；查看處理過的歷史數據時頁面是否會由於處理不當而報錯；

　　　　相較於傳統的測試流程，重點在於加入了第一輪的冒煙測試。相較於以往對一個個功能展開測試，等待開發一一修復，再一一驗證比起來，這種方式極大地節省了時間。若是該版本基本的功能缺陷較多，可一次性將這些缺陷提交給開發，在開發人員修復的這段時間裏，咱們能夠處理手頭的其餘工做。