團隊敏捷化轉型過後，該如何進行項目的測試以及驗收？敏捷測試與傳統測試有什麼不同？自動化測試在其中又擔任着怎樣的角色？本文將給大家介紹敏捷自動化測試，以及Choerodon豬齒魚自動化測試的落地。
敏捷測試的定義和意義
在傳統開發模式中，開發人員和測試人員往往各司其職：開發人員瞭解到產品需求後開始編寫代碼，測試人員拿到產品需求說明書後開始編寫測試用例，等到開發完成，再開始對照測試用例進行人工測試工作。
但是在軟件生命週期的需求、設計、開發、測試這四個階段中，後面的階段一般是依賴於前面的階段的，所以越往後期響應變化的難度越大。比如，在開發過程中不僅需要響應需求變更，而且需要響應設計上的變化。從這個角度來看，處於最後階段的測試必須及時響應前面三個階段的所有變化。可是在傳統的開發模式中，當需求變更產生的時候測試人員所編寫的測試用例往往已經完成，需要對其進行推倒重構，整個測試流程就是在重複一些沒有用的工作。
傳統測試流程圖：
而敏捷測試是遵從敏捷軟件開發原則的一種測試實踐。敏捷開發模式把測試集成到了整個開發流程中而不再把它當成一個獨立的階段，因此測試變成了整個軟件開發流程中必不可少，需要考慮人力、時間成本的一環。敏捷測試包含了具備專業測試技能人員在內的跨職能團隊，這使得這種組合式的團隊能更好地交付價值，滿足項目的業務、質量和進度目標。
在敏捷開發模式中，所有的開發人員同時也是測試人員，對自己的業務負責，對團隊的代碼負責，是一種邊開發邊測試的模式。敏捷模式中一到四周的短開發週期，克服了傳統模式中項目週期長、生命週期的工作內容不好分配、後期變更影響大等困難。
由於敏捷方法中迭代週期短，測試人員應儘早開始測試，包括及時對需求、開發設計的評審，更重要的是能夠及時、持續的對軟件產品質量進行反饋。敏捷測試中通常包含以下幾個階段來保證敏捷測試的可靠性、時效性：
1. 驗收測試：對於這個迭代中新增、修改的功能按照迭代初期提出的需求內容進行測試驗收。可採用冒煙測試的方法對新版本的業務流程進行測試。
2. 迴歸測試：對於模塊進行全量測試，保證其全部功能的可用性，驗證當前迭代新增、修改過的功能對於其他內容沒有不良影響。
3. 系統測試：運用場景法測試和相互交叉測試保證整個系統在迭代結束後處於一個可發佈狀態。
簡單地說，敏捷測試就是持續地對軟件質量問題進行及時的反饋與響應。
敏捷測試流程圖：
自動化測試能帶來什麼
自動化測試在敏捷測試中佔有絕對的主導地位。雖然在傳統項目開發週期的測試階段也推薦自動化測試，但由於整體的項目週期比較長，人員上的資源也較爲充足，不使用自動化測試也可以控制測試人員人天成本並且達到測試目標。一般來說，迴歸測試能夠獲得幾周甚至上月的時間，而在敏捷的開發模式中則迫切要求測試的高度自動化，一個迭代通常是兩三週的時間，那也就意味着你只有兩三天的時間來進行整個項目的全套測試流程。沒有自動化，也就談不上敏捷。在敏捷測試流程中，主要分爲以下幾個主要測試階段：
▌單元測試（Unit Test，UT）
是針對程序模塊（軟件設計的最小單位）來進行正確性檢驗的測試工作。程序單元是應用的最小可測試部件。在過程化編程中，一個單元就是單個程序、函數、過程等；對於面向對象編程，最小單元就是方法，包括基類（超類）、抽象類、或者派生類（子類）中的方法。
▌集成測試（Integration Test，IT）
整合測試又稱組裝測試，即對程序模塊採用一次性或增值方式組裝起來，對系統的接口進行正確性檢驗的測試工作。整合測試一般在單元測試之後、系統測試之前進行。實踐表明，有時模塊雖然可以單獨工作，但是並不能保證組裝起來也可以同時工作。
▌用戶驗收測試（User Acceptance Test，UAT）
用戶驗收測試，也叫用戶可接受測試，一般在項目流程的最後階段，這時相關的產品經理、業務人員、用戶或測試人員根據測試計劃和結果對系統進行測試和驗收，來決定是否接收系統。它是一項確定產品是否能夠滿足合同或用戶所規定需求的測試。
▌迴歸測試（Regression Test）
迴歸測試是軟件測試的一種，旨在檢驗軟件原有功能在修改後是否保持完整。迴歸測試主要是以檢查退化爲目的的測試。退化主要指由於系統的版本更新，在之前的版本中正常運行的功能變得無法正常運行，或者緊急修正了某個問題，但引發了其他的問題的現象。
以上這四種測試模式，目前都可以找到適用的主流自動化測試框架來滿足需求。單元測試和集成測試可以使用如今比較流行的JUnit、TestNG、Spock等框架進行測試。而用戶驗收測試與迴歸測試可以使用一些api接口測試框架 REST Assured + TestNG 、mocha + chai 等。還可以使用一些針對UI界面的測試框架例如selenium和appium來編寫測試腳本。
Choerodon自動化測試落地
在敏捷測試的支持過程中，Choerodon平臺支持了基於手動測試的操作結構（項目版本->用例文件夾，測試循環->測試階段）的主流自動化測試框架。目前包括 mocha + chai 的api測試框架，以及 TestNG + REST Assured 的api測試框架。未來迭代中會新增支持 TestNG + selenium 的前端測試UI框架。從而完整地支持了敏捷測試中包含四個測試方面的主流框架（單元測試與集成測試在持續交付模塊中落地實現）。
在自動化測試的運行模式上，我們沿用了持續交付模塊所使用的基於不同的k8s平臺定義環境，然後通過頁面修改運行配置，達到可在不同環境中嵌入運行測試的目的。運行結束後將測試報告回傳並加以解析，生成測試用例、測試階段和測試執行。並儘可能保留並重新設計了不同框架的原生html報告，給了PO多種查看測試結果的途徑，且支持定時任務等運行方式。
類原生的 Mocha + chai 測試報告：
雖然在技術上支持了敏捷化的自動化測試，但是在自動化測試落地的過程中，也遇到了一些問題的。
1. 重新定義工作量
在敏捷的開發模式中，迭代規劃會議尤爲重要。因爲敏捷團隊中沒有專門的測試人員，所以當一個團隊決定去實踐自動化測試的時候，意味着相同難度的任務工作量基本變成了原來的兩倍。作爲PO在規劃故事的過程中，應該充分考慮到測試腳本的編寫工作量，並計算到成員的工作內容當中，從而給團隊成員”減負“，鼓勵他們更高質量地完成測試任務（畢竟在測試腳本上偷懶可比在業務代碼上偷懶容易多了）。
2. 鼓勵互相幫助
從敏捷測試的理論上來說，每個開發人員負責維護自己功能的測試代碼。但是在實際的迭代過程中，難免會造成任務分配有輕微失衡的情況出現。這種情況下應鼓勵隊員主動幫助其他成員分擔測試代碼維護等瑣碎任務，促進團隊成員間的互幫互助，作爲團隊的一份子應當把整個項目當成自己分內的工作內容。而不是說這個功能是”李四“寫的，事不關己高高掛起。
3. 留出足夠的測試時間
在實踐自動化測試以後，可能在迭代結束前的測試階段會更容易測出Bug，這個時候應比以前多預留出一段時間給團隊成員以確保在迭代結束前可以求證全部缺陷，鼓勵團隊成員把這個迭代發現的問題就在這個迭代中解決，從而使用自動化測試提高交付質量。
寫在最後
手動測試和自動化測試對於敏捷項目來說同等重要，人工手動測試纔是保證交付結果的最後一關。不能因爲使用了自動化測試而忽視傳統測試，這兩者只是在開發的不同階段中扮演了不同的角色。
關於敏捷的自動化測試的實踐，太多人有不同的見解，正所謂一千個觀衆眼中有一千個哈姆雷特。每個團隊的敏捷落地都有各自的特色與道路，所以實踐出最適合自己團隊的自動化測試方案，提高團隊的凝聚力與生產力纔是敏捷的最終目的，祝大家都找到一個適合自己團隊的敏捷方法。
關於Choerodon豬齒魚
Choerodon豬齒魚作爲開源多雲應用平臺，是基於Kubernetes的容器編排和管理能力，整合DevOps工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理，同時提供IoT、支付、數據、智能洞察、企業應用市場等業務組件，致力幫助企業聚焦於業務，加速數字化轉型。
大家也可以通過以下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：
- 官網：http://choerodon.io
- 論壇：http://forum.choerodon.io
- Github：https://github.com/choerodon
- 微信公衆號：Choerodon豬齒魚
- 微博：Choerodon豬齒魚
歡迎加入Choerodon豬齒魚社區，共同爲企業數字化服務打造一個開放的生態平臺。