测试三明治和雪鸮探索测试

测试金字塔理论被广泛应用于计划和实施敏捷软件开发所倡导的测试自动化,并且取得了令人瞩目的成就。本文尝试从产品开发的角度出发,结合Kent Beck最近提出的3X模型和近年来迅速发展的自动化测试技术,提出并讨论一种新的测试层级动态平衡观:三明治模型。同时,为了应对端到端测试在实践中面临的种种挑战,设计并实现了一种面向用户旅程的端到端自动化测试框架——雪鸮。实际项目经验表明,雪鸮能够显著提升端到端测试的可维护性,减少不确定性影响,帮助开发人员更快定位和修复问题,对特定时期的产品开发活动更具吸引力。

微服务下使用GraphQL构建BFF

微服务架构,这个在几年前还算比较前卫的技术在如今遍地开花。得益于开源社区的支持,我们可以轻松地利用 Spring Cloud 以及 Docker 容器化快速搭建一个微服务架构的原型。不管是成熟的互联网公司、创业公司还是个人开发者,对于微服务架构的接纳程度都相当高,微服务架构的广泛应用也自然促进了技术本身更好的发展以及更多的实践。本文将结合项目实践,剖析在微服务的背景下,如何通过前后端分离的方式开发移动应用。

云与性能测试

云测试看字面意思就是关于云计算、云平台的测试,而它大体又可以分成两种类型:测试云(Test Cloud)和用云测试(TaaS)。 测试云,顾名思义测试的目标是云,测试者通过设计测试去保证云平台本身和部署在云端的应用正确性。而用云测试是指利用搭建在云端的测试服务 — TaaS (Test as a Service)来进行更高效的测试。云计算有着超大规模、虚拟化、高可靠性、高可伸缩性和按需服务等诸多优点,但平台的特殊性也给测试带来了新的挑战和机遇,其中性能测试受其影响颇深,本文旨在针对云测试的两种类型探讨云与性能测试。

移动应用的测试策略与测试架构

今天我们来谈谈移动测试的测试策略与测试架构。对于移动应用,首先它本质上也是软件系统,所以通用的软件测试方法技术都可以使用。其次它又拥有嵌入式的特征,比如开发需要交叉编译、需要远程调试、硬件资源相对不足等。所以移动应用的测试也有其特殊之处,比如也需要交叉编译、远程测试以及各种硬件相关测试等。对应的移动应用的测试策略和测试架构也有其特殊性之处。

测试矩阵

测试的种类繁多,难于理解,难于沟通。我觉得主要是在于我们将两个测试分类的维度混杂在了一起。

如果我们不再提“单元测试”、“性能测试”这种含糊不清的概念,而是通过测试矩阵上的二维定位法,改称“方法级别的功能测试”和“API级别的性能测试”,我想我们对于测试的沟通讨论甚至学习实现将明确的多,也简单的多。

自动化测试框架分类与思考

自动化测试一直是敏捷开发和敏捷测试的重要基石,也是DevOps和CI/CD必不可少的组成部分。由于不同项目的测试需求不同,以及各种不同的限制,导致需要的自动化测试框架和工具也不同。比如很多金融和能源类的企业就倾向于选择收费的企业级自动化测试框架或者工具,而新型互联网企业则倾向于开源免费的自动化测试框架或者工具,或者基于它们进行二次定制开发,或者重新开发适合自己的自动化测试框架、工具或者平台。

我之前写过一篇文章——《自动化测试框架Cucumber和RobotFramework的实战对比》仅仅针对两种自动化测试框架进行了讨论,却引发了大量的讨论,由此可见业界对于自动化测试框架存在很多不同的理解和争议。在我看来,没有任何一个自动化测试框架是银弹,并且适合所有类型的测试,所以“如何选择一款适合自己的测试框架”变成为了一个首要问题。