首页
学习
活动
专区
工具
TVP
发布

E2E 测试容器化实践

齐磊,ThoughtWorks 高级质量咨询师 今天给大家带来的话题是E2E容器化实践,可能QA更关注些。 在互联网最初之时,没有任何容器化的概念,那么刚开始的时候是怎样开发软件或者是网站的吗?...容器化能给QA带来哪些方面的测试,第一个是单元测试,第二个是集成测试,第三个是E2E测试。之前在虚拟化时代这三个也能做,但是容器化时代已经来临,我们要进入到容器化时代。 测试容器化解决了什么?...先聊一下E2E测试,我们是先编写测试脚本,然后去上传,这里有两种触发CI的方式,一种是开发环境部署后触发,一种是定时触发,当触发之后,会把代码放到运行测试的服务器上去运行,这时当你运行完之后就会把结果告诉你...运行E2E测试 最早的时候容器化尝试是这样,怎么在没有界面的情况下去运行,我们知道端到端测试需要页面做一些操作,在容器里怎么做操作?...持续集成 什么时候用trigger E2E testing,我们知道端到端的测试,项目比较小可能运行时间需要2-3分钟,项目大的话可能一两个小时。

1.5K20
您找到你想要的搜索结果了吗?
是的
没有找到

圈外人看E2E保护

E2E保护介绍 E2E(End-to-End)保护是一种端对端保护机制,举个例子:控制器中某个安全关键性功能模块的输出计算要依赖于内部某个非安全性的模块或其他安全等级要求不高的硬件通过总线传输过来的数据...E2E实现方式 在 AutoSAR标准中,E2E 保护的实现有三种不同方式: 1、 E2E Transformer:这是一种在AutoSAR 4.2.1中首次被提出的全新且标准化的 E2E 实现方式,并这种实现方式下...,RTE 会调用 E2E Transformer 的 API,E2E Transformer 的 API 进一步调用E2E Lib 提供的函数库,实现 E2E的保护和校验。...2、采用 E2E Protection Wrapper(E2EPW):这种在 RTE 之上进行了一次封装,E2EPW负责调用 E2E Lib 提供的函数库,实现 E2E 的保护和校验,并通过RTE 的...基于E2EPW方式,如下是进行跨ECU通讯的E2E保护示例图: 3、针对跨 ECU 之间的通信,COM E2E Callout 的 E2E 保护和校验是在基础软件层做的,在这种实现方式下检验的单元是以

1.2K21

如何知道我们的E2E测试覆盖率?

我们一直在思考,既然已经编写了许多 E2E 测试用例,但是我们应该继续编写多少剩余测试? 在单元测试中,很容易知道已经覆盖了哪些代码区域。但是我们能及时知道API调用的动态范围吗?...我们一直在思考,既然已经编写了许多 E2E 测试用例,但是应该继续编写多少剩余测试?永远不够?或者我们可以止步于此? 我们需要一个可以告诉当下在哪里的女巫,她就是 Java Agent。...啊..听起来像是基本的E2E测试场景,对吧?最大的不同是,我们将自动打开浏览器来模拟用户操作(键入或单击)以与后端服务进行交互。...可视化您的 E2E 测试覆盖范围可以指导回答我们身在何处的问题。

1.3K20

如何自动化测试 React Native 项目 (上篇) - 核心思想与E2E自动化

测试是比较合理的平衡点(Google在blog中推荐70/20/10的测试用例个数比例) 简单介绍一下对 Unit, Integration 以及 E2E 自动化测试的想法: E2E 测试 E2E自动化测指通过...但实际应用中E2E测试的缺点也很明显: 要花很长时间才能找到真正的bug。 在fail的E2E case里找root cause很痛苦。 E2E测试依赖于测试Build和测试环境。...经常E2E case挂了是因为各种非bug的原因,需要花时间和精力去维护测试Build和环境才能保证E2E case都pass。 小的bugs很难被发现。...当UI或者功能变化的时候, 维护E2E测试的成本是很高的,如果E2E带来的收益还比不上维护他们的成本, 就得不偿失了。 因此全部用E2E进行自动化测试是不现实的。...我个人之前也试过写150+条E2E脚本来进行测试, 后来维护脚本的时间精力实在太大。因此我们需要更高效和容易维护的测试脚本来代替E2E测试。

3.5K32

golang测试用例规范

── heartbeat_test.go│ │ └── heartbeat_testcase.json2.3 A3用例2.3.1 存放位置类别存放位置说明大仓模式【必须】放到根目录/test/e2e.../test/e2e/e2e-pay )小仓模式(方案一)【必须】单独建立一个仓库【推荐】仓库名建议为test开头: test-xxx 【推荐】仓库根目录/test/e2e目录下( 可以根据实际需要再分类...,建立子目录,如:根目录/test/e2e/e2e-pay)小仓模式(方案二)【必须】放到团队协议仓库里【推荐】仓库根目录/test/e2e目录下 (可以根据实际需要再分类,建立子目录,如:根目录/test.../e2e/e2e-pay)小仓模式(方案三)【推荐】放在API网关所在仓库【推荐】根目录/test/e2e目录下(可以根据实际需要再分类,建立子目录,如:根目录/test/e2e/e2e-pay)代码结构示例...(服务2接口测试代码)├── go.mod├── go.sum├── readme.md└── test│ └── e2e│ │ ├── e2e_test.go (e2e

1.1K31

你的微服务敢独立交付么?| 洞见

添加了E2E测试之后,我的交付流水线就变成了下面这个样子。 ?...因为有了E2E测试的存在,问题迎刃而解,当A服务的新版本破坏了与B服务的集成时,E2E测试就会及时诊断出来,并阻止A服务的最新版本向产品环境流动,保证产品环境不被破坏。...假设A服务的修复过程中,B和C服务也提交了新的代码,我们假设这两个提交是没有问题的,但因为A服务的1.1版本导致E2E测试挂掉的问题还没有被修复,所以B和C的新版本也被E2E测试拦了下来,此时的E2E测试就像是一个亮起红灯的路口...即并不添加新的集中的Pipeline做E2E测试,而是为每一个服务的Pipeline都添加一个相同的E2E测试的Stage,就相当于将E2E测试Inline到每个服务各自的部署流水线中,如下图所示。...其实Inline E2E测试还不是最关键的,最关键的变化点就是假设A服务有了新的提交,运行到A服务自己Pipeline的E2E测试的时候,此时的E2E测试并不是像之前一样获取B和C服务的最新代码库版本做集成验证

82021
领券