【iSQE工具系列直播】传统VS新兴？测试工具对对碰线上圆桌回顾
发表日期：2022-07-19被浏览： 1348次返回
iSQE工具系列线上圆桌“传统VS新兴？测试工具对对碰”已于7月6日顺利开播。本期圆桌邀请到上汽乘用车测试主管工程师叶增玲、MICRO FOCUS资深技术顾问陈学锋、腾讯PCG工程效能部研发协同效率中心副总监任志超、万博智云测试总监崔哲、交通银行信用卡中心测试经理龚伟奇、中国电子技术标准化研究院标准化工程师李文鹏、IREB敏捷模块专家工作组组长刘海英，围绕圆桌主题分享了精彩观点。本文依据圆桌论坛嘉宾的对话内容整理而成。
话题一、功能测试
刘海英：我们今天的主题是“传统VS新兴测试工具对对碰”。工具的本质是为人类解决问题，提高它的产能和效能。测试工具种类繁多，如何把种类繁多的工具落地是非常难的一件事情，标准给了我们一把尺，这把尺衡量工具能够测什么、怎么测以及工具方法的策略。接下去时间交给我们的嘉宾来进行碰撞。
龚伟奇：传统跟新兴两个差距其实非常大，不管是传统还是新兴的，目的是一样的，都是条条大路通罗马，目的都是质量的彼岸。
如果从道法术的层面来看的话，更多的区别是在术的层面，也就是说表现形式上，但它们的原理其实是一样的。最主要的目的是要保证我的功能可用，最后要保证提供给客户的需求、功能能满足上线投产的需要，让它变成一个合格的可以使用的产品，才是对功能测试的最基本要求。
叶增玲：我所在的团队比较多的是基于App、经销商端的零售以及小程序。本身的载体和互联网是比较接近的，要在很短的时间内完成一个紧急需求的快速上线，同时可能要面临一个问题，功能测试为什么还会有遗漏？这一切都是为了一个产品交付而服务的。功能测试对我们来说的话有两种，一种就是急速的迭代，另一个是很稳定的产品，周期差异还是会比较大。
任志超：首先在互联网行业，不会特别强调功能测试、性能测试、安全测试，大家更强调的是我们为什么要去做测试？互联网行业之所以会有这么快的迭代节奏，很多时候是基于人的理念，我们的测试本身已经变成了我们该如何能够保证我们的历史债务尽可能在线上进行收敛。
所有的功能测试的工具，一定是说某个制品。所以在整个DevOps的领域里面比较核心和关键的是我们的制品跟功能测试资产之间的一个协作和耦合。质量交付实际上是保证最终线上服务的一致性和稳定性。
崔哲：我们的客户更偏向于b端。其实我们并不在乎“功能”，其实我们更偏向是业务的测试。对于b端的客户，我们系统只是在一定程度上，帮助他们做信息化或者做数字化。我们更重点关注于他们的业务本身的正确性
陈学锋：选择工具确实要根据自己的业务特点来。传统跟新兴，这两个对比差别是特别大，各行各业的新兴、传统，它的开发模式不同，技术框架不同，用户的特点也不同，质量要求肯定也不同，所以测试要求就不同。对工具的要求就不一样，对测试介入的时间要求就不一样、频率的要求也不同以及对测试人员的要求也不一样。从这一点来说，工具的能伸缩性其实是一个很好的点。
刘海英：由于我们的被测的对象，被测的形态，测试的发展，在不同行业怎么测的？对工具有什么有什么样的要求？
龚伟奇：我们的产品涉及的范围非常广，相对来说对测试工具的要求不一样。传统的客服系统，虽然要求迭代得很快，但是在自动化这方面，做得相对来说欠缺一些。但是对于像手机APP，就像刚才陈老师说的一样，在测试的时候要能够更准确的识别出来，对界面的识别、帮助快速的做自动化的一键回归测试。不同的产品形态对测试工具的要求还是很丰富的。
叶增玲：我们针对APP和小程序比较关注的是兼容性，还有一个是前端性能。
第二部分其实是针对于 to b系统，更多的是内部人员使用。我们比较关注的是一个业务属性，还有在一些后台的接口，所以我们会在自动化这一块回归和性能这边会有一个比较高的诉求。
最后一部分跟车机相关，在车企，试驾的车本身成本很高，台架车都很贵。所以我们对这一块更多的是基于软硬件的一个OTA的仿真协议的仿真平台的诉求。结合前面的说的就是UI的自动化，可以在实验场去做一些定标定轨的一些测试。
任志超：在腾讯，大家都喜欢造轮子，到烟囱的这样一个大的文化背景下面，其实我们之前梳理过一次。我们从需求到代码到CI，到测试，到CD，到线上的运维，到我们的数据，到实验，从不同的阶段，我们梳理出来的工具将近有60多种，分别在不同的团队，不同的场景和不同的需求下面被引入。
我们考虑的是我们需要有一条总的这种管道，能够通过统一标准化的方式，把工具框架paas化，这些工具和框架在统一的这种CICD的链路标准化的体系上，能够耦合起来，通过这些流水线让我们的每一个业务都能够在自己的研发链路上找到合适的工具，并且在合适的点去用合适的工具产生足够有效的我们的所谓的质量交付或者业务交付的能力。
崔哲：我们现在做的一个云管工具，管理公有云厂商上面的所有资源的。每个云商的标准不一样，得到的结果也不同。市场上没有这样的工具，分享一个方法，就是把所有的东西全部都提炼出来，自己开发一套云引擎，对接几乎市场上所有的云资源。
刘海英：你们会对外赋能吗？比方说你们的工具给到其他厂商去使用吗？
任志超：大家也许在腾讯云的网站上也看到了很多这种开放出来的一些这种工具链路，包括 pts腾讯云的压测，然后包括coding集成了一整套DevOps的我们的这种研效的能力。
腾讯内部也有很多比较好用的内部的工具，比如我们部门的test one，将各类我们的测试的能力做paas化，能够跟上层的不同的SARS服务做集成，来给大家提供更好的这种所谓的工具接入的体验的这样子一些开源服务。
可选的工具是很多的，但是从业务本身的逻辑来梳理，怎么能够找到整个业务发展过程中，基于现在架构下面的质量敞口，以及基于这些质量敞口和当前业务的痛点，该给出一个什么样子的解决方案，可能对于现阶段很多同学来说，其实是比较头疼的一个问题。
因为每个阶段随着业务的发展，它的质量敞口，它的架构的演进是相当快的。举个例子，我之前在小红书的时候，从17年到20年，小红书就从一个Python的单体应用演进到Java，到微服务，到servicemesh，整个语言架构和框架都在快速地演进。在这样一个快速演进的架构里面，从单云、单机房到多云、跨云这种混合的场景、巩固的场景下面，你就会发现你原来的工具和是solution会不能满足新的业务的诉求。
我们试图将腾讯内部的一些好的经验和方法，能够给更多的外部的这种有需要的公司可以去分享，让大家能够从大规模踩坑的过程中，能够得到今后能够怎么避免这样子的坑的一些思考。
陈学锋：对功能测试我们的一个观点是，工具其实是可以单独直运的，但它又不单一，所以它应该是成为一系列的一个工具，可以去自由的组合很多的这种解决方案。对于现在新兴的行业来说特别重要，因为他们的业务很复杂，而且有这样的一个需求，所以工具之间的话工具链组合蛮重要的，这就是工具的一个伸缩性。
李文鹏：刚才听了各位老师的意见，我从感觉上来说，我们的标准的方向算是做对了，也是适应各位老师说的，其实现在对于工具不再像之前，我就是某一类工具，我们标准也是按照能力的一个维度去划分的，主要分为动态测试、代码分析以及测试管理三个方面。像动态测试这一块，其实测试设计，还有咱们用的一些测试技术、测试理念基于风险的，关键字驱动、基于模型的测试，都属于比较通用的要求。在动态测试这一块，差距更大的需求就是在测试环境上面。刚才汽车行业的老师说的，手机上面可能跟现在互联网公司所采取的一些策略基本类似，在这里也考虑了一个重点，刚才的老师也提到说是兼容性，其实也主要是在测试环境上面的一些要求。
第二个在测试管理，动态测试、性能测试跟测试管理工具去融合，测试管理工具可能是主要的流程。测试管理工具又会根据测试理念和生成周期过程模型会比较相关。
我们标准将测试工具的能力分成了3个大类， 36个小类，也是希望大家可以根据自己的需要去选择合适的能力，再进行组合，最终得到自己的测试工具。
话题二、性能测试
刘海英：性能测试对于工具有什么不一样的需求，然后特别是有哪些新的一些变化？
龚伟奇：双11的时候，大家知道淘宝都很紧张，压力测试很大，那个时候对我们来说压力也挺大的，这就涉及到我们整个交易有个峰值，这是我们性能测试的一部分，大家就要是关注到有更高的TPS处理峰值。
除此之外还有另外一个就像刚才说的一样，我们有一些手机的APP，这块也要关注性能，这也是我们性能测试的第二个部分。
是否可以把性能测试和功能测试合并起来，既做全链路压测，也可以把这些全路压测作为一个背景，在这个背景下我们做一些功能测试，这样可以保证在性能测试背景下，我们功能测试的覆盖面更广一点，这样测试的更充分一点。
任志超：小红书的全电路压车平台，我们会有一个环节叫做基于背景造成的我们的一个全链路的验证，这一类的压测，其实不能叫压测，应该叫做大促保障。
保障包括事前、事中、事后，在事前的这种验证量也会在有这种高的性能压力或者峰值的全链路压力的流量下面，把它当成一个背景流量去执行一些我们的操作test，做一些扩散的功能测试和随机的一些所浏览。
在这种背景下面，很多功能上面的开关和能力，我们在保障计划里面会在真正流量上来之前把它关掉。不仅仅是验证，还要保护。在峰值流量过来的时候，我们不仅验证它全链路的稳定性，也可以扩散验证它功能的有效性。同时也通过一些降级的能力，将一些不必要的这种功能关闭掉，在这种高峰期，能够保证真正核心的业务。龚老师说得很好，我们事实上在全链路压测过程中，我们是会跑一些自动化的脚本和手工的一些探索性测试同时在做。
龚伟奇：任老师他的一些观点其实我是很赞同的，首先压测的东西不光是测试的事，其实它是一个整个系统东西有方案有策略。第二个他刚才说的其实也看出来互联网行业在一些方面其实走的是的确比我们要前一点，以后有机会可以交流，互相学习。
叶增玲：像前面几位老师说的，我们可能会碰到的问题并不是大促，我们遇到的问题是过年回家的时候能不能发动起来，然后能不能读出里程这样的状况。
在这个过程中，我们一般是做一些熔断优化，提前有一个系统容量的规划，包括之后的监控系统的完善，更多的是整个的监控体系，注重于前期的一个方案和目标，做一个系统扩容的状况会比较多一点。
崔哲：现在很多企业已经上云了，弹性伸缩的能力已经非常强了，所以基本上很多的这种压力都是交给了云厂商，并不是由系统本身去处理。如果有临时或者突发性的这种增加，也会把这种压力转嫁给云商，云商进行弹性伸缩。
对于我这样的产品的性能我们通常都会借用云商本身，比如刚才任老师讲他们的PDS，这是我们很常用的一个工具。或者是阿里云它现在云原生的景区点，其实也是我们常用到的云上的工具。
有一个疑惑的，我们的很多性能其实是被云商给限制住了，云商本身有限流。
任志超：完全把这种线上的稳定性托付给云端的自动货，其实有时候会有一些风险。
因为线上的真实的就是to c用户感知到的这种所谓的稳定性，它是由整个链路上面的我们的这种质量敞口决定的，质量敞口实际上是一个洋葱模型，就类似于剥洋葱一样，比如说我解决了这种get为接入层的问题，你会发现其实可能流量下来以后，压力达到了你的服务层，这时候你又需要对服务层进行自动扩充，然后可能到服务，从往下又牵涉到存储或者数队列或者数据库，这一类的io的瓶颈往往有时候会变成一个我们的单点瓶颈。
所以在我们需要依赖这种自动或是我们的前提是我们对整个链路南北向电路的整个质量敞口有一个分析和认识。
前期的这种所谓的全电路压测，实际上是为了把洋葱一葱一层剥掉，看看在洋葱的里面有没有真正的比如说单点故障，或者有一些这种性能在这个里面的一些瓶颈。
同时在这种所谓的流量的限流，还有垄断这一类的机制，其实限流无外乎两点，一种是业务层的限流，这个东西其实是要从业务层去解决的，我们可能是需要去提前去找到这种第三方的所谓的容量规划，去找到第三方的这种接入能力。
然后你要有动态的分配机制，也就是前面叶老师谈到的我们的容量规划，容量规划不是简单的某一个点上的容量规划，是整个业务从业务我们的业务流量的模型，水位模型来映射到你的不同的架构上面，你的资源的预计应该是什么样的，怎么去保障，然后你通过你的全电路压测的能力去对它进行注意。
陈学锋：
对于性能测试的话，一个是要从业务的角度来看，另一个就是说要有很多的层次，刚才说的洋葱的比喻，我觉得特别你要看看在哪个层次出了问题，所以这个工具的话你能不能定位得到。
话题三、安全性测试
刘海英：安全在各个行业现在是越来越受重视了，新的25000标准都拉到了一个新的属性当中，说明它的重要性。
龚伟奇：我们安全应该是从广义上来考虑，一个是系统的安全，就是保证系统防止受到攻击保护，第二个就对银行业务特色，对用户信息的一些保护应该是比较重要的。然后第三个的话，安全是一个广义的安全，应该是一个叫容错性，在一些特殊情况下，你要保证把东西记录下来，最后能够把一些错误的数据恢复了，这是一个数据安全的东西。
叶增玲：我们确实是相当重视安全，这一块其实是有一个专门的部门去负责车机端的性能。我说一下我这边接触到的一个安全，因为我们更多的也是可能说是APP端的一些安全类似于等保的一些要求，然后本身 APP的一些的安全的信息或者是漏洞扫描渗透测试这些会做。
任志超：从互联网公司来说，本身安全就是互联网业务其实持续发展的一个很重要的基础。互联网的业务面临的挑战和银行、车企这些面临的挑战其实是一样的，分为安全的测试、安全的体系、安全的防护、安全的合规。
安全在某种意义上来说，今后很长一段时间其实它是一个叫做tpm的领域，可信的安全计算。从源头开始，包括从语言编译器，到操作系统，到整个执行环境，到网络链路，一整套是不是基于一个可信的安全域进行维护、变更和改进的一个过程。安全还应该包括可审计，就是刚才老师谈到的，当我出问题的时候，我一定要回溯可以去审计可追溯。
陈学锋：安全测试确实这个话题特别广，其实简单的分，肯定是分软件硬件，还有网络，这些设备。
为了防止黑客或者恶意软件引起的问题，去控制我们的系统，去获取我们的机密信息，有一个很强的很大的能及时更新的这种叫做安全库，安全漏或者叫漏洞库，扫出来以后再告诉我这个漏洞是什么，怎么来的，怎么防治怎么解决，整个链路整个一系列东西都帮我解决掉。
问题1、关于机器辅助的探索性测试。
任志超：如果从端上来说，现在有一些比如说这种字节跳动有smart monkey，腾讯有lean monkey这一类，带有一定的这种额外的Pattern，它可以基于业务价值链去完善，进行随机点这一类的探索的能力。
还有一系列是基于线上的操作日志，基于APM操作日志来去聚类生成我们线下的一些UI自动化测试能力，实际上反过来去给现有的测试资产提供更多的一些拓展场景
CodeParrot本身就是利用大家的代码的item和学习的手段去预测代码。很多的BDD的场景，大部分都可以逐渐地被一些自动化生成的Codeslap的来替代。
自动生成单测、UI测试用例，自动的生成测试数据，驱动现有的单测和自动化的测试case，这都是已经在现实实践已经被使用的一些东西了，今后我们的这种能力其实会逐渐的越来越快。
问题2、测试工具能力要求的分类适用于测试人员能力要求吗？
刘海英：实际上ISTQB的体系就是对我们测试人员从业者的这样的能力进行认证。
在我们接下去的活动当中，我们会做针对专项做更深入的探讨，也会请更多的嘉宾来一起参与我们的讨论，也欢迎我们的听众来一起参与我们的讨论。