不找不务实的公司和工作;要按自己的想法去找工作。

发布新日志

  • 2011-6-15

    2011-06-15 15:56:18

    只是想了想而已,于是就成下面的东西了:

    1、测试计划:
      上次培训时提到测试策略,比如采用怎样的功能测试方法、测试入口出口标准。
      记得以前的测试策略都放在测试计划里的,并且是从组织标准过程中挪过来的。
      尤其在集成测试策略中会提到是由上及下的集成方法或是由下及上的集成方法。
      测试入口:开发完成单元测试、集成测试,并出示单元、集成测试report。
      测试出口:所发现问题都已解决,遗留问题少于5%。
      不过现在都没有测试策略一说。
      转测标准:初验通过。初验用例有测试人员提供,一般是从写好的用例中抽取能覆盖基本功能的用例。
      需要注意:如果是在基线版本上做定制,也需要验证基本版本的功能。
     
    2、测试方案
       之前写测试方案都没有思路的。上次测试巴林版本,才对测试方案的结构有了一个较为明确的思路。
       首先,概述:概要提出该方案针对的测试内容;
       第二,测试对象分析:分析测试内容,详细的需求是怎样的;
       第三,测试设计:对于详细的需求,需要考虑哪些方面、哪些场景的测试;
       第四,测试用例:对于详细的场景,预置条件和预期结果是怎样。
       第四步也就是详细测试设计,粒度基本接近于测试用例。因此写用例时直接从这里开始即可。
      
       小结:测试方案的思路,和分析一个业务场景很类似。一步一步,来龙去脉都很清楚。
       将自己的方案讲解给别人听,也是一种理清思路的好方法。
      
    3、测试用例:
       测试用例设计方法有很多种,但是实际使用的时候有以下问题:
       1)使用的方法比较少,一般都是:等价类划分、边界值、猜错法等。我们常用的场景覆盖应该属于等价类划分里。
       2)一旦遇到比较复杂的数据设计,希望用类似于正交法这样的方法来设计用例,由于对类似方法不熟悉,因此无从下手。
       3)对于用例的覆盖程度,目前无法计算。
         一般只计算用例覆盖率,这也是基于已有用例而言。
       4)对于缺陷与用例相关的度量,没有做。
         在提单的时候,有说明,如果这个问题是通过用例发现的,打Y,如果不是通过用例发现的,打N。
         但是在最后总结的时候,没有去统计、度量。
       5)测试用例的必要性:以前在NFS的时候,总有一种错觉:用例写了发现不了问题,还不如不写用例。
         但后来发现,用例是必须写的,至少覆盖了能想到的测试思路、测试点,这样与无用例的情况相比,漏测可能性较小。
         并且在有测试用例的情况下,也比较好分配和计算工作量。
         有人说,不是通过用例发现的问题,需要补充case,并总结、分析业务场景。
         如果能发现一个这样的场景问题,类似的场景也可能有问题。
    4、业务知识:
       以前不知道什么叫做业务,在NFS的时候没这个概念,只知道需要了解需求、了解系统。
       业务覆盖面很广,任何与产品相关的都可以是业务。大到支撑的平台、小到一个输入框,都属于业务。
       学习业务知识的步骤,其实没总结过,自己接触了很多,好像伴着业务知识过两天,也就了解了。
       其实,应该是有步骤的,让我想想:
       1)了解下功能、模块是什么东西,使用场景是什么,最后的目的是什么?
       2)想想可能会涉及到哪些模块,各个模块之间是如何关联、业务是如何触发?怎样从源头一步步走到数据库结果的?
       3)针对每个关联的模块,具体做了哪些事情,进一步挖掘。
       这样,就从业务场景、关联模块等大的方面,到业务逻辑、如何实现等小的方面,就有了比较清楚的认识。
       在关注较为细节的业务逻辑实现的时候,最好借助于场景日志、存储过程,可以协助快速理解。
      
       业务知识是很重要的一块。
       对业务知识了解多、想得多,在编写测试方案和测试用例的时候也就更有思路。
      
    5、测试技能:
       目前而言,也就是基本的业务掌握和数据库这块。
       总感觉还是有点浮在水面,没有去深挖问题。但我也不知道怎样才是深挖,从哪去挖,如何去挖。
       我们目前的工作面比较窄,都集中在业务这块。对于专项测试比较淡薄,基本上就是面向手工功能测试这块。
      
      
    6、测试思想:
       其实,手工功能测试是其他所有测试的基础,思想基础。所谓的自动化,其实也就是工具而已。
       所以,lpb说的对,学习东西,先掌握其思想。等需要用得时候,再实际去关注细节。
       所以,tmy说的对,测试思想很重要。
       以前在NFS还总想这些问题,因为测试这块没人关注这个,而开发PM很关注这个。
       记得还跟大Boss PK过,也在bbs上和XJ对峙过。
       现在就完全浸在业务里了。一头钻进了业务,没想过外层的东西了。

  • 傻乐 happened @2011-3-25

    2011-03-25 16:03:05

    说要在数据库中监控dblink,所以创建一个定时job,如果dblink有问题,job执行就用正确的数据给重新创建一下;如果没有呢,就重新创建一个。就算不使用,新建一个也不受影响。主要代码如下:

    SELECT COUNT(1)
        INTO v_Count
        FROM USER_OBJECTS T
       WHERE T.Object_Type = 'DATABASE LINK'
         AND T.OBJECT_NAME = UPPER(i_DbLinkName);

      BEGIN

        IF v_Count >= 1 THEN
          v_SqlStr := 'SELECT 0 FROM dual@' || UPPER(i_DbLinkName);
        ELSE
        v_SqlStr := 'CREATE DATABASE LINK SER_REP_LINK CONNECT TO ' || i_UserName || ' IDENTIFIED BY ' || i_Pwd ||' USING ''' || i_DbAlias || '''';
        END IF;

        EXECUTE IMMEDIATE v_SqlStr--------STEP1
          INTO v_Result;
      EXCEPTION
        WHEN OTHERS THEN
          -- drop DBLink first
          v_SqlStr := 'DROP DATABASE LINK SER_REP_LINK';
          EXECUTE IMMEDIATE v_SqlStr;--------STEP2

          -- rebuild DBLink
          v_SqlStr := 'CREATE DATABASE LINK SER_REP_LINK CONNECT TO ' || i_UserName || ' IDENTIFIED BY ' || i_Pwd ||' USING ''' || i_DbAlias || '''';
          EXECUTE IMMEDIATE v_SqlStr;
      END;

      COMMIT;

    第一种情况,把dblink using后面的连接字符串改为一个不存在的,job执行后,dblink果然恢复正确。

    第二种情况,删除dblink,然后等待job执行去创建一个。但等了很久,sorry,没有。

    好吧,调试job对应的procedure。奇了怪了,每次执行到STEP1的时候就奔到Exception里了然后开始drop,在STEP2之后,就出去了,跑到外面的Exception里了。看了下,说是没有找到数据库连接。其实如果STEP1执行成功了,就直接退出不会抛异常的。看了下前面的v_Result,是null。这个值是干什么用的呢?得,注释掉看看。这下可以了。

    再把第一种情形跑一下,也pass。

    后来问了下oracle专家,如果excute immediate 后面用into的话,前面肯定是select,这里第一种情况下对应的就是select 0 from dual,所以不会有问题,但第二次用的是create database link,不是select,怎么会有Result呢?

    不错哈,问题定位出来了,还学习到了一点,乐啊乐啊乐啊……主要是发脚本过来的同事把我的测试结果mail给了PM,说v_Result去掉了,请比对合入代码。

  • 傻乐 happened @2011-3-22

    2011-03-25 15:52:12

    现场反馈有张表因为数据量较大,导致页面响应超时。PM看了下表结构,说用了分区,但实际查询时又没用到,需要去掉分区。(我对查询调优没经验,不知道为啥要这么干)

    他提供的方案steps如下:创建一个临时表;创建一个存储过程,执行该存储,把原表数据insert到临时表中;删除原表;将临时表rename为原表名称。

    我起初也是按这个方案跑的。某天要重新跑的时候突然想起来曾经在哪听说的快速创建表的一个方法:create table table1 as select * from table2.请教一下PM,他说这样也可以,但数据量大(原表有700w条记录),不建议使用。

    我不知道效果如何,于是have a try。因为不知道时间,所以在服务器端跑的,set timing on一把,执行完毕1分半。

    再试试原来的存储,也是在服务端跑,12min多一点。

    于是,PM按我的想法改了他的方案。

  • 写在这个纪念日

    2010-05-12 14:37:46

    汶川地震2周年,愿逝者安息,生者坚强。生活会更美好!

    昨天,公司总部撤销我们这个点,于是,一层楼的人都失业了。

    该找工作了。以前总想着要走,可是还依然坚持。这次是必须走了。

    虽然可以去楼下的老公司,但我害怕会是继续没有技术、混沌的工作。

    虽然找工作会很麻烦,要是找到了、去了其他城市,搬家、办手续、适应,都是很多很多问题。但我想,终该去面对这些。

    回想以前的自己,干事总是有目标有冲劲,会努力按计划去做好。工作两年来,这点优点没再体现出来过。我想,还是要努力,不断的努力。我会是我想要的那个样子的。

    小何,工作两年,却不敢说有2年工作经验。熟悉web测试,主要是手工功能测试。喜欢学习、钻研工具和技术,希望能加入到可以学习、使用到自动化功能测试技术的工作中。自己接触过qtp和RFT。会用junit做黑盒的单元测试。

    有过一点安全测试的经历,但深入不了。

    参加公司的cmmi3级评估,是主要的文档编写人员,是ATM小组成员之一。

    在测试结果的统计分析这块比较薄弱。

    希望以后能用数据来说明自己的工作。

  • 坚持做对的事情

    2009-03-16 17:24:12

    今天系统又部署了,我先随便看了下,后台能访问,但前台不行。于是,重新部署。

    部署完了之后,我看了看后台,重点测试的模块,一点就有错,原来没有加验证。验证是基本的问题,没有完成,是不应该提交部署的。提交到测试这边,测试提出问题,开发那边还是得改。为什么不全部做完了再确认提交呢?

    再看看前台,新加了一个模块,且不说功能没有实现,作为一个完整的功能模块,后面并没有同步部署对应的管理模块。这样不能算一个完整的功能,不应该只提交一半。

    我问开发人员这次的版本是多少,他说随便弄一个。我问质控组同事,他也说管不了。

    就因为boss把项目弄乱掉了,所以大家就这样了。

    不能大家都不管,总得有人出来把这事解决掉。

    于是,我跑到开发人员那边,找负责人把问题说清楚,回来之后把建议发给相关人员。随后部署的同事和质控组的同事过来,三个人又把这事一说,同意了我的做法,赶紧整理问题重新部署去了。

    虽然现在很乱,有些事情不是我们能左右的,但该做对的事情,我们一定要坚持!

  • 安全测试调研告一段落

    2008-04-17 14:14:06

    安全测试调研告一段落,效果不好。与同事相比,觉得自己工作做得不够好。

    不管怎样,所有的成果只有在实际的工作中实施了才能判断好与坏。

    加油!

    下面的日子,开始做毕业设计,开始在公司混饭,开始和宝贝天天忙碌……

    希望宝哥哥心情好点……

  • 又一个标志

    2007-11-21 16:07:54

    建一个自己的博客,呵呵……把工作的感觉与味道到倾倒在这里,鞭策自己,加油,加油!
Open Toolbar