测试专栏特别放送 答疑解惑第六期

你好,我是茹炳晟。

今天的“答疑解惑”系列文章,我们一起来解决测试数据准备和测试基础架构这两个系列8篇文章中的问题。你可以通过下面对每篇文章的简单总结回顾一下文章内容,也可以点击链接回到对应的文章复习。

这两个系列下的文章留言已经很少了,或许是你没有坚持学习,也或许是这部分内容并没有切中你现在的痛点。毕竟,广义上的软件测试,包括了测试数据平台、测试执行平台等,而我们也不能每一种都有机会接触。

但这里,我想再给你打打气,有些知识虽然你在接触时感觉自己不会用到,但随着技术发展、公司业务转型,或者是你个人的职业晋升,都会需要越来越宽广的知识面,这也正应了我在专栏里面提到的一个比喻,测试工程师通常是“广度遍历”,关注的是“面”。所以,坚持学习,才是我们从“小工”蜕变为“专家”的正确路径。

问题一:有些时候,我们需要创建消息队列里的数据,这类数据应该如何创建呢?

在第35篇文章《如何准备测试数据?》中,我从测试数据创建的维度,和你详细分享了生成测试数据的四种方法:基于GUI操作生成测试数据、通过API调用生成测试数据、通过数据库操作生成测试数据,以及综合运用API和数据库的方式生成测试数据。

其实,我们要创建的测试数据并不仅仅局限于数据库,很多时候还需要创建消息队列里面的数据。所以,在阅读完这篇文章后,我希望你可以思考一下如何处理这类问题?或者,请你分享一下你曾经是如何解决这个问题的。

这里,我来分享下我的方法吧。

通过模拟消息队列中的测试数据,可以实现各个被测模块之间的解耦,这个思路非常关键。至于如何来模拟消息队列中的测试数据,在技术上其实没有任何难度。

我们通常的做法是,在测试数据工具的底层封装一个工具类,这个工具类内部通过调用消息队列的API或者操作接口函数来实现消息队列的CRUD操作,然后凡是需要改变消息队列中数据的地方,都通过这个工具类来完成实际操作。

问题二:你所在公司,采用是什么测试数据策略?为什么选用了这种策略?

在专栏的第36篇文章《浅谈测试数据的痛点》中,我和你分享了选择不同时机去创建测试数据,是为了解决不同的数据准备痛点。为了解决这些痛点,我的经验是把测试数据分为“死水数据”和“活水数据”,其中:“死水数据”适合用Out-of-box的方式,而“活水数据”适合采用On-the-fly的方式。

在这篇文章最后,我希望你可以分享一下自己项目中采用的是什么测试数据准备策略,以及会不会使用线上真实的数据进行测试。

这里我来分享下eBay在准备测试数据时的策略吧。

eBay在准备测试数据时,采用的并不是单一的某种方法,而是针对实际的业务场景选取了不同方法,最后将这些方法进行组合完成整个测试的数据准备工作。可谓是多管齐下。

这里,我和你分享下eBay主要使用了的几种策略:

所以,测试数据策略的选择,最重要的是适合自己所在的公司或者项目的实际情况。这里我和你分享的eBay的实践,希望可以在针对特定场景选择测试策略的时候,可以感到有据可依。

问题三:如果你所在公司,也处于测试数据1.0时代,你们还用到过哪些测试数据准备函数的实现方法吗?

在专栏的第37篇文章《测试数据的“银弹”- 统一测试数据平台(上)》和第38篇文章《测试数据的“银弹”- 统一测试数据平台(下)》中,我从全球大型电商企业早期的测试数据准备实践谈起,和你一起分析这些测试数据准备方法在落地时遇到的问题,以及如何在实践中解决这些问题。

我希望通过这种遇到问题解决问题的思路,可以带着你去体会时代的演进,理解测试数据准备技术与架构的发展历程,并进一步掌握3.0时代出现的业内处于领先地位的“统一测试数据平台”的设计思路。

正如我在文中所说,目前大多数企业都还处于测试数据1.0时代。其实,这也很正常。因为,1.0时代的测试数据准备函数,才是真正实现数据创建业务逻辑的部分,后续测试数据准备时代的发展都是在这个基础上,在方便用户使用的角度上进行的优化设计。所以说,测试数据1.0时代是实现后续发展的基础。

其实,对于测试数据准备函数的内部逻辑实现来说,除了我在文章中提到的基于API、数据库,以及API和数据库相结合的三种方式以外,还有一种方法也很常用,尤其适用于没有API支持的复杂测试数据场景。

