|
|
# 03｜工具选择：什么工具框架值得用？
|
|
|
|
|
|
你好，我是柳胜。
|
|
|
|
|
|
工具选型评选会你应该不陌生，无论你是作为评审者，还是方案建议人。不过常常出现的场景就是，方案建议人讲了一通新工具A如何优秀强大，从问题分析到方案解决一应俱全。但参会专家并不是全都熟悉这个新工具，就会问出一堆类似“为什么你不用工具B”的问题。
|
|
|
|
|
|
结果也可想而知，懂A的不懂B，懂B的不懂C，懂C的不懂A，最后评审会咋决策？只好陷入一个依靠个人影响力来决策的模式。要破除这种死循环，就要找到一个量化模型。在我看来，量化数据才是团队有效交流的手段，也是团队达成共识的基础。
|
|
|
|
|
|
有了这样的模型，好处多多。评审阶段，可以更科学地预估某个工具的能力和风险；工具投入使用后，模型依旧能帮你持续观测，检验这个工具是否带来了预期价值。
|
|
|
|
|
|
今天我会带你一起推演出这个模型。学会推演方法，远比套用“模型”更重要。
|
|
|
|
|
|
## 自动化测试案例的成本
|
|
|
|
|
|
在开始量化评估之前，我们先回顾一下前面学过的ROI模型。
|
|
|
|
|
|
|
|
|
|
|
|
通过这个模型，我们得到一个重要结论：**一个自动化测试案例的开发工作量，在给定条件下，什么经验的工程师用什么工具，需要多长时间完成，这是可以估算的定值。但维护工作量包含了多种可变因素，是自动化测试项目的风险所在。**
|
|
|
|
|
|
今天我们聚焦公式里的分母，也就是开发成本d和维护成本m。
|
|
|
|
|
|
先说开发成本。在软件开发中，估算开发规模的传统方法有功能点和代码行，前沿的方法也有用AST抽象语法树。那如何估算开发一个自动化案例需要多大工作量呢？
|
|
|
|
|
|
首先我们要看一下自动化测试案例是如何产生的，目前在业界，主要有5种方式。
|
|
|
|
|
|
### 方法一：录制和回放方法
|
|
|
|
|
|
第一代的自动化测试工具大多基于录制回放，像最早的WinRunner就是录制桌面UI应用的。目前代表工具就是Selenium IDE。
|
|
|
|
|
|
要生成测试代码很简单，开启浏览器Selenium的插件，打开测试的网页，比如http://www.baidu.com，输入关键字“极客时间”，点击搜索，就会自动生成测试脚本了，如下图。
|
|
|
|
|
|
|
|
|
|
|
|
通过录制产生自动化脚本的这种方法，优点是速度快、零编码，对测试人员技术要求低。缺点是规模一旦扩大，维护工作量几乎无法承受，比如和CICD集成、自定制报告、多环境支持等等。
|
|
|
|
|
|
### 方法二：关键字驱动
|
|
|
|
|
|
不过，录制回放产生的脚本，还是面向过程的一个个函数，还需要测试人员有一定代码基础，才能扩展和维护这些函数。
|
|
|
|
|
|
那么，有没有办法，让没有代码经验的人也能编辑、维护脚本呢？关键字驱动方式应运而生了，它增加了页面控件对象的概念，调用对象的方法就是操作对象运行，在这种机制下，对象、对象的行为、输入的数据和描述信息，这些内容都能用一个表格的形式呈现。业务人员只需要编辑表格，就能修改运行逻辑了，这就叫做**关键字驱动**。
|
|
|
|
|
|
下面是一张关键字驱动表格，编程就是编辑表格里的关键字和对象。关键字是一组预定义好的指令，编辑完表格后，框架会驱动这个表格，执行设定好的命令，来完成自动化测试。
|
|
|
|
|
|
|
|
|
|
|
|
相比录制回放，关键字驱动框架的优势在于降低了测试开发人员的技术要求。而且测试开发人员对代码还有了更多的逻辑控制能力，比如增加循环结构、wait time、log输出，只要框架提供足够丰富的关键字就行。
|
|
|
|
|
|
但你也不难看出，编辑表格的人和维护关键字仓库的人，并不是同一拨人。前者是对业务了解的测试人员，后者是技术能力强的开发人员，这样开发维护起来会增加难度。
|
|
|
|
|
|
### 方法三：模块库开发
|
|
|
|
|
|
随着软件技术的发展，自动化测试人员的技术水平也在提高，要解决的问题也更加复杂。比如自动化测试的代码怎么能够有效地复用，有没有好的扩展能力等等。这个扩展能力是二维的，分为水平功能扩展和垂直层级扩展。
|
|
|
|
|
|
水平功能扩展指的是测试功能增多，自动化测试代码就借鉴了软件的模块设计思维，一个应用的测试场景可以切分成多个功能模块。比如订餐的流程可以分成登录模块、下单模块、快递模块，模块之间通过调用关系连接起来，组成测试场景。
|
|
|
|
|
|
|
|
|
|
|
|
而在技术层面上，又可以垂直切分出功能案例库和通用库。比如页面的组件可以形成复用库、page对象、button对象、link对象等等，把和开发技术耦合的技术层封装在复用库里，而和测试相关的业务功能实现在功能案例库里。
|
|
|
|
|
|
|
|
|
|
|
|
这样的设计，遵循了高内聚低耦合的软件设计思想，未来自动化测试规模扩展时也很方便。比方说增加一个支付功能，就可以把支付页面的对象写到复用库里，新创建一个支付测试案例，前面和下单模块衔接，后面和快递模块对接，就能跑起来了。
|
|
|
|
|
|
|
|
|
|
|
|
模块库开发的优点是可扩展、可复用，困难是需要架构工作和代码工作，对自动化测试开发人员的代码能力要求也比较高，接近开发工程师。
|
|
|
|
|
|
### 方法四：BDD混合框架
|
|
|
|
|
|
还有一种方法是BDD混合框架。BDD全称是Behavior Drive Development，行为驱动开发，它通过Gherkin语法定义测试场景。
|
|
|
|
|
|
Gherkin语法包含一套类自然语言的关键字：when、given、then，given描述条件，when描述行为，then描述结果。这样一个场景的3要素：上下文、动作和结果就说明白了。
|
|
|
|
|
|
所以，Gherkin语法描述出来的测试场景，能够同时被非技术和技术人员理解。客户、需求人员、开发人员和测试人员从BDD案例各取所需，需求人员得到用户手册，开发人员得到Use Case，测试人员得到测试案例。这些都有BDD框架支持生成代码，比如Cucumber。
|
|
|
|
|
|
|
|
|
|
|
|
BDD和关键字驱动框架的优缺点基本一样，不同的是，BDD不局限于测试框架，能够和软件流程集成在一起，也有相应的开发IDE插件，比如Eclipse plugin。
|
|
|
|
|
|
### 方法五：更高ROI的探索，自动化前沿技术
|
|
|
|
|
|
最后，我要说一下目前比较火，听起来也很酷的自动化前沿技术。
|
|
|
|
|
|
AI测试曾被寄予厚望，我们期待由它发展出一套自动化测试全栈解决方案，可以自动生成测试案例和代码，而且维护工作量为零。不能说这些全都是镜花水月，我相信目前AI只在一小部分测试领域里落地，比如图像识别的Applitools，可以用作图片验证；游戏领域里的监督学习，用来行为克隆等等。
|
|
|
|
|
|
我也曾看过一些AI根据规则自动生成测试案例的演示，但演示只是演示，它演示的方案需要的很多条件，现实还不具备，比如基于非常理想的数据模型等等。所以，我认为AI“落地”的定义是，它的形式是产品，而不是个人业余的项目或者一段开源代码。
|
|
|
|
|
|
相比AI测试，我更看好另外一种自动化生成测试的思路，就是基于规则化或可以模式化的业务场景，把案例的生成和代码生成一并自动化，形成一种可以量化的案例发现方案。我会在第5讲带你了解这个思路如何实现。
|
|
|
|
|
|
记住，**测试工作是要能证明软件功能的成败，其方法论基石是确定论，而不是未知论**。说得通俗一点，测试是在编网，虽然网会漏鱼，但我很确信只要投入人手和时间，就能把网编到什么程度，网住什么鱼。 而不是今天我捉到一条鱼，明天不知道鱼在哪里。这是我不认为AI能完全替代手工测试工作的原因。
|
|
|
|
|
|
好，业界已知的生成自动化测试方法，我们做了归类了解，接下来再分析不同类型的自动化测试开发成本和维护成本。
|
|
|
|
|
|
我给这个表格起一个名字，叫做**案例DM分析表**。D代表Development，M代表Mantainence。
|
|
|
|
|
|
|
|
|
|
|
|
## 工具的成本
|
|
|
|
|
|
前面探讨的给定了类型工具的情况下，案例的开发、维护成本如何衡量。但别忘了，成本计算时，还有个不小的成本：工具和框架的成本。这个在选型阶段没有考虑的话，会给后面埋下很多隐患，带来不少让人头疼的问题，比如下面这些。
|
|
|
|
|
|
1.当你的团队开始上手案例开发时，发现框架只支持JavaScript，Perl，但你的团队都是熟悉Python和Java。在这种情况下，是培训已有团队还是招聘新的人才，还是弃用方案而选择新的框架？
|
|
|
|
|
|
2.当你需要升级框架时，高版本对低版本的兼容性。它有可能让你的原有测试案例不能工作，最糟糕的是，会出现一些奇奇怪怪的问题，每一个问题的诊断过程是一场对你毅力和耐心的考验。
|
|
|
|
|
|
3.当你的案例在运行的时候，遇到一个框架抛出来的exception，网上搜不到解决方案，去社区论坛提问，也没人响应，自己去看源代码又陷入浩若烟海的context中去，那种无力感蔓延开来，直让你怀疑人生。
|
|
|
|
|
|
4.当你的案例规模扩展，新的API案例需要调用PATCH原语，但你已使用了一年的API框架不支持PATCH，更悲催的是，你发现这个API框架已经停止更新，凋零的社区、隐身的支持人员、破败的代码，都是对你的毒打。
|
|
|
|
|
|
进坑容易出坑难。我见证过一个自动化测试团队选型工具草率，导致在2年内更换了4个工具。每次换工具，都会重写一遍自动化测试案例，人收获了教训离开公司另谋高就，但公司浪费了2年的时间和资源，之后还要换一拨人乐此不疲地重复这样的故事。
|
|
|
|
|
|
可以说，选型合适的框架是自动化测试架构设计中一个重要的选择，它通过开发成本和维护成本两个因子影响自动化测试ROI，ROI低于1的时候，这个项目就要over了。
|
|
|
|
|
|
那什么是ROI好的框架呢？
|
|
|
|
|
|
首先，框架要**满足我们的测试需求**。比如，UI框架能有对象识别能力，API框架能有http原语封装，对xml和Json的支持，单元测试框架能有mock能力。
|
|
|
|
|
|
其次，框架应该有**广泛的同行用户、持续的更新、成熟的社区和积极的客户响应**，这些也能帮我们降低维护框架的成本，获得更好的ROI。
|
|
|
|
|
|
把这些因素量化，就能得到一个工具四维成熟度表，你可以把它作为原始模型，用到你的工作里。
|
|
|
|
|
|
|
|
|
|
|
|
## 小结
|
|
|
|
|
|
今天这一讲，我们从开发成本和维护成本的角度系统梳理了工具和框架的优劣势。根据脚本的生成方式的不同，可以划分出录制回放工具、关键字驱动工具、模块库开发工具、BDD混合工具和AI工具，针对自动化的不同类型和规模，脚本的开发和维护成本也会发生变化。
|
|
|
|
|
|
框架本身也会有维护成本，这里我们优先选择成熟主流的框架，会降低维护的成本。这里“成熟主流”，我们使用用户的数量、更新的频率、社区成熟度、开发语言与团队的适配度四个指标来对比度量。
|
|
|
|
|
|
我并没有给出一个精准计算工具框架ROI的公式，而是给出几个维度来帮你厘清工具和框架的选择思路。
|
|
|
|
|
|
记住，这里有两大原则：
|
|
|
|
|
|
1.按照团队的**技术能力、项目的预期长短、将来扩展的规模大小**，选择ROI最大的工具和框架；
|
|
|
|
|
|
2.当工具和框架带来的ROI无法升高时，就考虑按照原则1 **重新评估**，选择ROI更好的工具和框架。
|
|
|
|
|
|
所以，工具和框架的评估不是一劳永逸，而是在整个自动化测试生命周期内实时观测，如果有变要及时止损，让ROI持续提升。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
在工作中，你的团队非常熟悉Python，所以选择某个支持Python框架。基于这样的原因做选择是不是遵循ROI原则？这样的选择会带来什么样的好处和坏处？
|
|
|
|
|
|
欢迎你在留言区跟我交流互动，也推荐你把这一讲分享给更多同事和朋友，说不定就能帮他通过下一次的工具选型评审会。
|
|
|
|