持續測試 | 測試流程提效：在 CODING 中實踐迭代內的持續測試

本文做者：程勝聰 - CODING 產品經理

持續測試帶來的變革

持續測試（或者敏捷測試）要求測試做爲基礎活動貫穿於軟件交付的整個過程當中。相比起在 DevOps 時代陷入困境的傳統測試模式，持續測試首要改變的是「測試後置「的情況，強調測試前置，經過儘早定義測試、測試與開發並行、在過程當中保持緊密協做，從而實現快速反饋業務風險的目的。持續測試的實踐變革是關於人、流程和技術的全面工程：既須要技術上的支撐，好比持續集成、持續部署的基礎能力，也須要人員自動化代碼能力的提高，同時對流程的改進也是其中不可或缺的一環。

正如敏捷宣言開篇提出的四個核心價值，團隊應該聚焦在爲客戶帶來價值的行爲和結果、而不是傳統的循序漸進完成既定項目的事項和生產過程交付物，這對測試的要求也是同樣：

1. 個體和互動高於流程和工具；
2. 工做的軟件高於詳盡的文檔；
3. 客戶合做高於合同談判；
4. 響應變化高於遵循計劃。

然而，對於上述宣言中的「四個高於」字面上的理解，你們每每容易產生困惑：協做很重要，那麼是否是流程、文檔、計劃就再也不須要了呢？其實否則，畢竟軟件的內在複雜度還在，那麼爲了更好地交付軟件而進行的計劃和文檔說明就仍然有着重要的價值。只不過咱們須要改變原來過於臃腫的流程、文檔、計劃，讓其再也不成爲團隊快速響應目標的束縛。因此，「輕流程」、「合適粒度」、「儘早計劃」纔是咱們應該做出的適當的改變。若是說自動化測試和精準測試是在測試執行這個單點上對效率的提高，那麼迭代內測試則是在總體流程上的對測試效率進行提高。

如何實踐迭代內的持續測試

測試過程通常包括計劃、設計用例、執行這幾個環節，下圖就是在敏捷模式的迭代中的測試視角的經典工做流。讓咱們從敏捷模式下測試視角的經典工做流出發，探討一下如何在一個迭代中實踐持續測試。

基於上述場景，咱們能夠根據以下步驟開展測試活動，達成與開發的工做同步、拓寬測試時間窗口的目標：

首先，在迭代規劃會上，產品經理就需求故事與團隊一塊兒進行解讀、分析和工做量評估。在任務認領時，開發和測試（或者充當此角色的另外的開發）結對負責某一個需求故事。當迭代規劃完成時，其實就能夠建立迭代對應的測試計劃，計劃內應該包括迭代故事列表以及相應的驗收標準（Acceptance Criteria，簡稱 AC）。

而後，在迭代過程當中，應該以表明業務價值的需求故事做爲一個總體進行交付。也就是說，結對的開發和測試應該以一樣優先級處理某一個需求故事，儘量快地實現故事的端到端交付後，再處理下一需求故事。所以在開發實現編碼的同時，測試也應該同步編寫該故事的測試用例——多數狀況下是對 AC 進行細節性的展開和編寫補充完整。當用例編寫完畢後及時進行評審，甚至在接口契約獲得保障的狀況下實現接口自動化測試的編碼。這樣每一個故事都是開發完成後立刻測試經過，處於可交付的狀態。

最後，在迭代完成後，甚至能夠執行一遍覆蓋了當前迭代的需求故事所對應的測試用例集，依據測試報告反映的總體測試狀況進行回顧，以待持續改進。

CODING 如何助力實踐迭代內的持續測試

基於上文說起的場景，CODING 以【測試計劃爲測試活動的主體】爲理念，設計並打磨產品，力求給用戶帶來「沉浸式」的測試體驗。接下來將演示如何在 CODING 測試管理中開展一個完整迭代的測試活動：

1. 迭代規劃會上：

首先，從項目協同中規劃好的迭代開始，查看/建立團隊的測試計劃、並關聯對應迭代。

而後在團隊測試計劃建立完成後，計劃中會展現迭代的需求故事。接着爲需求故事建立相應的功能用例，內容上可能只是帶上規劃會中達成一致的驗收標準（AC），把相關的用例任務分配給對應的測試同窗，就造成了一個測試團隊視角的迭代看板。這些操做徹底能夠在規劃會上或會後的短期內完成，測試計劃包括了迭代故事列表以及相應的 AC 做爲內容的用例，暫且稱之爲「測試計劃 alpha 版」。

2. 迭代進行中：

開發同窗實現編碼的同時，測試同窗同步編寫該故事的測試用例，用例逐步補充完整的測試計劃能夠稱爲「測試計劃 beta 版」。當用例編寫完畢以後及時進行評審，甚至在接口契約獲得保障的狀況下實現接口自動化測試的編碼。這樣的節奏也就實現了測試與開發的工做同步。

需求故事提測後，執行測試用例，對照用例步驟驗證功能是否正常。在這樣「小步快走」的模式下，迭代在任什麼時候候結束均可以交付有業務價值的需求故事，而不是一批「半成品」。如此經過開發測試的緊密協同工做，逐步接近體現業務價值的持續交付。

3. 發佈的時候：

在迭代最後需求故事都完成後，咱們就能夠得到包含完整測試用例內容的「測試計劃正式版」。由今生成測試報告，根據經過率和報告反映出來的風險來判斷是否能夠發佈到下一個環境（如 STG）。

總結

CODING 迭代視角的測試工做流的核心理念是引導測試的前置，在過程當中加強了測試與其餘角色的協做和反饋。目的是經過產品能力來幫助團隊固化良好實踐，從而實現高效的測試：

首先，儘早規劃了測試。從需求規劃會開始，在充分理解需求並認領任務以後，咱們就能夠圈定測試範圍，並由此產生簡單版本的測試計劃、並快速制定驗收標準和完成初步用例的編寫。

其次，經過創建需求和用例的關係，對高優先級（業務價值）的需求所需測試作到一目瞭然，爲基於風險的測試策略（Risk-based Testing）打下基礎。

再次，迭代進行過程當中實現測試和開發工做的並行開展。在開發工程師進行業務代碼實現的同時，測試工程師能夠對測試用例做進一步細化補充完整，甚至實現測試的自動化代碼實現。經過緊密協同、「小步快走」，每次交付的都是完整業務價值的「成品」。

最後，測試過程當中的操做以及產生的數據並記錄下來，可以快速的反饋給團隊，而這些沉澱下來的數據，將成爲工程實踐持續改進的指引。