?

七牛云发展至今，累积已服务于 70 多万家客户，产品矩阵愈发清晰丰富，围绕富媒体场景推出了对象存储、融合 CDN 加速、容器云、大数据平台、深度学习平台、智能日志分析平台等产品，并提供一站式智能视频云解决方案。而如何保障这些产品的质量，是七牛云工程效率部测试服务一直从事和探索的问题。接下来，我将简要的介绍下我们的具体实践以及一些方向上思考，希望对大家有所帮助。
?

整体的测试策略，我们主要落实到四个方向:?
?
? 保障基础代码质量
? 构建业务测试覆盖
? 增加质量监测环节
? 普及与改进流程规范
?

保障基础代码质量

?
首先明确，产品质量并不是简单的测出来的，它依赖于软件生命周期中的各个环节，且越是早期进行质量保证活动，效果会越好。所以在提测之前的基础代码质量上，我们非常看重。在把控上，我们会重点参与到三个交付物环节的 review，具体包括需求评审、架构评审，以及我们的测试设计评审，确保产品从规划、实现和验收标准上就符合整个团队的预期。
?
同时我们也在推广和探索测试技术应如何更好的自动化保障基础代码。比如我们会通过静态扫描周期性的检查所有代码库，为开发人员提供反馈，让其知道哪里做的有问题。同时通过收集语言层面的编程规范，推广 code review 最佳实践。当然，单元测试层面也会重点强化基础服务建设。
?
在七牛云，核心业务库的单测覆盖达到了 80%+，比如核心纠删码存储系统，自研 HTTP 缓存服务等。同时我们会把单测覆盖率统计自动化做到每个 github PR 的统计上，让大家清晰的看到，本次提交的覆盖率详情如何，为研发和 code review 人员提供清晰指引：
?
?
?

构建业务测试覆盖

?
有了基础代码的质量保障，我们还要从业务角度关注产品质量到底怎么样，做好质检和验收。
?
先说迭代模式，我们在接到研发的提测需求时，首先会检查这一阶段的准入标准，比如单测是否符合标准，代码是否有人 review 过，不符合标准会被打回，符合标准的，就会进入待测试阶段。之后会在充分把握需求的同时，对具体技术实现细节，进行深入理解和分析，在此基础上进行具体测试场景的设计或者补充，再到最终的测试执行。之后研发在拿到我们输出的验收结论时，也要 review 这个结果，是否有明显遗漏。通过这种互相检查机制，再加上深入到代码细节的白盒测试，确保整个交付的质量严格把控。
?
其次在测试执行的具体策略，也是遵循分层理念，不光验收单个服务的接口行为，还要确保多个服务之间的集成测试，以及最终系统层面的场景验收通过。
?
当然除了常规测试手段，在云服务测试上，还有几个点是我们比较看重的。
?
?

常态化并发场景下的测试验收

?
云服务一般都是分布式，高可用架构，我们在测试一个接口时，一次请求没问题，不代表这个接口就没问题。很多时候，问题都需要在并发场景，一定压力下才会暴漏。所以在平时的测试验收上，这一点需要特别注意。当然在过往的经验中，我们也积累较多的 go 语言并发模型及相关测试框架的使用经验，能让我们在平时的迭代中，轻松自如的做到这一点。?
?
?

高可用测试

?
常规的测试验收是保证系统在正常的情形下做正确的事，而高可用测试，考量的则是如果服务所依赖的环境不符合预期了，系统还能正常工作吗？实践发现，在面对多机房，海量机器的场景下，云计算基础设施出问题的概率是非常大的。比较常见的如磁盘损坏、网络故障、机器宕机等等，可能时时刻刻都在发生，每一种故障都有可能引发数据丢失、系统雪崩等重大灾难，对业务造成难以估量的损失。所以云服务的高可用测试尤其重要。
?
有一个很典型的例子，就是我们在验证七牛云存储核心存储引擎的删除回收功能时，需要在测试环境不间断的模拟各种文件的上传与下载，以及随机删除请求，同时还要对整个存储系统注入各种随机的异常场景，如服务挂掉，磁盘损坏等，然后在这样的场景下，连续不间断的测试一个月以上，确保所有预期数据不丢失，不损坏，方才算验收通过。其标准之苛刻，可见一斑。
?
?

尽可能提高测试覆盖率

?
云服务都是服务海量用户，任何的严重错误都是不可容忍的。但是我们知道测试矩阵又是无穷尽的，在有限的测试人力下，不能盲目地投入到无限测试中去。所以在如何提高测试覆盖率方向上，我们也是一直在探索。目前主要从两大方向着手。一是精准测试，我们内部研发了 go 语言的系统测试覆盖率统计系统，能够精确从源码层面反应测试覆盖程度，来辅助我们日常的迭代。另一方面，通过复制线上真实流量来验收每一个版本迭代，确保无回归问题。这一方案，已运用在七牛云 CDN 缓存系统的常规质量保障上，效果显著。
?

质量监测体系

?
前面我们从代码质量和业务验证角度，描述我们如何保障质量。但实践中发现，还有些场景和问题，上述场景并不能很好的覆盖到。比如句柄泄露，内存泄露等问题，这种问题需要一定的时间的发酵，且单纯的从业务角度，感知也不会太明显。而质量监测体系就帮我们解决这个问题，所以我们将业务质量的监测结果提升到常规的迭代验收层面。
?
在平时，我们不仅验收服务的对外行为，还需要关注业务调用链是否健康，服务的自身运行时是否有问题，业务性能指标是否有退化等等。通过这些手段，尽可能的在测试阶段就检出更多的问题，减少问题遗漏到线上的几率。如果说业务验收从用户角度来考虑，那么业务质量监测就是从整个系统端来度量。各有各的优势，在质量保证体系里，二者缺一不可。
?

流程规范普及与改进

?
技术在不同阶段总有其局限性，任何环节出问题，影响产品最终服务客户的质量都是不可容忍的。所以在常规的技术保障之外，我们也会推动和普及一定的流程规范， 确保全流程，各个环节的质量有效把控，比如典型的迭代规范，发布和线上操作规范，以及事故处理流程等等。
?
?

?

牛人说

?
「牛人说」专栏致力于技术人思想的发现，其中包括技术实践、技术干货、技术见解、成长心得，还有一切值得被发现的内容。我们希望集合最优秀的技术人，挖掘独到、犀利、具有时代感的声音。
?
?

原文地址：http://blog.51cto.com/7741292/2159760