3．敏捷軟件測試的經驗分享

經過普元多年敏捷測試的項目實施，要支持產品的快速迭代，達到敏捷測試的預期效果，我們重點在以下幾個方面開展了工作。

組織文化的改變

公司研發采用扁平化的管理模式，在敏捷的組織文化中，相比于流程，敏捷更關注人，所以敏捷測試組織是應該是以人為導向、自組織、協作式的一種文化氛圍。

作為領導，工作中與大家一起共同進退，組織團隊建設，發展團隊成員間的友好關系。

建立敏捷型測試組織

從項目特點來看，敏捷是屬于“強項目型”管理的方式，但敏捷人員可以來自于靜態職能組織或將測試人員整合到敏捷項目中。

無論人員來自哪里，在敏捷團隊中，測試和開發同屬一個項目，大家的目標是一致的，敏捷測試人員可以在質量思想方面影響團隊的其他成員。如測試人員可能會幫開發人員評審代碼，開發人員也會幫測試人員執行測試，人員角色的職能可以模糊化。

敏捷測試團隊還需要把客戶納入到組織中，學會一起工作并建立彼此間的信任，一起做好軟件的質量保證。

獲得領導支持

任何一個大的改變要想實施成功，都離不開領導層的大力支持。敏捷測試也強調領導的作用，從領導層的角度需要提供一個寬松的環境，讓整個敏捷測試團隊能夠形成自組織的模式。當遇到問題時不是進行追責，而是給予足夠的信任和支持，協調資源幫助團隊解決問題，陪伴團隊成長。

領導可以制訂一些KPI考核指標，也需要實施一些激勵措施，提高大家工作的積極性。

盡早進入測試

測試人員需要了解敏捷，掌握敏捷的基本知識和原則，從而才能在整個敏捷體系中更快的融入到敏捷環境中，從而更好的開展整個測試工作。

測試工作不再是軟件功能實現后再進行，而是測試工作前移，功能實現前就已經對測試做好規劃，做好測試用例的設計及準備，等待條件具備再做測試執行。

建立有效溝通方式

敏捷測試人員需要與需求人員、開發人員保持溝通，建立一種相互合作的氛圍。傳統測試不同角色之間的接口可能主要是文檔，在敏捷測試過程中，我們在弱化文檔，不為文檔而文檔，主要還是以溝通為主，做為敏捷測試人員我們需要去變被動為主動，積極去做些改變。

為了取得更好的溝通效果，敏捷測試過程中的溝通方式可以不拘一格，實行正式的溝通和非正式的溝通，正式溝通的形式可以是郵件或會議，非正式的溝通工具可以是面對面、電話、Wiki、微信等。

引入CI、CD和CT

敏捷測試要取得好的效果，CI、CD及CT³是必不可少，缺少任何一項，整個流程就會不順暢，效果也就大打折扣。

但要做好這CI、CD和CT，除了需要合適的工具提供支撐，還需要項目整體團隊緊密協作。測試人員自身還需要具備一定的技術能力，在過程中提供驅動力，推動整個過程有序進行。

持續集成

敏捷研發過程中，測試的版本更換比較頻繁，要求代碼集成要快，構建一次一般需要控制在15分鐘，由于構建的項目較多，我們通常采取分布式并行執行。

編譯構建產物存放介質倉庫，支持通過Web方式下載，供項目組成員取用。在我們的敏捷研發過程中，主要基于普元DevOps平臺實現持續構建。

自動化部署

配置與介質分離，按不同環境進行組合，使用普元DevOps平臺標準化的部署流程，快速部署程序包并啟動，定時進行健康檢查。

使用DevOps進行測試環境的部署，可以解決一些關鍵問題，如部署目錄的規范化、部署行為的規范化、部署過程的透明化、對部署結果進行初步檢查以及支持部署異常的快速回滾。

通過DevOps平臺的支持，可以避免無關人員獲得敏感配置值，避免無關人員操作無關進程，通過頁面交互方式，可以方便快捷搭建好所需環境，也大大減少了手動部署帶來的壓力。

在我們的敏捷過程中，主要是基于普元的DevOps平臺實現發布部署。

自動化測試

自動化測試是敏捷測試非常重要的組成部分。

在敏捷開發這種極短的交付周期內，僅僅靠手工測試，是難以滿足快速發布要求的。所以自動化測試是必不可少的一種手段。

另外這里談到的自動化測試不僅僅是指功能的自動化測試，還包括單元測試、靜態質量掃描、性能測試、安全掃描等，也涉及自動化測試如何集成在整個交付管道中，縮減整個交付時間，最終給項目帶來價值。

在我們的敏捷測試中，使用了普元統一測試平臺UTP完成自動化測試，它支持微服務接口的自動化測試、Web UI的功能測試、移動App的兼容性測試等，是我們測試人員的好幫手。

提升敏捷測試能力

回到測試的本質，作為敏捷測試人員需要做好敏捷測試的知識儲備，無論是測試基礎知識還是測試的技術技能，個人都需要考慮提升，組織上需要為個人提升打開空間，組織相關的培訓，與行業先進測試理念接軌。

團隊內部要經常進行團隊分享，需要傳道。對于敏捷測試的新思維，如果沒有進行相關培訓和了解，會讓具體執行人覺得沒有底氣。同樣，敏捷項目中測試人員在進行測試前也需要接受敏捷知識的培訓。如果可能的話，最好是邀請具有豐富經驗的敏捷測試教練進行指導，避免走錯方向。