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

本文主要是介绍互联网平台测试实战经验分享，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

•引子

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

互联网平台是做什么的？

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

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

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

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

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

互联网平台的发展，也都是从上图的阶段开始的，我们把互联网平台的发展分为以下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，比较容易映射复杂值的环境。