终于尝试着将需求,计划,实践,缺陷联系起来(图多,杀小猫)
自己试的，不知道是否正确，写出来，请大家指正。起因： 公司的缺陷管理，一直只使用TD中的Defects部分，说白了，就是个功能全面的留言板，而没有把TD的全部功能用起来。我下边的叙述，就是尝试把整个TD应用起来。
软件配置：Win2000 Server+SQLServer2000+各种补丁+TestDirector 7.6+SP4
先写好Requirements,注意树状的分支，该写的项目就写，别偷懒。
最小的分支最好是一个功能点。
然后tools-covert to tests-convert all
[ 本帖最后由 redsong 于 2005-11-15 13:10 编辑 ] 三种选择中
第一种是把需求树中的最小级别转换成Test Plan中的“步骤”
第二种是把需求树中的最小级别转换成Test Plan中的”最小级别“
第三种是把需求树中的最小级别转换成Test Plan中的”目录“,(目录下边还可以自己增加树状的Test Plan结构)
个人认为 选择第二种比较好。 下一步之后可以在 目录(Subject) 测试(Test) 步骤(Design Step) 描述(Description) 之间转换
这里用中文显然表达的不清楚 还是用英文更好。
点Legend可以看到详细的说明
文件夹样子的的图标是 Subject
M的图标是Test
粗粗的叹号是Design Step
文本文件的图标是Description
这里我默认啥都没改。 再下一步是选 转到Test Plan之后的路径 转到Test Plan后 左侧还是树状的结构。
现在要做的是 在右侧 对每个不可细分的需求点 增加测试步骤的描述。
左侧的树状结构中选中某个不可再分的需求点(粗粗的M的图标)
右侧 选中“Design Steps” 之后点第一个图标(两个叹号一个加号的图标) New Step
输入 测试这个功能点的每一个步骤。 写好之后 大致是这样的情况 接下来是Test Plan和Test LAB之间的关系。 这块我是这样理解的，也是我最不敢肯定我理解的是否正确的地方
整个项目，Test Plan有很多，但是，时间，人力的限制，不可能每个Test Plan都去做一遍测试，而仅仅是把重要的Test Plan进行测试， 这时候，就要把选择需要做测试的Test Plan 转到Test Lab中来。
我不肯定我的理解是否正确，希望大家斧正。
左侧New Test Set之后 右侧切换到Execution Flow,之后点Select Tests 这时最右侧出现Test Plan中的树状结构。
右击要进行测试的Test Plan中的最小分支(M图标)，点 Add Tests to Test Set,出现如图所示的结构。 这时候点Run 或者Run Manually 开始进行测试 上图中 点Exec Steps依照已经写好的步骤进行测试。
[ 本帖最后由 redsong 于 2005-11-15 17:04 编辑 ] 如果某个步骤通过了 在Status中选择Passed 如果失败了选择Failed 同时 Add Defetc.
[ 本帖最后由 redsong 于 2005-11-15 17:05 编辑 ]
先回后看！
辛苦！！！ 这时 Add Defetc的时候内容中 会自动增加一些东西。到此为止 我感觉需求 测试Plan测试LAB 缺陷终于联系起来了。
[ 本帖最后由 redsong 于 2005-11-15 17:07 编辑 ] 辛苦
学习 最后说说我的想法：
1 TD功能太强大了。仅仅用他的缺陷管理这部分，就已经能够把测试过程中的工作流问题完全管起来。
2 如果想使用TD的其他功能，那么最好的办法是 要么都用，要么都不用。
比如 只想用需求部分和缺陷部分，而中间的Plan和Lad省略不用，这样不是很显示。
3 如果用TD，最好所有的人都用TD. 比如写需求的人用的是word,写测试用例的人用Excel，而真正测试的人用TD,这样很麻烦。
4 Test Plan里边的步骤的确很麻烦，无形中会增加很多工作量。 这块的应用，我认为应该是一个人写好，其他人来用的。比如一个人写好详细的测试用例。然后找一堆不是很懂这套产品的人按照测试用例来操作。如果写测试用例的人和执行测试的人是同一个，那么，如此详细的测试用例，似乎用处就不是很大了。
我是新手，上边所有的图文，都是自己摸索出来的，肯定有思路不对的地方，大家别照超，欢迎批评指正。
最后，感谢另外一个帖子中tofy兄弟给我的提示“TEST LAB就是测试实施了，可以从TEST PLAN抽取部分或全部的用例，然后来执行，用例执行完以后，相应的需求和用例的状态会自动发生改变，当然事先需求和用例必须要关联起来；”---这句话给了我很大的帮助，谢谢tofy.
[ 本帖最后由 redsong 于 2005-11-15 13:52 编辑 ] 不好意思，没等发完就回帖了。
谢谢楼主了！ 所有的提到“粗粗的叹号”的地方 ，替换为"脚印"更好一些。体现“步骤”的意思。 很好的帖子，看了受益匪浅，虽然我公司目前的环境中TD也只用了Defect模块，但将来新项目若测试先期介入的话肯定会把TD的其它功能模块利用起来。谢谢楼主这篇文章，非常有实践性与借鉴性。支持！ 好文!
不过
LZ使用TEST直接与DEFECTS关联这一块好象不太妥当,如果是多个TEST出现的都是一个BUG的情况怎么对应啊? 一个DEFECT只能对应一个TEST,第二个关联的出现会切断DEFECT与第一个TEST的关联. 如果这样的话就只能看到BUG,而找不到TEST了. LZ有什么高招解决这个问题么? 原帖由 ken6328 于 2005-11-15 20:11 发表
好文!
不过
LZ使用TEST直接与DEFECTS关联这一块好象不太妥当,如果是多个TEST出现的都是一个BUG的情况怎么对应啊? 一个DEFECT只能对应一个TEST,第二个关联的出现会切断DEFECT与第一个TEST的关联. 如果这样的话 ...
你的完整意思我不太明白，但是“多个TEST出现的都是一个BUG的情况” 这块我理解。
以前只应用Defects部分的时候，我鼓励所有测试人员写上他们发现的所有BUG，而不用管同样的BUG以前是否被其他人提交过。我觉得这样做至少有3个好处：
1 重现：比如一个BUG, A测出，但是不能重现，而同样的Bug,B也测出，无形中就相当于重现了。
2 工作量：如果B测试出来的BUG因为发现A已经提交过同样的了而没有提交，无形中对B的工作量有影响。
3 因人而异：同样的BUG，A和B会有不同的理解，从各自不同的角度去叙述，有助于研发人员修改bug.
上边提到的是只应用Defcts部分的时候，现在刚刚尝试着吧需求，用例，实践结合起来。怎样更有助于工作，还理解的不是很透彻，还望多指教。 哦I see that!
可是在统计BUG数的时候会很麻烦啊,有很多相同的BUG,造成在TD中无法简单的直接生成产品真实的BUG率.
不容易掌握产品的测试进度和测试深度啊.
呵呵这只是我个人的感觉
