发布新日志

  • TD邮件发送

    2008-08-26 12:04:55

    以前都不用TD的邮件功能的,这次在外做项目,但开发人员不在现场,想起了TD的这个功能,于是开始配置,

    还是从51上得到的信息,终于能够发送邮件了(虽然还只是手工的),具体步骤等有空了放上来……

    PS:用的邮件服务器是试用版,谁有注册码呀

  • IE7登录TD8.0

    2008-08-25 14:42:10

    买了个新本本 里面居然装了IE7.0 貌似蛮漂亮的 可突然发现 居然无法上TD!!我用腾讯的TT,也不行……

    终于还是在51testing里找到了解决方法:

    1.执行附件中的文件 IE6SP2.reg (不会看不到附件吧)

    2.重新打开IE,登录TD

    Over,很简单哦,具体原理下次去51上看看,转载过来,主要原理好像是“欺骗”,让TD以为是IE6,而非IE7

  • 忙忙忙

    2007-09-14 09:52:15

    最近比较忙 比较忙 比较忙

    忙得没有时间来更新日志

    忙得不知道该写什么

    忙得差点把这里遗忘

    ……

  • 用QTP执行语句打开程序的几种方法

    2007-09-04 11:34:59

    kangaroo的空间里看到关于"用QTP执行语句打开程序",我也试了一下,果真可以,另外通过查看QTP Help得知,如果[op]参数为空,则表示默认为Open,也就是说直接输入SystemUtil.Run "www.baidu.com" 就可以打开了。

    Syntax

    object.Run file,[params],[dir],[op],[mode]

    具体还是查Help吧,那里比较清晰,看了就明白了

    SystemUtil.Run "www.baidu.com"

    其中'SystemUtil'表示一个对象Object,其下有一个方法Method叫做Run

    "www.baidu.com" 就是Syntax中的那个file,即要运行的DD。

     另外,补充一下其它的一些方法:

    方法一:

    StartURL = "www.baidu.com"
    set IE = CreateObject("InternetExplorer.Application")
    IE.Visible = true
    IE.Navigate StartURL

    方法二:

    InvokeApplication "C:\Program Files\Internet Explorer\IEXPLORE.EXE www.baidu.com"

    方法三:也就是前面提到的方法

    Systemutil.Run"C:\Program Files\Internet Explorer\IEXPLORE.EXE","www.baidu.com"

    Note其中的"C:\Program Files\Internet Explorer\IEXPLORE.EXE"可以换成其它浏览器程序,如TencentTT,也要看QTP是否支持

  • QTP Tutorial Learning Note

    2007-09-04 10:52:52

    把QTP的Tutorial看完了(不是英文版,而是《QTP8 Tutorial_oldsidney_cn.pdf》),其中遇到些问题没有解决,记录在这里,看以后的学习过程中能不能把这几个问题解决掉

    1."6参数化"中对'fromPort'进行参数化后,执行多次时,再次登录总是不成功,需要人工重新登录后才能继续


    2."7建立输出值"后,'depart_price'是正确了,但是同时还有一个总金额,由于参数化的原因,第二次执行时,结果和之前也是不一样的,所以结果是failed


    3."9.5对动作作参数化",对'toPort'字段参数化没有问题,但同样对'fromMonth'和'toMonth'进行参数化后,重放时,认不出这两个下拉框了

  • QuickTest Professional SP认证的考试大纲

    2007-09-04 10:01:06

    以下是QuickTest Professional SP认证的考试大纲,可以看做一个学习计划,放在这里激励自己吧

    刚看了非常著名的《QTP8 Tutorial_oldsidney_cn.pdf》,目前看到第九章了,做了考试大纲后面的三道题,居然都对的,呵呵,有信心了

    QuickTest Professional 9.0
    Product Specialist Exam – Study Summary

    Exam Topics:
    In order to complete the QuickTest Professional 9.0 product specialist exam, you need to prepare yourself
    with the following:
    Section I: Setting up the QuickTest environment
    · Test Planning
    · Recording settings
    Section II: Test Creation
    · Creating a basic test
    · Object Repository
    Section III: Test Enhancement
    · Synchronization
    · Parameters
    · Data Table
    · Checkpoints
    Section IV: Advanced Features
    · Object Repository management
    · Recovery Scenarios
    · Database checkpoints
    Recommended Study Sources:
    · Using QuickTest Professional 9.0 training course
    Participant Profile:
    As a candidate for the product specialist exam, we recommend:
    · Attending Mercury’s QuickTest Professional 9.0 training courses
    · At least three months of hands-on field experience with QuickTest Professional 9.0
    Exam Provisions:
    During the exam you are provided with:
    · A standard installation of Quality Center 8.2
    · A link to the online exam
    Exam Layout:
    · The Product Specialist exam begins a t 9 AM and must be completed within 4 hours. The exam
    consists of multiple choice and multiple select items.
    Sample Items:
    1. Which of the following statements can create a branching condition step in a test?
    a. While…Wend
    b. If…Else
    c. For…Next
    d. Do…Until

    2. What feature from Microsoft has to be installed in order to add a breakpoint?
    a. MS Outlook
    b. Internet Explorer
    c. MS Debugger
    d. Internet Explorer 6 Service Pack 2
    3. You would like to run a particular test up to a certain step. What QuickTest feature will you use to
    stop the test run at a specific step in the test?
    a. Pause
    b. Step Into
    c. Step Over
    d. Breakpoint
    e. Clear
    Answers: 1 – B, 2 – C, 3 – D

  • Mantis的安装方法

    2007-08-31 11:38:03

    Mantis的安装方法

     

    我公司的服务器是 2003 ,我是这样安装Mantis 

    1.
    安装easyPHP 1.8  http://easyphp.org/
    2.
    配置apache.
    easyPHP面板上,修改apache的配置文件httpd.conf.要改以下4步。
    A.
    port改为8080,保存后在easyPHP界面上启动apache,如果报错不能启动,则需做B步。

    (port改为88,保存后退出easyPHP,重新启动,一般不会报错,这样就不用做B步啦)
    B.iis默认站点的端口改成非80端口。重复A,将port改为80,启动apache,应不会再报错。访问http://localhost,应能看到easyPHP的页面。(即空出80端口给apache)
    C.
    修改httpd.conf,Listen 127.0.0.1:80改成Listen 192.168.10.1:80,192.168.10.1指安装电脑的局域网ip,这样,局域网内就可以访问mantis了。
    D.
    批量替换${path}为你的EasyPHP1-8安装目录,如C:\Program Files\EasyPHP1-8
    easyPHP面板上重启apache。则apache的设置就完成了。
    3.
    设置phpmyadmin(mysql的管理界面):将phpmyadmin整个目录copywww目录下。访问http://192.168.10.1/phpmyadmin,应该能看到数据库管理界面。
    4.
    解压mantiscopy mantis目录到www下。(我用的是mantis-1.1.0a3)
    5.
    访问http://192.168.10.1/mantis,则会出现安装界面。按默认设置,填创建数据库的userroot,密码空,把产生sql显示的check box选上,按确定按钮。则会显示出安装信息,里面有建表的sql,将这段sql copy并保存起来。(建数据库不成功,则要手动到mysql里建表,见6)
    6.
    手动建表的方法:http://192.168.10.1/phpmyadmin,在界面里,建一个新数据库bugtracker,然后在bugtracker上执行5copy下来的sql。则建表完成。
    7.
    配置mantis,步骤如下:
    A.
    mantis目录下,将config_inc.php.sample改为config_inc.php
    B.
    编辑config_defaults_inc.php,修改配置如下:
      $g_default_language  = 'chinese_simplified'; #
    默认为中文
      $g_enable_email_notification = OFF;#
    默认不发email,配好email后可以设为On
    8.
    至此整个安装配置完成。访问http://192.168.10.1/mantis应该能看到登陆界面,用administrator-root可以登陆进去。
    9.
    设置mantis,主要加项目、用户、设置用户权限、设置流程等,具体请参考mantis的在线帮助。
    10.
    设置好后,即可使用。

    注:
    1."2.A"
    中,最好不要使用80端口,用8080会好一点。估计需设置一下2003server的安全设置。
    2."3"
    中,应该不用copy phpmyadmin目录到www也可以,需修改一下httpd.confphpmyadmin目录设置。
    3."5/6"
    中,应该可以自动安装好数据库,这样就不用手动安装了。
    4."7.B"
    中,邮件未配好,最好配好它,bug系统用email来通知比较及时,也可避免测试人员人工通知程序员。
    5.
    数据库的备份问题。最好人工地定时通过phpmyadmin来备份一下bugtracker数据库的数据。

  • SQL笔记

    2007-08-30 16:44:25

    原发布日期:2005年10月10日, 星期一 17:25

    1.取长度

       Oracle中length取字符、lengthb取字节,如“张三”——length=2lengthb=4

        DB2length取字节,如“张三”——length=4

     

    2.关于join

    A B

    1 1

    2 2

    4 3

    inner join --1 1

                 2 2

     

    left join   --1 1

                  2 2

                  4 -

     

    right join --1 1

                 2 2

                 - 3

     

    full join   --1 1

                  2 2

                  4 -

                  - 3

    注:

    1)建议不要用full join,结果常常不对,可以用left join 和right join 实现

    select * from table a

          left join table b

    union

    select * from table a

           right join table b

    2)要去除小表中为空的记录:

    select * from table a

         left join table b

         on      ……

    where a.col1 is not null

    未完待续……

  • [转]SQL语句优化技术分析

    2007-08-30 16:41:17

    SQL语句优化技术分析

    操作符优化

    IN 操作符

    IN写出来的SQL的优点是比较容易写及清晰易懂,这比较适合现代软件开发的风格。

    但是用INSQL性能总是比较低的,从ORACLE执行的步骤来分析用INSQL与不用INSQL有以下区别:

           ORACLE试图将其转换成多个表的连接,如果转换不成功则先执行IN里面的子查询,再查询外层的表记录,如果转换成功则直接采用多个表的连接方式查询。由此可见用INSQL至少多了一个转换的过程。一般的SQL都可以转换成功,但对于含有分组统计等方面的SQL就不能转换了。

           推荐方案:在业务密集的SQL当中尽量不采用IN操作符。

    NOT IN操作符

           此操作是强列推荐不使用的,因为它不能应用表的索引。

           推荐方案:用NOT EXISTS 或(外连接+判断为空)方案代替

    <> 操作符(不等于)

           不等于操作符是永远不会用到索引的,因此对它的处理只会产生全表扫描。

    推荐方案:用其它相同功能的操作运算代替,如

           a<>0 改为 a>0 or a<0

           a<>’’ 改为 a>’’

    IS NULL IS NOT NULL操作(判断字段是否为空)

           判断字段是否为空一般是不会应用索引的,因为B树索引是不索引空值的。

           推荐方案:

    用其它相同功能的操作运算代替,如

           a is not null 改为 a>0 a>’’等。

           不允许字段为空,而用一个缺省值代替空值,如业扩申请中状态字段不允许为空,缺省为申请。

           建立位图索引(有分区的表不能建,位图索引比较难控制,如字段值太多索引会使性能下降,多人更新操作会增加数据块锁的现象)

    > < 操作符(大于或小于操作符)

           大于或小于操作符一般情况下是不用调整的,因为它有索引就会采用索引查找,但有的情况下可以对它进行优化,如一个表有100万记录,一个数值型字段A30万记录的A=030万记录的A=139万记录的A=21万记录的A=3。那么执行A>2A>=3的效果就有很大的区别了,因为A>2ORACLE会先找出为2的记录索引再进行比较,而A>=3ORACLE则直接找到=3的记录索引。

    LIKE操作符

    LIKE操作符可以应用通配符查询,里面的通配符组合可能达到几乎是任意的查询,但是如果用得不好则会产生性能上的问题,如LIKE ‘%5400%’ 这种查询不会引用索引,而LIKE ‘X5400%’则会引用范围索引。一个实际例子:用YW_YHJBQK表中营业编号后面的户标识号可来查询营业编号 YY_BH LIKE ‘%5400%’ 这个条件会产生全表扫描,如果改成YY_BH LIKE ’X5400%’ OR YY_BH LIKE ’B5400%’ 则会利用YY_BH的索引进行两个范围的查询,性能肯定大大提高。

    UNION操作符

    UNION在进行表链接后会筛选掉重复的记录,所以在表链接后会对所产生的结果集进行排序运算,删除重复的记录再返回结果。实际大部分应用中是不会产生重复的记录,最常见的是过程表与历史表UNION。如:

    select * from gc_dfys

    union

    select * from ls_jg_dfys

    这个SQL在运行时先取出两个表的结果,再用排序空间进行排序删除重复的记录,最后返回结果集,如果表数据量大的话可能会导致用磁盘进行排序。

    推荐方案:采用UNION ALL操作符替代UNION,因为UNION ALL操作只是简单的将两个结果合并后就返回。

    select * from gc_dfys

    union all

    select * from ls_jg_dfys

    SQL书写的影响

    同一功能同一性能不同写法SQL的影响

    如一个SQLA程序员写的为

           Select * from zl_yhjbqk

    B程序员写的为

           Select * from dlyx.zl_yhjbqk(带表所有者的前缀)

    C程序员写的为

           Select * from DLYX.ZLYHJBQK(大写表名)

    D程序员写的为

           Select *  from DLYX.ZLYHJBQK(中间多了空格)

    以上四个SQLORACLE分析整理之后产生的结果及执行的时间是一样的,但是从ORACLE共享内存SGA的原理,可以得出ORACLE对每个SQL 都会对其进行一次分析,并且占用共享内存,如果将SQL的字符串及格式写得完全相同则ORACLE只会分析一次,共享内存也只会留下一次的分析结果,这不仅可以减少分析SQL的时间,而且可以减少共享内存重复的信息,ORACLE也可以准确统计SQL的执行频率。

    WHERE后面的条件顺序影响

    WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响,如

    Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1

    Select * from zl_yhjbqk where xh_bz=1  and dy_dj = '1KV以下'

    以上两个SQLdy_dj(电压等级)及xh_bz(销户标志)两个字段都没进行索引,所以执行的时候都是全表扫描,第一条SQLdy_dj = '1KV以下'条件在记录集内比率为99%,而xh_bz=1的比率只为0.5%,在进行第一条SQL的时候99%条记录都进行dy_djxh_bz的比较,而在进行第二条SQL的时候0.5%条记录都进行dy_djxh_bz的比较,以此可以得出第二条SQLCPU占用率明显比第一条低。

    查询表顺序的影响

    FROM后面的表中的列表顺序会对SQL执行性能影响,在没有索引及ORACLE没有对表进行统计分析的情况下ORACLE会按表出现的顺序进行链接,由此因为表的顺序不对会产生十分耗服务器资源的数据交叉。(注:如果对表进行了统计分析,ORACLE会自动先进小表的链接,再进行大表的链接)

    SQL语句索引的利用

    对操作符的优化(见上节)

    对条件字段的一些优化

    采用函数处理的字段不能利用索引,如:

    substr(hbs_bh,1,4)=’5400’,优化处理:hbs_bh like ‘5400%’

    trunc(sk_rq)=trunc(sysdate), 优化处理:

    sk_rq>=trunc(sysdate) and sk_rqsysdate+1)

    进行了显式或隐式的运算的字段不能进行索引,如:

    ss_df+20>50,优化处理:ss_df>30

    ‘X’||hbs_bh>’X5400021452’,优化处理:hbs_bh>’5400021542’

    sk_rq+5=sysdate,优化处理:sk_rq=sysdate-5

    hbs_bh=5401002554,优化处理:hbs_bh=’ 5401002554’注:此条件对hbs_bh 进行隐式的to_number转换,因为hbs_bh字段是字符型。

    条件内包括了多个本表的字段运算时不能进行索引,如:

    ys_df>cx_df,无法进行优化

    qc_bh||kh_bh=’5400250000’,优化处理:qc_bh=’5400’ and kh_bh=’250000’

    应用ORACLEHINT(提示)处理

    提示处理是在ORACLE产生的SQL分析执行路径不满意的情况下要用到的。它可以对SQL进行以下方面的提示

    目标方面的提示:

    COST(按成本优化)

    RULE(按规则优化)

    CHOOSE(缺省)(ORACLE自动选择成本或规则进行优化)

    ALL_ROWS(所有的行尽快返回)

    FIRST_ROWS(第一行数据尽快返回)

    执行方法的提示:

    USE_NL(使用NESTED LOOPS方式联合)

    USE_MERGE(使用MERGE JOIN方式联合)

    USE_HASH(使用HASH JOIN方式联合)

    索引提示:

    INDEXTABLE INDEX)(使用提示的表索引进行查询)

    其它高级提示(如并行处理等等)

    ORACLE的提示功能是比较强的功能,也是比较复杂的应用,并且提示只是给ORACLE执行的一个建议,有时如果出于成本方面的考虑ORACLE也可能不会按提示进行。根据实践应用,一般不建议开发人员应用ORACLE提示,因为各个数据库及服务器性能情况不一样,很可能一个地方性能提升了,但另一个地方却下降了,ORACLESQL执行分析方面已经比较成熟,如果分析执行的路径不对首先应在数据库结构(主要是索引)、服务器当前性能(共享内存、磁盘文件碎片)、数据库对象(表、索引)统计信息是否正确这几方面分析。

  • 读后感--测试用例设计的误区(二)

    2007-08-30 16:38:53

    原发布日期:2005-11-14 11:29:40

    2.测试用例应该详细记录所有的操作信息,使一个没有接触过系统的人员也能进行测试

    不记得最初是从哪里也得到这么一个用例设计的"准则",使得我写用例时严格按照这一准则行事,以前项目不紧张的时候,没有觉得什么不好,现在时间紧了,一度紧张到连用例都不写了,直接拿来就测,从一个极端跳跃到了另一个极端,当然没有测试用例对测试不可能没有影响,所以逐渐地,开始写简单的用例(实际相当于原来测试用例中的一个用例标题名称),初衷是自己的一个指导,当其他测试人员也用来参考时,即发现无法理解,或理解有误的情况发生,现在总结下来,测试用例不能少,根据资源情况协调,能明确用例的目的即可 至于"未接触过系统的人员",我觉得可以通过其它方式手段(培训、或当面交流或自己熟悉),先让他们能够初步熟悉,没有必要用花费大量时间的用例来使他们顺利执行测试

    原文《测试用例设计的误区》:http://www.51testing.com/?454/action_viewspace_itemid_19592.html

    未完待续……

  • 读后感--测试用例设计的误区

    2007-08-30 16:37:43

    原发布日期:2005-11-03 13:49:48

     读后感--测试用例设计的误区

    1.能发现到目前为止没有发现的缺陷的用例是好的用例
    1)同意这句话:我倾向于将测试用例当作一个集合来认识,对它的评价也只能对测试用例的集合来进行
      在写用例的时候,关注的重点在于如何用最少的测试路径覆盖最多的需求(需求中已经定义了什么是需要的什么是不需要的),这样就等于是覆盖了文章中说到的两点"* 程序做了它应该做的事情* 程序没有做它不该做的事情",在测试资源普遍缺乏的情况下,尽可能提高效率

    2)"变态路径"--测试过程中偶尔发现一种缺陷,而这种缺陷仅仅在异常操作情况下,才会出现,我们的开发人员称之为"变态路径。这样的操作在开发人员看来正常的用户是绝对不会执行到的,实际发生的可能性微乎其微,开发人员常会拒绝修复。个人认为,对于这种用例,在设计过程中如果也要考虑的话,会花费大量的时间精力,在时间紧张的情况下,应作权衡,舍弃这样的用例,而一旦发现了这样的缺陷,就应该要督促开发人员修复

    原文《测试用例设计的误区》:http://www.51testing.com/?454/action_viewspace_itemid_19592.html

    未完待续……

  • [转]测试用例设计的误区

    2007-08-30 16:34:58

    测试用例设计的误区
    文章出处:51testing论坛 作者: 发布时间:2005-10-19

    1、能发现到目前为止没有发现的缺陷的用例是好的用例:
    首先要申明,其实这句话是十分有道理的,但我发现很多人都曲解了这句话的原意,一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去,忘记了测试的目的所在,这是十分可怕的。我倾向于将测试用例当作一个集合来认识,对它的评价也只能对测试用例的集合来进行,测试本身是一种“V&V”的活动,测试需要保证以下两点:

        * 程序做了它应该做的事情
        * 程序没有做它不该做的事情

    因此,作为测试实施依据的测试用例,必须要能完整覆盖测试需求,而不应该针对单个的测试用例去评判好坏。

    2、测试用例应该详细记录所有的操作信息,使一个没有接触过系统的人员也能进行测试;
          不知道国内有没有公司真正做到这点,或者说,不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中,对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧,除了自己没人能够执行,写得太详细吧,消耗在测试用例维护(别忘了,测试用例是动态的,一旦测试环境、需求、设计、实现发生了变化,测试用例都需要相应发生变化)上的时间实在是太惊人,在目前国内大部分软件公司的测试资源都不足的情况下,恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人,甚至是测试工程师本身,全然不顾实际的资源情况,一定要写出“没有接触过系统的人员也能进行测试”的用例。
          在讨论这个问题之前,我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷,测试活动本身也可以被看作是一个Project,也需要在给定的资源条件下尽可能达成目标,根据我个人的经验,大部分的国内软件公司在测试方面配备的资源都是不足够的,因此我们必须在测试计划阶段明确测试的目标,一切围绕测试的目标进行。
          除了资源上的约束外,测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻,那测试用例就没有必要太详细了,文档的作用本来就在于沟通,只要能达到沟通的目的就OK。
          在我担任测试经理的项目中,在测试计划阶段,一般给予测试设计30% - 40%左右的时间,测试设计工程师能够根据项目的需要自行确定用例的详细程度,在测试用例的评审阶段由参与评审的相关人对其把关。

    3、测试用例设计是一劳永逸的事情;
          这句话摆在这里,我想没有一个人会认可,但在实际情况中,却经常能发现这种想法的影子。我曾经参与过一个项目,软件需求和设计已经变更了多次,但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措,间接的后果是测试用例成了废纸一堆,开发人员在多次被无效的缺陷报告打扰后,对测试人员不屑一顾。
          这个例子可能有些极端,但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的,测试用例文档是“活的”文档,这一点应该被测试工程师牢记。

    4、测试用例不应该包含实际的数据;
          测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出,没有测试数据的用例最多只具有指导性的意义,不具有可执行性。当然,测试用例中包含输入数据会带来维护、与测试环境同步之类的问题,关于这一点,《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法,可以参考。

    5、测试用例中不需要明显的验证手段;
          我见过很多测试工程师编写的测试用例中,“预期输出”仅描述为程序的可见行为,其实,“预期结果”的含义并不只是程序的可见行为。例如,对一个订货系统,输入订货数据,点击“确定”按钮后,系统提示“订货成功”,这样是不是一个完整的用例呢?是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢?显然不是。订货是否成功还需要查看相应的数据记录是否更新,因此,在这样的一个用例中,还应该包含对测试结果的显式的验证手段:在数据库中执行查询语句进行查询,看查询结果是否与预期的一致。

Open Toolbar