保证软件的质量和全面的审计跟踪

监管环境需要进行审计跟踪，记录每个工件的测试时间、测试者的名称和测试结果。监管环境还需要一个能支持电子签名的审批流程。了解如何使用 IBM Rational Quality Manager 创建和维护高品质的审计跟踪。

IBM Rational Quality Manager 是一个协作中心，可以跨几乎任何平台和测试类型实现由业务驱动的软件和系统品质。它是针对 Collaborative Lifecycle Management (CLM) 工具的 Rational 解决方案的一部分，构建于 Jazz 平台之上。该软件可以帮助团队无缝共享信息，通过自动化加快项目时间表并报告关键的指标，从而实现明智的发布决策。

Rational Quality Manager 可以帮助质量保证团队：

合作：无缝共享项目信息和状态更新，使团队成员可以在整个生命周期内同步团队工作。

自动化：减少劳动力密集型活动，加快项目进度。

管理：理解和报告项目指标，以便准确、可靠、及时地做出发布决策。

Rational Quality Manager 可以结合使用需求管理工具 IBM Rational Requirements Composer and IBM Rational DOORS。每当需求发生改变时，您都可以链接测试用例并将它标记为可疑，这样所有人都可以了解到不断改变的业务需求和用户需求的测试结果。

Rational Quality Manager 集成了广泛的自动化测试工具，比如 IBM Rational Functional Tester，Selenium（开源），IBM Rational Performance Tester，IBM? Rational? Test Workbench 等等。有了这些产品，您就可以从一个集中的位置使用各种工具运行测试并收集测试结果。

监管环境中的需求

监管环境要求您维护永久的签名记录。必须遵循多种法规：比如，某些行业必须遵守美国联邦法规第 21 条美国食品和药物管理局（FDA ）规例第 11 部分。即使是系统行业也必须遵循各种不同的法规。根据行业的不同，可以适用相同的原则；例如，您需要知道每个工件的测试时间，测试者的姓名，测试结果，以及在测试发生时测试工件的批准状态。您希望确保测试者仅仅进行所要求的测试而不是其他测试。

在审核期间，要求用户使用它们的电子签名来表示他们已经审核过文档（电子签名具有法律约束力）。根据具体行业，用户在批准或拒绝审核时可能需要输入其他备注。这些内容可以包括一些关键信息，比如审核发起时间，审核完成时间，以及测试完成后测试用例或测试方案的批准状态。当将一个测试流程被标记为失败时，用户需要输入失败理由，以及某个失败的测试导致的失败条件。这些需求适用于在相同或不同地理位置工作的团队。因此，分布式测试环境中使用的工具必须为这些需求提供支持（电子签名和备注），并且必须限制那些会无意绕过这些需求的用户。 Rational Quality Manager 之类的工具在一个底层流程中内置了这些功能。通过本文了解该流程的约束性，并使它满足您的需求。

配置 Rational Quality Manager 流程

您可以向这个现有的流程增加一些先决条件，以便能够满足以下需求：

要求对审核和批准使用电子签名。

要求在审核期间输入特定的数据。

只允许执行经过批准的测试。

在某个步骤被标记为失败时要求测试人员输入详细信息。

Rational Quality Manager 需要依赖一个底层流程，它是一个动态变化的实体。从对该流程应用约束条件开始，系统就会限制用户绕过这些约束条件。这个流程将在后台运行并监视用户行为。当用户执行某个可能会绕过限制的操作时，流程将会检测到这个风险并阻止用户执行此操作。

例如，假设某个项目管理员启用了 A test case must be in approved state before it can be run 的限制。从这一刻开始，用户只能运行得到批准的测试用例。如果该测试用例没有经过准许，那么系统仅在此时会限制用户运行该测试。该用户必须发起一个审核批准流程。在测试用例得到批准后，用户就能够运行该测试用例。

对审核和批准使用电子签名

您可以要求用户在批准测试时添加电子签名。Rational Quality Manager 中的多个工件都增加了电子签名支持，例如：

