如果搜索自动化测试相关的文章，看到的集中在两类：一是宏观上的关于手工测试和自动化测试的区别、自动化测试的优缺点、测试金字塔应该的结构（比如三角、倒三角、甜筒、梯形、洋葱、地球仪模型等），等等。一是微观上的关于测试工具的使用。对于读者来讲，在没有一定的实践基础上，前者很容易陷入一种形而上的讨论，读时不明觉厉，掩卷不知从哪开始。后一种又很容易造成一种“自动化测试=自动化工具/自动化执行”的错觉，弄不好便会变成拿着锤子找钉子。
本篇文章的尝试回答这样的问题：如果QA没有太多自动化测试实践，但又在测试效率上碰到瓶颈，冀望自动化测试就能解决当前困境时，应该作出怎样的一些思考？。（注：文章后半部分会涉及HTTP接口，希望读者已经了解HTTP协议的基本内容）
从头讲起 - 测试的cycle time
测试的核心问题是：测什么（What），怎么测（How）。对QA来讲，测试就变成要能够想到、还要能够测到（测试效率）。这两个问题有时有本质的困难，有些测试点就是再给出两倍的时间也不一定能想到，同时有些测试能想到却不一定能测到（比如全组合测试）。
在这种理解上，自动化测试到底能帮助QA什么呢？要说清这个问题，还得先从基本的测试过程开始。一般一次完整的测试要经历以下步骤：
理解需求、测试分析、设计用例、准备环境、准备数据、执行用例、判断结果、（报Bug、重测）、Sign off
如果说测试是QA对质量的反馈，并称呼从“理解需求”到“Sign off”为一个完整的测试Cycle，那么可以说只有经历了一个完整Cycle的测试才更有意义。比如，设计很多用例而不执行，团队并没有从“设计用例”活动中得到有效的质量反馈（除了一些澄清）。同样，有了Bug而不报告，也不能算有效的测试，因为真实的质量反馈并没传达到团队。
另外一方面，可以简单定义从“理解需求”到“Sign off”所经历的时间为测试Cycle Time，那么如果Cycle Time过长，长到团队得到第一次反馈时已经是迭代Last Minute，这时也可以认为测试效率很低。这也包括对Bug的重测过程。
自动化测试的目标应该是测试Cycle Time的整体的缩短，加快测试反馈周期。
Single Cycle Time
要理解这个，可以借助价值流图的方式，给以上每个步骤记录一个时间，我们能得到这样一个结果：
假设单个阶段活动为5分钟，且只有一个Bug并一次修复成功，则测试Cycle Time合计5*8 = 40分钟。如上图，QA要经历30分钟（不含Bug时间）的测试活动才能给团队第一次的测试结果，经历40分钟的测试活动才能将相关功能Sign off.
如果“自动化测试=自动化执行”，哪怕把执行时间缩短为秒级别，Cycle Time也只减少了5分钟，节省5/40 = 12%的时间。
但是如果我们的自动化节省了包括准备环境、数据等的时间，比如用基于模型的方法自动化了分析到准备数据的全过程，使其整体时间缩短到5分钟，则节省的时间则是20-5 = 15分钟，节省15/40 = 37.5%的时间。
糟糕的自动化是有了很快的执行速度，却给“喂”了无效甚至错误的测试数据，这时的执行快只是一种假象，无助于加快有效反馈的目的。还有一种自动化测试是将手工测试用例翻译成自动化测试脚本，这通常只是片面追求执行快而已，整体Cycle Time也许变得更长，因为书写和维护自动化脚本也是要花时间的。
自动化测试工具的出发点
当我们执行了数个测试用例，也就是经历了数个测试Cycle后，发现一些活动可以抽象出来，如上图所示，这也就是一大类工具产生的根源。也正因为如此，大多数工具都是为了某类特殊目的而产生，同时天生就有其局限性。据不完全统计，目前的测试工具数以百计，并且还在增加中。诸多工具中，很大部分都聚焦在用例执行上。
测试工具作为基础设施，辅助QA测试，但是在“测什么”这个问题上收效甚微，还得依靠QA自身的分析能力。QA需要明确自己的测试问题域，同时理解这些工具的设计出发点，合理地使用它们。从Cycle Time的描述可以看出，只着眼测试执行的工具通常离Cycle Time整体缩短的目标还有相当大的距离。
所以当你碰到瓶颈，以为是因为没有使用某个或某类自动化工具时，请仔细想想你的测试问题域和已有的测试过程是否已经优化了。通常我们会发现，优化现有的测试过程比单纯增加一个测试工具的效果更突出。
注：考虑QA的日常，可以再细分一下，以便参考：
常规用例设计与执行
探索用例设计与执行
回归用例设计与执行
其它非功能性用例设计与执行
以API自动化测试为例
上面讲的都还在概念层次，我们以API测试为例来具化一下这些概念，来看看测试、自动化测试、测试工具的联系，以及一个新测试工具的产生过程。
聚焦在API上，一方面很多系统的对外服务本身就以API为主。另一方面，随着架构的演进，大多网站也采用了前后端分离的方式，也就是API对外可见，相当于系统给用户暴露了至少两类访问途径。据说douban，facebook等网站的API直接访问量是大于其Web访问的。
API测不测？如果系统只提供API服务，答案是肯定的。但是如果系统是网站或者系统有前端界面，得到的答案却有点“模糊”，一方面QA受本身技术的限制没有意识到API的存在及其重要性，另一方面以前端界面为默认或者承诺的交互方式为由而降低了它的优先级。但是如果以用户可能会通过什么样的方式来影响系统的角度上讲，只要API有访问的可能，API测试覆盖就不可或缺。
API测试场景 - 测试问题域
API作为专门测试，除非有专门工具的封装，它没有Web那样直观的界面，需要对相应协议的理解。要想谈API自动化测试，就得先看看QA测试API时有哪些场景以及难点（先假设我们只讨论功能和性能，不涉及安全、契约测试等）。
场景1：单个API的单次执行，只要会至少一种API调用方式即可，比如curl、Postman之于RESTful类API。（难点：无）
场景2：单个API的多次执行，这时需要对API的正常返回、异常返回以及API对多种数据组合进行测试。（难点：大量数据的准备和管理，测试执行）
比如：对一个POST请求，Post body有6个字符串类型字段，如果一个字符串正向、负向数据合计为5，则全组合为5的6次方：15625
场景3：多个API的单次执行，它们之间没有依赖。（难点：管理每个API以及它们对应的数据）
场景4：多个API的单次执行，它们之间有执行顺序依赖，没有数据依赖。（难点：管理API间的执行顺序）
场景5：多个API的单次执行，它们之间有执行顺序依赖，也有数据依赖。（难点：管理API间的执行顺序，数据依赖）
场景6：多个API的多次执行，它们之间有执行顺序依赖，也有数据依赖。（难点：管理API间的执行顺序，数据依赖，大量数据的准备和管理，测试执行）
通常，一个系统开发到中期时（比如4个迭代），系统可能会累计超过30个API，它们会包含GET、POST，数据依赖。同时QA需要时时对系统回归，以及通过API对系统数据准备等，并持续这些活动到开发结束。大一点的系统超过100个API也不少见。
场景7：API的数据来源于第三方系统（难点：数据源不可控）
场景7的项目上下文依赖太多，暂时不予讨论。其它6个场景却可以很明确地识别其难点。从量级上讲，假设系统有50个API，平均每个API需要准备和执行正向、负向数据组合为50，则我们有50*50 = 2500个用例。管理这个量级的数据和执行并不是一件容易的事。
API自动化测试的方向
从上面的分析可以看出，2500个测试用例的执行和管理是一个很大的挑战（国内项目通常只有一个QA，而API测试只是QA在项目中众多的测试活动中的一种）。这就是QA面对的问题的特殊性，因为开发通常不会面对这种规模的用例管理与执行。这时必然要通过某种途径缩短Cycle Time，使完成每次测试周期的代价足够小，我们要从分析到执行到报告等各个环节上下功夫。
首先，API测试有天然的Data-Driven的特点，一条数据就是一个用例，并可以直接执行（嗯，没有中间环节赚点击）。
同时，准备这些数据已经有很多方法论及其工具的支持，比如组合测试，等。
在CI/CD成为标配的今天，测试环境一般不成为问题，除非有大量的第三方依赖。
但执行效率有时却成为关键，如果平均一个API执行时间为1秒，串行执行2500个用例则需要2500秒，约42分钟。如果并行执行，则需要考虑场景、优先级及依赖。
考虑到对整个产品的所有API进行管理和执行，碰到的难点就包括但不限于：管理单个API的测试数据以及各类数据变种、执行和报告，多个API的数据、执行和报告，API的依赖，按场景执行，按优先级执行，并行执行，统计结果、性能数据。
通过测试流程改进并不能解决上述的所有问题，这时引入自动化就成为必然。市面上API测试工具很多，这些工具在协议层做到了尽善尽美，同时也提供比较方便的界面。但是面对QA碰到的上述特殊性要求却总显得力有不逮。以几种工具或方式为例：
Postman：用户界面友好，易上手，但API数量和测试数据变多后，管理就很不方便
SoapUI：老牌API测试工具，支持Groovy script对Test Case的定义和管理，对QA有代码要求，与工具强绑定
Programing（比如Java Junit + httpclient，Python pytest，等）：对QA的代码要求高，实施周期长
我们还有什么选择
既然已有的方案和工具不能解决问题，而QA碰到的问题又那么实实在在，也就只有尝试自己梳理方案甚至写新的工具了。这里有两个方向：
一：只解决当前项目的问题，方案与项目上下文强相关。好处是没有多余工作，缺点是方案可移植性差。
二：抽象上面的问题，得到通用方案或者工具。好处是多个项目可重用，但是需要大量的基础性工作，针对特定项目还要在通用方案或工具上辅以针对性的手段。
仔细梳理了上述问题域，根据方向二，经过一段时间的努力，工具Go4Api已经初见雏形：
— Go4Api定义了一种精简的Json格式，自我表达，它包含一个用例、用例间关系和HTTP Request/Response/Assertion等全部信息，同时本身还可以参数化，由另外的数据文件驱动。
— 借助Go语言并发内置的语言特性，Go4Api的调度机制能处理成千上万的用例以及管理它们的优先级、先后依赖、数据依赖、并发执行。
— 面对API测试里多种数据组合问题，Go4Api内置了Mutation Test和Fuzz Test。其中Mutation Test功能能对现有的数据进行多种Mutation（即正、反向变异）并执行；Fuzz Test能根据API及其Fields的定义，通过规则生成数据，并实现了Go语言版的Pairwise算法，对用例数进行有效降低并执行。
— Go4Api还可以对HAR、Swagger API的格式文件进行转化，使之成为Go4Api能识别并处理Json格式。
github repo
Introduction
更多详情请见Github地址：https://github.com/zpsean/go4api
wiki: https://github.com/zpsean/go4api/wiki
go4api能做什么，不能做什么
Go4Api解决了之前所列场景1~场景6所识别出来的所有问题了吗？还不彻底。比如以下两点没有完全支持：
— 如果一个API的数据来源于多个API的执行结果，这种复杂的数据依赖部分支持。
— 一个POST API创建了新的数据，可以通过go4api Scenario功能为它加一个包含DELETE API的Child Case达到 tear down的目的，但是如果系统还没有DELETE API呢？传统的方法是SQL Delete等方式，Go4Api目前部分支持sql形式的teardown。
Go4Api Scope
另外，Go4Api有图形操作界面吗？目前没有看到有界面的必要。但是Go4Api提供了友好的可视化测试报告。
总结
测试是一个系统活动，是否自动化测试以及怎样自动化测试需要全面考虑测试的问题域本身。
自动化执行不等于自动化测试，缩短测试Cycle Time，加快测试反馈周期应该是考虑自动化测试方向的重要因素。在有些场景下，自动化测试数据准备可能比自动化执行带来更多好处。
测试工具不是天生的、也不是万能的，它通常是针对某类测试问题域的解决方案。如果使用不当，误把工具当测试问题，只会练就屠龙术而已，无助于解决测试问题本身。
注：作为验证，Go4Api已经在作者参与的项目实际使用。后续会有文章介绍Go4Api具体的应用场景和实际使用经验，敬请期待。
另外，为啥预览显示很好的小图片发布后变那么大，width调整不生效
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
