测试淘宝网性能测试时的思考

　　In software engineering, performance testing is testing that is performed, from one perspective, to determine how fast some aspect of a system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage.

　　从技术类型来看，当前主流的技术框架，有C/S和B/S。当然，性能测试也相应的分成这两种。它们的测试方法，是不相同的。

　　C/S架构的系统，性能方面主要关心的是接口，以及数据库端是否能承受得住压力，还有数据库是否存在并发问题。C/S架构形式多样，虽然关注的地方比较单一，但是性能测试非常复杂，针对不同的内容，可能方法完全不一样。在此，不做讨论。

　　B/S架构的系统，性能方面关注的内容比C/S丰富的多。经典的web框架，分三层结构：客户显示层、业务逻辑层、数据库层。随着技术的发展，业务逻辑层又被拆分成很多层次，例如应用层、基础服务层、消息同步层、cache等等。业务逻辑层又可以使用多种中间件实现，比如java开发的系统，会用到 jboss。整个系统的性能，除了jboss，还依赖于apache、网络、数据库性能等。

　　计算机技术已经广泛应用于企业管理、互联网络等方面，相应的也诞生了办公使用的OA系统和大型互联网站系统。笼统可以划分为这两种。例如，人力资源管理系统、移动的信息管理平台，都应该属于OA系统范畴;而淘宝网，应该属于大型互联网站系统，而且是纯粹电子商务方面的。这里，主要是针对淘宝网性能测试的思考。

　　在淘宝，系统架构比上述的轻描淡写更加复杂。针对这么复杂的大型系统，面对每天巨大的流量、巨大的用户群体，如何保证网站的性能?保证网站不宕机?通过性能测试可以解决这些问题，但是，新的问题又提出了，淘宝网的性能测试又该如何入手呢?

　　或许我们很容易想到，通过统计网站的用户量，进行大量用户下的性能测试，就能保证网站的性能。但，事实真的是这样吗?不然。

　　其实，网站与OA系统是有区别的。一个信息管理系统，它是一定能计算出总用户数和使用用户数的，也能比较准确的统计到并发用户数，而且在一定时间内，系统使用的频率一定是不高的。但是，一个超大型的电子商务网站，面对几亿的用户群体，在同一时间，使用用户数是不停变化的，且在同一时刻，即便用户在线，也可能点击浏览的是不同的页面，触发的是不同的请求。如果单从并发用户的角度去考虑问题，进行分析和建模，未必适用。

　　既然传统的策略不能用，我们该怎样去面对呢?我们需要寻找固定不变的东西，从而找到突破点。从互联网的特点出发，可以看到，在线用户是不断变化的，但是页面是固定的。用户U访问了P页面的行为，是能捕获的。换句话，对于页面P，不管当前有100个用户，还是1000个用户在使用，页面的page view是可以统计的。这，就是问题的突破口。通过该方式，可以将页面流量直接转化成page view，做为性能测试的预期目标，而不去care在线用户数和并发用户数。得到这个数值之后，再通过建模、分析，将它转化成测试工具可以衡量的指标，从而使复杂的模型变得简单化。

　　突破口找到之后，接下来的工作就相对容易开展些。搭建性能测试环境、性能测试设计、性能测试脚本编写与执行、结果分析、调优等环节，都有了依据。

　　任何问题的解决，最难克服的就是突破口。

原文转自：http://www.ltesting.net