测试方案

测试用例

测试套件

测试脚本

测试用例结果

测试套件结果

以下步骤介绍了如何修改流程来实现测试用例正式审查（test case formal review）保存操作。然而，这些步骤可以应用于前面提到的任何工件。在设置了约束条件后，在批准或拒绝某个测试用例时，用户必须输入电子签名和强制备注。

1.在您的项目中打开管理 UI。通常，管理页面的 URL 为 https://<server>:<port>/<contextRoot>/admin（例如，https://jkebanking.net:9443/qm/admin）。

2.导航到 Preconditions and Follow-up Actions，如图 1 所示。

3.找到包含以下信息的行：

What 列：Save Formal Review

Who 列： Everyone

When 列：Always

Actions 列：Edit Configuration 图标。

注意：如果 Who 列被表示为 Data Migration Administrator，您仍然可以打开该列并在稍后将相关用户修改为 Everyone。

图 1. Save Formal Review 的先决条件

4.单击 Add 以显示 precondition selector。

5.如图 2 所示，选择 E-Signature required for Test Case Formal Review 约束并单击 OK。

图 2. 测试用例先决条件

注意：如果先决条件仅适用于 Data Migration Administrator，那么应将该设置修改为适用于 Everyone。

6.如图 3 所示，选择左侧面板的先决条件，查看详细内容。

7.选择复选框 Require Comments。

图 3. 先决条件的详细内容

提示：

如果您想预先输入所有审核员在批准工件时都必须使用的备注，那么可以选择 Require a predefined comment。

要仅针对 Approval type Formal Review 启用电子签名，请选择复选框 Require signature only for Formal Review records of type Approval。

8.保存 Preconditions and Follow-up Actions 流程设置。

从此刻开始，任何审核或批准都要求用户提供一个电子签名。

与对正式工件审核使用电子签名类似，您可以在执行锁定或解锁操作时要求提供电子签名。如果启用了电子签名需求，那么用户在执行工件锁定或解锁操作时必须输入用户身份验证信息。

只允许运行经过批准的测试用例

在任何开发流程中，用户必须只能够运行那些针对版本计划内功能进行测试的测试用例。在测试人员运行测试之前，需要确保测试用例的准确性和完整性；否则，运行测试可能没有任何收获。为了确保测试用例满足这些要求，一种常见的做法就是对测试进行审查。不过，尽管测试设计者、测试审核者和测试人员可能并不是同一个人，但测试人员可能仍会漏掉对测试用例是否得到批准进行验证这一步。如果测试人员运行了一个未批准的测试用例，那么他所投入的测试工作可能没有任何意义。为了避免浪费时间和精力，需要实现一个流程约束来防止测试人员不小心运行未经批准的测试用例。

1.导航到 Preconditions and Follow-up Actions。

2.如图 4 所示，查找包含以下信息的行：

What 列： Execute Test Case

Who 列： Everyone

When 列： Always

Actions 列： Edit Configuration 图标。

图 4. Execute Test Case 先决条件

3.单击 Add 来显示 precondition selector。

4.如图 5 所示，选择 Disallow Execution until the Test Case is Approved 约束条件并单击 OK。

图 5. Execute Test Case 先决条件对话框

5.保存项目区。

提示：您可以选择 Disallow Execution until Test Script is Approved 以启用更严格的约束。

要求用户在标记失败步骤时输入实际结果

运行测试并及时发现存在的缺陷固然重要，但是在某些行业中，还需要进行审计，记录测试步骤失败的原因，并记录运行测试时应用程序的行为。在运行测试时，测试人员可以输入这些数据。不过，测试人员可能会忘记这样做。为了确保输入数据，可以对 Rational Quality Manager 系统进行配置，要求测试人员在将测试步骤标为失败时必须输入真实数据。

1.导航到 Preconditions and Follow-up Actions

2.如图 6 所示，找到包含以下信息的行：

What 列：Save Test Case Result

Who 列：Everyone

When 列： Always

