简介：在作为系列的后一篇覆盖的部分是缺陷生命周期的后一个环节，缺陷的验证。本文主要描述了如何通过 Rational Team Concert（RTC）、Rational Quality Manager（RQM）及 IBM Workload Deployer（IWD）实现缺陷验证的自动化，而且笔者通过一个 RTC web 插件来展现自动化页面。

　　背景

　　系列前两篇中我们描述了如何用 IBM 产品帮助开发人员快速重现缺陷问题，下面本文主要描述一下我们是如何使用 IBM 产品加速缺陷验证过程的。

　　在缺陷验证的过程中，测试人员需要完成一下几个任务：

　　● 定位可验证的缺陷 (Verifiable Defect)

　　　　▲ 可验证的缺陷是指缺陷对应的产品代码变动已经被开发人员提交并包含在产品新版本中。

　　　　▲ 定位的范围一般包括

　　　　　　→ 测试人员自己提交的缺陷（Created by）

　　　　　　→ 由其他人员提交的，需要测试人员关注的缺陷（Subscribed by）

　　　　▲ 测试人员一般需要针对每个关注的缺陷查看是否相应的代码变更已经包括在新产品版本中。

　　● 快速部署缺陷验证的测试环境

　　　　▲ 环境准备一直是比较耗时的部分，不过这里我们可以借助在第一篇中我们创建的重现缺陷用的 IWD 中的虚拟系统模式 (Virtual System Pattern)。

　　● 调用对应的测试用例执行

　　　　▲ 测试人员需要找到对应的测试用例，在新产品版本中重现执行。

　　● 更新缺陷状态和信息

　　　　▲ 根据新的测试执行结果，可以判断缺陷是否还存在，从而更新缺陷状态和信息记录。

　　本文主要解决的问题

　　● 如何快速定位可验证的缺陷

　　● 把缺陷验证环节自动化，自动化内容包括：

　　　　▲ 准备测试环境

　　　　▲ 执行测试用例

　　　　▲ 更新缺陷状态和信息

　　● 更好的用户体验

　　　　▲ 现在每个团队都会在不同程度上通过自动化工具来解决上述问题。由于上述工作涉及存储不同信息的软件系统，测试人员需要登陆不同的系统采取相应的操作，例如：

　　　　　　→ 缺陷管理系统：开发和测试人员在这里可以更改缺陷的内容和状态。

　　　　　　→ 产品 build 管理系统：每个产品在正式发布前，内部的研发解决都会采用某个软件或系统对产品代码进行管理并且对内部发布产品非正式版本 (Build) 用于开发和测试。产品 Build 管理系统会记录每个 Build 所包含的代码变动，也会同时记录这一代码变动是由哪个缺陷引起的。

　　　　　　→ IT 环境管理系统：这一系统通常会为开发测试人员提供可用的环境。在某些团队中会通过不同的软件来调用 IT 环境管理系统来实现不同程度的自动化环境部署。

　　　　　　→ 测试管理系统：存储测试用例，测试结果和测试计划等内容。

　　　　▲ 所以开发和测试人员在完成缺陷验证工作的过程中，需要登录各种不同的软件系统，而没有统一入口的使用方式会带来不好的用户体验。

　　实现框架