TD的学习与总结（转载）

上一篇 / 下一篇 2007-06-11 09:19:19 / 个人分类：TD

查看( 1007 ) / 评论( 1 ) / 评分( 5 / 0 )

goL.Gc0TD经验谈原文

4mHYRb9Y2N0

6y,e$` ui8Cx0写了两篇关于测试方面的日志，今天我来回忆一下TD的历程。点击图片可在新窗口打开

"F7\~jO2G0 TD（TestDirector）是一个功能强大的测试管理系统，此系统涵盖了整个测试流程。相对一些其它的一些缺陷管理工具而言，TD容易操作、易学易上手。51Testing软件测试网0o:}"f@9])r5s

u1{J-k A0 由于最早学习的就是TD，到现在已经有一段时间了，前两篇文章（自动化、QTP）居然把这个给淡忘了，惭愧万分。

iy-n*FL M6n0下面开始介绍一下TD吧：
安装与我就不细说了，上网下载安装手册“下一步”就OK了。如果可以的话，安装程序里也有英文的帮助说明。配置此篇暂略过…… 51Testing软件测试网v7C {+}F

TD主要分为四个功能版块：51Testing软件测试网s` zwy
    1、需求Requirements51Testing软件测试网oo,Z3X+KH3L
    2、测试计划Test Plan
    3、测试实验室Test Lab51Testing软件测试网4]3z1`h6n
    4、缺陷Defects51Testing软件测试网P }+b L+Hm

2jJA*?gf[5B.K~:Y0    TD上需求是定义测试内容与详细的需求，理论上是由测试组完成的。但综合公司的具体环境，有些时候可能需要开发来完成。
    测试计划可以由需求直接转化（tools —> Convert to tests），也可根据需求文档自定义测试计划。51Testing软件测试网ju\9~ B,Y.v
    测试实验室里，你可以创建执行流程。这里记录了所有你执行过的测试与结果。
i/~:ZV oX0    缺陷管理栏，记录了测试过程中发现的所有问题，与开发的交互多在于此。51Testing软件测试网}JD&@'?W`

    其实TD的操作并不难，没有代码，不会有太多文字，也全部都是很常用的控件组合。只要你熟悉这个测试流程，使用TD没有问题！  51Testing软件测试网J.k/h$`+t1t)Y/r
    整体流程可概括为：创建项目，明确需求；根据需求生成测试计划；按照计划设计并执行测试；发现问题记录问题。
&i?WRw0但实际应用中可能会遇到一系统的阻力了。51Testing软件测试网J9J+q9\4gPm
    例如你公司开发整个流程是否正规，是否有文档可依。你是否有权力或有能力参与需求的设计与修改。之所以我所谓的“需求有些情况由开发定义”。TD的功能就在那里，该怎么做合适，我想没有定论，需要根据企业实际情况来定了。
/c4~sY Pi \0    对于测试而言，我觉得能设计出一个合理有效的测试用例是最很需要的。这个需要你动脑筋，需要对你产品的功能及业务非常熟悉，否则写用例也是纸上谈兵。用例的设计格式，可以参考TD安装生成的默认测试演示库，那里就是设计整个“订飞机票”网站的测试流程，很有学习价值。
_^ mG3JP'F0    在测试实验室里，你可以像开发设计业务流程一样，设计出一个测试步骤一步步的执行（Execution Flow）。在执行网格里你可以看到测试的历史记录与结果，我们需要在这里查看测试的进度和BUG的分部。
~i"o.GvI0    缺陷管理里，就是测试和开交流的天堂了。我个人觉得很好用！你可以通过对列的筛选，很快到找到你要需要的信息并进行分析。在测试执行时可以自动添加缺陷，里面还自动记录一些测试信息。在以后的回归测试中，R&D Comments里记录了开发和测试的交互过程，也可以查看历史记录（history）。分析结果并输出……
    有一个很隐蔽的功能，在右上角的 tools -> Document Generator 。你可以选择TD里任何你想要的信息，然后设置格式输出到WORD，下班后拿回宿舍分析。
f*?6Ar&PN l^0    菜单里的Analysis也是比较常用的工具，可以帮助你分析结果并输出报告。
%UF.I.M+O1H U3|0      在Add-Ins Page里有很多插件，可以根据需要下载安装。有office插件、TD浏览器等等……
E.J#hd#t$lN r`0    不同版本的TD，功能核心都是一样的，只是外观有些变化，增加了一些小功能。至于现在出现的QC我也有幸尝试过，界面色调完全改了，多了文字处理功能、强化了图像分析功能。这些我想用过TD的朋友们肯定很容易上手的啦。
    讲到最后，连最重要的用例设计都没详细讲到。因为每家公司的产品和面对客户都不尽相同，其实没有一个固定的说法。我只浅谈一下我的感想吧：  51Testing软件测试网%cFF r#s
   1、设计用例之前，你必要非常熟悉产品。用产品的每个功能模块与关联要很清楚。
   2、更多的去了解客户的需要，有机会多和客服勾通。如果能和客户面对面最好了，客户对产品的要求往往和开发者会有一定的差距。了解业务流你会设计更实际的用例，发现更有意义的BUG。
{5z!fJ{5nm0   3、多和组内同事讨论，“三人行必有我师”。即使你再强，你也会有想不到的地方，一个人的力量是有限的。
UpWZA\ yt0   4、用例的描述，要简要、清晰。因为你设计的用例可能被别人执行、新员工的参考和学习。51Testing软件测试网 Lw?zE(N
    5、每个步骤，尽可能多的想到他的关联，但不要冗余（容易理解不容易做）。
   6、一个完整的用例应涉及所有的功能与业务需求（需要很周全的考虑）。
{K*haKn[)zx0暂时想到的就这么多吧，欢迎广大的测试朋友们前来补充。
^`hV*_z0    所以，要设计出一个精炼而有效的测试用例，是不容易的。也是我们每个测试人员力求的！
TD对于管理而言，相对于对工作进行了量化的标准。在TD上，你可以看到某个人什么时候在做什么事情、当前测试进度到哪了、某个版本缺陷的分布等等等等。对公司而言，产品库的建立是公司的一个资本。IT的工作量的一直是很难衡量的一个问题，TD在此对企业的管理者也提供了一些帮助。

B6hY:G H X*|#BX!I0 由于某些需要，可能我们需要尝试一些其它的管理工具。我个人也尝试过Rational、开源、其它的。Rational的那一套，我在自动化里有谈到。内容太多了，关于他的CQ，仅仅是缺陷管理，没有TD强大。但Rational是一套解决方案，CQ只是其中一个模块，拿起来和TD比有些不合适。Rational的资料在网上可利用的就更少了，我一直没有研究出什么成绩来，在此就不多说了。网上还有很多缺陷管理工具，开源的bugzilla就有很多人推荐。但安装都很麻烦，不易维护，功能不也多，我也没有多研究了。还有试过TestTrack..... 这些功能都很少，仅相当于TD中的Defects。还是推荐用TD吧，其它小工具也有他存在的理由，适合一定的需求环境，需要大家可以搜一下。