Actions 列：Edit Configuration 图标。

图 6. 保存 Test Case Result 先决条件

3.单击 Add 按钮显示 precondition selector。

4.如图 7 所示，选择 Require an Actual Result for Script Steps 约束条件并单击 OK。

图 7. 要求输入真实数据的对话框

5.当在右侧打开对话框时，选择复选框 Failed steps，如图 8 所示。

图 8. 约束条件的细节

6.保存项目区。

查看测试用例

前面的小节介绍了如何修改流程，使用户在批准测试用例的正式审核时输入电子签名和必要的备注。本节将介绍如何发起一次正式的审核，向您展示该流程如何在用户未提供电子签名而批准测试时对用户进行限制。

发起测试用例审核

1.打开 Rational Quality Manager。应用程序的 URL 通常为 https://<server>:<port>/<contextRoot>/web/console/<projectArea> [例如，https://jkebanking.net:9443/qm/web/console/JKE Banking (Quality Management)]。

2.打开一个现有的测试用例并导航到 Formal Review 部分。

3.如图 9 所示，单击 Action 下拉列表并选择 Ready for review。在 Formal Review 部分，单击 Approval 并在正式审核中增加一个用户作为审核的批准者。保存该测试用例。

图 9. 保存测试用例的批准

使用电子签名审核测试用例

要完成测试用例的审核，请以测试用例批准人员的用户身份进行登录。

1.导航到该测试用例，在 Formal Review 下单击 Action 下拉列表并选择 Approve。

2.在 Formal Review 部分，选择 Approved 并单击 Save 以保存测试用例。

3.请注意，在单击 Save 后，将打开一个 E-signature Required 对话框（如图 10 所示），其中的字段用于提交您的 User ID、Password 和 Comment。

图 10. E-Signature Required 对话框

4.在该对话框中，输入登录用户的身份验证信息，并在 Comment 字段中输入备注。在这里，需要输入用户名和密码以验证用户的身份。这些凭证使用电子签名保存。单击 OK 并保存测试用例。该操作将文档的电子签名与验证信息关联在一起。

5.要查看每个工件的完整的历史签名，可以在工件的 Associated E-Signature 部分中查看。

6.要将包含测试用例信息信息的电子签名历史作为 PDF 文件导出，可以使用测试用例提供的标准的 PDF 导出选项。

此时，您已经成功配置了系统，使用户能够在审核测试用例时输入电子签名。用户在批准或拒绝请求时将被要求输入必要的备注。

运行测试期间的审计跟踪

本节将介绍如何运行一个简单的测试用例，并展示 Disallow Execution until Test Case is Approved 和 Require Actual result 约束条件如何推动流程并防止用户绕过约束。

1.打开一个现有的或新的测试方案，将前例中的测试用例添加到该方案中。

2.将测试方案的状态修改为 Under Review 并保存方案。

3.创建一个包含若干步骤的手动测试脚本，并将其状态修改为 Under Review，然后改为 Approved。

4.向此前创建的测试用例添加这个手动测试脚本。确保添加脚本后测试用例的状态为 Approved。

注意：如果测试用例此时不是已批准状态，那么您将无法运行测试，因为流程约束起了作用。

5.做出以上更改后，测试用例和测试脚本都处于 Approved 状态，而测试方案处于 Under Review 状态，如图 11 所示。

图 11. 工件组织

6.从测试用例编辑器中，单击 Run 启动一次测试运行。

注意：在 Run Test Case 对话框中，从 Test Plan 下拉列表中选择您的测试用例所链接的测试方案，如图 12 所示。

图 12. Run Test Case 对话框

7.在测试运行期间，选择第一步并单击绿色的选中（checkmark）图标，将第一个测试步骤标记为已通过，如图 13 所示。

图 13. Web Login Execution 页面

8.选择第二步并单击红色破折号图标，将其标记为失败。在页面顶部将显示 Precondition not met: Actual Result is required for Failed steps 错误，如图 14 所示。此时，您无法将此步骤标记为错误。

