TD使用简介及测试流程PPT课件.ppt

TestDirector使用简介 2020 3 25 1 TD使用简介 二 Bug属性介绍三 测试人员定义的问题严重程度等级四 Bug优先级定义说明 一 登录TD 2020 3 25 2 一 登录TD 2020 3 25 3 一 登录TD 选择第一项TesTDirector 系统会自动从服务器下载客户端安装程序 并自动安装 如果ie或其他浏览器设置了拦截功能 请点击安装插件 如果安装过程中出错 安装不成功可以直接点击Add inpage 选中TD客户端下载安装 以后访问TD无需再次安装 另 注意如果机器安装了其他杀毒或者防火墙软件 如卡巴斯基等限制了6666端口 请去掉该端口的限制 2020 3 25 4 一 登录TD 2020 3 25 5 一 登录TD 在此处选择所属的域 我们目前的域名是TEST2009 选择项目名称 用户ID和密码即可登录 项目名称 用户和密码是在项目管理部申请创建测试项目的信息 2020 3 25 6 登录进入后 选择最上面工具栏菜单的 DEFECTS 即可看到问题列表 一 登录TD 2020 3 25 7 一条缺陷记录主要包括 1 缺陷ID2 主题3 详细描述4 缺陷的状态5 缺陷的版本6 模块7 缺陷的来源8 严重程度 二 BUG属性介绍 9 缺陷优先级10 缺陷提交者11 提交缺陷的日期12 指定缺陷负责人13 缺陷是否可重现14 附件15 讨论 2020 3 25 8 TD使用简介 三 测试人员定义的问题严重程度等级四 Bug优先级定义说明 二 Bug属性介绍 一 登录TD 2020 3 25 9 二 BUG属性介绍 2020 3 25 10 1 缺陷ID 每一条缺陷记录都应该有一个自己的ID 用来作为自己唯一的标识 TD自动生成 2 主题 要使用精确而简短的语言描述主题 描述主题时 应当根据实际情况 简要的描述出自己的操作和现象 一般使用陈述的形式 不应该包含表现个人情绪等感情色彩的内容 比如感叹号或者一些形容词 3 详细描述 此处应当把完整的测试过程或者测试条件分析整理成一系列清楚的 可准确重现缺陷的测试步骤 4 缺陷的状态 每条缺陷记录都应当有一个状态 用来表明这条缺陷记录当前的处理情况 二 BUG属性介绍 2020 3 25 11 缺陷状态 open 表示测试人员提交的问题 fixed 表示开发人员已作修改 Rejected 表示开发人员认为不是缺陷或者本版本不作处理待下一版本修改 打成Rejected状态的问题 需开发人员在comment里面加以说明 Reopen 表示测试人员验证fixed状态的缺陷时 发现问题仍然存在 Deferred 表示遗留问题 经协商在该版本中不作修改的缺陷 Close 关闭缺陷 N A 表示非问题 此处要着重强调一下 开发人员可以修改的状态是从open或reopen转换成fixed和rejected两种 也可以按状态过滤查看 以上状态也是我们定义的整个bug的生命周期 二 BUG属性介绍 2020 3 25 12 二 BUG属性介绍 2020 3 25 13 5 缺陷的版本 表明发现缺陷的版本 一般使用开发过程中的内部提交程序版本来表示 6 模块 用来说明缺陷发生在哪个程序模块中 如果希望随时都能查询到某个功能或模块一共发现了多少缺陷 哪些已经被解决并确认通过 可以通过查看该项获取信息 7 缺陷的来源 软件测试并不仅仅是指对于软件最终具体实现的测试 还包括对软件需求和软件设计的测试 在软件开发过程中的需求阶段 设计阶段 编码阶段以及产品发布后的售后支持阶段 都会发现不同的软件缺陷 来自于不同阶段的缺陷应当填写不同的标识 我们使用的分4类 需求 设计 编码 第三方 二 BUG属性介绍 2020 3 25 14 8 严重程度 缺陷的严重程度用来描述出现的缺陷对系统的影响 我们划分为 A 极其严重问题B 严重问题C 一般问题D 轻微问题9 优先级 缺陷的优先级用来描述某个缺陷应当被赋予的关注程度 我们使用分为 1 立即改2 排队3 不紧急10 缺陷的提交者 缺陷的提交者并不仅仅是测试人员 在实际工作中 所有参与项目或者项目有关的人员都可以提交自己发现的缺陷 11 提交缺陷的日期 记录缺陷提交的日期 二 BUG属性介绍 2020 3 25 15 12 指定缺陷负责人 每一条缺陷记录都应当指定一个负责人 并由其来负责解决这个缺陷 缺陷负责人需要根据缺陷的来源和具体缺陷信息来选择 另 开发人员可以通过过滤分派给自己的缺陷进行查询 方便修改 13 缺陷是否可重现 Y表示缺陷可重现 N表示缺陷不可重现 属于偶然 14 附件 一般是测试数据说明文件和问题的屏幕截图以及被测软件运行的相关日志文件 15 讨论 在我们使用TD的Comment一栏里可记录交流信息 为缺陷提交者和缺陷负责人提供了一个沟通的平台 二 BUG属性介绍 2020 3 25 16 测试人员定义的问题严重程度等级是指在站在用户角度看到的问题状态和现象 错误按照严重程度分为四类 A类问题 极严重错误 错误导致了产品失败 包括程序无法继续执行 系统崩溃等 B类问题 严重错误 错误导致了某一项功能不能执行 或后续的功能不能执行 或当前操作范围内的数据受到破坏 或对系统造成一定程度的影响 或重要数据的错误 但在严格的限制下产品可以运行等 C类问题 一般性错误 指一般性的执行结果与预期结果不符合的错误 但在很小的限制下产品可以运行 D类问题 轻微错误 错误是表面化的或微小的 三 测试人员定义的问题严重程度等级 2020 3 25 17 TD使用简介 二 BUG属性介绍四 Bug优先级定义说明 一 登录TD 三 测试人员定义的问题严重程度等级 2020 3 25 18 以上四类错误举例说明如下 A类问题 如程序运行时发生一般性保护错误 导致程序无法继续运行 或导致死机 计算错误 丢失数据 功能丢失 出现系统错误 与前一版本不兼容等 B类问题 如当前输入的数据全部丢失 或由于资源泄露导致系统可用资源下降 功能键不可用或错误等 C类问题 如提示框重复 不可用的按钮应该隐藏或变灰 格式验证不严格 日期格式验证 操作之后 光标位置停留不正确等 D类问题 如屏幕上某个字符串被覆盖 文字语法 拼写 格式错误 菜单名称与里面的名称不一致等 三 测试人员定义的问题严重程度等级 2020 3 25 19 TD使用简介 三 测试人员定义的问题严重程度等级 四 Bug优先级定义说明 一 登录TD 二 Bug属性介绍 2020 3 25 20 Bug优先级定义1 立刻改 否则测试无法进行 2 排队 Bug需要正常排队等待修复或列入软件发布清单 3 不紧急 Bug可以在方便时被纠正 四 Bug优先级定义说明 2020 3 25 21 软件测试流程 2020 3 25 22 1 项目立项之初 测试工作负责人根据项目任务书确认测试项目基本信息 2 测试工作负责人确认项目测试经理 3 项目测试经理编写测试计划 包含测试时间安排 资源使用 测试策略 测试内容 风险 退出准则等等 4 项目测试经理根据软件需求规格说明书等编写测试用例 其中参加其阶段评审 注意需求的变更等活动 5 项目测试经理组织测试计划及测试用例进行评审 评审通过到步骤6 不通过 到步骤4 6 项目经理在项目集成测试完毕 向测试工作负责人提交系统测试执行申请 经部门经理或部门主管 测试工作负责人 项目管理工程师批准后 安排项目测试工程师和测试工程师执行测试 7 测试工程师进行系统预测试 检验系统是否可以进行正式的系统测试 如果达到系统预测试标准 执行8 否则反馈给项目经理 返回6 软件测试流程 2020 3 25 23 8 测试工程师根据测试用例 执行第一轮测试 提交测试问题 反馈给项目组 详见 Bug管理规程 文档3 1提交 9 项目经理 编码工程师确认是否是一个问题 是否修改 详见 Bug管理规程 文档3 2确认Bug 10 项目经理 编码工程师将已确认为问题的Bug分派给编码工程师进行修改 详见 Bug管理规程3 3分派Bug 11 测试工程师对第一轮测试修改的问题验证 对遗留问题 非错问题和项目测试经理 编码工程师进行确认 产生歧义提交测试工作负责人和项目经理审定 对已改问题进行关闭 详见 Bug管理规程 文档3 4修改Bug 3 5验证Bug和3 6关闭Bug 12 判断是否达到测试退出标准 没有达到标准 依次重复7至