框架中有四个主要的部分：

　　1、搜索：这个部分负责跟缺陷管理系统和产品 Build 管理系统交互获得跟用户有关的可验证缺陷信息、对应的产品 Build 信息和测试用例的信息。

　　2、部署环境：负责接收搜索部分提供的结果，准备测试环境。框架中给出了两个部署环境的方案，第一个是创建一个新的测试环境；第二个是查找跟这个用户有关的已经存在的测试环境，并把产品的最新 Build 部署到这个环境中。这里第二个方案也是为了能够更好地重用测试资源，以免造成浪费。

　　3、测试执行：根据搜索部分提供测试用例，调用对应的自动化测试用例脚本进行验证。

　　4、状态更新：根据测试执行的结果自动更新缺陷的状态和内容。

　　框架中提到的不同软件系统，每个团队可以针对自己的实例完成实现。

　　实现部分 1：搜索可验证的缺陷

　　在 RTC 中我们的实现是开始于 RTC 中的一个缺陷查询 (Query)，用户可以自己定义一个缺陷查询包括那些状态时 Resolved 的缺陷。

图 2. RTC 中的缺陷查询

　　清单 1. 引用 RTC 中用户自定义的缺陷查询

　　搜索条件包括三个方面，

　　● 产品– 由于 RTC 同一个项目中可能会涉及多个产品的缺陷记录，而一个用户又有可能会对多个产品的缺陷负责，所以产品作为第一个筛选条件。

　　● 产品版本– 由于 RTC 同一个项目中可能会涉及同一个产品的不同版本的开发以及缺陷记录，而一个用户又有可能会工作于不同的产品版本。

　　● 环境 -- 在 RTC 中可以为不同的项目缺陷记录定义不同的字段，这里可以定义环境的信息。（如图3）

图 3. RTC 缺陷中的环境字段

　　根据用户自定义的缺陷查询和选定的三个筛选条件，我们可以完成第一次筛选，得到待验证的缺陷列表。下面就需要去版本控制系统中查找当前产品版本中包含哪些待验证的缺陷。

图 4. 筛选可验证的缺陷

　　由于本文作者没有直接使用 RTC 作为版本控制软件，而是采用其他软件进行版本控制，所以这里没有具体介绍图 4 中代码的实现。