大家好，我是來自普元的葉婉婷。今天由我來和中生代技術的朋友分享一下流程微服務的自動化測試。
首先，我給大家分享一下普元多年實踐的自動化測試過程與方法；
闡述一下我們的測試理念：測試一切、測試驅動開發、測試自動化；1）測試一切文檔、配置、環境、釋出包，一切皆代碼，這個很好了解，我不再贅述；2）測試驅動開發測試提前，靈活協作，測試用例同步開發；3）測試自動化多種測試技術能力、元件化開發、統一管理，不間斷測試執行；為了實作測試驅動開發、測試自動化，我們認為需要以下四個要素：1）靈活協作的過程；2）測試設計方法；3）全棧測試團隊；4）自動化測試服務；
普元多年來在産品研發過程中，一直踐行靈活協作的rdt過程，在新一代雲平台項目中，我們分為若幹rdt小團隊，每個團隊負責一個或多個領域系統，以實作不同的使用者場景；在每個rdt小團隊中，采用需求、開發、測試協同并行工作模式；随着産品需要在公有雲上部署運維，我們做了一些改進，運維組參與分析使用者場景、需求設計測試評審、回報運維遇到的問題，而且，運維組自身也作為rdt團隊直接負責統一監控中心的需求定義和設計開發；
那麼為什麼在靈活協作的過程中，就能将測試盡量提前呢？從上面過程中我們可以看到，在計劃階段，每個rdt團隊對使用者場景都有了統一認識，那麼在接下來的每個疊代開發中，定義需求規格、設計概念模型/原型界面/api定義/資料模型的同時，測試可以并行進行測試對象分析、測試點分析、測試資料和測試元件設計，并且強調rdt的互相評審；基于這些成果，開發進行編碼的同時，測試就可以并行進行測試用例的開發，并且測試用例開始不間斷的執行，自動化測試相比傳統開發過程大大提前，通過測試盡量提前達到測試驅動開發的目标；
自動化測試畢竟不同于手工用例，我們從四個方面定義了自動化測試的設計原則與方法：1）易管理性統一規劃、統一版本控制的規範要求；2）易實作性采用分層設計，測試基礎服務層、測試能力支撐層、測試元件層、測試用例
層，支援多種技術的測試能力，測試元件複用，用例專注業務邏輯；3）易維護性元件與用例分離、區分變化與不變、測試用例原則上不互相依賴、測試資料 容易維護；4）易定位性測試用例獨立、低複雜度、要求斷言資訊的準确性；
自動化測試分層設計對測試團隊提出了更高的要求，也就是要求我們必須成為全棧測試團隊，具備各層的能力：測試架構師負責總體設計、測試基礎服務層，提供統一管理、統一排程的能力；領域技術專家負責測試能力支撐層，對各領域測試技術進行分析和選型，提供測試服務能力以及基礎的技術元件；測試專家負責指導測試開發工程師進行測試方案設計、測試元件和用例的實作；
除了過程、方法、團隊，自動化測試的落地最終還是需要依賴各種自動化測試服務的實作，我們也一直在做這方面的努力，并形成了産品化的自動化測試服務能力；除測試基礎服務以外，我們沒有選擇從零開始，而是評估并引入好的開源技術和公司内部其他産品的可用技術，按照我們的自動化測試設計原則和方法進行相應的改造；比如webui測試服務，我們選用了selenium，為了适應我們的用例開發規範和易用性，我們對其接口進行了重新封裝，形成我們的webui基礎元件庫；比如ci工具jenkins1.x，由于我們産品多、每個産品版本也多，使用時間久了之後其任務管理界面簡直就是災難，任務的調用關系也非常不直覺、難以維護，是以我們擴充實作了持續內建項目管理、圖形化的持續內建任務流管理，以适應我們的需要；另外，像用例開發/調試，除了支援java以外，我們還複用了普元的邏輯流圖形化開發能力、元件庫可視化管理能力，用例開發效率更高、更易維護；
在企業級應用中，流程服務的測試一直面臨諸多的問題，諸如：— 系統内部任何一個微小的變化，要上線測試；— 外部關聯系統變化，引起的業務驗證測試；— 如果流程作為一個公共的服務，一旦服務更新，所有業務系統都會有影響，所有業務系統全部都要驗證。這些都會給測試造成巨大的工作量，不僅消耗過多的時間，還無法很好的保證品質。當這些問題投射到雲環境與分布式架構中，所面臨的複雜度與解決難度的更新不言而喻。
如圖所示，在基于微服務架構的數字化企業雲平台中，流程是一類重要的微服務。我們正在嘗試将流程微服務的測試自動化，并由devops平台高效的驗證微服務的改變是否影響原先的業務，進而提供高品質的上線保障，讓測試人員告别那些讓人生無可戀的重複性操作。
基于微服務的自動化測試的本質是通過資料的錄制記錄既有的測試過程，并通過案例固化過程中的全部測試資料，最終通過對案例的調用回放完成流程微服務測試的自動化。
流程微服務的自動化測試并非完全脫離手工測試，這裡的自動化是建立初次手工測試的基礎上的。第一次手工測試會在資料庫中記錄下所有的測試資訊，我們将收集這些資訊錄制形成測試資料檔案，根據每條流程執行個體錄制一個測試資料檔案。每個檔案中包含：該流程執行個體運作過程中的所有相應請求/相應封包，該流程執行個體運作過程中的上下文變化，該流程執行個體的流轉路徑（活動+連線），該流程執行個體包含的子流程執行個體。
在流程微服務的自動化測試裡，我們會根據實際的接口調用來設計多個元件，這些元件放置于一個測試元件微服務中提供給測試人員使用，每個簡單的元件都對應一個接口的請求封包。這就猶如搭積木，每個積木是一個簡單的接口封包，多個積木搭在一起形成一個房子，即多個接口封包固定調用形成一個複雜元件。多個房子、花壇、汽車形成一個小鎮，即多個簡單元件和複雜元件結合在一起生成的最終一個“流程執行個體的自動化測試”案例。有了之前收集的資料檔案，就是根據每個資料檔案，選擇積木的問題了，再根據資料檔案給每個元件添加必要的參數，這樣就形成了測試案例。在案例生成的過程中測試人員不需要編寫任何代碼！
我們将統一測試平台門戶設計為一類領域系統，可以上傳我們的測試案例部署，選擇案例點選執行即可。每個案例的運作其實就是相應手工測試的一次回放。案例執行完成會形成詳細的測試報告，包含了成功、錯誤、異常的詳細資訊，案例統計圖，以及案例執行時間。清晰明了地達成便捷測試。
流程微服務有時也會和其他微服務之間通信，往往測試環境中無法與其他微服務直接互動，這時候我們為了模拟流程微服務引擎與其他微服務互動過程，提供了一個服務擋闆功能，服務擋闆也是設計中的數字化企業雲平台的一類領域系統，由api mock提供擋闆能力，即用服務擋闆替代生産上的微服務。（未來我們會詳細介紹api mock相對于傳統mock的優勢）
當自動化測試進行到其他微服務互動時，流程微服務引擎向擋闆發起請求，擋闆響應請求，并動态拼寫回調封包，當所有的回調封包完成之後，擋闆通知測試引擎，測試引擎向流程引擎發送回調封包。
對于測試案例，不僅需要模拟流程流轉的服務接口過程，還需要驗證流轉過程中的參數正确性，是以需要驗證元件來完成參數的确認。
- 對比服務接口傳回封包資訊是否一緻；
- 一個活動完成後循環等待後繼活動是否激活；
- 一個活動完成後對比目前後繼活動與曆史測試資料中後繼活動是否一緻；
- 一個活動激活後對比目前活動産生的連線是否與曆史測試資料中連線資訊一緻；
- 每當一個可能引起上下文改變的服務接口完成後，對比目前流程執行個體與曆史測試資料中的上下文是否一緻。
最後總結回顧一下，我們的測試理念：測試一切、測試驅動開發、測試自動化，以及為了實作這三點所需的四個要素：靈活協作的過程、測試設計方法、全棧測試團隊、自動化測試服務。有了适合自己的過程、方法、團隊、工具的保障，自動化測試的實踐自然能夠水到渠成。以上就是本次分享的全部内容，感謝大家。
q&a
q1:自動化測試在非微服務架構和微服務架構的本質差別是？
a1
微服務自動化測試重要的一點就是服務間的互動。我們提供mock元件來模拟服務間調用，而傳統的整體架構沒有這種問題
q2:有沒有資料支撐，做自動化的資料度量？
a2
資料支撐指的是什麼？我們在項目中跑4000的用例是沒有問題的
q3:哪些場景下不應該做自動化呢？
a3
做不做自動化測試主要看你的用例數量，重複執行率，以及自動化測試難度。當你覺得測試用例少，或者難度過大的時候不建議用
q4:資料錄制是采用什麼方式存儲和辨別的呢？如何做到後續的複用和擴充？
a4
資料錄制是用資料庫記錄初次手工測試産生的資料，以流程執行個體id為辨別。我們開發的工具會根據流程執行個體id取出這些資料形成檔案，即使資料庫被清，根據檔案可以再次生成用例。擴充了新的服務接口我們隻要開發新的元件即可。
q5：自動化測試有壓力測試的模拟嗎？
a5 暫時我們沒有提供壓力測試的自動化測試
q6：請問提到的中間mock元件和美團技術部落格分享的mock元件類似的功能嗎，可以推薦下相關的mock開源元件嗎？
a6:我們這裡的mock元件就是用mock
server模拟資料來進行服務間調用。這個元件是我們測試元件的概念。就是自己将mock調用方法封裝成的一個元件。
分享者簡介：葉婉婷，普元資訊soa産品部進階軟體工程師，現為普元微服務應用平台項目開發團隊一員。在過去的兩年參與了流程平台項目，主要負責eclipse插件開發及自動化測試平台開發。愛好：旅遊、電影、美食、遊泳。