#1 楼
与在微服务中具有单个测试点(或多或少)的单片应用程序不同,您将不得不分别测试每个服务。在计划基于微服务的应用程序时,我建议考虑以下几点:测试自动化。手动测试微服务应用程序将面临很大的挑战,因为服务的数量通常很大。精心设计的油井要求。在需求准备阶段投入更多的精力。您已经测试了要求,以确保每个服务的接口均已正确描述
性能。考虑一下您将如何测试整个解决方案的性能。由于服务间呼叫通常是通过网络执行的,因此网络延迟通常会影响整体性能。
考虑业务连续性测试。与整体应用程序不同,每个服务可能部署在单个主机上,因此可能会导致某些服务中断。
设计一些兼容性测试,以便确保在某些服务的接口更改时引入了向后兼容性。
基本上,当您测试微服务架构时,您应该更像是因为单片应用程序是库函数调用的构建,通常是对测试人员隐藏的,而微服务应用程序是由测试人员通常可以访问的微服务调用的构建。
#2 楼
从根本上来说,测试就是测试就是测试,但技术上可能有所不同,但总体方法是相同的。在系统和单个模块(及以下)级别上的测试与任何其他系统中的测试大致相同,您只需要记住世界其他地区。
集成测试变得更加复杂。
集成测试一词指的是模块之间的实际集成,但是即使在进行模块和单元测试时,也需要考虑它。
模块数量呈指数增长,这不仅与单个消息功能有关,还与消息的时间安排和长序列有关。
这意味着当您开始在系统内进行测试时,不仅事情变得更加复杂,而且还有更多的组合需要检查。
另一方面,微服务的去耦概念服务并使其尽可能小,使您的生活测试变得更加容易。 (通常)模拟其他服务很容易,有时就像重放正确的消息一样简单。
然后您将有一个相对简单的模块进行测试,例如,允许您在测试人员之间拆分测试或更简单的测试。测试自动化软件模块。
如果您需要TLDR;那么这就是我所开始的,将其视为架构为次要的任何其他系统。
#3 楼
通常,任何在微服务体系结构中开发的应用程序都具有单元,集成,端到端,UI测试。他/她知道系统的内部知识,并且涉及到体系结构的哪一层。微服务是合同测试,在其中编写测试以确保微服务的显式和隐式合同按广告中的说明工作(在文档中)。评论
如果进行手动测试,合同测试与功能系统测试有何不同?即使在系统测试中,也要确保其功能符合要求文档。
– QA9
18年5月31日在12:11
概括地说,所有测试都是关于预期与实际的对比。
– Vishal Aggarwal
18年5月31日在21:01
#4 楼
该角色将具有两个方面:测试依赖于微服务(UX)的UI组件和系统
测试微服务本身不是全部它们可以通过UI进行测试。
对于#2,我们教了我们的质量检查SoapUI(免费)。
邮递员是另一种选择,将QA分担给开发人员以编写api测试(例如httpclient)是另一种选择。
评论
+1,用于直接使用http客户端库,与第三方工具相比,我发现这是最有效的解决方案。
– Vishal Aggarwal
18年6月1日在8:11
@Vishal imho在SoapUI中编写Api测试要比使用原始的HTTP客户端容易得多。开发人员接管QA职责往往表明缺乏QA或QA技能。
–RandomUs1r
18年6月1日在18:11
这取决于您的质量检查技术水平。
– Vishal Aggarwal
18年6月3日在16:25
#5 楼
我见过微服务场景,其中每个微服务的开发人员都在关注满足合约测试的需求,而合约测试专注于语义之上的语法,而整个系统的架构师则专注于绘制架构。默认情况下,这让质量检查人员进行了许多集成检查。假设微服务A的字段称为“名称”,微服务B的字段称为“名称”,微服务C的字段称为“名称”。有自动测试,A和B如何连接,B和C如何连接,但是后来有人不得不进入一个完整的暂存环境,并观察在自动生成的邮件中如何在前端输入的名称会在几个服务中呈现。到那时,开发人员已经在“合同已履行”上打了勾,然后继续下一个任务。
评论
什么是前端?和完整的技术堆栈?目前,我没有太多有关前端的信息。后端可能将在.NET中开发。开发尚未开始,该项目仍处于计划阶段