日志 - 日历
2008 7.24 Thu
  12345
6789101112
13141516171819
20212223242526
2728293031  
«» 2008 - 7 «»
搜索BLOG文章
 
博客基本信息
用户名: hulinyan
等级: 小学生
在线时间: 145 分钟
日志总数: 51
评论数量: 91
访问次数: 46729
建立时间: 2006-04-27
最新访问

XML RSS 2.0 WAP

我的日志
TD使用小结2007-04-21

TD使用小结:

TD的使用主要有四块,其中每块中都有报告分析和图表分析功能,可以生成各种报告和图表,但是报告分析功能TD提供的模板太乱了,不好用,自定义模板麻烦,很少用,图表分析功能倒是挺好用的,比较直观,而且提供的条件组合也挺多的,测试实验室的分析不太好用,可能是目前测试集的生成比较乱,只能通过日期看到每天的测试执行情况,可能对了解测试进度有点帮助,统计和分析就不行了。自定义显示列功能也挺好的,每个人在测试各阶段关注的东西都不同,自定义一下显示列可以让关注的东西很清晰,而且还可以保存到收藏夹,使用很方便。

1.     测试需求:

建议在添加需求时在备注栏说明原始需求的出处,虽会增加部分工作量,但是这对需求评审、用例评审、测试集的生成,添加缺陷阶段都有好处,特别像银联项目的需求,测试需求分析时从多份文档提取需求,后来因测试及问题反馈等原因又进行了补充,时间一久,对需求有很多疑问要重新确认,麻烦;

2.     测试计划:

A.      对于与需求一一对应的测试用例可以从需求直接生成,这样既不容易遗漏用例,也省去关联需求的操作;

B.      用例评审通过时应将用例的状态修改为ready,这样方便通过分析功能查看是否所有用例都通过评审,也方便筛选;

C.      公共模块的用例可以使用测试模板和参数功能,可以解决公共模块用例设计容易导致用例错误及在测试执行时才要求输入参数的问题,提高测试用例的复用,具体的用法可参考附录1.TDCase的复用

3.     测试实验室:

A.     简化测试记录过程;

原做法:通过时则将状态修改为pass,并在实际结果中填ok,失败时将状态修改为fail,并在实际结果中记录现象。

建议:通过工具栏提供的通过按钮 <formulas></formulas>和失败按钮 修改状态,状态为pass时,填写ok意义不大,通过 将状态置为passTD会自动跳到下一步,不需要手工选择步骤,失败时点击 按钮将状态置为failTD会停在当前步骤,这时可以在实际结果栏进行响应说明;

B.      测试执行中添加bug

Bug的添加有两种方式:

直接在缺陷管理中进行添加,此时需要对所有步骤及预期结果、实际结果进行描述,并

需要手工选择subject(此项选择在统计模块bug数时用到,因目前没有进行这方面的统计,

此项为可选项,添加时不会去选择这项)。

在测试执行时也可以通过工具栏的添加缺陷按钮进行bug的上报,此时TD会自动选择subject;并将相关的用例信息及当前步骤的操作说明、预期结果、实际结果添加到描述中,可以简化很多添加bug的步骤(因目前部分用例将步骤分的很细,导致这时TD自动添加的描述可能不足以说明bug的操作步骤,需人工进行补充说明,这点可以在测试用例设计时进行改善,推荐测试执行时发现的bug都采用这种方式进行上报)

4.     缺陷管理:

验证bug确认bug已经修复,添加注释,关闭bug,此时应在关闭版本选项中选择关闭版本,这样可以方便筛选和统计,也省去注释中对关闭版本的说明;

确认未修复的bug,添加注释后重开bug,此时应将发现版本修改为验证时使用的版本,因在bug验证阶段,开发人员可能同时在解决bug,此时上一轮修复的bug将和本轮修复的bug混在一起,无法筛选出来,而TD提供的选择列中没有重开bug版本选项,目前可通过修改发现版本进行区分;

 

附录1.

TDCase的复用
在你设计的测试步骤里,可以调用其他手工测试。 当你运行测试时,测试步骤中调用的测试作为这个测试的一部分。这种方法很有用,例如,如果你使用了测试模板,你就可以在不同的测试中重复使用。
为了增加一个的测试的适应性和能力,你可以在测试中添加参数,然后在测试中调用它。参数是一个变量,它可以替换特定的测试中分配给它的一个定值。你可以根据调用它的测试或一个测试集在不同的场所下来改变参数的值。
例如,你可以创建一个“Login_Template”,它记录了当启动应用程序时,登录的用户名及密码信息。你需要在多个测试的开始调用这个“Login_Template” 但在一些案例中,你需要用不同的用户比如administrator 登录。因此你要创建两个参数 <<user name>><<password>> 根据不同的调用“Login_Template”的测试来改变这些参数的值。如果所有的调用都是使用一个用户登录,你可以为这个参数的用户及密码设置一个默认值。
这个部分包括了下面几个方面:
一、创建测试模板
test plan tree 在你可以定义一个手工测试为测试模板。一个测试模板通常包含了参数,它可以被不同的测试调用。
注意: 把一个测试设成一个测试模板来使用只是一个过滤的目的。你不需要设置一个测试为测试模板仅仅为了能被调用或添加参数。
To create a template test:
test plan tree中右击一个测试, 选择 Template Test. 一个方框会加到手工测试图标的上,这就表明现在它是一个测试模板。
二、添加参数
你可以在一个手工测试的步骤的 description expected results中添加一个参数。
To add a parameter:
1.
Design Steps标签中, 把焦点放在一个步骤的Description Expected Results 中,就可以添加参数了。
2.
点击 Insert Parameter 按钮 。打开参数属性对话框。
3.
输入一个 Parameter Name,点击OK。一个新添加的参数的语法是<<parameter name>>
三、调用含参数的测试
当你在design steps中调用一个包含参数的手工测试时,你可以为这个参数赋值。
To call a test with parameters:
1.
Design Steps标签中, 点击New Call to Test 按钮 。打开Select a Test 对话框。
2.
默认只会显示template tests。如果你要选择的测试不是测试模板,清除Show only Template Tests
3.
选择你要调用的带参数的手工测试。打开一个显示被调用的测试中包含的参数的对话框。
4.
Value 列,输入每个参数的值,点击OK
5.
Select a Test 对话框上点击OK。这个调用作为一个链接插在design steps中,在调用的测试里会显示出这个参数所赋的值。
注意: 如果你在调用测试的时候不为参数赋值,当你把测试加入测试集或运行测试时会提示你要给参数赋值。
6.
在调用的测试中编辑参数的值,右击调用的测试选择Called test parameters。在Called Test Parameters 对话框中为参数重新赋值,点击OK


原创文章如转载,请注明:转载自懒懒萚兮的blog [ http://hulinyan.blog.zj.com/ ]
本文链接地址:http://hulinyan.blog.zj.com/blog/d-121016.html

TAG: 测试
相关文章
文章评论0条回复