图 14. 先决条件发挥作用

9.要将某个步骤标记为失败，必须在此步骤中输入实际结果并标记为失败。在输入结果后，就能够顺利地将此步骤标记为失败。

10.在添加了测试用例的结果后，通过单击 Show Result 可以打开测试用例结果。

提示：您刚刚运行的测试用例已经处于已批准状态。尝试运行一个未批准状态的测试用例，这样您就可以激活流程约束条件 Disallow Execution until the Test Case is Approved。在调用了该条件后，您就无法运行该测试用例，直到它通过批准。

本节解释了如何将一个测试用例链接到一个测试方案，如何向测试用例添加一个手动测试脚本，以及如何运行一个测试用例并将某个步骤标记为失败。此刻，系统将阻止用户继续执行操作，因为用户没有输入实际的测试结果。下一步是分析测试运行的结果，查看捕获了哪些信息。这一步有助于完成审计跟踪。

分析结果

现在测试已经完成，接下来要分析结果，查看测试期间捕捉到的信息。Rational Quality Manager 中的测试结果非常详细，包含丰富的信息，比如运行测试所使用的测试环境，相关的测试方案和测试用例，测试的起始和结束时间。Result Details 部分和 State of Related Artifacts 部分可以帮助您分析捕捉的数据。这些数据可以为审计提供帮助。

测试工件的状态

测试用例、测试方案甚至测试脚本，这些相连的测试工件的状态（例如 Draft、Under review、Approved 和 Retired）都是暂时性的；它们会随时间改变。 在周期的 Sprint 1 中，您可能批准了某个测试用例并运行它生成了测试用例结果。稍后在 Sprint 2 中，您可能重新打开同一个测试用例以添加额外的信息。此时，测试用例结果显示，当测试用例在 Sprint 1 中运行时，测试用例处于 Approved 状态。该信息可以为整个测试流程中的某次审计提供帮助。

打开测试用例结果并导航到 State of Test Artifacts 部分。该部分显示了测试方案、测试用例和测试脚本在测试运行时的状态。该信息将保存到测试用例结果中。

在图 15 的例子中，在运行测试时，测试方案的状态为 Under Review，测试用例的状态为 Approved，测试脚本的状态为 Approved。

同时添加的还有时间戳，它记录了信息捕捉的时间，有助于执行正确的跟踪。通过利用这些信息和时间戳，审计人员可以判断测试是否依照流程执行。

图 15. 相连的工件的状态

在图 16 所示的 Test Case Result 列表视图中，您可以在不同的列中查看这些信息。您可以通过表的 Manage Display Settings 设置管理这些可选列。

您可以使用这些列对条目进行排序、过滤和分类，从而发现感兴趣的测试结果。

您可以通过 CSV 或 PDF 文件从列表视图中导出这些测试用例结果。

图 16. 测试用例结果的列表视图，其中显示了所有测试工件的状态

对测试步骤进行审计跟踪

在测试运行期间，除了测试用例结果外，还会捕捉有关测试人员的信息。运行具体步骤的测试人员的姓名和用户 ID 都会被捕捉。同时还记录了时间戳。如果这是一个由多个用户运行的长期测试，这些信息就可用来跟踪运行具体测试步骤的测试人员以及运行测试的时间。您可以在测试用例结果的 Result Details 部分查看这些详细内容，如图 17 所示。

图 17. 测试人员信息

所有这些信息都可以通过 PDF 格式从 Rational Quality Manager 中导出，并可用于审计用途。

结束语

本文介绍了如何配置 Rational Quality Manager 以满足监管环境下的各种需求。在 Rational Quality Manager 中执行自定义流程，确保团队中的所有人都遵循正确的路径。提示用户在流程需要的时候输入电子签名。用户只能够运行经过批准的测试。可以自动捕捉修改历史并将它们保存到系统中。这些信息可以通过 PDF 格式进行提取。测试人员的姓名，每次测试的时间以及测试结果都保存到系统中，可以在审计时使用它们。