记录阿里巴巴QA架构组成长点滴。2008年关键词为效率,技术,影响力!QA/测试架构师定义:开发和设计测试框架测试库;纵横全局的考虑产品的功能,设计复杂的测试系统;负责研发某一项特定的测试技术;为公司考虑如何提高测试效率。领导公司测试技术的发展和测试策略上的方向,关注整个公司的测试部门的问题,前瞻性的考虑未来的版本的测试策略和技术。测试架构师计划/设计测试平台,关注着产品的测试过程,提供咨询服务,影响到公司内的测试机构测试社区,以及开发机构等,对产品各个方面施加深远而正确的影响,最终提高整体软件质量。

注意性能测试脚本运行受业务流程的影响

上一篇 / 下一篇  2008-05-12 13:55:27 / 个人分类:性能测试与容量规划

by jack

    前一阵在做一个日文网站的性能测试。脚本设计好后,发现单个脚本调试有时能通过,有时又通不过(通不过时检查点找不到);通过手工操作是没有问题的。当时由于界面看不懂(日文,汗啊~),所以一时没有搞清楚是怎么回事。曾怀疑该应用性能有问题(代码陈旧,性能确实不好)
    经过翻译后了解到,通不过的情况下出现了一个错误页面,页面上有一行出错的提示,而该提示的内容就是“出错了”(没有具体错误信息,再汗~)。该脚本是一个论坛上回复帖子的操作;忽然灵机一动,猜想会不会是一般的那种论坛防灌水机制——连续操作过快就会抛出错误呢?为验证猜想,做了如下试验:一、在脚本中回复动作前加入60秒的think time,连续循环运行一百次,结果发现没有再出现通不过的情况;二、修改脚本每次运行时重新登录其它帐号,也就是使用不同帐号来回复贴子,结果发现也没有再出现通不过的情况。手工操作只所以不会出问题,是因为手工操作的时间比较长,超过了防灌水限制的时间。
    从上面的试验结果来看,可以想到的解决方案有:1.加入think time或pacing使运行时间间隔大于防灌水限制的时间;2.不断更换帐号登录。两种方式实现不同,产生的压力有异:方案1虽然解决了防灌水限制的时间问题,但由于时间间隔拉长,可能产生的访问压力便达不到要求了,而为了让压力达到要求再增加并发的数量也是不合理的;方案2可以保证产生的压力可以方便的控制,但每次回复动作同时也带上了登录操作,登录操作如果在同一服务器上,则产生了与回复同量的登录请求,可能不符合具体业务的压力要求。还有一个办法就是从代码上修改,将限制去掉或将时间缩短到脚本不会触到的底线。
    可以看出,在性能测试脚本的设计时,一定要考虑好业务本身有没有什么限制使得连续、并发的操作收到影响,因为这些都可能导致脚本运行抛出错误而原因与服务器无关。这类限制一般有单位时间内对操作量的限制、操作超时的机制等。


TAG: 性能测试与容量规划

 

评分:0

我来说两句

日历

« 2024-03-20  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 152917
  • 日志数: 163
  • 文件数: 1
  • 建立时间: 2008-02-26
  • 更新时间: 2008-12-10

RSS订阅

Open Toolbar