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

E2E 测试容器化实践

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

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

    圈外人看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.8K21

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

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

    1.8K20

    Vue 框架学习系列十二:Vue 3 单元测试与E2E测试

    在Vue 3应用中,E2E测试通常用于测试应用的路由导航、表单提交、数据交互等复杂场景。常用工具:Cypress:一个现代化的前端E2E测试框架,提供了强大的调试功能和丰富的API。...TestCafe:一个零配置的E2E测试工具,能够自动等待元素的出现和交互。实践方法:安装依赖:以Cypress为例,安装Cypress和相关依赖。...scripts": { "test:e2e": "cypress open" }npm run test:e2e三、最佳实践持续集成:将单元测试和E2E测试集成到CI/CD管道中,确保每次代码提交都会自动运行测试...总结单元测试和E2E测试是Vue 3应用开发过程中不可或缺的部分。通过合理的测试策略和实践方法,可以显著提高代码的质量、稳定性和可维护性。...本文介绍了Vue 3单元测试和E2E测试的基本概念、常用工具和实践方法,希望能够帮助开发者更好地理解和实施测试工作。

    1.5K10

    如何自动化测试 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测试。

    4.2K32
    领券