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

发布新日志

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

    2008-05-12 13:55:27

    by jack

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

  • 扩展LoadRunner功能的一种实现思路

    2008-03-18 23:50:07

     

       附件是以前在电信临闪之前想到的一些IDEA,由于时间关系,没有来得及实现。呵呵,供各位碰到同类问题的同学参考。

       具体的实现思路可以和我再交流.

     

       ppt 在BLOG无法上传,请移步

    http://bbs.51testing.com/viewthread.php?tid=108978&pid=916217&page=1&extra=page%3D1

  • Oracle NCA协议的检查点函数

    2008-03-18 13:59:56

    int nca_obj_status ( LPCSTR name );
    LR录制NCA协议和HTTP协议所用的函数还是有所不同的,在检查点函数方面,nca_obj_status和web_reg_find有类似功能。首先对象识别,返回对象的状态后,然后进行判断

    example:

    int status;
    nca_set_window("tgbrg4100m000 : Maintain Project Models [550]",100);
    nca_obj_wait_info("Models", "focused", "1",100);
    status= nca_obj_status("F1_gwindow_multiocc");
    if (status == E_OK)
           nca_menu_select_item("Edit;Delete Ctrl+Delete");
    nca_set_window("ttstpq0102 : Maintain Project Models",100);
  • 项目是否开展性能测试考虑的一些纬度

    2008-02-26 22:57:18

     


    平常性能测试时经常要权衡的角度,供大家参考

    1 项目流量:高吞吐率/高并发用户

    2  项目重要性:关键应用 or 一般应用
             关键应用如:支付 等与敏感数据打交道的   
    3  项目发展阶段:已经通过功能测试 or 已经平稳运营

    项目软件架构: 单机版,两层架构,N层架构
             一般而言多层架构且部署复杂更易于出现性能问题。
             
    项目自主研发代码的比重: 高 or  低
             采用成熟组件或者框架,且有专业人士辅助,则性能问题概率低些

    4 软件性能模型
             close /open/batch
             close:即业务吞吐率与用户量保持在一定可控的范围内,如银行营业厅
             open: 业务吞吐率与用户率变化幅度大,可能出现瞬时极限高峰,如无联网应用
             batch: DSS, 如电信经营分析系统。 用户数少,但历史数据量大,可忍受的响应时间长

             一般言,batch性能测试迫切性低
242/2<12
Open Toolbar