互联网测试工作，无非两大块，质量和效率，说起效率呢，往往很多人就会想到一个词----自动化。测试自动化在网上一搜，无数相关文章会告诉你接口自动化啊，UI自动化啊，XX自动化啊，笔者甚至见过测试要自动化一切啊。。。每当看到这些，笔者就知道，写文章的人都是没有真正思考过人，人云亦云，毫无主见，自动化真那么厉害软件测试这个工种早就淘汰了。

    说下我对自动化的理解，自动化是一种概念，而不是仅仅是方案，它是解决测试效率的一种思路。那怎么才能借助这种思路解决问题呢，而不是争论在使什么自动化框架好啊，什么好积累啊，什么门槛低啊。。。。

    其实有了自动化思路还是空谈，必须要结合业务场景，团队人员能力等诸多方面综合考虑，下面笔者将在我司实践自动化的思路分享给大家：

    我司用户产品做自动化思路有三个大维度，包括线下测试，上线过程，线上测试。

    先说说线下测试，我们把业务场景和团队分成三个阶段，初创阶段，稳定阶段，突破阶段。这三个阶段基本能够覆盖一款互联网产品的三个主要阶段了，我们一一说来。

【初创阶段】

特点：（产品）方向不稳定，功能和ui变化大。（人员）技术能力弱，全靠测试case补。

解决方案：这个阶段啥自动化方案都白扯，你根本没时间做技术工作，就算有也白做，后续肯定要大改，投入产出比太亏。那怎么办，我们除了加人没有更好的方案了吗？非也，对于土豪公司来讲，加人当然不在乎，但是一般初创公司很难在没看清产品发展的情况下贸然扩大测试团队。笔者是这样做的，让所有测试工程师接不同项目的测试工作，也就是让每个人都做全能选手，然后大家一起分析，哪些项目或业务重复性大，然后固话这块业务的测试case及人力安排，固话的好处是这些case除了测试也可以让产品和研发一起测试，这样团队每个人都是qa，而qa就可以专门去做变化较快的业务。你看看这块我们用到任何一种自动化框架和理论，但是效率是不是也提升了呢，再次强调，自动化是思路，不是方法。

【稳定阶段】

特点：产品大方向及功能已经明确，虽然迭代频繁，但是不会大改。

解决方案：将已经稳定的业务自动化掉，具体选用什么框架，根据各自技术栈来决定，笔者写过php，java的（顺便提一句，自动化框架总有一天要自己写，后续我会说到）。将稳定的业务先把接口自动化搞定，在提测阶段和上线阶段使用，保证研发提测质量和上线质量，qa只关注新功能就好。当稳定阶段业务发展一段时间后，你就会发现新功能/接口的测试量也越来越多，使用自动化框架添加case已经非常耗时了，而且case的编写完全取决于工程师自己的能力（良心），因为同一个case不同人写的力度粗细就会差距很大，有的时候大到case能不能起到作用。所以这时候就需要自动化case的标准化规范，那这个规范怎么写呢？我们写个wiki放上去，跟工程师说，都按这个写，写错打屁股？这无论从执行层面和管理方面都不可行，这时候笔者主导开发了一个自动化case编写平台，接口的入参，接口名填上去就好，针对返回值的校验把主流的case检查方法（也就是assert这些）做成选择项，添加case的工程师只要选择对于某一个自动的检查方法就好，方法比较多，比如：value的类型判断，是int，还是string，还是其他，key和value是否存在，value值是否大于/小于/等于等的判断。这个平台开发后把工程师添加case的时间基本可以忽略不计了。

【突破阶段】

    一般能到此阶段的公司，无论公司业务还是团队，基本已经成型了。笔者看到走到这步的创业公司并不多。这个阶段测试的质量保证怎么做，自动化用什么样的思路做呢？这时候需要的是整体性的思维考虑了，这块笔者展开说就比较多了，我先贴张图，说下现在笔者所在公司做的事情，后续详细再讲。

简单说下这几个平台作用：

解耦平台：这个是笔者公司针对测试环境经常出问题做的，主要解决下游测试环境有问题的情况，也能在上游进行顺畅的测试。

自动化添加平台：上边有介绍，目的是减少自动化添加的成本。

接口diff平台：线上第一台和线上服务的接口diff，目的是在保证数据相同的情况下，新代码和线上老代码相同接口返回数据是否一致，验证即将上线的代码不会影响老业务接口。

上线确认平台：这是从管理角度出发做的，让研发和qa对上线有变更的文件意义确认，确保研发和测试理解一致，解决研发和测试因为沟通不全面的问题。

线上服务接口监控：线上第一时间发现接口问题的利器

问题定位平台：当监控发现一个接口报警之后，qa往往会跟研发说，xxx有问题了，研发还要一顿查，是机器问题，还是服务问题，还是线上代码bug。问题定位平台能够模拟研发查问题的思路，在报警的同时直接告诉研发问题出在哪，这样很快就能修复上线了。