對標蘋果的靈動島 華為帶來實況窗功能
繼蘋果的靈動島之后，華為也在今天正式推出了“實況窗”功能。據今天鴻蒙OS 4.0的現場演示顯示，華為的實況窗可以更高效的展現出實時通知，比如鎖屏上就能看到外賣、打車、銀行
譯者 | 陳峻
審校 | 重樓
出品 | 51CTO技術棧（微信號：blog51cto）
如今，軟件開發對于速度和靈活性的持續追求，催生了各種超越傳統界限的方法和實踐。而作為現代DevOps實踐的基石，持續測試的出現與發展，正好滿足了加速軟件交付的需求。下面，我將和您探討持續測試的最新發展，并重點關注它與微服務及無服務器架構的緊密關系。
持續測試是一種在軟件開發生命周期的每個階段，都需要進行測試的做法。從單元測試到集成測試、乃至其他測試，這種方法都能夠協助盡早地發現和糾正缺陷，以確保軟件的質量。它不只是單純的缺陷檢測，而是包含了一整套的方法集。其中，單元測試可以檢查單個組件，而集成測試則可以評估不同模塊之間的協作。因此，此方法不僅能夠最大限度地減少缺陷，還可以確保整體系統的穩健性。可見，集成測試的意義在于促進不斷改進的循環。也就是說，測試的反饋意見可以為后續的開發周期提供可用于改進的信息，從而創建一種持續改進的文化。
如今，微服務架構已成為現代應用開發的主導力量。它將單體應用分解為更小的、更獨立的服務，從而為軟件的開發和部署方式帶來范式上的轉變。雖然這種架構具有可擴展性和靈活性，但是也帶來了管理和測試大量分布式服務上的挑戰。因此，微服務的復雜性就需要我們采取更精細的測試策略，以實現其獨立的功能、以及相互關聯的特性。
分解測試策略是有效進行微服務測試的基礎。這種方法主張孤立地檢查每個微服務。它包括對單個服務進行嚴格的測試，以確保其功能符合既定的規范，然后方可進行全面的集成測試。這種有條不紊的方法不僅能在早期發現缺陷，還可以保證服務之間的無縫通信，以符合微服務的模塊化特性。可以說，該策略保障了在同一個測試生態系統中，每個微服務都被視為一個獨立的單元，為系統的整體可靠性做出貢獻。目前，屬于該類別的測試策略包括但不限于如下示例：
單元測試可被用于驗證單個微服務的正確性。例如：如果您有一個負責用戶身份驗證的微服務，那么單元測試就會去檢查身份驗證邏輯是否能夠正常工作，是否可以處理不同的輸入，以及是否能夠對有效與無效的身份驗證嘗試做出適當的響應。
組件測試可被用于測試一組相關的微服務或組件的功能。例如：在某個電子商務系統中，您可能擁有用于產品編目、庫存管理、以及訂單處理的不同微服務。那么組件測試將會涉及到驗證這些微服務是否能夠無縫協作，以實現訂單提交、庫存檢查、以及產品目錄更新等流程。
合約測試可以通過驗證每個微服務是否遵守指定的接口和通信協議，以確保微服務之間的合約能夠得到切實的遵守。如果微服務A依賴微服務B的數據，那么合約測試將驗證微服務A能否正確地“消費”由微服務B提供的數據。
微服務的性能測試包括評估其在各種負載下的響應時間、可擴展性、以及資源利用率。它將有助于在開發過程的早期，發現潛在的性能瓶頸。
微服務的安全測試會涉及到漏洞檢查，確保適當的身份驗證，授權機制是否到位，以及驗證敏感數據是否得到了安全的處理。
故障注入測試用于評估每個微服務對于故障的適應能力。您可以故意向微服務注入諸如：網絡延遲或服務不可用等故障，以觀察其響應情況。此類測試有助于確保微服務能夠從容地應對各種意外故障。
隔離測試主要被用于驗證微服務是否能夠獨立于其他服務運行。隔離測試往往通過在測試微服務時，模擬或刪除其依賴關系，以確保微服務能夠在隔離的狀態下運行，從而避免了在實際環境中，造成隱藏的依賴關系問題。
微服務離不開服務虛擬化。它允許團隊在受控環境中，模擬微服務的行為，從而兼顧了微服務的隔離與測試難題。服務虛擬化使得開發和測試團隊有能力通過創建微服務的副本，在不依賴整個系統的情況下進行隔離測試。這種方法不僅能夠加快測試的周期，還可以通過復刻真實場景，來提高結果的準確性。作為一種推動力，它在確保全面測試的同時，避免了對微服務生態系統所需的敏捷性產生潛在影響。
微服務在很大程度上也依賴于API來實現無縫通信。在驗證這些關鍵性接口的可靠性和功能時，強大的API測試顯得至關重要。API測試的方法主要包括仔細檢查每個API端點對于各種輸入、以及邊緣情況的響應。此類檢查可以確保微服務能夠按照預期進行有效的通信和數據交換。同時，API測試不僅是對端點的驗證，也是對整個通信框架的驗證，它屬于微服務架構的基礎層。
無服務器計算通過將基礎設施的抽象化，讓開發人員可以只關注代碼，而無需管理底層服務器。無服務器計算在帶來高度可擴展性和成本效益的同時，也帶來了測試方法上的范式轉變。而為了確保無服務器應用的可靠性，我們往往需要一些新的測試方法。
無服務器架構往往通過事件驅動，來對觸發器和刺激做出響應。事件驅動測試通常被用來驗證由事件觸發的功能，是否有能力被完整執行。其中一些方法不僅包括了仔細檢查被測功能對于特定事件的響應，還包括評估其針對動態的、不可預見的觸發因素的適應性。也就是說，事件驅動測試可以確保無服務器應用對于各種事件，做出準確可靠的響應，從而提升了應用防范潛在差異性的能力。這種方法對于在以事件為中心的環境中，保持無服務器功能的響應性和完整性，是至關重要的。
無服務器功能在冷啟動期間往往面臨巨大的性能挑戰。持續的性能測試可以幫助無服務器功能，發現并解決從休眠狀態啟動時可能產生的延遲問題，進而確保其發揮最佳性能。通過積極主動地應對冷啟動挑戰，無論無服務器功能的初始化狀態如何，開發團隊都可以自信地實現無縫的用戶體驗。
由于無服務器應用通常也依賴與第三方服務的無縫集成，因此我們需要確保這些集成的兼容性和穩健性，成為無服務器架構持續測試的一個重要方面。其中，一種典型的方法是：對無服務器功能與第三方服務之間的交互進行嚴格測試，驗證數據交換是否順暢且正確。通過解決潛在的兼容性問題，以及確保集成的魯棒性，開發團隊可以提升無服務器應用的可靠性和穩定性。
目前，業界有一系列旨在簡化微服務和無服務器架構中測試流程的工具和技術，可以被直接運用到持續測試之中。這些工具不僅能夠促進測試的開展，還可以提高測試生命周期的整體效率和效果。
JUnit、TestNG、Spock、Pytest和Behave等工具，都是在微服務綜合測試中非常實用的工具。這些框架通常都能夠支持單元測試、集成測試、以及端到端測試。
AWS SAM（Serverless Application Model，無服務器應用模型）、Serverless Framework、AWS Lambda Test、Azure Functions Core Tools和Serverless Offline等框架都是可以幫助您開發、測試和部署無服務器應用的工具。它們具有如下不同的功能和用途：
下面的表格總結了上述五種工具的主要區別：
特點 | AWS SAM | Serverless Framework | AWS Lambda Test | Azure Functions Core Tools | Serverless Offline |
云提供商支持 | AWS | AWS、Azure、GCP | AWS | Azure | 多云 |
部署 | 基于 YAML 的語法與 AWS CloudFormation 集成 | CLI 界面 | 不支持 | CLI 界面 | 不支持 |
本地發展環境 | 是 | 是 | 是 | 是 | 是 |
插件系統 | 沒有 | 是 | 沒有 | 沒有 | 沒有 |
測試用例生成 | 是 | 沒有 | 是 | 是 | 是 |
持續測試與CI/CD管道的無縫集成，形成了一套強大的自動化測試流程。Jenkins、GitLab CI和Travis CI等工具可以協調整個測試工作流程，以確保每個代碼的變更在部署之前都經過了嚴格的測試。總的說來，由持續測試與CI/CD管道集成所提供的機制，既能夠保證軟件的質量，又可以達到如今數字化要求的速度。
綜上所述，由于持續測試能夠在整個開發過程中持續檢查軟件的問題和錯誤，因此已成為了快速、可靠地交付軟件過程的重要一環。隨著微服務和無服務器架構不斷重塑軟件應用的格局，持續測試的作用將變得更加突出。面對各種創新架構所帶來的挑戰，我們需要善于利用最新的工具和方法，讓開發團隊跟上快速迭代的需求，交付出高質量的軟件。
鏈接：https://dzone.com/articles/continuous-testing-in-the-era-of-microservices-and
本文鏈接：http://m.www897cc.com/showinfo-26-64105-0.html微服務和無服務器架構時代的持續測試
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： C++函數模板：掌握返回類型推導的藝術
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號