51Testing软件测试论坛

标题: 典型网站测试案例分享 [打印本页]

作者: higkoo 时间: 2008-9-28 21:10
标题: 典型网站测试案例分享
WEB的性能测试在性能测试里应该是最多，一般网站多有以下需求。

先以简单的开篇（博客/论坛等后续再讨论）：
若某公司网站仅有此需求：
有1000万用户，日访问量（PV）为5000万。

接下来，你会怎么做？

[ 本帖最后由 higkoo 于 2008-9-30 12:32 编辑 ]

作者: higkoo 时间: 2008-9-30 12:30
标题: 我的想法：
性能测试，目的就是为了测试系统是否达到预期指标。
  比如：
1. 能保证5千用户同时在线。
2. 2百用户同时登录响应时间不超过8秒。
3. 1周内能处理完成3千份表单。
4. 在1年后是否上述指标的对比。
5. ……
  需求因各人而异，万变不离其中。无非就是很多人去做很多事情，不同系统的处理和业务不尽相同。我们要做的，就是要分析系统运行过程中可能会出现的各种情况。然后，逐个去验证系统是否能应对这些情况。
  抛开业务、逻辑，把整个过程简化：

[attach]46243[/attach]
  图中“动作块”为与服务器交互的一个时间段，应用在具体业务里可以是一个用户的整个登录过程，也可以是某一个动作的响应过程。
  “吞吐量”图中定义为单位时间内完成“动作块”的数量。
  整个曲线描述了一段用户（动作）加压的过程，可以是一个系统的真实场景的一部分，也可以是测试过程的一个场景。
  图中可以看出，随动作块的不断增多，动作块持续的时间不断变长。
那么，怎么衡量这个系统的性能呢？上图说明了以下三点：
  A. 当动作块为一个动作时，动作块的长度即为响应时间，响应时间为一个衡量标准。
  B. 吞吐量曲线图中没有划出来，吞吐量就是衡量系统处理能力的重要指标。
  C. 并发数也是系统的一个处理能力，是为了保证系统能正常运行不被压垮。

  得出这三个指标后，与系统的需求进行对比。如果各项指标都远超预期值，那么恭喜你，系统性能非常棒。

相反，如果这三个指标有（都）不能达到的，那么不多说，赶紧去调优吧。

还存在一种情况需要进一步分析的，各指标和预期值高出不多。

譬如：按最大吞吐量计算，系统有能力在规定的时间处理完规定的事情；系统能承受最大并发用户数。
但是，用户数最多的时候是否吞吐量也是最大呢？如果不是，差别有多远？
为什么要问这个问题？满足了还不够吗？

当然不行！若大用户量会导致吞吐量下降明显，那么可能会导致系统在指定时间不能完成任务喔。
这时，存在风险！建议先调优。此时需要对系统的真实运行情况进行评估：
* 若业务经常会集中处理（波峰波谷交替），那么系统真实运行时是达不到最大处理能力的。高风险！
* 若业务处理基本平缓（波动不明显），偶尔出现波峰，那么OK。低风险。
* 若情况比较复杂，应结合高压力下的吞吐量进行计算结合实际情况下给结论或建议。
* 若情况不清楚，那么风险也是很大的，还是尽量搞清楚吧。否则就不要下结论了，描述一下在指定条件的反应。

以上是我个人的心得体会，若有不正确的地方，欢迎批评指正。

也欢迎大家勇跃留言，发表自己的看法和意见。

作者: zasdsd 时间: 2008-10-22 22:01
标题: 这个让我想起了奥运官网
前段时间正好听老师说过奥运官网的崩溃，现在看到你的帖子，受益良多，

作者: zy-cumt 时间: 2008-10-23 09:03
受益匪浅，我也想起了奥运的售票网站，从楼主那里获取了感性的认识，谢谢分享

作者: liaogd 时间: 2008-10-23 15:05
支持

作者: SMALLCAI 时间: 2008-10-23 15:10
不错的帖子

作者: meimei_0 时间: 2008-11-4 14:55
看了，但还是一头雾水，我真是绝对的新手啊！

作者: lylus 时间: 2008-11-5 09:59
受用，支持！！

作者: zhanjiezhan 时间: 2008-11-5 10:30
谢谢分享

作者: archonwang 时间: 2008-11-5 11:59
业务分析的过程很必要，问题是如果之前没有旧有系统的参考，你会怎么做？

楼主，网络拓扑如何？采用何种架构？

[ 本帖最后由 archonwang 于 2008-11-5 12:01 编辑 ]

作者: higkoo 时间: 2008-11-15 23:25
标题: 回复 10# 的帖子
此图只是抽象出压力的分布，不涉及到细节上的问题。

无论采用何架构、网络结构。抽象分析压力结构是第一步。

作者: higkoo 时间: 2008-11-15 23:30
标题: 补充说明：
此模型更适合于没有历史数据的系统。

有历史数据或可参考数据的系统，应结合实际情况确定压力的范围。

画这张图的目的实际就是：
1. 抽象出负载测试的过程。
2. 提供衡量应用程序能力的参考。

作者: cxxhanxue 时间: 2008-12-18 17:52
学习

作者: 杀手要低调 时间: 2009-1-7 11:59
学习

作者: polly12052000 时间: 2009-1-8 18:44
阅读学习一下

作者: xiahuaoxiang 时间: 2009-5-18 08:54
???

作者: nuanhuakai 时间: 2009-11-10 22:09
en 学习了

作者: kekebaobao 时间: 2009-12-18 15:48
xuexile

作者: freedom_me 时间: 2009-12-23 15:24
不怎么明白·还是要感谢lz

作者: 小不点蜗牛 时间: 2009-12-25 18:48
有意义，置顶楼主

作者: xinyuan9270 时间: 2011-7-21 09:11
期待呵呵。。。怪不容易的

作者: wzfxf227 时间: 2011-7-21 11:16
我的做法：
在有旧系统可调研的情况下，分析系统访问日志，得出TPS指标（包括峰值和均值）；响应时间是个主观的东西，可以由设计人决定；并发量是产生TPS的方法，不是衡量系统能力的指标，只是在执行过程中的一个递增值，在递增过程中，衡量TPS和响应时间的达标情况。即时性能达标的同时也要有稳定性测试做保障，以满足日业务量以及更长时间业务量稳定发生的需求。

在没有旧系统可调研情况下，则完全是系统的并发压力测试，衡量系统能够达到的最大TPS，再根据能够达到的TPS衡量是否可以完成日业务量等需求。在这个过程中，可以得到极限TPS指标，可以满足日业务量的TPS指标。

靠并发量衡量能够满足的用户量没有什么依据，根本原因在于业务特点的差别造成了用户量与并发量间的不确定性。

作者: yandaju 时间: 2011-8-4 15:00
还是挺不错的。

作者: 106911611 时间: 2011-8-9 14:57
看看

作者: JOzyJO 时间: 2011-11-7 09:44
谢谢分享

作者: cye_30 时间: 2012-1-12 19:13

作者: gyl0825 时间: 2012-1-13 14:11

没看懂，还是很感谢楼主

作者: woddebbmm 时间: 2012-3-2 15:25
我想起了火车票订票系统。。。。。

作者: wenshichan 时间: 2012-4-7 17:32
阅读阅读

作者: 2351112831 时间: 2012-5-31 10:29
有学到东西了

作者: lixl99999 时间: 2014-12-24 16:34
脚本

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)