这种方法就是,事先在数据库中插入一条所谓的模板数据,在下一次需要创建这类数据的时候,就直接从模块数据种复制一份出来,然后再根据具体的要求来修改相应的字段。

这里需要特别注意的是,对于1.0时代的测试数据准备函数来说,我们还需要建立工具的版本管理机制,使其能够应对多个不同的数据版本。

问题四:目前Selenium Grid已经有Docker的版本了,你有没有考虑过可以在云端搭建Selenium Grid呢?

在专栏的第39篇文章《从小作坊到工厂:什么是Selenium Grid?如何搭建Selenium Grid?》中,我从测试基础架构的概念讲起,并和你分享了传统Selenium Grid 和基于Docker的Selenium Grid的搭建方法。

不知道,你有没有在课后去尝试搭建Selenium Grid呢,这其中是否遇到了什么问题?如果你遇到了问题,欢迎你给我留言,我将帮助你一起解决。

在这篇文章最后,我希望你可以畅想一下是否可以在云端搭建Selenium Grid。这里我结合eBay的探索,来谈谈我的看法吧。

对于一些大公司来说,在云端来搭建Selenium Grid已经被证明是切实可行的,而且也已经呈现出逐渐向云端过度的趋势。这主要得益于云端部署的易维护性和上云本身的便利性。

比如,eBay已经实现了在PCF上基于Docker来运行Selenium Grid的方案,其中落地的难点在于配置Docker的网络和IP地址。主要原因是,PCF会为部署的应用提供统一App URL的命名转换。

从本质上讲,只要Selenium Grid是基于Docker实现的,那么上不上云本身并没有本质区别。但是,考虑到将来的App以及所有的后台服务都会逐渐向云端过度,所以测试基础架构这块必然也会遵循这个趋势,和App以及后台服务的环境保持在一个技术栈上,将会减少公司整体基础架构的多样性,从而提高研发效能。

问题五:你觉得测试基础架构的设计和搭建过程中,还有哪些点需要再优化呢?又可以从哪些方面进行创新呢?

在专栏的第40篇文章《从小工到专家:聊聊测试执行环境的架构设计(上)》和第41篇文章《从小工到专家:聊聊测试执行环境的架构设计(下)》中,我首先和你分享了测试执行环境的概念,然后为你剖析了测试基础架构的演进历程,希望可以帮助你理解测试基础架构的设计,最终可以定制一套适合自己的测试基础架构。

学习完这两篇文章,我希望你思考的是,你所在团队,还可以再测试执行环境的架构设计上,进行哪些优化和创新?

其实,测试基础架构的优化和创新都是由问题本身驱动的。如果不是为了解决实际遇到的问题,企业是不会为了追求更新的技术而去寻求测试架构的改进方案的。所以,通常情况下,我们都是在测试或者DevOps的过程中,遇到了问题或者瓶颈才会考虑新的技术与方法。

除了上面这些技术驱动的原因外,还有些是由企业的组织结构驱动的。比如,eBay的某些产品线,CI/CD团队在印度,而测试架构团队在中国。大家都知道CI/CD的流水线脚本和测试执行是强耦合的,而要求两个异地团队实时合作并保证完全同步很困难。为此,我们就需要考虑为CI/CD提供统一的测试接口,这样流水线脚本就可以以解耦的方式与测试集成了。

问题六:你觉得在我给出的全球化电商的测试基础架构中,还可以增加哪些与测试相关的服务?

在专栏的第42篇文章《实战:大型全球化电商的测试基础架构设计》中,我根据自己的实践经验,把大型全球化电商网站全局测试基础架构的设计思路归纳为了“测试服务化”,并用一张图展示了整体的测试基础架构。

为了便于你回顾文章内容,我把文中用到的大型全球化电商网站的全局测试基础架构设计图,放到了这里。

- 其实,除了图中的各类测试服务以外,你完全可以根据你的业务场景来搭建更多的测试服务,以提高团队的测试效率和研发效能。

这样的例子还有很多,但在实际工作中,我们还是要根据测试本身的上下文以及被测产品的性质,来决定将哪些需求实现成测试服务会。

假如,你的项目只是偶尔会做前端性能测试,那么你就完全没必要去自己实现前端性能测试服务,直接采用现成的工具效率会更高。而如果你的产品需要经常做前端性能测试和优化,而且还不止一个团队会需要这种类型测试的时候,你就应该考虑将前端性能测试服务化了。

最后,感谢你能认真阅读第35~42这8篇文章的内容,并写下了你的想法和问题。期待你能继续关注我的专栏,继续留下你对文章内容的思考,我也在一直关注着你的留言、你的学习情况。

感谢你的支持,我们下一期答疑文章再见!