前言

得益于过去几年移动互联网红利，移动测试圈也发展的如火如荼，催生了很多的测试框架，解决方案，甚至测试相关的技术大会。然而云计算测试这块却探讨的不多，原因会有很多，比如从业门槛高，技术一般特性强(非测试专属)，行业中搞云计算的企业也不多等等因素。

笔者近几年一直活动在云计算领域，在此想结合这几年的切身体会，给大家介绍下云计算领域的测试技术体系，以及各自的发展方向。有些跟传统的质量保证方向一样，有些稍有些区别。一家之言，以飨大家。

总起

一定要明确，不管是什么业务形态，所有的测试技术一定是为保障产品质量，提高迭代效率而存在的。这是主线方向，不能丢。所以沿着此条思路，任何产品形态的测试技术发展脉络就都是有迹可循，云计算也不例外。如果我们将产品从代码形态到最终服务线上客户这个过程看成是一条流水线的话，那么保证产品质量的过程基本可分为保障代码质量，构建业务测试场景并不断提高测试覆盖率，到最终的构建质量监测与评估的全套闭环。每一步都是有足够的纵深可以挖掘，每一步做好了都会非常出彩。

保障代码质量

很多传统企业甚至外企，测试作为质量保证的最终一环，在追求高质量的前提下，会将测试这一环建设的比较重。研发测试比一直居高不下，有时可能会达到夸张的2比1，甚至1比1的情况，然而，在日益严重的人力资源成本下，这种模式很明显难以为继。同样在云计算领域，这种模式更加的不可能。云计算技术为了应对海量用户，高并发场景等，会广泛的使用分布式技术。服务的多实例化，天然的支持灰度升级。在这种模式下，小步快跑，快速迭代才是王道。

同样在这样的形式，利用有限的测试人力，去获得更大的质量保证成果，就成为必然，这也是我们一直思考的方向。在此形势下，质量必须是全员建设，且围绕业务质量，将质量保证体系前移，是我们探索出的一个非常有利的手段。而生产高质量的代码，就是其中非常重要的一环。那么如何保障代码质量呢？笔者认为，通常绕不开以下三个方面: 构建语言的编程规范，能够快速检测语言层面的代码缺陷，以及构建强大友好的单测服务支撑。

构建语言的编程规范

所有的工程师都明白，遵守良好的编程规范对保证代码质量，加强团队协作具有不可估量的价值。大多数语言，围绕其语法语义层面都会有基本的编程规范推荐, 比如go语言的gofmt。同样，作为代码可读性考量，业界也会有其通用性的规范。这一块的落实，大家多数是通过Code Review方式来进行。当然也有做的比较好，直接落实在工具，IDE层面，比如阿里巴巴，不光出了JAVA开发手册，还同时配套主流编程工具IntelliJ IDEA，eclipse的相关辅助插件。

我们做质量保证体系的，这块就非常有责任去相应的推动落实，以更好的工具化，服务化的方式提供给大家使用。不一定每样都要自行研发，最好结合公司的研发资源，以最佳实践方式来落地。这块搞好了，不光有实际收益，对团队，公司的技术影响力也会有很大的提升。

检测语言层面的代码缺陷

同样，语言层面的静态分析，也是检测缺陷的有力手段。不同于传统测试手段，静态分析可以在不运行代码的前提下，通过一定的词法分析，语法分析等来快速检测代码的规范性，安全性等问题。这类工具的一大特性就是快，可以想想，如果我们能提供一个比较好用的类似工具，在工程师提交PR时，就检测到他们代码中的问题，工程师立马改正，这种效率可就远胜于集成测试阶段发现问题然后再改了！

不过搞静态分析难度系数较大，且很多时候准确率不高，要想做好这块，需要有较大的技术投入才行。

构建强大友好的单测服务支撑

