发布新日志

  • 如何对测试人员进行考核

    2009-02-01 16:58:02

    本人很懒,一段时间没有更新日志了,今天是牛年上班第一天,没什么事情,就写写一些感想吧。

    我目前管理着研发团队,因为公司不大,人员没有什么流动变化,但我仍然坚持每个季度对员工进行一次评价,一方面我自己了解员工适合做什么事情,另一方面使员工了解自己的不足和提高方向。

    因为这是测试论坛,我只谈谈测试人员的考核。

    测试人员的考核主要是三个方面:第一,工作成果;第二,工作效率;第三,过程改进。

    一、工作成果

    为什么把工作成果列为第一位,因为公司的效益是要靠成果体现的,以结果论成绩是比较容易实现和接受的方法(虽然也有争议,比如“没功劳也有苦劳”)。

    1、数量指标

    遗留BUG比例=用户发现BUG数/测试人员发现BUG数。这里我只考量比例,不注重BUG绝对数量,原因有二,一是开发人员的素质导致不同模块的BUG比例不一致,二是不同模块的难度也不样,不能因为测试人员分配工作的不同而造成成果的差异。

    2、质量指标

    遗留BUG严重程度比=用户发现严重BUG数/测试人员发现严重BUG数:用户发现一般BUG数/测试人员发现一般BUG数。如果这个比例越大说明测试的质量越低,测试人员应该尽量消除严重类的BUG。

    3、效能指标

    效能指标=被拒绝的BUG数/测试人员发现BUG数。因为我规定测试人员把所有BUG首先提给我,由我分配给开发人员,当我发现不是BUG时都会直接拒绝掉。被拒绝说明测试人员对需求、测试案例、公司产品的理解不够。有一个新来测试人员,上一个项目,发现10个BUG,6个被我拒了,之后的一个星期就被我辞退了。

    二、工作效率

    公司的效益也来自于效率,因为产品的推出和项目的实施都有一个时间期限,越早发现问题对公司的整体产品质量是有很大益处的。

    1、进度偏离率

    进度偏离率=实际测试时间/计划测试时间。这里要注意一个问题,因为产品开发和BUG的修复是开发人员负责的,因此开发人员的开发质量和进度会严重影响测试的时间。

    2、发现严重BUG的时间率

    时间率=到最后一个严重BUG为止的实际测试时间/实际测试时间。BUG的发现是越早越好,这是大家都知道的原则。因为严重BUG对系统的设计和需求可能都有影响,因此测试人员也应该以提早发现为要务。

    三、过程改进

    测试也是一个不断完善和进化的领域。如果测试人员能提出有效的工作改进方法,说明他是一个会思考,值得培养的好员工。

     

    最后,我用四象限法把每个测试人员的考核结果标注下来,一目了然。

     

  • 电信分拆的后果

    2008-02-15 16:05:33

        最近发生了一件事,才让我了解到电信分拆后的痛苦。

        某产品经过我们性能测试后给客户使用,客户却抱怨系统性能很差(页面响应慢),我们经过客户调查发现,北方各省使用正常,而南方多省均反映性能差。至此,拍脑袋就想到了,这是网络的原因,北方归属网通,南方归属电信,而服务器是挂在网通的。

        上网一查,原来网通和电信互相制造壁垒,导致它们之间的互通有点“便秘”。这也算是分拆的后遗症。

     

        PS:最后,通过负载均衡解决了这个问题。

  • 不要把LoadRunner当万能工具

    2007-08-09 14:17:11

    近日看论坛,发现很多坛友在问LoadRunner如何录制客户端的操作(如弹出框)。其实大家误解了LoadRunner的功能,还是需要从原理上了解LoadRunner,才能用好它。

    1、LoadRunner录制脚本时是基于网络协议的(如HTTP等),如果仅仅是客户端的操作,没有网络通讯,LoadRunner是无法获取的。

    2、LoadRunner是做性能测试的,因此一些操作即使无法录制和回放也无所谓,可以通过think_time来代替。

    3、如果业务逻辑实在需要回放(参数化)客户端操作,可以通过QTP来做。

     

     

     

  • LoadRunner学习笔记一

    2007-08-08 16:31:02

    最近做了公司产品的一个简单性能测试,使用的是LoadRunner,第一次用难免遇到问题,不过现在都解决了。

    一、Think Time
    录制脚本时有think time,但在做并发测试时不需要,可在Run time setting中ignore它。
    (注:Generator和Controller的scenario中都有Run time setting,在执行场景时以场景中的设置为准。)

    二、网页验证
    录制的脚本并不包含网页内容的验证,需要在Generator中手工添加,步骤如下:
    1、打开树视图(View Tree)

    2、选择要验证的网页

    3、在Server Response中选择要检查的文本(如success)

    4、右键单击并选择“添加文本检查(web-reg-find)”

    5、在脚本中此网页请求之前生成一条语句web_reg_find("Text=success", LAST);

    三、用户登录的参数化
    由于系统不允许重复登录,因此在创建VU时必须选择不同的用户。步骤如下:
    1、首先在Generator脚本的参数列表中,定义参数username,并添加值列表{U1, U2, U3}

    2、设置select next row为Unique,Update Value on为Once

       其中Unique保证不同的VU选择不同的username值,Once保证在不同的iteration使用同一值。

    3、在Controller的scenario中选择VU数为3。

    运行时三个VU分别选择U1,U2,U3登录。

    四、集合点
    为了测试某个页面在50个并发的处理情况,需要在此页面前设置集合点。步骤如下:

    1、在Generator中页面前选择Insert->Rendezvous,输入集合点名称。

    2、在Controller中scenario->Rendezvous可以定义集合点的VU

    五、监控系统资源
    添加一个Windows XP机器后,总是报“拒绝访问”,在查阅了网上大侠们的解决方案后,按照以下步骤解决:
    1、在目标机器上开启Remote Procedure Call(RPC)和Remote Registry Service两个服务

    2、在目标机上共享C$

    3、在controller的机器上运行"\\监视目标服务器IP地址\C$"


    六、分析

    执行完毕后,在Controller中选择Results->Analyze Results分析执行结果。

    1、在Average Transaction Response Time中反映了交易时间。

    Min:最小服务器响应时间;Mean:平均服务器响应时间;Max:最大服务器响应时间;StdDev:事务处理服务器响应的偏差,值越大,偏差越大;Median:中值响应时间

    开始对Median和StdDev不理解,查阅了书籍才知道。

    Median:返回给定数值集合的中位数(它是在一组数据中居于中间的数。换句话说,在这组数据中,有一半的数据比它大,有一半的数据比它小)
    StdDev::估算样本的标准偏差。它反映了数据相对于平均值(mean)的离散程度。计算方式参见《概率论》。

     

    2、在Web Page Breakdown可查看每个页面的响应时间以便进行问题定位。

     

     

     


     

     

  • 缺陷管理小工具

    2007-05-24 16:19:39

    最近准备做一个缺陷管理的小工具在公司内部用,先记录在案。
  • 测试自动化初步

    2007-05-21 17:31:17

        经常有人提起测试自动化,认为它是一个提高测试效率的“银弹”,我认为是高估了测试自动化的作用。在什么情况下不适合做测试自动化,已有多文论述,本人不再赘言。

        近日做产品测试时,又勾起了我做自动化的意愿。起因是产品增加了一些功能,并修改了一些数据库表结构,我们需要测试这些增加的功能。为了测试而做的环境准备花费了半天时间,因为产品的定制化程度很高,使得最初的配置耗时而复杂。实际这部分功能完全可以通过自动化来提高效率和正确性。

        实现自动化的方法有几个:

    • 通过录制脚本,用成熟的自动化工具(如QTP)来做。缺点是复杂而缓慢。
    • 直接写数据库脚本;由于是公司内部的产品测试,所以这么做也是完全可能的。缺点是不宜理解。
    • 自定义一个小工具,控制数据库脚本中的可选参数。

        OK。最后就选用第三种方案了。

       

  • 列表的测试

    2007-05-18 10:46:59

    在测试列表类的功能时,如果列表中的数据存在不同类项,需要在测试案例中设计不同类项混杂的情况。
  • [论坛] 测测你的职业类型

    2007-04-11 11:11:08

    看看你的职业类型,很准的。

    注意:测试时要不加思索,快速完成。

    测测你的职业类型.doc
    (2007-04-11 11:04:24, Size: 26.5 kB, Downloads: 0)


    测试答案.xls
    (2007-04-11 11:04:24, Size: 18 kB, Downloads: 0)

  • 产品回归测试

    2007-04-03 12:12:28

        近日,公司的产品做了一次代码移植,需要为移植后的产品做一次回归测试,以保证其可用性。基于公司测试现状,我制定了公司的回归测试管理指南。

        回归测试过程指南

    一、目的

        回归测试作为产品使用过程中的bug修正或者功能改进验证的基本步骤,验证产品的功能和性能基本满足要求。在回归测试之前(后),测试人员仍然要针对具体功能需求做相关测试。

    二、指南纲要

    1、启动

        条件:开发组或者需求组提出产品变更需求。

        步骤:

    • 获取和评估变更项;确定对回归测试集的影响;
    • 对回归测试集进行增、删、改

    2、测试环境准备

        步骤:

    • 根据测试目标准备一个干净环境
    • 安装测试必备工具(缺陷管理工具,GUI测试工具,性能测试工具)
    • 安装自定义的测试工具
    • 用虚机或者Ghost进行环境备份,以利于重用。

    3、测试准备

        步骤:

    • 被测系统的安装和卸载测试
    • 安装被测系统

    4、执行测试

        步骤:

    • 初始化数据
    • 根据回归测试集的描述按模块有步骤地测试(回归测试集规范参见附录一、测试流程规范参见附录二)
    • 恢复环境

    5、结束

        条件:测试完成或者测试中止(测试中止规范参见附录三)

        步骤:

    • 测试过程数据的采集
    • 测试分析报告

    三、过程改进

        在实践中不断总结,提高测试效率,优化测试过程。

  • 测试开始了

    2007-03-29 14:26:05

        从事了9年的软件产品开发,从程序员一直到架构师。现在开始选择一种新的生活——测试(更准确的说是QA质量保证),大多数人都不理解,但我知道,我为了快乐而来!

Open Toolbar