互联网平台测试 实战经验分享

•引子

其实以下问题，没有标准答案，但是看完本文后，会有概念。

互联网平台是做什么的？

互联网平台软件测试和其他软件测试有什么区别？

好了，让我们带着问题来看一下：

互联网公司的被测系统架构及特点如何？

•     分布式
•     高并发
•     高可用
•     集群
•     负载均衡
•     海量数据
•     系统安全

其实，互联网公司现在看起来这么大，业务这么复杂，但是在互联网初期，大家也都做的很烂，以下是淘宝网第一版：

互联网平台的发展，也都是从上图的阶段开始的，我们把互联网平台的发展分为以下4个阶段：

•  【初创期】要求功能新，能买就买，有开源的就用开源的，能模仿的就模仿，甚至可能是能偷就偷。
•  【发展期】要求能够快速迭代，功能不停的加，系统互相依赖增多，经常牵一发而动全身。随着用户量的增加，性能问题逐渐浮出水面。
•  【架构期】为了解决依赖的问题，为了解决用户增加导致的性能问题，开始拆分业务，拆分服务器，拆分数据库，重新架构。
•  【成熟期】出现了更加清晰的业务架构，更方便的第三方接入和运营策略，极少出现重复造轮子的情况，内部系统也使用平台进行管理。

发展到现在各家互联网平台的架构（无论是业务架构还是技术架构），都比初创期相对复杂的多：

支付宝架构：

美团架构：

大部分第三方支付架构：

复杂的架构，都是从需求发展过来的，为了实现业务架构而重构技术架构，是再普通的事情了，我们可以看看随着业务发展，互联网平台是如何一步一步发展到现在这种架构的：

上图这种将所有功能都部署在一个web容器中运行的系统就叫做巨石型应用。

巨石型应用有很多好处：IDE都是为开发单个应用设计的、容易测试——在本地就可以启动完整的系统、容易部署——直接打包为一个完整的包，拷贝到web容器的某个目录下即可运行。

但是，上述的好处是有条件的：应用不那么复杂。对于大规模的复杂应用，巨石型应用会显得特别笨重：要修改一个地方就要将整个应用全部部署(PS：在不同的场景下优势也变成了劣势);编译时间过长;回归测试周期过长;开发效率降低等。另外，巨石应用不利于更新技术框架，除非你愿意将系统全部重写(代价太高你愿意老板也不愿意)。

那时的配套数据库部署也是单机的方式：

后来发展到应用服务器和数据库服务器分离：

由于用户量的增加，单台服务器已经无法满足请求，开始使用应用服务器集群：

数据库成为瓶颈，发展出数据库拆分，NOSQL崛起：

NoSQL数据库的四大分类

键值(Key-Value)存储数据库

这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。举例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.

列存储数据库。

这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra, HBase, Riak.

文档型数据库

文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。

图形(Graph)数据库

图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。如：Neo4J, InfoGrid, Infinite Graph.

因此，我们总结NoSQL数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。

无论是传统SQL还是NOSQL，都要向分布式存储发展，但是无论如何，一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个：

一致性(Consistency) (所有节点在同一时间具有相同的数据)

可用性(Availability) (保证每个请求不管成功或者失败都有响应)

分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

Redis通过goosip来同步消息，以达到最终一致性：

Mycat数据库主备：

系统越来越复杂，单一的数据库已经无法满足业务需求，架构师为了能提供能多的用户支持，也为了解耦服务，开始使用微服务架构(此处举例为Dubbo)：

 

服务器需要分流，对应的LB也分层，DNS，F5，LVS，Nginx，Haproxy等等：

总体来说，目前的架构带来了以下好处：

读写分离带来更强的数据库负载和容灾能力

垂直拆分使多种数据库产品混用成为可能

水平拆分使数据库具备扩展能力

NOSQL作为缓存能大幅度提高数据库响应能力

标准化
 

从这里，技术架构有了具体的原则，需要考虑的方面包含且不限于有以下几点：

由此带来测试流程变化：

传统的测试方法仍然在宏观上起作用：

快速迭代下的多元化测试：

• 需求评审
• 开发设计评审
• 接口验证测试（联调）
• 功能测试
• 接口自动化回归
• 功能测试回归
• 准生产验证，生产验证
• 根据开发更改进行性能评估，做性能测试

由于互联网平台的需求响应快，对应敏捷开发的敏捷测试也发展起来了：

• 每天持续集成
• 自动化回归
• 版本修改点分析
• 修改点影响范围分析
• 针对性的功能测试
• 自动化脚本修改
• 分析bug

各个微服务测试的共通部分，促进了测试平台化的发展，很多大型的互联网公司都有自己的测试平台：

综上，由于近年来DevOps和TestOps的发展，互联网时代的测试更加系统化，更加追求效率。