TD使用简介及测试流程要点.ppt

* * 站在客户角度 TestDirector使用简介 TD使用简介 二、Bug属性介绍 三、测试人员定义的问题严重程度等级 四、Bug优先级定义说明 一、登录TD 一、登录TD 一、登录TD 选择第一项TesTDirector，系统会自动从服务器下载客户端安装程序，并自动安装。如果ie或其他浏览器设置了拦截功能，请点击安装插件；如果安装过程中出错，安装不成功可以直接点击Add-inpage，选中TD客户端下载安装；以后访问TD无需再次安装。 另：注意如果机器安装了其他杀毒或者防火墙软件，如卡巴斯基等限制了6666端口，请去掉该端口的限制。 一、登录TD 一、登录TD 在此处选择所属的域，我们目前的域名是TEST2009，选择项目名称、用户ID和密码即可登录。（项目名称、用户和密码是在项目管理部申请创建测试项目的信息） 登录进入后，选择最上面工具栏菜单的‘DEFECTS’即可看到问题列表。 一、登录TD 一条缺陷记录主要包括： 1、缺陷ID 2、主题 3、详细描述 4、缺陷的状态 5、缺陷的版本 6、模块 7、缺陷的来源 8、严重程度 二、BUG属性介绍 9、缺陷优先级 10、缺陷提交者 11、提交缺陷的日期 12、指定缺陷负责人 13、缺陷是否可重现 14、附件 15、讨论 TD使用简介 三、测试人员定义的问题严重程度等级 四、Bug优先级定义说明 二、Bug属性介绍 一、登录TD 二、BUG属性介绍 1、缺陷ID：每一条缺陷记录都应该有一个自己的ID，用来作为自己唯一的标识。TD自动生成。 2、主题：要使用精确而简短的语言描述主题。描述主题时，应当根据实际情况，简要的描述出自己的操作和现象。一般使用陈述的形式，不应该包含表现个人情绪等感情色彩的内容，比如感叹号或者一些形容词。 3、详细描述：此处应当把完整的测试过程或者测试条件分析整理成一系列清楚的、可准确重现缺陷的测试步骤。 4、缺陷的状态：每条缺陷记录都应当有一个状态，用来表明这条缺陷记录当前的处理情况。 二、BUG属性介绍 缺陷状态： open—表示测试人员提交的问题； fixed—表示开发人员已作修改； Rejected—表示开发人员认为不是缺陷或者本版本不作处理待下一版本修改；（打成Rejected状态的问题，需开发人员在comment 里面加以说明） Reopen—表示测试人员验证fixed状态的缺陷时，发现问题仍然存在； Deferred—表示遗留问题（经协商在该版本中不作修改的缺陷）； Close—关闭缺陷； N/A—表示非问题。 此处要着重强调一下，开发人员可以修改的状态是从open或reopen转换成fixed和rejected两种。也可以按状态过滤查看。 以上状态也是我们定义的整个bug的生命周期。 二、BUG属性介绍 二、BUG属性介绍 5、缺陷的版本：表明发现缺陷的版本，一般使用开发过程中的内部提交程序版本来表示。 6、模块：用来说明缺陷发生在哪个程序模块中。如果希望随时都能查询到某个功能或模块一共发现了多少缺陷，哪些已经被解决并确认通过。可以通过查看该项获取信息。 7、缺陷的来源：软件测试并不仅仅是指对于软件最终具体实现的测试，还包括对软件需求和软件设计的测试。在软件开发过程中的需求阶段、设计阶段、编码阶段以及产品发布后的售后支持阶段，都会发现不同的软件缺陷，来自于不同阶段的缺陷应当填写不同的标识。我们使用的分4类：需求、设计、编码、第三方。 二、BUG属性介绍 8、严重程度：缺陷的严重程度用来描述出现的缺陷对系统的影响。我们划分为： A-极其严重问题 B-严重问题 C-一般问题 D-轻微问题 9、优先级：缺陷的优先级用来描述某个缺陷应当被赋予的关注程度。我们使用分为： 1-立即改 2-排队 3-不紧急 10、缺陷的提交者：缺陷的提交者并不仅仅是测试人员，在实际工作中，所有参与项目或者项目有关的人员都可以提交自己发现的缺陷。 11、提交缺陷的日期：记录缺陷提交的日期。 二、BUG属性介绍 12、指定缺陷负责人：每一条缺陷记录都应当指定一个负责人，并由其来负责解决这个缺陷。缺陷负责人需要根据缺陷的来源和具体缺陷信息来选择。 另：开发人员可以通过过滤分派给自己的缺陷进行查询，方便修改。 13、缺陷是否可重现：Y表示缺陷可重现，N表示缺陷不可重现，属于偶然。 14、附件：一般是测试数据说明文件和问题的屏幕截图以及被测软件运行的相关日志文件。 15、讨论：在我们使用TD的Comment一栏里可记录交流信息。为缺陷提交者和缺陷负责人提供了一个沟通的平台。 二、BUG属性介绍 测试人员定义的问题严重程度等级是指在站在用户角度看到的问题状态和现象。 错