微服務質量體系建設知識點

微服務架構

        是現在軟件開發領域/互聯網領域比較常用的架構思維，區別於單體應用，是將項目按照業務拆分爲獨立的項目/應用/服務，只負責一小塊具體的業務或分層；

形象理解爲單體應用像古代的刻板印刷，而微服務更像活字印刷術。

       微服務通過輕量級接口或消息隊列進行通信；

缺點：

      微服務通常也是分佈式系統，在系統容錯，網絡延遲，分佈式事物等方面容易產生各類問題；

      還由於技術棧的多樣性，導致應用程序設計和體系結構不一致，產生維護成本；（這一點公司內部可以人爲避免）

      網絡安全漏洞對微服務通訊的影響；

      還應主要考慮成本更高的問題，包括溝通及維護成本；

      可靠性，數據一致性，關聯性等問題。

微服務的三大挑戰：

      1.架構設計成本高

      2.團隊協作難度大

      3.測試成本高

從2個方面來保障質量：

1.選取合適的測試策略模型保障全面有效

2.建立質量保障體系，使質量保障內化爲企業的組織能力

測試人員的核心競爭力：質量保障體系建設技能和測試策略分析能力還有優化測試體系的全劇視角。

微服務架構下，既需要保障各服務內部每個模塊的完整性，又需要關注模塊間、服務間的交互。只有這樣才能提升測試覆蓋率和全面性，因此，可以通過如下的分層測試來保證微服務的全面性。

微服務測試金字塔：

       單元測試：從服務中最小可測試單元視角驗證代碼行爲符合預期，以便測試出方法、類級別的缺陷。

       集成測試：驗證當前服務與外部模塊之間的通信方式或者交互符合預期，以便測試出接口缺陷。

       組件測試：將測試範圍限制在被測系統的一部分（一般是單個服務），使用測試替身（test doubles）將其與其他組件隔離，以便測試出被測代碼的缺陷。

       契約測試：驗證當前服務與外部服務之間的交互，以表明它符合消費者服務所期望的契約。

       端到端測試：從用戶視角驗證整個系統的功能能否符合用戶的預期。

       探索測試：

可見，上述測試策略模型中的測試方法，是自下而上逐層擴大測試範圍和邊界，力保微服務架構的模塊內、模塊間交互、服務內、服務間交互、系統範圍等維度的功能符合預期。

微服務“測試蜂巢”：

微服務“測試鑽石”：金字塔之上增加了非功能性測試=安全&性能等專項測試

【概念理解】質量保障體系解讀：通過一定的流程，測試技術和方法，藉助於持續集成和持續交付等技術把質量保障活動有效組合進而形成系統化標準化和規範化的保障體系，同時還需要相應的度量和運營手段，以及組織能力的保障。

重點

1.流程規範

2.測試技術和方法

3.持續集成&持續交付

4.度量和運營【度量維護視角：質量、效率、產品價值】

5.組織的保障
————————————————
版權聲明：本文爲CSDN博主「小螞蟻啃骨頭」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/Chengzi_happy/article/details/113059097