如何寫一個高效進程/線程池

企業中的測試仍然沒有得到應有的廣泛應用。 編寫尤其是維護測試需要花費時間和精力，但是縮短軟件測試并不是解決方案。 為了提高測試效率，應該追求哪些范圍，方法和測試技術？

基于許多實際項目，我整理了一系列有關企業測試的經驗和意見。 特別是對于比“ hello world”要復雜得多的應用程序，遵循哪種方法至關重要。 我將主要關注測試應用程序的功能行為，即它們如何很好地滿足我們的業務邏輯。 在下文中，我將說明有關如何在不同的范圍和使用不同的方法來提高測試效率的最佳實踐：

• 想法與約束
• 單元測試
• 用例測試
• 代碼級集成測試
• 系統測試
• 開發工作流程和管道
• 測試代碼質量和可維護的測試
• 測試框架和技術

介紹

不管測試的類型和范圍如何，擁有測試套件的目的都是為了驗證我們的應用程序可以在生產中按預期工作。 從用戶的角度來看，這應該是驗證系統是否完成其工作的主要動機。

由于人的注意力跨度和上下文切換是一件事情，因此我們需要確保我們的測試能夠快速運行和驗證，并具有可預測的結果。 在編寫代碼時，快速驗證（少于或等于一秒鐘）對于確保高效的工作流程以及我們不會分散注意力至關重要。

另一方面，我們需要確保測試保持可維護性。 軟件更改非常頻繁，并且具有足夠的功能測試覆蓋范圍，生產代碼中的每個功能更改都將要求更改測試范圍。 理想情況下，僅當功能（即業務邏輯）發生更改時，測試代碼才會更改，而對于代碼清理和重構則不會更改。 通常，測試方案需要使非功能性的結構更改成為可能。

當我們研究不同的測試范圍時（我們將更詳細地介紹），就會出現一個問題，即哪個范圍需要花費更多的時間和精力。 對于微服務應用程序或我們具有大量分布和集成的任何系統，驗證系統邊界的集成測試變得更加重要。 因此，我們需要一種有效的方法來驗證本地開發過程中的整個應用程序，同時保持應用程序環境和設置與生產環境盡可能相似。

原則與約束

無論選擇哪種解決方案，我們都為測試套件定義以下原則和約束：

• 測試需要快速執行和驗證，并提供快速反饋。 對于沒有進一步集成的單元測試，我們應該能夠在一秒鐘內運行數百個測試。 對于集成測試，執行時間取決于場景，理想情況下不超過一秒。
• 在開發過程中，測試還必須提供集成級別的快速反饋。 這要求測試上下文快速啟動，或者在我們編寫代碼時保持運行。 因此，應該有可能通過少于5秒的重新部署和測試周轉時間來建立有效的開發周期。
• 測試需要使其能夠重構生產代碼，而無需在測試范圍內進行重大更改。 不會更改應用程序功能行為的代碼更改應僅導致最小的測試代碼更改。
• 確實會更改功能行為的代碼更改應同樣會導致有限的測試代碼更改。 例如：“將HTTP邊界交換到gRPC，將JSON交換到其他東西，甚至交換企業框架等，要花多少精力？”。
• 測試技術和方法必須與根據我們的業務需求量身定制適當的抽象，委托和代碼質量兼容。 我們需要能夠設計表達性API，擴展潛在的DSL并設計正確的抽象。
• 測試技術需要支持“開發模式”，該模式以一種能夠在集成環境中進行即時更改和重新部署的方式運行應用程序，例如服務器的“開發”和調試模式， Quarkus的開發模式， 網真 ， 監視和部署方法 ，以及其他方法。
• 測試方法需要與單獨設置開發和測試生命周期兼容。 也就是說，開發人員必須能夠在測試生命周期之外設置和配置其本地環境（例如，使用Shell腳本），然后在已經設置好的環境中快速運行測試方案。 出于靈活性和可重用性的原因，各個測試用例不應管理測試設置的生命周期。
• 我們需要能夠在多個范圍內重用測試方案，例如，一次定義業務方案，然后將設置重新用于系統測試，負載測試，在本地或針對外部部署的環境中運行。 復制方案應該很簡單，方案應該只包含幾行代碼，通過使用不同的實現來達到不同的目的。

在本系列的下一部分中，我們將研究代碼級單元測試和組件或用例測試，以及它們如何與這些原理和約束相匹配。

翻譯自: https://www.javacodegeeks.com/2019/09/thoughts-on-efficient-enterprise-testing.html

如何寫一個高效進程/線程池

總結

以上是生活随笔為你收集整理的如何写一个高效进程/线程池_关于高效企业测试的思考（1/6）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。