发布新日志

  • 【转】QTP识别和操作对象的原理

    2009-07-01 10:48:34

    感谢作者: yabest   链接:http://www.51testing.com/html/32/n-6132.html

    呵呵,这个文章本来是在给别人的帖《GetROProperty,GetTOProperties,GetTOProperty的区别 》回复时写的,没有独立出来。

      http://bbs.51testing.com/viewthread.php?tid=13554&page=1#pid369327

      写完后,在网上被多处转载。没想到今天又被转贴回51testing来了。

      虽然在精华版里,也赚了几朵花,但没独立总是不方便。所以修整了一下,独立成帖,以方便大家阅读。

      欢迎大家拍砖!(当然更欢迎大家送花sdlkfj5)

      一、QTP识别对象的原理(by yabest, http://www.yabest.net)

      QTP里的对象有两个概念,一个是Test Object(简称TO),一个是Runtime Object(简称RO)。

      这两个概念从字面上不大好理解,也容易混淆。

      但从实际作用上来看,应该说TO就是是仓库文件里定义的仓库对象,RO是被测试软件的实际对象。

      QTP识别对象,一般是要求先在对象仓库文件里定义仓库对象,里面存有实际对象的特征属性的值。

      然后在运行的时候,QTP会根据脚本里的对象名字,在对象仓库里找到对应的仓库对象,

      接着根据仓库对象的特征属性描述,在被测试软件里搜索找到相匹配的实际对象,最后就可以对实际对象进行操作了。

      仓库对象TO一般在录制/编写脚本时加入仓库文件,它不仅可以在录制编写时进行修改,也可以在运行过程中进行动态修改,以匹配实际对象。

      和TO、RO相关的几个函数有:

      GetTOProperty():取得仓库对象的某个属性的值

      GetTOProperties():取得仓库对象的所有属性的值

      SetTOProperty():设置仓库对象的某个属性的值

      GetROProperty():取得实际对象的某个属性的值

      (注:这几个函数访问的都是对象的封装属性,不是对象的自身属性,封装属性和自身属性的区别详见后面第二章QTP操作对象的原理)

      理解了TO的含义,你就可以自由的用SetTOProperty()定义TO,以灵活的操作RO

      比如有个测试任务,窗口上有很多待检查的记录,每条记录右边都有一个Check按钮,用来检查各条记录。

      记录个数不定,所以Check按钮个数也就不定,只有一个Edit显示记录个数。

      我们要对每条记录进行检查,也就是要点击每个Check按钮。

      但是Check按钮个数不定,不好录制,而且个数可能也很多(上百个),即使能一一录制,那也很麻烦。

      那我有一个好办法,只录制一个按钮对象,它设有两个特征属性 label=OK, index=0

      然后用下面的脚本,就可以完成测试

      buttonNum = CInt(JavaWindow("Test").JavaEdit("Record Num").GetROProperty("value"))

      For buttonIndex = 0 to buttonNum - 1

      JavaWindow("Test").JavaButton("Check").SetTOProperty("index", buttonIndex)

      JavaWindow("Test").JavaButton("Check").Click

      Next

      或者窗口上有New、Modify、Delete、Check等好几个按钮,要把这几个按钮一一按过去

      我在对象仓库里只设置一个按钮对象AnyButton,label特征属性值填任意值,然后用下面脚本执行测试

      JavaWindow("Test").JavaButton("AnyButton").SetTOProperty("label", "New")

      JavaWindow("Test").JavaButton("AnyButton").Click

      JavaWindow("Test").JavaButton("AnyButton").SetTOProperty("label", "Modify")

      JavaWindow("Test").JavaButton("AnyButton").Click

      JavaWindow("Test").JavaButton("AnyButton").SetTOProperty("label", "Delete")

      JavaWindow("Test").JavaButton("AnyButton").Click

      JavaWindow("Test").JavaButton("AnyButton").SetTOProperty("label", "Check")

      JavaWindow("Test").JavaButton("AnyButton").Click

      另外,QTP还支持脚本描述的方法来定义和访问对象,即不需要在仓库里定义,也能访问和操作实际对象

      ( Written by yabest,http://www.yabest.net )

      如上面两个任务,可以如下实现

      1. 不需要在仓库里定义Check按钮对象,直接用下面脚本来实现测试

      buttonNum = CInt(JavaWindow("Test").JavaEdit("Record Num").GetROProperty("value"))

      For buttonIndex = 0 to buttonNum - 1

      JavaWindow("Test").JavaButton("label:=Check", "index:="+CStr(buttonIndex)).Click

      Next

      2. 不需要在仓库里定义New、Modify、Delete、Check按钮对象,直接用下面脚本来实现测试

      JavaWindow("Test").JavaButton("label:=New").Click

      JavaWindow("Test").JavaButton("label:=Modify").Click

      JavaWindow("Test").JavaButton("label:=Delete").Click

      JavaWindow("Test").JavaButton("label:=Check").Click

      二、QTP操作对象的原理(by yabest, http://www.yabest.net)

      QTP为用户提供了两种操作对象的接口,一种就是对象的封装接口,另一种是对象的自身接口。

      对象的自身接口是对象控件本身的接口,只要做过软件开发,使用过控件的人应该很清楚。

      对象的封装接口是QTP为对象封装的另一层接口,它是QTP通过调用对象的自身接口来实现的。

      两种接口的脚本书写格式的差别在于:

      自身接口需要在对象名后面加object再加属性名或方法名,

      封装接口就不用在对象名后面加object。

      具体格式如下:

      对实际对象的操作:

      对象.object.自身属性

      对象.object.自身方法()

      对象.GetROProperty("封装属性")

      对象.封装方法()

      对仓库对象的操作:

      对象.GetTOProperty("封装属性")

      对象.GetTOProperties()      ’获取所有封装属性的值

      对象.SetTOProperty("封装属性", "封装属性值")

      比如操作JavaEdit对象,通过QTP封装的封装接口,脚本如下:

      设置JavaEdit的内容:

      JavaDialog("Add NE").JavaEdit("NE Name").Set "NE1"

      读取JavaEdit的内容:

      msgbox JavaDialog("Add NE").JavaEdit("NE Name").GetROProperty("value")

      如果通过JavaEdit的自身接口,脚本如下:

      设置JavaEdit的内容:

      JavaDialog("Add NE").JavaEdit("NE Name").object.setText("NE1")

      读取JavaEdit的内容:

      Msgbox JavaDialog("Add NE").JavaEdit("NE Name").object.getText()

      QTP执行JavaEdit().Set语句时,是通过执行JavaEdit().object.setText()来实现的。

      QTP执行JavaEdit().GetROProperty("value"),是通过执行JavaEdit().object.getText()来实现的。

      JavaEdit对象的封装接口Set()和GetROProperty("value"),是QTP封装JavaEdit对象的自身接口setText()和getText()而得来的。

      对象的封装接口是QTP使用的缺省接口,我们录制出来的脚本都是使用封装接口,大家用的也都是封装接口。

      但是封装接口不如自身接口丰富,因为QTP只是封装了部分常用的自身接口嘛。

      所以我们在需要时,可以绕过封装接口,直接调用对象的自身接口。

      不过有些自身接口不够稳定,在实践中偶尔会出现问题,但是概率很少。

      封装接口有相应功能的话,就尽量用封装接口吧!

      ( Written by yabest,http://www.yabest.net )

      理解了封装接口和自身接口的原理,我们就可以更加灵活的操作对象了。

      但是我们怎么知道对象都有哪些封装接口和自身接口呢?

      其实很简单,用对象查看器(Object Spy)查看对象,在查看窗口里有列出这些接口,包括属性和方法。

      窗口中间有选择栏让你选择Run-time Object或者Test Object,

      当你选择Runtime Object时,它显示的就是对象的自身接口(自身的属性和方法)

      当你选择Test Object时,它显示的就是对象的封装接口(封装的属性和方法)

      (注意:GetROProperty访问的是实际对象的封装接口,GetTOProperty访问的是仓库对象的封装接口,

      两者访问的都是对象的封装接口,即Object Spy窗口里选Test Object时显示的属性。

      不要以为GetROProperty访问的是自身接口,即Object Spy窗口里选Run-time Object时显示的属性。

      QTP里的Test Object/Run-time Object的概念太容易让人混淆了!

      它既用来区分仓库对象和实际对象,又用来区分对象的封装接口和自身接口。)

      明白了这些,你还等什么呢?快拿起对象查看器,看看对象都有哪些封装接口和自身接口,肆意的操作它,玩弄它吧!

      比如执行

      JavaDialog("Add NE").JavaEdit("NE Name").object.setVisible(false)

      哈哈,你的JavaEdit对象就当场消失不见了!!!

      你可以拿这个做恶作剧,指着这个窗口逼问开发人员,JavaEdit对象哪去了?

      开发人员肯定瞪大眼睛看着这个窗口,当场翘掉!!!
  • 【转】Web测试工具小结

    2009-06-12 14:26:41

  • 【转】qtp测试链接的方法-含脚本

    2009-06-12 14:24:57

    在QTP中,对于网页链接的测试可以使用Link对象,例如下面的脚本用于对链接的地址进行检查:
    ‘ 对链接的地址进行检查
    Browser("Welcome: Mercury Tours").Page("Welcome: Mercury Tours").Link("REGISTER").CheckProperty ("url",http://newtours.demoaut.com/mercuryregister.php)
    其中使用了CheckProperty方法,用于对比Link对象的URL属性是否等于指定的地址。也可以使用Link对象的Object属性中的href属性来进行比较,例如下面的代码所示:
    href = Browser("Welcome: Mercury Tours").Page("Welcome: Mercury Tours").Link("REGISTER").Object.href
    ‘ 如果地址不正确,则报告错误
    If NOT href ="http://newtours.demoaut.com/mercuryregister.asp" Then
    Reporter.ReportEvent micFail,"Link Error",href
    ExitAction
    End If

  • 【转】链接测试及工具

    2009-06-12 14:13:11

    摘要:在软件测试中,链接测试是网站所特有的测试。链接测试测试包括测试所有链接是否都是链接到正确的目标、链接的目标是否存在和是否存在孤立的页面。链接测试需要多整个网站的所有链接进行,而一般的网站内的链接错乱复杂,犹如一张大蜘蛛网,稍有疏附便有测试不完全的地方,因此引入链接自动化测试能够大幅提高链接测试的效率。

      关键字:网站测试  链接测试  自动化测试  测试工具

    正文:

      链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。

      链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。

      链接测试的原理 

      从待测网站的根目录开始搜索所有的网页文件,对所有网页文件中的超级链接、图片文件、包含文件、CSS文件、页面内部链接等所有链接进行读取,如果是网站内文件不存在、指定文件链接不存在或者是指定页面不存在,则将该链接和处于什么文件的具体位置记录下来,一直到该网站所有页面中的所有链接都测试完后才结束测试,并输出测试报告。

      如果发现被测网站内有页面既没有链接到其他资源也没有被其他资源链接,则可以判定该页面为孤立页面,将该页面添加到孤立页面记录,并提示用户。

      测试链接目标是否存在和是否有孤立页面都可以通过程序自动完成,但是程序却不能判断目标页面是否于用户的意是否相符合,如果链接到不正确的页面,例如将公司介绍链接到产品介绍,则程序无法进行判断,因此链接页面的正确性需要人工进行判断。 

      链接测试工具软件介绍 

           Xenu Link Sleuth

      该工具可以说是本人所见过的最小但功能最强大的检查网站死链接的软件了。你可以打开一个本地网页文件来检查它的链接,也可以输入任何网址来检查。它可以分别列出网站的活链接以及死链接,连转向链接它都分析得一清二楚;它支持多线程,可以把检查结果存储成文本文件或网页文件。

    HTML Link Validator

      该工具软件可以检查Web中的链接情况,看看是否有无法连接内容。本程序可以在很短时间内检查数千个文件,只需用鼠标双击放有网页的文件夹就能开始检查。可以标记错误链接的文件﹐很方便的显示链接﹐使用者也可以编辑这些资料。 

    Web Link Validat

      Web Link Validat用输入网址的方式来测试网络连结是否正常,你可以给出任一个任意存在的网络连接,像软件文件、HTML文件、图形文件等等都可以测试。

    如何利用HTML Link Validator对网站进行链接测试 

      该软件可以对单个HTML文件、文件夹内的所有HTML文件、远程网站等内容进行链接测试,测试结果可以保存为文件文件、网页文件或者导入到Access数据库中。

      安装Web Link Validat后,打开Web Link Validat,进入到Web Link Validat的主界面,如下图所示。Web Link Validat的界面很简单,功能也很单一,操作很容易上手。

            

      +”号图标,因为在Web Link Validat双击有特殊的用途。默认情况下,双击HTML文件则对该文件中的所有链接进行链接测试,双击目录则对该目录和所有

      子目录中的HTML文件进行链接测试。测试结果会再右下角的窗口进行显示,如下图所示。

               

      测试完毕后,可以通过REPORT菜单中的HTML REPORT来进行测试结果的查看,可以查看的方式包括:

    1、  错误链接报告

    2、  完整的报告

    3、  测试文件清单

    4、  用户自定义的HTML报告,可以允许用户定义显示条件。

    5、  重定向链接列表

      除了测试本地网站,还可以测试远程网站,选择测试方式为“Validate html files on web server”,然后在“Starting address:”中输入被测试网站页面的URL,会车后即开始对指定页面开始测试,如下图所示。
                 

      在被测试结果链接列表中,双击任意链接则直接打开该链接所在文件,并定位在该链接处,可以对链接直接进行修改,该功能能够节约寻找错误链接的时间,加快修改速度。 

    总结

      链接测试因为技术含量不高,很多程序员都不愿意做链接测试,但是链接的正确却直接影响用户对该网站的印象,一个网站如果出现链接上的错误,不管其页面做的如何漂亮,用户对其信任度都会大打折扣。因此,我们首先必须重视链接测试,虽然其需要耗费很多的时间,但是可以提高网站的整体质量,另外引入链接自动化测试工具可以加快链接测试进行的速度。

     

    Xenu Link Sleuth 简介
    该工具可以说是本人所见过的最小但功能最强大的检查网站死链接的软件了。你可以打开一个本地网页文件来检查它的链接,也可以输入任何网址来检查。它可以分别列出网站的活链接以及死链接,连转向链接它都分析得一清二楚;它支持多线程,可以把检查结果存储成文本文件或网页文件备注:对于动态生成的网页进行测试时会不准确

    XENU功能特点
    . 首先,它是免费的
    . 其次,它有易学的用户界面
    . 很好的错误报告
    . 忙状态时,保存当前操作
    . 可以一链即查看所有“失败链接报表”
    . 有重新检查失败链接的功能“recheck broken
    links”
    . 非常小巧
    . 可检查本地网页文件
    . 可生成网站地图
    . 支持有安全论证的站点(https://)
    . ..

    如何输入待检测URL地址
    . File->Check URL Or Ctrl+N

    设制测试时的属性信息
    打开此配置项操作为:
    File->Check URL->more Options
    Options->Preferences


    没有绝对的最大线程数,完全取消用户的测试机的内存的大小而定

    弹出验证信息输入窗口

    检测结果图

    查看断开链接的属性信息

    生成报告.File->Report or R

  • 软件测试过程的一些思考

    2009-03-04 13:24:30

    一. 测试过程中的优点

      1. 对需求的测试

      测试人员在获得需求后,对需求进行正确性,一致性,完整性,可理解性等的检查,将检查过程中发现的问题都记录下来,然后在需求评审之前一到两天统一汇总到需求人员手中,需求人员对测试人员的问题进行解答,在进行需求评审会议的时候,需求人员在讲解完需求后,再针对测试提交的问题进行解答,解答完问题后,评审人员根据之前的情况再提问需求人员,这样可以提高评审会议的效率,同时,测试人员在检查需求,以及参与需求评审的时候,对需求的理解就会更深入。

      2. 测试风险的估计及应对

      写在测试计划中的测试风险,一定要有明确的可执行的应对方法。否则,如果在测试过程中出现了风险防范中列举的风险,但是没有可执行的方法,可能会严重影响到测试工作,最常见的的,比人测试人员的离职会不会对整个项目测试工作造成影响,有没有可以预防的方法,因为,新招聘一个测试人员参与项目,不但会严重影响到测试进度的,还可能出现因为交接不充分而出现测试遗漏。

      3. 测试时间安排

      测试计划中,测试时间安排是最重要的一个方面,要将测试时间安排的最合理主要有两个方面,一个是测试人员的能力,一个是测试工作量的估算,能力决定了测试人员擅长或者不擅长的方面,分配测试工作的时候,应该量体裁衣,每个测试工作人员做自己最擅长的部分,对于能力较弱的,可以分配一些简单的测试工作,但是量可以多一点。另一个方面是测试工作量的估算,它决定了测试时间安排的合理与否,测试项目可以分为好几个测试阶段,每个测试阶段的测试内容可以分为不同的测试任务,而每个测试任务又可以分为测试子任务,不能再分的测试子任务才能作为一个独立的测试任务,估算该测试任务需要花费的时间,在估算测试工作量的时候,还要考虑缓冲,测试工作量如果估算的十分精确,一定要有缓冲时间,因为,人不可能完全按照计划工作。

      4. 测试用例评审

      测试用例评审之前,主持人要做好准备工作,向测试用例提前发送给邀请的对象,同时在会议开始之前准备好会议室,电脑等,在测试用例评审过程中,因为测试用例很多,不能一一都过,最重要的是,测试人员在测试评审的时候,讲解清楚每个测试用例,或者每组测试用例是用来验证什么的,以及这些测试用例执行后能够发现哪些类型缺陷,讲解清楚自己的一个测试思路。

      5. 测试汇报进度

      从测试进入项目开始,测试人员最好是每天能够汇报当天的进度以及以后一两天的工作安排,汇报对象为测试组成员,测试经理,而测试经理则将每个人的汇报汇总后,发邮件给需求,开发,这样,一方面督促测试人员做好自己的工作,令一方面,也可以让其他项目相关人员了解测试人员的工作进度,更好的做好前提工作,因为测试人员的工作基本上是依赖于需求和开发的。

      6. 测试环境管理

      测试环境最好是有测试人员管理,这样,一方面可以锻炼测试人员的能力,更重要的是可以杜绝开发随便修改测试环境中的数据。保证测试环境的独立性。

      7. 版本控制

      如果测试人员测试的版本,每个版本之间是迭代开发完成的,则需要针对每个版本都做冒烟测试,对每个版本都要根据测试策略做完整的测试。如果每个版本提交比较频繁,测试人员只针对重要的版本进行测试,但针对每个版本都应该做版本验证测试,以免遗留有重要的缺陷。

     8. 测试总结

      每个测试人员在某个时间段,或者一个项目结束后,都应该写一写测试总结,内容可以是在这个过程中获得的新技能,或者发现了自己的哪些不足,还可以是对测试的一些总结,这样,一方面可以在没有测试工作的时候督促测试人员去学习一些新技能,思考一些新方法,另一方面,通过总结,对测试人员自身的发展也是比较好的。

      9. 测试会议

      每周可以组织一次测试会议,针对某个主题展开讨论,形成一些可以执行的措施,测试会议中,测试人员说明一下当前各自工作内容,分享一些测试心得,使得每个测试人员都可以了解其他测试人员目前在做什么,另外,可以说明一下当前测试工作中碰到的哪些问题,大家一起讨论一个解决方法。

      10. 测试文档整理

      对测试过程中经常使用的文档,都可以整理成文档模板,比如测试用例模板,测试计划模板,测试报告模板等,虽然测试文档有很多的模板,但是根据公司特点整理的模板就是最好的模板,在写这些文档的时候,根据模板,可以提高工作效率,另外,对于业务文档,测试培训文档都应该整理,这些文档可以作为公司财产,更重要的是,当有新人进来的时候,完整的文档,可以让新人更快的融入团队。

      二.测试过程中的缺点

      1.需求问题多

      需求不确定是测试中经常出现的一个问题,有时候是因为没有专门的需求人有,需求文档不全面,有时候虽然有需求人员,但是,需求人员在完成需求文档的时候,可能是因为时间关系,也可能是因为考虑不细致,需求中总会有一些模棱两可的内容,而测试依照需求编写测试用例的时候,就会发现这一部分需求没有办法写测试用例,询问需求,要么被告知暂时就按需求来,要么需求自己也不知道具体是什么,出现这样的情况,都是不可测试的,很多时候,因为测试依照的是需求,既然需求这么说了,测试就没有什么方法了,要么就是等待,要么就是这一部分现不管了,后来,因为测试要忙其他的时候,逐渐就会把这些给忘记了,直到发布测试版本执行测试的时候,才会发现原来这个地方根本就不知道如何去测试。

      需求变动也是测试中经常出现的一个问题,其中有一部分原因是前面描述的需求不确定导致,还有原因是客户或者老板觉得目前的需求是不合理,不完善的需要修改或者增加,需求变动是无法避免的,但是,很多时候,需求变动了,需求口头告诉开发人员,开发人员就按照需求的说明对程序进行了改动,等测试在测试过程中发现程序展现出来的和需求完全不一致,提交bug了,开发拒绝了,说是需求要这样做的,问需求,需求说,是他让开发做的,测试人有比较尴尬,因为提交了无效的bug,又决定委屈,因为的确,根据需求,它就是一个bug,而更严重的是,测试还要修改测试用例,还要考虑开发这样修改,会不会影响到其他地方。

      针对以上两个需求的问题,测试最终要的是把握两点,一是需求必须是正确的,完整的,可测试的,无异议的,如果需求没有达到这一点,测试一定要跟着需求,让他将需求修改,如果必要,可以跟更高一级的领导汇报。第二,测试需要在整个项目组确定一种氛围,就是需求如果有变动,一定要以书面形式告之项目组相关人员,之后走需求变更流程,测试重新评估测试时间。如果出现因为需求变动导致的bug,测试不能因为开发是按照需求要求而修改了程序就不提bug,这样的问题,也必须提交bug,并且在总结的时候,一定要说明哪些是因为需求变动没有告之测试而出现的bug,这样,会对需求和开发有一定的影响。

      2.开发经常延期

      在项目开发过程中,容易出现到了开发承诺提交测试版本的时候,却不能按时提交测试版本,一般情况下,开发延期了,项目都不会顺延的,这个时候,测试完全被动了,不知道在延期的这段时间具体做什么,因为根据计划,是要开始执行测试了,其实,如果测试在更早的时间就能获悉开发要延期,则可以做一些延期准备工作,比如,可以安排准备测试数据,或者安排对测试用例进行组内相互检查,还可以安排对开发进行支持的一些工作。

      3.评审效果差

      无论是需求评审,还是测试用例评审,开发对这方面表现出来的积极性不够,可能是开发更喜欢设计的工作,对阅读的工作不喜欢,这样虽然是评审,开发只是走走过程,没有实质性的建议提出来。

      4.测试用例优先级划分不科学

      测试用例的执行,其实并不是每一轮测试都需要全部执行,根据项目的实际情况,可以对测试用例进行优先级分类,但是,在测试过程中,对测试用例的优先级的划分,完全是根据测试人员自己的经验和对被测项目的理解而划分的,因为个人能力的局限性,这样的划分是有很多的缺陷的,如果按照这样的分类进行测试,存在很高的风险,因此,一般的测试过程中,虽然划分了测试用例的优先级,但是,测试人员为了安全,还是会将所有的用例都执行的,测试用例优先级划分起不到应有的效果。

    摘自:http://www.51testing.com/html/46/n-109746.html

  • 报表测试的注意事项

    2009-03-04 13:01:12

    报表功能的基本要求,就是通过查询/统计/分析,提供用户所需的准确的数据。如果无法实现这个基本功能,则报表完全失去意义。

      对于用户来说,报表可以直接影响到他们的决策,例如可能因为报表对销售和库存情况反映的不准确,导致错误的大量进货;或者因为报表对应收应付金额计算的不准确,而导致企业对资金占用情况做出错误的估计,

      从而导致错误的决策,最终造成用户在经营上的损失。诸如此类,相信只要大家留心,还可以找出很多这样的例子。

      进销存系统中的报表多如牛毛,而且各种不同行业的进销存系统中的业务有区别,报表也有些区别,因此不太可能对各种报表逐个讲解,而主要是把一些报表测试的经验总结成了十几条可以在各种行业的报表测试中应用的“最佳实践”,来跟大家一起分享。希望下面的这十几条像一招招简单实用的“擒拿手”,可以供正在进行报表测试或者准备开始作报表测试的朋友随手拈来,见招拆招,轻松应对这项工作

      (1)提高对业务的熟悉程度

      其实对任何一个软件进行测试,都必须要熟悉它的业务,包括业务流程和业务规则。但是报表同一般的业务功能还是有些区别的。例如对于单据的增、删、改,通过对界面的浏览和探索性的操作,大概都可以弄明白它的业务流程和业务规则,因为这些内容比较直观,而且在不同的行业中也差不了太多。但是在报表中,是很难直观的看到我们所需要了解的内容的。例如报表中的某个数据项,它的算法或者说数据来源,恐怕是比较难看出来的——即使是很类似的一个数据项,在不同行业的实际业务中,它的算法和数据来源也可以能完全不同的。

      所以对于报表业务的熟悉,主要是两个方面:数据项的算法和数据来源,也就是说要明白一个数据项同具体的业务有什么关系,单据的增、删、改或者状态的变化,对报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些,那么就无法验证报表中的数据是否准确,也无法通过报表去检查业务系统的正确与否。

      (2)覆盖所有可能的查询统计方式,而不是以自己的使用习惯为准

      对于报表的使用者来说——一般是企业的中层或高层领导,他们对于报表的要求可能会是多方面的,例如在进销存系统中,可能需要按不同商品进行分类统计,也可能是按供应商分类统计,这些都是由用户在实际工作中的需要来决定的,所以假如一个报表提供了多种查询统计的方法,那么在测试时,只要时间充分,就应该覆盖这些所有可能被用到的查询统计方法,而不是以自己的使用习惯为测试的依据。

      (3)使用或构造受控的数据环境

      数据对于报表测试来说是一个非常非常重要的问题。因为上面说到,报表的基本功能就是通过各种查询统计分析的方法,为用户提供准确的数据,帮助用户做出决策。那么那些用来进行测试的数据从哪里来呢?

      首先,应该保证准备足够多的有效的数据。前面一条也提到了,在实际测试报表时,应当尽可能的覆盖到报表所提供的各种查询统计方法,因此至少应该保证每一种查询统计方法都应该有对应的数据,得到的结果都不会是0,否则等于没有覆盖到这个被测的查询统计算法。当然数据也不是越多越好,能保证全部覆盖,并且刚好够用就可以了,因为数据的准备和生成也是很花时间的。

      其次,要保证数据的可控。数据并不是随意生成的,如果使用通过自动化工具或者通过业务测试时随意的输入的数据来进行报表测试,一般来说是不太可能的。因为如果无法控制数据来源,那么即使知道报表中每个数据项的算法,也无法最终验证报表的查询统计结果是否正确。例如,系统的会有不同类型的单据,每种单据又会有不同的状态,某个报表的统计中,可能会涉及到多种类型和状态的单据,那么在准备数据时,就要充分考虑到这一点,准备各种不同的单据来满足测试的要求。又比如,如果整个系统中只有一个供应商,一个商品,那么测试按供应商分类统计或者按商品分类统计的报表时,意义也就不大了。

      所以如果希望高有效、更高质量的完成报表的测试,那么就要重视并增加对于数据准备工作的关注:用于验证报表功能的数据,一定是专门为报表准备的,并且是经过精心设计,要分析影响数据项算法的各种因素,以及每个因素可能出现的不同变化,这样才有可能覆盖各种查询统计方法;同时,才能保证无论使用哪个数据项的算法进行计算,其结果都是可以预知的——因为数据来源已经被我们控制了。

      特别是对于算法比较复杂,又提供了多种查询统计方式的报表,如果想完整的测试,就需要准备大量的数据。而如果想高效、高质量的完成这项功能,就一定要理解数据准备工作的重要性。

      经过精心设计的数据还有一个好处,就是当在进行业务功能的测试时,不再需要使用一些随意的数据,而是可以通过业务测试的过程,把报表测试所需要的数据输入到系统中。并根据报表对单据类型和状态的需要,进行相应的操作。

      如果留心,你也会发现报表测试同其他业务功能测试的有个区别。业务功能(例如单据的新增、审核等)的测试用例设计,通常需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖;而对于报表功能,虽然没有太复杂的业务流程和规则,但是算法更加复杂,同时报表功能本身就是一种对数据的加工处理,因此会更偏重于对于各种数据来源和算法的遍历或覆盖,也就是要准备各种正常的、异常的数据,来验证报表是否取到的该取的数据、没有取不该取的数据,并且最后计算出了正确的结果。

      (4)特征性数据的准备

      这又是一个同数据准备有关的问题,也是一个解决实际问题的经验。如果由多人同时对一个系统进行测试,虽然大家各自使用的数据都是经过精心设计的,但是在实际进行报表测试时,还是很难保证其他人的数据不会对自己的测试结果产生影响,最明显的一个问题就是原来自己对结果是可以预知的——因为数据是经过精心设计的,是可控的,但是现在掺杂了别人的数据,就需要花时间去区分这种“假”的错误和真的错误。

      有一个经验是可以借鉴的,就是在初期,团队内对数据的准备达成一致,使数据中的某一项具有特征性,例如分别使用不同的供应商,或者使用不同的商品。最后测试报表时,通过限定选取的数据来源,来保证相互之间尽可能的没有影响。

      (5)做好数据环境的备份和维护

      虽然数据是经过精心准备的,但是难免在操作过程中因为误操作导致环境的变化,例如不小心把一张单据变成了另外一种状态,或者某个类型的单据多做了一张。对于这种情况,一个简单的方法就是去维护你的数据文档——一般我们都可以用EXCEL表来保存我们事先准备的数据,可以一个文件保存一个类型的单据,例如采购单、入库单、出库单等等,文件中的每张表用来保存不同状态的单据,例如已经审核过的入库单,没有审核过的入库单,全部入库的入库单和部分入库的入库单,等等。假如你一不小心,把一张本来准备入一半的入库单全入了,那也不要惊慌,去重新调整一下你的数据文档,在相应的类型相应的状态的单据列表中新增一张就行了。

      而如果想减少回归测试的工作量,那么应该考虑在一些关键的“点”上备份测试数据。例如所有的基础单据已经输入完成,但是还都没有开始审核或者出入库,那么可以备份一下,下次再测的时候可以直接在数据库中恢复这部分原始数据。

      (6)在业务功能测试通过之后才开始

      这一点相信应该不难理解,如果业务功能本身存在缺陷,导致的数据不准,那么最后进行报表测试也就没有什么意义了。所以,应该在保证各项同报表有关的业务的功能测试通过之后,才开始考虑对报表进行测试。

        (7)寻求开发人员的协助

      在报表测试中很常见的一个问题,是需求文档中可能没有定义报表的各个数据项的算法,这时候你需要找开发人员帮忙,向他们了解准确的算法和相应的公式。

      (8)多个报表相互对照

      这是一项“高级”的报表测试技能,需要对整个系统中的各种业务的熟悉程度达到一种炉火纯青的地步。除了可以准确的说出各个业务的处理过程对每张报表的影响之外,还能够进行横向的联系,知道不同报表之间存在的关系。例如,一个简单的例子,库存报表中,你可以看到商品的出入库情况,而在销售报表中,你可以看到商品的销售金额和销售成本金额,在应收应付报表中,你又可以看到不同供应商或客商之间的应收应付金额。那么这几张报表之间,是否存在一些关联呢?是否会存在一些可以相互验证的地方呢?

      (9)着重对那些算法复杂、与业务功能关联较多的报表的测试

      如果只是简单的把某个日期范围内的所有入库情况统计出来,可能不会出错;但是如果还要考虑按照供应商或商品汇总,同时要选取特定的类型或状态的单据,再进行一些响应的计算,恐怕就很难保证开发人员永远不会出错了。这就像业务功能的测试一样,越是复杂的业务,越有可能出错。

      (10)留意四舍五入对报表数据的影响

      从这一条开始,后面的内容可以说也是一些在实际测试时要注意的事项。

      这也是一个常见的问题。在一般的进销存系统中,都会存在这种情况,无论小数点后保留几位,总是难以避免明细和汇总之间的差别。原因可能是因为采购和销售的包装不一致,因为拆零引起的,例如10/30*30≠10;或者由于毛利率、税率等因素导致的不一致。我们曾经试过在保留4位小数的情况下还是无法避免这种情况。

      (11)留意进/存/销时使用不同单位对报表数据的影响

      例如采购时是5箱,每箱有100盒,而销售单位是盒,入库之后,可能会要求按照销售单位来统计,这时要注意开发人员是否会选择了错误的单位,把500盒弄成5箱。

      (12)留意业务单据中存在多个日期字段时对报表数据的影响

      一般来说,一张单据上都会有多个日期字段,比如采购单就有采购日期、单据日期、审核日期,而入库单也会有单据日期、入库日期,诸如此类。那么在测试时,一定要留意,开发人员是否按照要求选择了正确的日期,包括日期选取的一致性——是否存在这边取采购日期,那边取审核日期的情况。

      (13)留意是否存在遗漏的单据类型

      例如像出入库的报表,入库方向的,除了最主要的采购入库外,可能还会包括退货入库、盘盈入库、报溢入库;出库方向的,除了最常见的销售出库,还会包括盘亏出库、报损出库。那么在具体测试时,一定要准备充分这些相应类型的单据,并且要留意开发人员是否遗漏了相应的单据类型。

      (14)留意不同状态的单据对报表数据的影响

      例如采购单,当采购单发出后,供应商会开始送货,可能第一批之送来了一半的商品,那么这时采购单的收货状态是“未完成”;当供应商把商品送齐了以后,采购数量=收货数量,则采购单的收货状态变为“已完成”。那这时留意,开发人员在采购报表中,是包含所需要的状态的单据,还是只包含了一部分?

      (15)留意那些被当做默认规则的因素

      有些规则——例如单据类型或者单据状态——是作为默认规则写死在SQL语句或者数据库的存储过程里面,这些规则不会体现在界面,也不会由用户选择决定。但是这些规则恰恰是最容易被忽略的部分。所以,一定要同开发人员反复确认,保证自己已经了解了同报表各数据项计算有关的各个因素。

      (16)保证测试人员可以通过UI找到自己所需的所有原始数据

      在进行系统测试时,无论是报表,还是一般的业务功能测试,都不要去直接通过SQL语句查询数据库中的内容,而是通过UI来输入,再通过UI体现处理的结果进行验证——因为这是系统测试,不是集成测试,将来用户是决不会去直接查数据库的。因此,如果需要对报表的结果进行验证,应该通过其他的功能模块,去查询业务单据,或者其他报表,根据UI体现的结果,来进行确认。

      (17)检查大数据量对报表的影响

      报表测试也会涉及到性能测试,主要是在大数据量查询统计的测试。大数据量一是说原始数据多,二是被操作、计算的数据多,三是某个数据项被是经过多次计算得出的。特别是对于一些算法比较复杂的报表,10万条数据和100万条数据时的响应时间将表现出巨大的差别。

      (18)不要遗漏权限控制和访问安全性的测试

      这里说的权限控制不是谁可以访问某个模块,谁不可以访问某个模块,而且数据的计算也没有直接的关系,而是侧重于报表设计的测试。我们都知道不同的报表是设计给不同的人看的,例如出入库报表是给仓库管理人员看的,里面不会包含商品的价格,而只会包含数量;而财务报表中,只会包含采购、销售的金额,而不会包含数量,这样才能保证可以相互对照,不会出现营私舞弊的行为。那么在测试时,应当考虑报表是否泄漏了不该泄漏的信息。当然,这里对业务的熟悉程度就是更高的要求了。

      又如,不同的业务员只能看到同自己有关的业务,但是领导可以看到所有业务员的业务——例如不同的业务员分管不同的客户或者地域,他们之间的销售情况是互相保密的。

      还有一种情况,系统的用户可能会为他的供应商提供一个专门的程序或者Web页面,供其对其供应的商品的销售、库存情况进行查看。那么对于这种情况,一方面是要保证某个供应商只能看到他所供应的商品的销售、库存情况,如果某个商品由多个供应商同时提供,那么其中一个供应商应该只能看到他提供的那部分,而看不到其他供应商提供的同一商品的情况。当然,这种功能一般都是通过外网(internet)来访问的,所以也还要考虑相应的访问安全性测试,以免泄漏重要的商业信息。

    摘自:http://www.51testing.com/html/44/n-109744.html

  • 测试CheckList

    2009-02-23 11:23:56

  • 【转】使用Multi Test Manager实现QTP脚本的批处理运行

    2009-01-22 10:50:24

    使用Multi Test Manager实现QTP脚本的批处理运行

    有人问有没有什么工具可以管理QTP脚本,管理运行设置等,我第一个印象就是TD,不过他不想用TD,部署太复杂了,而且那么大,而只是为了实现这个功能也太浪费了。后来就知道了Multi Test Manager,相当于是QTP的一个插件,可以实现所需要的功能,而且很小,才其几M,用起来也很简单。

    实现的功能:

    1、可以添加多个QTP脚本,按设置的顺序依次运行。添加后可设置哪些脚本运行哪些不运行;

    2、可以定制运行脚本的时间;

    3、可以定制运行脚本的循环次数;

    4、可设置失败时停止脚本;

    5、可在远程运行脚本;

    6、可在执行后产生HTML报告,并发送邮件;

    7、Mercury Multi-Test Manager支持COM访问和调用。(没试过)

    8、Prefence里面的设置都写在mtm文件中,可用记事本打开来改。若脚本文件路径改变了不想一个个改就可以打开这个文件全部替换。

    缺点:无法自动打开QTPRO.exe,只有打开QTP后,再执行Test Manager的run操作才能运行。可能是版本不兼容的问题。

    另一个可批处理运行QTP脚本的工具是QTP自带的Batch Runner,功能比较少,不能定制时间和循环次数,也不能远程执行的。

    感谢作者,链接:http://www.51testing.com/?149842/action_viewspace_itemid_83394.html

  • 【转】详解:数据库名、实例名、ORACLE_SID、数据库域名、全局数据库名、服务名

    2009-01-07 10:08:14

    发现有好多基础要补。先来一个ORACLE的基础知识。
    转自http://www.cnblogs.com/terry52/archive/2008/07/02/1234101.html,感谢"天天@BLOG"

    数据库名、实例名、数据库域名、全局数据库名、服务名 ,
    这是几个令很多初学者容易混淆的概念。相信很多初学者都与我一样被标题上这些个概念搞得一头雾水。我们现在就来把它们弄个明白。

    一、数据库名
    什么是数据库名?

    数据库名就是一个数据库的标识,就像人的身份证号一样。他用参数DB_NAME表示,如果一台机器上装了多全数据库,那么每一个数据库都有一个数据库名。在数据库安装或创建完成之后,参数DB_NAME被写入参数文件之中。格式如下:
    DB_NAME=myorcl
    ...
    在创建数据库时就应考虑好数据库名,并且在创建完数据库之后,数据库名不宜修改,即使要修改也会很麻烦。因为,数据库名还被写入控制文件中,控制文件是以二进制型式存储的,用户无法修改控制文件的内容。假设用户修改了参数文件中的数据库名,即修改DB_NAME的值。但是在Oracle启动时,由于参数文件中的DB_NAME与控制文件中的数据库名不一致,导致数据库启动失败,将返回ORA-01103错误。

    数据库名的作用
    数据库名是在安装数据库、创建新的数据库、创建数据库控制文件、修改数据结构、备份与恢复数据库时都需要使用到的。
    有很多Oracle安装文件目录是与数据库名相关的,如:
    winnt: d:\oracle\product\10.1.0\oradata\DB_NAME\...
    Unix: /home/app/oracle/product/10.1.0/oradata/DB_NAME/...
    pfile:
    winnt: d:\oracle\product\10.1.0\admin\DB_NAME\pfile\ini.ora
    Unix: /home/app/oracle/product/10.1.0/admin/DB_NAME/pfile/init$ORACLE_SID.ora
    跟踪文件目录:
    winnt: /home/app/oracle/product/10.1.0/admin/DB_NAME/bdump/...
    另外,在创建数据时,careate database命令中的数据库名也要与参数文件中DB_NAME参数的值一致,否则将产生错误。
    同样,修改数据库结构的语句alter database, 当然也要指出要修改的数据库的名称。
    如果控制文件损坏或丢失,数据库将不能加载,这时要重新创建控制文件,方法是以nomount方式启动实例,然后以create controlfile命令创建控制文件,当然这个命令中也是指指DB_NAME。
    还有在备份或恢复数据库时,都需要用到数据库名。
    总之,数据库名很重要,要准确理解它的作用。

    查询当前数据名
    方法一:select name from v$database;
    方法二:show parameter db
    方法三:查看参数文件。

    修改数据库名
    前面建议:应在创建数据库时就确定好数据库名,数据库名不应作修改,因为修改数据库名是一件比较复杂的事情。那么现在就来说明一下,如何在已创建数据之后,修改数据库名。步骤如下:
    1.关闭数据库。
    2.修改数据库参数文件中的DB_NAME参数的值为新的数据库名。
    3.以NOMOUNT方式启动实例,修建控制文件(有关创建控制文件的命令语法,请参考oracle文档)

    二、数据库实例名
    什么是数据库实例名
    数据库实例名是用于和操作系统进行联系的标识,就是说数据库和操作系统之间的交互用的是数据库实例名。实例名也被写入参数文件中,该参数为instance_name,在winnt平台中,实例名同时也被写入注册表。
    数据库名和实例名可以相同也可以不同。
    在一般情况下,数据库名和实例名是一对一的关系,但如果在oracle并行服务器架构(即oracle实时应用集群)中,数据库名和实例名是一对多的关系。这一点在第一篇中已有图例说明。

    查询当前数据库实例名
    方法一:select instance_name from v$instance;
    方法二:show parameter instance
    方法三:在参数文件中查询。

    数据库实例名ORACLE_SID
    虽然两者都表是oracle实例,但两者是有区别的。instance_name是oracle数据库参数。而ORACLE_SID是操作系统的环境变量。ORACLD_SID用于与操作系统交互,也就是说,从操作系统的角度访问实例名,必须通过ORACLE_SID。在winnt不台,ORACLE_SID还需存在于注册表中。
    ORACLE_SID必须与instance_name的值一致,否则,你将会收到一个错误,在unix平台,是“ORACLE not available”,在winnt平台,是“TNS:协议适配器错误”。

    数据库实例名与网络连接
    数据库实例名除了与操作系统交互外,还用于网络连接的oracle服务器标识。当你配置oracle主机连接串的时候,就需要指定实例名。当然8i以后版本的网络组件要求使用的是服务名SERVICE_NAME。这个概念接下来说明 。

    三、数据库域名
    什么是数据库域名?

    在分布工数据库系统中,不同版本的数据库服务器之间,不论运行的操作系统是unix或是windows,各服务器之间都可以通过数据库链路进行远程复制,数据库域名主要用于oracle分布式环境中的复制。举例说明如:
    全国交通运政系统的分布式数据库,其中:
    福建节点: fj.jtyz
    福建厦门节点: xm.fj.jtyz
    江西: jx.jtyz
    江西上饶:sr.jx.jtyz
    这就是数据库域名。
    数据库域名在存在于参数文件中,他的参数是db_domain.

    查询数据库域名
    方法一:select value from v$parameter where name = 'db_domain';
    方法二:show parameter domain
    方法三:在参数文件中查询。

    全局数据库名
    全局数据库名=数据库名+数据库域名,如前述福建节点的全局数据库名是:oradb.fj.jtyz

    四、数据库服务名
    什么是数据库服务名?
    oracle9i版本开始,引入了一个新的参数,即数据库服务名。参数名是SERVICE_NAME。
    如果数据库有域名,则数据库服务名就是全局数据库名;否则,数据库服务名与数据库名相同。

    查询数据库服务名
    方法一:select value from v$parameter where name = 'service_name';
    方法二:show parameter service_name
    方法三:在参数文件中查询。

    数据库服务名与网络连接
    oracle8i开如的oracle网络组件,数据库与客户端的连接主机串使用数据库服务名。之前用的是ORACLE_SID,即数据库实例名

  • 2009年了,新的开始

    2009-01-07 10:00:36

    突然想写空间了……
Open Toolbar