使用批准在Rational Team Concert中实施测试驱动的开发，代码审查和集成测试
什么是测试驱动开发？
测试驱动开发（TDD）是一种软件开发过程，要求开发人员针对所需的功能编写（最初失败的）自动化测试用例，然后添加通过测试用例所需的最少代码，最后重构代码并确保自动化测试仍然通过。
在项目流程中添加TDD可以通过测试需求将重点放在开发上。 在传统开发中，编写代码，然后开发测试用例以测试代码。 在TDD中，在开始实施之前就编写了满足要求的测试用例（通常称为单元测试）。
什么是代码审查？
代码审查是计算机源代码的系统检查（通常称为对等审查）。 它旨在发现并修复在初始开发阶段中被忽略的错误，从而提高软件的整体质量和开发人员的技能。
这是非常重要的代码质量实践，通常由于实践上缺乏这种形式，因为正式的代码审查需要大量的投资来准备审查事件和执行时间。 在这里，我描述了如何将审核工作（代码审核指标）设置为项目流程的一部分，以深入了解将收益与投资进行比较。
什么是集成测试？
集成测试（有时称为集成和测试，简称为I＆T）是软件测试的阶段，在该阶段中，将各个软件模块组合在一起并作为一个整体进行测试。 它被实现为在单元测试完成后验证功能，性能和可靠性要求。
本文介绍如何设置项目流程，以使用IBM®Rational Team Concert™Scrum模板有效地实现这些流程。 在本文中，我描述了在我们的项目流程中完成的定制以及如何在开发流程中使用Rational Team Concert流程来强制执行TDD，代码审查和集成测试。
典型的软件开发项目流程
使用Rational解决方案的典型项目流程工作流可以描述为：
- 产品需求分为开发任务，并捕获在Rational Team Concert工作项中。 工作项目由经理分配给开发人员。
- 测试人员在Rational Quality Manager中针对这些需求开发测试用例。 这些测试用例通过“开发项目”部分链接到工作项目，以实现可追溯性链接。
- 开发人员在Rational Team Concert工作项中捕获所有实现细节和工作工件。
- Rational Team Concert中的批准过程用于确保在开发过程中实施TDD，即在实施开始之前就开发了测试用例。
- 为了质量管理目的，代码审核过程紧密集成在项目过程中。 Rational Team Concert中的审阅过程用于通过为每个变更集创建审阅记录来确保在项目中实施这种代码质量实践。 除非批准代码检查记录，否则无法解决该工作项。
- 集成测试完成了开发周期。 Rational Team Concert验证记录用于强制执行项目中的集成测试过程。 在批准验证记录之前，无法关闭工作项。
下一部分“项目区域定制”详细介绍了在Rational Team Concert scrum模板中完成的定制，以实施上述过程。
项目区域定制
在这里，我们使用Rational Team Concert Scrum模板来定义项目过程。 以下是为将TDD和审阅过程添加到默认Scrum流程而进行的项目区域自定义。 定义了新的工作项属性。
- TDD
- 在开始实际实施之前，确保测试用例的开发。 此属性是一个枚举，其值为“未完成”，“进行中”，“已完成”和“不需要”。 这些值指示测试用例开发状态。 这些值可以根据项目需要进行自定义。
- 检讨工作
- “持续时间”用于跟踪在评论中花费的精力。 这是跟踪项目是否真正从质量审核中获益的有用指标。 一旦在项目中执行了审查流程，我们就可以看到从开发到集成测试的缺陷泄漏量大大减少了。
创建TDD枚举并添加属性
- 在项目区域：流程配置选项卡中，转到项目配置>配置数据>工作项>枚举 。
- 为TDD添加一个新的Enumeration ID，并定义它可以包含的文字，如图1所示。
图1：定义TDD枚举
图2：定义TDD枚举文字
现在，将新的工作项属性添加到工作项类型。
- 在项目区域：过程配置选项卡中，转到项目配置>配置数据>工作项>类型和属性 。
- 选择需要为其定义这些属性的工作项类型。 在我们的情况下，这些将为“缺陷和任务”定义。 在Attributes部分中，选择Add以创建新的自定义属性Review Effort，其类型为Duration，而TDD的类型为TDD（Enumeration），如图3和4所示。
图5显示了“属性”列表中的新属性。
图3：在工作项自定义属性中添加审阅工作
图4：在工作项自定义属性中添加TDD
图5：工作项自定义属性中的TDD和审阅工作量
流程实施
TDD流程实施
项目需求分为开发任务，在项目区域中为其创建了相应的工作项。
- 项目经理将工作项分配给开发人员。
- 在开始开发工作时，开发人员与测试团队一起启动测试开发。 这是通过为TDD创建批准记录（即测试用例开发）并将测试人员添加为批准者来完成的。
- 测试人员会从Rational Team Concert收到有关批准创建的电子邮件通知。
- 测试人员在Rational Quality Manager中标识测试用例和场景，以确保覆盖工作项中详细描述的需求，并将这些测试用例链接到“开发项”部分中的工作项。
- 测试人员将工作项中的TDD属性值更改为“进行中”，以反映测试用例的开发进度。
- 一旦确定了所有测试用例并与开发人员一起审查，测试人员便将TDD属性值更改为“已完成”，并批准TDD批准记录。 通过源代码管理操作设置“要求交货时批准工作项（客户）”的前提，可以确保只有在批准TDD批准记录后才能交付为工作项设置的任何更改。 这将在允许任何代码更改之前强制执行TDD。 。
图6：强制执行TDD批准流程的前提条件
代码审查流程实施
- 开发人员根据需求和测试用例形式的工作项输入完成开发。
- 开发人员执行在Rational Quality Manager中标识的测试用例，作为功能验证测试的一部分。
- 实施和测试完成后，开发人员将代码更改集附加到工作项。
- 开发人员启动审核过程。
注意：
仅在代码审查后才完成代码交付。 - 作为审阅过程的一部分，开发人员为需要审阅的变更集创建审阅类型的批准，批准者设置为应审阅变更的人员。
- 通过电子邮件或事件馈送中的事件将审阅请求通知审阅者。
- 审阅者转到工作项，并在“更改资源管理器”视图中查看更改集。 有时，审阅者会将更改集接受到他的工作区中，以便他/她可以仔细查看，但是通常在更改浏览器中查看它们就足够了。
- 审阅者将来自审阅的任何评论添加到工作项，并批准或拒绝批准。
- 开发人员检查所有注释并重新启动过程，直到检查人员和开发人员就代码更改达成一致。
- 审核记录获得批准后，开发人员会将更改交付给集成测试。
通过“工作项”操作设置“保存工作项（服务器）”上的“需要批准”的前提条件，确保只有在批准“审核”后才能解决工作项。 如果重新打开工作项目，则会在待处理状态下创建“审阅”类型的新批准。 这样可以确保进一步检查任何代码更改。
图7：实施代码审查批准流程的前提条件
集成测试流程
交付更改后，开发人员在待处理状态下创建新的“验证”批准类型，并在解决工作项时将其分配给测试人员。 验证过程完成了集成测试过程。
仅当批准验证后，工作项目才关闭。 这是通过在“工作项”操作中设置“保存工作项（服务器）的所需批准”的前提而实现的。
图8：实施集成测试过程的前提条件
现在已经完成了在项目中有效实施带有代码质量和集成测试的TDD所需的过程定制。