搞质量的多数都熟悉测试金字塔理论，应该知道单测的投入产出比是最大的，所以从如何促进研发写单测角度，来进行一定的工程投入是非常值得的。甚至采用一些商业服务，也不为过。比如我司，所有的代码都托管在github上，单测跑在travis里，非常方便。

除此之外，我们还可以考虑出一些单测工具，最佳实践，各种例子来辅助，教习研发写单测。实践发现，很多时候并不是研发不愿意写单测，而是其不会写，又或者发现写某些单测的投入较大，于是他们就放弃了。而这些都应该是质量体系要解决的问题。

好的单测服务，不光是辅助研发如何写单测，同时也可以起到激励作用。比如，如果我们将单测结果能友好的量化出来，去推动不同研发之间的比拼意识，服务之间的比拼意识，甚至团队之间的比拼意识，那么就能起到非常好的良性促进作用。

这块整体的难度系数较低，收益又很明显，应当做为质量保证体系中很重要的一环去建设。

构建业务测试覆盖

前面谈了主要从如何保证代码质量的角度，提出了3个测试技术发展方向。但光关注代码这一层一定是不够的，我们还应该从业务角度去关注我们的产品质量到底如何。这个阶段是绝大多数QA人员比较熟悉的。可能不少QA同学会把这个阶段说成API测试，集成测试等，但这是动作。我认为这里主要应该强调目的，所以我把该阶段抽象为构建业务测试覆盖。我们不断的测试或者写自动化，其目标就是尽可能的覆盖各种业务场景，各种新需求，避免发布到线上出问题。

这块的测试技术发展上当遵循两大方向: 接口自动化，故障注入。

构建接口自动化

绝大多数云计算服务都是通过API方式，对外暴漏，所以从业务测试角度，我们就需要通过调用这些API，模拟业务请求来测试这些服务。在实际场景中，为了做好这些，通常需要一套完善的自动化测试框架，当然实操上也比较简单。不管哪个测试框架，主要解决以下问题，比如，需要好用的Http客户端来发送HTTP请求和处理Response，方便灵活的Assert库，测试用例的组织和执行。这是基本的需求，当case数量到一定量级，还需要做完善的测试报告，统一的log方便定位问题，以及灵活的业务SDK。

测试框架不建议从头自己写，选择热门开源的项目可以快速的开展工作。比如，go语言，就可以使用Ginkgo+Gomega+Gorequest+Glog的组合。

云服务接口因为要应对海量并发场景，单纯的功能测试需求，不够完善，还需要针对每个接口进行高并发测试。笔者之前分享过一篇GO并发编程实践， 里面的例子都可以融合到这些测试框架里，方便在实际的迭代中使用，以提高效率。稍加改造这些例子，完全可以应对更高的并发场景，以及基准测试等需求。相对与jmeter等工具会轻便很多。

另外，还有些公司因为绝大多数测试同学都是手工测试，为了提高这部分同学的效率，可能会专门为他们做些更简易的封装，提供UI界面。这些属于锦上添花型，在绝大多数QA同学都是测试开发的云计算行业，有点鸡肋，不建议花太多精力在这个方面。

不过，所有的这些方式其实都是常规的测试模式，需要人工一条条的补充业务测试场景。但是人就有可能犯错，有可能遗漏测试场景。并且在常规的迭代中，多数同学比较容易关注新需求，有时候就会遗漏旧有的业务场景组合，容易造成回归问题遗漏。所以针对接口自动化这个方向，如何能更好的提高业务测试覆盖率，才是需要QA同学持续探索的。

此方向，笔者将会在下篇中更深入分析，此处按下不表。

引入故障注入机制

说到云计算的测试技术，就不得不提起Fault Injection。前面提到的接口自动化，思考的逻辑是从业务角度，保证系统在正常的情形下做正确的事。但还里，还有个很大的问题就是如果服务所依赖的环境不符合预期了，系统还能正常工作吗？

