在测试的道路上,越走越远,越飞越高

TD的学习与总结(转)

上一篇 / 下一篇  2007-09-11 12:19:11

测试笔记
  • 笔记:
TD的学习与总结51Testing软件测试网-y/c*FH:d ?

3qu/rYt2oZW%e+_0TD(TestDirector)是一个功能强大的测试管理系统,此系统涵盖了整个测试流程。相对一些其它的一些缺陷管理工具而言,TD容易操作、易学易上手。51Testing软件测试网v.HWl[q ~%P:u_r
    由于最早学习的就是TD,到现在已经有一段时间了,前两篇文章(自动化QTP)居然把这个给淡忘了,惭愧万分    。
~z(XC,DWe @$r0下面开始介绍一下TD吧:
*t seqdv0    安装与我就不细说了,上网下载安装手册“下一步”就OK了。如果可以的话,安装程序里也有英文的帮助说明。配置此篇暂略过……  
gY{ayj-K;a0TD主要分为四个功能版块:51Testing软件测试网(I P(BW3c"ao
    1、需求 Requirements
!\ L"Ot kV+A:E"b w0    2、测试计划 Test Plan51Testing软件测试网9J.W)n-FsV!|7|s:Y
    3、测试实验室 Test Lab
(T xu|G R!LA7RGj0    4、缺陷 Defects
(ACcmc*xe0    TD上需求是定义测试内容与详细的需求,理论上是由测试组完成的。但综合公司的具体环境,有些时候可能需要开发来完成。
4NUr ` bU^\0    测试计划可以由需求直接转化(tools –> Convert to tests),也可根据需求文档自定义测试计划。51Testing软件测试网%Z)Q9}$@Xi
    测试实验室里,你可以创建执行流程。这里记录了所有你执行过的测试与结果。
YWC3fq9s_/^m'r0    缺陷管理栏,记录了测试过程中发现的所有问题,与开发的交互多在于此。51Testing软件测试网8~C@7};S}9i
    其实TD的操作并不难,没有代码,不会有太多文字,也全部都是很常用的控件组合。只要你熟悉这个测试流程,使用TD没有问题!  51Testing软件测试网/c-zc y_
    整体流程可概括为:创建项目,明确需求;根据需求生成测试计划;按照计划设计并执行测试;发现问题记录问题。
:IeW#|hE0但实际应用中可能会遇到一系统的阻力了。
Ds,C dD/R0    例如你公司开发整个流程是否正规,是否有文档可依。你是否有权力或有能力参与需求的设计与修改。之所以我所谓的“需求有些情况由开发定义”。TD的功能就在那里,该怎么做合适,我想没有定论,需要根据企业实际情况来定了。  51Testing软件测试网5oUq;L+ge/W}(j T
    对于测试而言,我觉得能设计出一个合理有效的测试用例是最很需要的。这个需要你动脑筋,需要对你产品的功能及业务非常熟悉,否则写用例也是纸上谈兵。用例的设计格式,可以参考TD安装生成的默认测试演示库,那里就是设计整个“订飞机票”网站的测试流程,很有学习价值。  51Testing软件测试网:D j7j$k d
    在测试实验室里,你可以像开发设计业务流程一样,设计出一个测试步骤一步步的执行(Execution Flow)。在执行网格里你可以看到测试的历史记录与结果,我们需要在这里查看测试的进度和BUG的分部。
:@/VB1l*t/t0    缺陷管理里,就是测试和开交流的天堂了。我个人觉得很好用!你可以通过对列的筛选,很快到找到你要需要的信息并进行分析。在测试执行时可以自动添加缺陷,里面还自动记录一些测试信息。在以后的回归测试中,R&D Comments里记录了开发和测试的交互过程,也可以查看历史记录(history)。分析结果并输出……51Testing软件测试网EH3G co0\K
    有一个很隐蔽的功能,在右上角的 tools -> Document Generator 。你可以选择TD里任何你想要的信息,然后设置格式输出到WORD,下班后拿回宿舍分析。  
Z/NNU u dGw0    菜单里的Analysis也是比较常用的工具,可以帮助你分析结果并输出报告。
9p~s1Q$m`/F$Gt0      在Add-Ins Page里有很多插件,可以根据需要下载安装。有office插件、TD浏览器等等……51Testing软件测试网\o*G|+[;@
    不同版本的TD,功能核心都是一样的,只是外观有些变化,增加了一些小功能。至于现在出现的QC我也有幸尝试过,界面色调完全改了,多了文字处理功能、强化了图像分析功能。这些我想用过TD的朋友们肯定很容易上手的啦。51Testing软件测试网8GNPa4eV7hP
    讲到最后,连最重要的用例设计都没详细讲到。因为每家公司的产品和面对客户都不尽相同,其实没有一个固定的说法。我只浅谈一下我的感想吧:  
+PU7r"O c#J0    1、设计用例之前,你必要非常熟悉产品。用产品的每个功能模块与关联要很清楚。51Testing软件测试网S-xC&]qo
    2、更多的去了解客户的需要,有机会多和客服勾通。如果能和客户面对面最好了,客户对产品的要求往往和开发者会有一定的差距。了解业务流你会设计更实际的用例,发现更有意义的BUG。
7V.v!r yK;yl \9K W0    3、多和组内同事讨论,“三人行必有我师”。即使你再强,你也会有想不到的地方,一个人的力量是有限的。
yt2K}qd!N0    4、用例的描述,要简要、清晰。因为你设计的用例可能被别人执行、新员工的参考和学习。
5C:XE^X;W6c6s0    5、每个步骤,尽可能多的想到他的关联,但不要冗余(容易理解不容易做)。
8f} [1z3{\3t.`0    6、一个完整的用例应涉及所有的功能与业务需求(需要很周全的考虑)。51Testing软件测试网^7m q$Z.j+MYw"j;S"~
暂时想到的就这么多吧,欢迎广大的测试朋友们前来补充。
*dPAD:[0    所以,要设计出一个精炼而有效的测试用例,是不容易的。也是我们每个测试人员力求的!  51Testing软件测试网TLk@sB o
TD对于管理而言,相对于对工作进行了量化的标准。在TD上,你可以看到某个人什么时候在做什么事情、当前测试进度到哪了、某个版本缺陷的分布等等等等。对公司而言,产品库的建立是公司的一个资本。IT的工作量的一直是很难衡量的一个问题,TD在此对企业的管理者也提供了一些帮助。
"{:|WF|3S.Z.Q `0    由于某些需要,可能我们需要尝试一些其它的管理工具。我个人也尝试过Rational、开源、其它的。Rational的那一套,我在自动化里有谈到。内容太多了,关于他的CQ,仅仅是缺陷管理,没有TD强大。但Rational是一套解决方案,CQ只是其中一个模块,拿起来和TD比有些不合适。Rational的资料在网上可利用的就更少了,我一直没有研究出什么成绩来,在此就不多说了  。网上还有很多缺陷管理工具,开源的bugzilla就有很多人推荐。但安装都很麻烦,不易维护,功能不也多,我也没有多研究了。还有试过TestTrack..... 这些功能都很少,仅相当于TD中的Defects。还是推荐用TD吧,其它小工具也有他存在的理由,适合一定的需求环境,需要大家可以搜一下。  51Testing软件测试网$w!h$kb dj&E9x+j
    这些可都是白手起家,“搜”出来的喔

TAG: TD TestDirector Mercucy 自动化 软件测试 功能测试

引用 删除 java7001   /   2009-11-04 16:20:42
很受用...
 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

Open Toolbar