杨波 微服务技术专家_专家称，这些是最有效的微服务测试策略
楊波 微服務(wù)技術(shù)專家
by Jake Lumetta
杰克·盧米塔(Jake Lumetta)
專家稱，這些是最有效的微服務(wù)測試策略 (These are the most effective microservice testing strategies, according to the experts)
Testing microservices is hard. More specifically, end-to-end testing is hard, and that’s something we’ll discuss in greater detail in this article.
測試微服務(wù)很難。 更具體地說，端到端測試很困難，這是我們將在本文中詳細(xì)討論的內(nèi)容。
But first, a quick story.
但首先，一個(gè)簡短的故事。
I learned just how hard microservice testing could be when I first dove into a tech stack with seven separate microservices. Each had its own code base, dependency management, feature branches, and database schema — which also happened to have a unique set of migrations.
當(dāng)我首次涉足具有七個(gè)獨(dú)立微服務(wù)的技術(shù)堆棧時(shí)，我了解了微服務(wù)測試的難度。 每個(gè)數(shù)據(jù)庫都有自己的代碼庫，依賴關(guān)系管理，功能分支和數(shù)據(jù)庫架構(gòu)-碰巧還具有一組獨(dú)特的遷移。
Talk about hectic.
談忙。
The approach we took was to run everything locally. So that meant, at any given point in time when I want to run end-to-end tests, I would need to go through the following five steps for each of the seven microservices:
我們采取的方法是在本地運(yùn)行所有內(nèi)容。 因此，這意味著，在我要運(yùn)行端到端測試的任何給定時(shí)間點(diǎn)，對(duì)于七個(gè)微服務(wù)中的每個(gè)微服務(wù)，我都需要經(jīng)歷以下五個(gè)步驟：
This was just a baseline requirement to enable tests to be run. Often times, I would forget to perform one of these steps for a service and spend 10–15 minutes debugging the issue. Once I finally had all the services happy and running, I could then begin to kick off the test suite. This experience sure made me miss the days of testing one big monolith.
這只是使測試能夠運(yùn)行的基本要求。 通常，我會(huì)忘記為服務(wù)執(zhí)行以下步驟之一，而花10到15分鐘來調(diào)試問題。 一旦我終于滿意并運(yùn)行了所有服務(wù)，便可以開始測試套件了。 這種經(jīng)歷肯定使我懷念測試一個(gè)大型整體裝置的日子。
So yes, I discovered that end-to-end microservice testing is hard — and gets exponentially harder with each new service you introduce. But fear not, because there are ways to make testing microservices easier. I’ve spoken to several CTOs about how they came up with their own creative ways of tackling this complex issue.
因此，是的，我發(fā)現(xiàn)端到端的微服務(wù)測試非常困難，并且您引入的每一項(xiàng)新服務(wù)都變得越來越困難。 但是不要擔(dān)心，因?yàn)橛卸喾N方法可以使微服務(wù)的測試變得更加容易。 我曾與幾位首席技術(shù)官談過他們?nèi)绾翁岢鲎约旱膭?chuàng)造性方法來解決這一復(fù)雜問題。
常見的微服務(wù)測試方法 (Common microservice testing methods)
單元測試 (Unit Testing)
A microservice may be smaller by definition, but with unit testing, you can go even more granular. A unit test focuses on the smallest part of a testable software to ascertain whether that component works as it should. Renowned software engineer, author, and international speaker Martin Fowler breaks unit testing down into two categories:
從定義上講，微服務(wù)可能會(huì)更小，但是通過單元測試，您可以變得更加細(xì)化。 單元測試專注于可測試軟件的最小部分，以確定該組件是否可以正常工作。 著名的軟件工程師，作家和國際發(fā)言人Martin Fowler 將單元測試分為兩類：
Sociable unit testing: This unit testing method tests the behavior of modules by observing changes in their state.
社交單元測試：這種單元測試方法通過觀察模塊狀態(tài)的變化來測試模塊的行為。
Solitary unit testing: This method focuses on the interactions and collaborations between an object and its dependencies, which are replaced by test doubles.
孤立單元測試：此方法著重于對(duì)象及其依賴項(xiàng)之間的交互和協(xié)作，這些交互和協(xié)作被替換為測試雙精度。
While these unit testing strategies are distinct, Fowler puts forth that they aren’t competing — they can be used in tandem to solve different testing problems.
盡管這些單元測試策略是截然不同的，但Fowler提出它們并沒有競爭-可以串聯(lián)使用它們來解決不同的測試問題。
During a discussion with David Strauss, CTO of Pantheon, David told me that “the opportunity is that Microservices are very straightforward to actually do unit testing on.”
在與萬神殿CTO大衛(wèi)·斯特勞斯的討論中，大衛(wèi)告訴我：“機(jī)會(huì)是微服務(wù)非常容易直接進(jìn)行單元測試。”
整合測試 (Integration testing)
With integration tests, you’re doing what it sounds like you’re doing: testing the communication paths and interactions between components to detect issues. According to Fowler, an integration test “exercises communication paths through the subsystem to check for any incorrect assumptions each module has about how to interact with its peers.”
使用集成測試，您可以按聽起來的方式做：測試組件之間的通信路徑和交互以檢測問題。 根據(jù)Fowler的說法 ，集成測試“通過子系統(tǒng)執(zhí)行通信路徑，以檢查每個(gè)模塊有關(guān)如何與對(duì)等方進(jìn)行交互的任何不正確的假設(shè)。”
An integration test usually tests the interactions between the microservice and external services, like another microservice or datastore.
集成測試通常測試微服務(wù)和外部服務(wù)(例如另一個(gè)微服務(wù)或數(shù)據(jù)存儲(chǔ))之間的交互。
Pawel ?Ledwon?, Platform Lead at Pusher, informed me that his team “l(fā)ean[s] towards integration testing. Unit tests are still useful for some abstractions, but for user-facing features they are difficult to mock or skip important parts of the system.”
Pusher平臺(tái)負(fù)責(zé)人Pawel``Ledwon''告訴我，他的團(tuán)隊(duì)``傾向于集成測試''。 單元測試對(duì)于某些抽象仍然有用，但是對(duì)于面向用戶的功能，它們很難模擬或跳過系統(tǒng)的重要部分。”
Not everybody I spoke to was a fan of the process. Mosquera’s take on the subject of integration testing, for example, is well worth noting:
與我交談的并不是每個(gè)人都喜歡這個(gè)過程。 例如，Mosquera對(duì)集成測試的看法很值得一提：
Integration testing is very error prone and costly, in terms of man-hours. The ROI just isn’t there. Each individual integration test brings small marginal coverage of use cases.就工時(shí)而言，集成測試非常容易出錯(cuò)且成本很高。 投資回報(bào)率不存在。 每個(gè)單獨(dú)的集成測試都會(huì)帶來用例的少量邊際覆蓋。端到端測試 (End-to-end testing)
Last but not least is end-to-end testing, which — as previously mentioned — can be a difficult task. That’s because it involves testing every moving part of the microservice, ensuring that it can achieve the goals you built it for.
最后但并非最不重要的一點(diǎn)是端到端測試，如前所述，這可能是一項(xiàng)艱巨的任務(wù)。 這是因?yàn)樗婕皽y試微服務(wù)的每個(gè)移動(dòng)部分，以確保其可以實(shí)現(xiàn)為其構(gòu)建的目標(biāo)。
Fowler wrote the following:
福勒寫道 ：
end-to-end tests may also have to account for asynchrony in the system, whether in the GUI or due to asynchronous backend processes between the services.不管是在GUI中還是由于服務(wù)之間的異步后端進(jìn)程，端對(duì)端測試都可能不得不考慮系統(tǒng)中的異步性。He goes on to explain how these factors can result in “flakiness, excessive test runtime and additional cost of maintenance of the test suite.”
他繼續(xù)解釋了這些因素如何導(dǎo)致“松散，測試時(shí)間過多和測試套件的維護(hù)成本增加”。
The best advice I can give when it comes to end-to-end testing is to limit the amount of times you attempt it per service. A healthy balance between the other microservice testing strategies mentioned — like unit testing and integration testing — will help you weed out smaller issues.
關(guān)于端到端測試，我能提供的最佳建議是限制每次服務(wù)嘗試嘗試的次數(shù)。 在上述其他微服務(wù)測試策略(例如單元測試和集成測試)之間保持良好的平衡，將有助于您清除較小的問題。
An end-to-end test is larger by definition, takes more time, and can be far easier to get wrong. To keep your costs low and avoid time-sink, stick to end-to-end testing when all other means of testing have been exhausted, and as a final stamp of quality assurance.
根據(jù)定義，端到端測試更大，花費(fèi)更多時(shí)間并且容易出錯(cuò)。 為了降低成本并避免浪費(fèi)時(shí)間，請(qǐng)?jiān)谒衅渌麥y試手段都用盡后堅(jiān)持進(jìn)行端到端測試，并以此作為最終的質(zhì)量保證。
測試微服務(wù)的挑戰(zhàn) (The challenges of testing microservices)
Microservices (compared to a monolith) require extra steps, like managing multiple repositories and branches, each with their own database schemas. But the challenges can run deeper than that.
微服務(wù)(相對(duì)于整體服務(wù))需要額外的步驟，例如管理多個(gè)存儲(chǔ)庫和分支，每個(gè)存儲(chǔ)庫和分支都有自己的數(shù)據(jù)庫架構(gòu)。 但是挑戰(zhàn)可能比這更深。
Here are a few key challenges associated with testing microservices:
以下是與測試微服務(wù)相關(guān)的一些關(guān)鍵挑戰(zhàn)：
Availability: Since different teams may be managing their own microservices, securing the availability of a microservice (or, worse yet, trying to find a time when all microservices are available at once), is tough.
可用性：由于不同的團(tuán)隊(duì)可能管理著自己的微服務(wù)，因此確保微服務(wù)的可用性(或者更糟糕的是，試圖找到同時(shí)提供所有微服務(wù)的時(shí)間)非常困難。
Fragmented and holistic testing: Microservices are built to work alone, and together with other loosely coupled services. That means developers need to test every component in isolation, as well as testing everything together.
零散的整體測試：微服務(wù)被構(gòu)建為可以單獨(dú)工作，并與其他松散耦合的服務(wù)一起工作。 這意味著開發(fā)人員需要單獨(dú)測試每個(gè)組件，以及一起測試所有組件。
Knowledge gaps: Particularly with integration testing (which we will address later in this article), whoever conducts the tests will need to have a strong understanding of each service in order to write test cases effectively.
知識(shí)差距：尤其是對(duì)于集成測試(我們將在本文后面介紹)，進(jìn)行測試的人員必須對(duì)每種服務(wù)都有深刻的了解，才能有效地編寫測試用例。
According to Oleksiy Kovyrin, Head of Swiftype SRE at Elastic,
Elastic的Swiftype SRE負(fù)責(zé)人Oleksiy Kovyrin表示，
One important issue we have to keep in mind while working with microservices is API stability and API versioning. To avoid breaking applications depending on a service, we need to make sure we have a solid set of integration tests for microservice APIs and, in case of a breaking change, we have to provide a backwards-compatible way for clients to migrate to a new version at their own pace to avoid large cross-service API change rollouts.使用微服務(wù)時(shí)，我們必須牢記的一個(gè)重要問題是API穩(wěn)定性和API版本控制。 為了避免根據(jù)服務(wù)中斷應(yīng)用程序，我們需要確保我們有一套針對(duì)微服務(wù)API的可靠的集成測試，并且在發(fā)生重大更改的情況下，我們必須為客戶提供向后兼容的方式來遷移到新的自行調(diào)整版本，以免大規(guī)模推出跨服務(wù)API更改。Stefan Zier, Chief Architect at Sumo Logic, also reiterated to me that microservice testing is indeed “very, very difficult.”
Sumo Logic的首席架構(gòu)師Stefan Zier也向我重申，微服務(wù)測試確實(shí)“非常非常困難”。
“Especially once you go towards more continuous deployment. We’ve invested and continue to invest fairly heavily into integration testing, unit testing, and would do a lot more if we had the people to do it,” Zier told me.
“特別是一旦您要進(jìn)行更連續(xù)的部署。 Zier告訴我，我們已經(jīng)投資并且繼續(xù)在集成測試，單元測試上投入相當(dāng)大的資金，如果讓我們的人來做，它將做得更多。
With that being said, he admitted that, at certain stages, when Sumo Logic wants to test their services holistically, “more or less [the] entire company [becomes] a quality assurance team in a sense.”
話雖如此，他承認(rèn)，在某些階段，當(dāng)Sumo Logic想要整體測試他們的服務(wù)時(shí)，“整個(gè)公司或多或少都在某種意義上成為了質(zhì)量保證團(tuán)隊(duì)。”
解決方案：針對(duì)初創(chuàng)企業(yè)的五種微服務(wù)測試策略 (Solution: Five microservice testing strategies for startups)
Yes, testing microservices can be difficult, but given all the benefits of microservices, foregoing them because of testing challenges isn’t the right path. To tackle these challenges, I got insight from several CTOs and distilled five strategies they used to successfully approach testing microservices.
是的，測試微服務(wù)可能很困難，但是鑒于微服務(wù)的所有好處，由于測試挑戰(zhàn)而放棄它們并不是正確的方法。 為了應(yīng)對(duì)這些挑戰(zhàn)，我從幾個(gè)CTO那里獲得了見識(shí)，并提煉了他們成功用于測試微服務(wù)的五種策略。
1.以文件為先的策略 (1. The documentation-first strategy)
Chris McFadden, VP of Engineering Sparkpost, summarized the documentation-first strategy quite nicely during our discussion:
在我們的討論中，Sparkpost工程副總裁Chris McFadden很好地總結(jié)了文檔優(yōu)先的策略：
We follow a documentation first approach so all of our documentation is in markdown in GitHub. Our API documents are open source, so it’s all public. Then, what we’ll do is before anybody writes any API changes or either a new API or changes to an API, they will update the documentation first, have that change reviewed to make sure that it conforms with our API conventions and standards which are all documented, and make sure that there’s no breaking change introduced here. Make sure it conforms with our naming conventions and so forth as well.我們遵循文檔優(yōu)先的方法，因此我們所有的文檔都在GitHub的markdown中。 我們的API文檔是開源的，因此都是公開的。 然后，我們要做的是在任何人編寫任何API更改或新API或?qū)PI進(jìn)行更改之前，他們將首先更新文檔，對(duì)更改進(jìn)行審核以確保其符合我們的API約定和標(biāo)準(zhǔn)。所有文件均已記錄在案，并確保此處沒有引入重大更改。 確保它也符合我們的命名約定等。If you’re willing to go one step further, you could dabble in API contract testing, which — as previously mentioned — involves writing and running tests that ensure the explicit and implicit contract of a microservice works as it should.
如果您愿意更進(jìn)一步，則可以涉足API合約測試，如前所述，API合約測試涉及編寫和運(yùn)行測試，以確保微服務(wù)的顯式和隱式契約能夠正常工作。
2.全棧即裝即用策略 (2. The full stack in-a-box strategy)
The full stack in-a-box strategy entails replicating a cloud environment locally and testing everything all in one vagrant instance (“$ vagrant up”). The problem? It’s extremely tricky, as software engineer Cindy Sridharan of Imgix explained in a blog post:
完整堆棧即裝即用策略需要在本地復(fù)制云環(huán)境，并在一個(gè)無所事事的實(shí)例中測試所有內(nèi)容(“ $ vagrant up”)。 問題？ 正如Imgix的軟件工程師Cindy Sridharan在博客文章中所述，這非常棘手：
I’ve had first hand experience with this fallacy at a previous company I worked at where we tried to spin up our entire stack in a [local] vagrant box. The idea, as you might imagine, was that a simple vagrant up should enable any engineer in the company (even frontend and mobile developers) to be able to spin up the stack in its entirety on their laptops.我曾在一家以前的公司工作過，曾有過這種謬論的第一手經(jīng)驗(yàn)，在那家公司，我們?cè)噲D在[本地]無家可歸的盒子中旋轉(zhuǎn)整個(gè)堆棧。 就像您可能想像的那樣，想法是，只需進(jìn)行一次簡單的游蕩，即可使公司中的任何工程師(甚至是前端和移動(dòng)開發(fā)人員)都能夠在筆記本電腦上旋轉(zhuǎn)整個(gè)堆棧。Sridharan goes on to detail how the company only had two microservices, a gevent based API server and some asynchronous Python background workers. A relatively simple setup, by all means.
Sridharan繼續(xù)詳細(xì)介紹了該公司如何只有兩個(gè)微服務(wù)，一個(gè)基于gevent的API服務(wù)器和一些異步Python后臺(tái)工作者。 絕對(duì)是一個(gè)相對(duì)簡單的設(shè)置。
“I remember spending my entire first week at this company trying to successfully spin up the VM locally only to run into a plethora of errors. Finally, at around 4:00pm on the Friday of my first week, I’d successfully managed to get the Vagrant setup working and had all the tests passing locally. I remember feeling incredibly exhausted,” she narrated.
“我記得整個(gè)第一周都在這家公司工作，試圖在本地成功啟動(dòng)虛擬機(jī)，但是卻遇到了很多錯(cuò)誤。 終于，在我第一周的星期五下午4:00左右，我成功地使Vagrant設(shè)置正常工作，并使所有測試都在本地通過。 我記得我感到非常疲憊，”她說。
In addition, Stefan Zier, Chief Architect at Sumo Logic, explained to me that — on top of being difficult to pull off — this localized testing strategy simply doesn’t scale:
此外，Sumo Logic的首席架構(gòu)師Stefan Zier向我解釋說，除了難以實(shí)現(xiàn)之外，這種本地化的測試策略根本無法擴(kuò)展：
“[With] a local deployment, we run most of the services there so you get a fully running system and that’s now stretching even the 16GB RAM machines quite hard. So that doesn’t really scale,” he said.
“在本地部署中，我們?cè)谀抢镞\(yùn)行大多數(shù)服務(wù)，因此您將獲得一個(gè)完全運(yùn)行的系統(tǒng)，而現(xiàn)在即使16GB RAM機(jī)器也很難擴(kuò)展。 因此，這并沒有真正擴(kuò)大規(guī)模，”他說。
3. AWS測試策略 (3. The AWS testing strategy)
This third strategy involves spinning up an Amazon Web Services (AWS) infrastructure for each engineer to deploy and run tests on. This is a more scalable approach to the full stack in-a-box strategy discussed above.
第三種策略涉及為每個(gè)工程師擴(kuò)展Amazon Web Services(AWS)基礎(chǔ)架構(gòu)，以部署和運(yùn)行測試。 這是對(duì)上面討論的全棧即用策略的一種更具可擴(kuò)展性的方法。
Zier called this a “personal deployment [strategy], where everyone here has their own AWS account.”
Zier將此稱為“個(gè)人部署[策略]，這里的每個(gè)人都擁有自己的AWS賬戶。”
“You can push the code that’s on your laptop up into AWS in about ten minutes and just run it in like a real system,” he said.
他說：“您可以在大約十分鐘的時(shí)間內(nèi)將筆記本電腦上的代碼推送到AWS中，然后像實(shí)際系統(tǒng)一樣運(yùn)行它。”
4.共享測試實(shí)例策略 (4. The shared testing instances strategy)
I like to think of this fourth strategy as a hybrid between full stack in-a-box and AWS testing. That’s because it involves developers working from their own, local station, while leveraging a separate, shared instance of a microservice to point their local environment at during testing.
我喜歡將第四種策略視為完整堆棧即裝式測試與AWS測試之間的混合體。 這是因?yàn)樗婕伴_發(fā)人員在自己的本地工作站上工作，同時(shí)利用單獨(dú)的共享微服務(wù)實(shí)例在測試期間將其本地環(huán)境指向。
Steven Czerwinski, Head of Engineering, Scaylr, explained how this can work in practice:
Scaylr工程主管Steven Czerwinski解釋了這在實(shí)踐中如何工作：
Some of [our] developers run a separate instance of a microservice just to be used for testing local builds. So imagine you’re a developer, you’re developing on your local workstation, and you don’t have easy way of launching the image parser. However, your local builder would just point to a test image parser that’s running in the Google infrastructure.[我們的]一些開發(fā)人員運(yùn)行一個(gè)微服務(wù)的單獨(dú)實(shí)例，僅用于測試本地構(gòu)建。 因此，假設(shè)您是一名開發(fā)人員，正在本地工作站上進(jìn)行開發(fā)，并且沒有啟動(dòng)圖像解析器的簡便方法。 但是，您的本地構(gòu)建器只會(huì)指向在Google基礎(chǔ)架構(gòu)中運(yùn)行的測試圖像解析器。5.存根策略 (5. The stubbed services strategy)
And finally, we have the stubbed services testing strategy.
最后，我們有存根服務(wù)測試策略。
Zier laid out SumoLogic’s approach to stubbed service testing by telling me how, “stubbing let’s you write these marks or ‘stubs’ of microservices that behave as if they were the right service and they advertise themselves in our service discovery as if they were real service, but they’re just a dummy imitation,” he explained.
Zier告訴我如何，SuerLogic展示了SumoLogic進(jìn)行存根服務(wù)測試的方法，“存根讓您寫下這些標(biāo)記或微服務(wù)的“存根”，它們的行為就像是正確的服務(wù)，并且在我們的服務(wù)發(fā)現(xiàn)中做廣告，就好像它們是真實(shí)的服務(wù)一樣。 ，但它們只是一個(gè)虛擬的模仿，”他解釋說。
For example, testing a service may necessitate that the service becomes aware that a user carries out a set of tasks. With stubbed services, you can pretend that user (and his tasks) have taken place without the usual complexities that come with that. This approach is a lot more lightweight compared to running services in their totality.
例如，測試服務(wù)可能需要使服務(wù)意識(shí)到用戶執(zhí)行了一組任務(wù)。 使用存根服務(wù)，您可以假設(shè)用戶(及其任務(wù))已經(jīng)發(fā)生，而沒有隨之而來的通常的復(fù)雜性。 與整體上運(yùn)行服務(wù)相比，此方法輕巧得多。
幫助您測試微服務(wù)的工具 (Tools to help you test microservices)
Here’s a list of tools that have benefited me during my own microservice testing experiences, bolstered by some recommendations from the pool of CTOs and senior developers:
以下是在我自己的微服務(wù)測試經(jīng)驗(yàn)中受益的工具列表，并得到了CTO和高級(jí)開發(fā)人員的建議 ：
Hoverfly: simulate API latency and failures.
Hoverfly ：模擬API延遲和失敗。
Vagrant: build and maintain portable virtual software development environments
Vagrant ：構(gòu)建和維護(hù)便攜式虛擬軟件開發(fā)環(huán)境
VCR: a unit testing tool
VCR ：單元測試工具
Pact: frameworks consumer-driven contracts testing.
契約 ：構(gòu)架消費(fèi)者驅(qū)動(dòng)的合同測試。
Apiary: API documentation tool
養(yǎng)蜂場 ：API文檔工具
API Blueprint: design and prototype APIs
API藍(lán)圖 ：設(shè)計(jì)和原型API
Swagger: design and prototype APIs
Swagger ：設(shè)計(jì)和原型API
微服務(wù)測試：困難，但值得 (Microservices testing: difficult, but worth it)
Testing your microservices won’t be a walk in the park, but the additional work is worth the benefits of having a microservice architecture.
測試您的微服務(wù)并不是在公園里散步，但是額外的工作值得擁有微服務(wù)架構(gòu)的好處。
Plus, the microservice testing strategies adopted by the likes of SumoLogic and Scaylr should help smooth the process out. Here’s a quick recap of those strategies:
另外，SumoLogic和Scaylr等公司采用的微服務(wù)測試策略應(yīng)有助于簡化流程。 以下是這些策略的簡要介紹：
Naturally, you may need to tweak each strategy to match your unique circumstances, but with some good old fashioned trial and error, your microservice testing strategy should come into its own.
自然地，您可能需要調(diào)整每種策略以適應(yīng)您的獨(dú)特情況，但是通過一些良好的老式嘗試和錯(cuò)誤，您的微服務(wù)測試策略應(yīng)該成為自己的策略。
If you’ve enjoyed this article, please help it spread by clapping below! For more content like this, follow us on Twitter and subscribe to our blog.
如果您喜歡這篇文章，請(qǐng)通過下面的鼓掌幫助傳播！ 有關(guān)此類的更多內(nèi)容，請(qǐng)?jiān)赥witter上關(guān)注我們并訂閱我們的博客。
Jake Lumetta is the CEO of ButterCMS, and is publishing Microservices for Startups.
杰克Lumetta是首席執(zhí)行官ButterCMS ，并發(fā)布了創(chuàng)業(yè)微服務(wù) 。
And if you want to add a blog or CMS to your website without messing around with Wordpress, you should try Butter CMS.
而且，如果您想在您的網(wǎng)站上添加博客或CMS而不用弄亂Wordpress，則應(yīng)該嘗試Butter CMS 。
翻譯自: https://www.freecodecamp.org/news/these-are-the-most-effective-microservice-testing-strategies-according-to-the-experts-6fb584f2edde/
楊波 微服務(wù)技術(shù)專家
總結(jié)
以上是生活随笔為你收集整理的杨波 微服务技术专家_专家称，这些是最有效的微服务测试策略的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 梦到打架出血了是什么征兆
- 下一篇： 梦到婆婆晕倒了是什么意思