实践发现，在面对多机房，海量机器的场景下，云计算基础设施出问题的概率是非常大的。比较常见的如磁盘损坏，网络故障，机器宕机等等，可能时时刻刻都在发生，每一种故障都有可能引发数据丢失，系统雪崩等重大灾难，对业务造成难以估量的损失。云计算系统需要在各种故障场景下仍能正常工作，做到高可用，高可靠需要投入巨大的精力。同样，如何更灵活验收这些场景，如何能模拟更多的故障场景，也是测试技术需要投入的巨大课题。

好的故障注入方式一定是朝着Simulate everything automatically, and be able to reproduce the fault again方向去的。从常规的服务挂掉，到机器宕机，坏盘，磁盘高负载，网络延迟，丢包，不通等等情况，通过工具或者命令我们都可以手动模拟的，但是模拟一次系统不出问题，不代表就一定不出问题，云计算的复杂业务调用关系就决定了故障注入必须是常态化的运行，这样才能在长时间，高频次的测试下，增大问题检出概率。所以故障注入系统应该构建成自动化的方式，并且每次执行还要记录详细的故障注入步骤，这样在检测出问题时，方便复现和修复后的再次验证。

质量监测体系

前面我们从代码质量和业务验证角度，阐述了云计算测试技术的几个方向。但实践中发现，还有些场景和问题，上述场景并不能很好的覆盖到。比如句柄和内存泄露等问题，这种问题需要一定的时间的发酵，且单纯的从业务角度，感知也不会太明显。再比如，前面说到的故障注入，那故障发生后，如何判断系统是否工作正常？如何判断一个故障对系统的影响范围？这些问题必须明确，因为只有这样，我们才能更好的分析问题，明确问题的修复优先级。

实践发现，要解决上述问题，我们还需要构建完善的质量监测体系，辅助做好业务质量的测试和评估。

业务质量监测

为了更好的运营系统，服务客户，所有云计算系统一般都会有一整套的线上监控体系。但在测试环境同样运营这一套系统的却很少，我认为这是很大缺失的。测试环境我们可以不照搬线上完整的一套，但是入口级的业务质量必须要有。这样在做故障模拟测试时，就可以及时的感知系统的整体质量。同样上面提到一些服务本身的内建质量也应该加上，比如内存，句柄等等。真正能在集成测试和灰度验收时，检测到更多的问题。

传统的验收测试，比较关注业务本身的”true与false”,但在实际生产的复杂场景，还有更多的指标需要关注。比如响应时间。如果说业务验收从E2E角度来考虑，那么业务质量监测就是从整个系统端来考量。各有各的优势，在质量保证体系里，二者缺一不可。

云计算测试技术体系图

总结我上面描述的测试技术体系，可以用下面这个图来概况:

里程碑

很多时候，很多测试团队会做着做着，把自己做成人力外包团队，输出QA 人力 Resource，这是是非常low的。七牛的CEO老许曾说过，七牛的所有团队都应该是产品团队，包括HR。Can’t agree more!! 我认为理想中的测试团队不光要拥有业务质量的全局视角，还要能深入到业务构建的底层技术细节，然后围绕业务质量方向，打造核心产品或平台，以此来提供高价值的质量保证服务。测试不在于人，而在于服务。测试服务不是测试同学的玩物，应该是围绕解决如何保证业务质量的难题。同时，单个人，或者单个组织来做质量保证必有其局限性，质量全员建设才是王道。

需要明确的是，上面总结的是测试技术体系，并不是完整的质量保证体系。完整的质量保证体系，不光有技术层面，还要有一定的流程规范来约束。

另一方面，要达到我上面所说的测试技术体系，常规的测试团队很难完成，而应该结合基础设施团队共同构建才能达到。这里不是常规的缺乏质量sense的基础设施团队，而应该是真正的Test Infrastructure Team。

童鞋，点个赞吧(⊙o⊙)？

Contact me ?

Email: jinsdu@outlook.com

Blog: http://www.cnblogs.com/jinsdu/

Github: https://github.com/CarlJi

知乎: https://www.zhihu.com/people/jinsdu/posts