下载 Oracle 应用程序测试套件

标签 testing, performance, 全部

如何开发、维护和支持质量管理和开发流程

作者：James Downs

概述实际测试方法，并且快速介绍 Oracle Test Manager for Web Applications。

2008 年 10 月发布

为所有软件开发定义测试计划、承诺条件以及测试交付件和流程的工作都可能面对不同的、不断变化的挑战，从识别可应用的流程到定期维护这些决定。

选择工具来帮助支持这些实践和策略，不仅可以减轻它们的负担，而且可以增加效率、组织性和成功的支柱。

在解释如何在我的公司开始和实施质量计划前，先提供一些背景信息。 Meridian Knowledge Solutions 是学习管理系统 (LMS) 和学习内容管理系统软件的领先供应商。我们还提供专业服务、课件、开发和托管服务。我们为 200 多家公共和私有部门中的 450 万用户提供服务。

我们的旗舰产品 Meridian Global LMS 将学习内容管理、劳动力分析、知识管理和竞争力建模集成到一个 LMS 中。Meridian Global LMS 使用户可以根据需要访问课件、文档、数据、教师和其他学员。可以轻松随意地使用任何旨在用于辅助工作绩效的资料，并将它们完全集成到一个 Web 站点中。

本文将概述 Meridian 中使用的测试方法和流程、选择 Oracle Test Manager for Web Applications（Oracle 应用程序测试套件的一个组件）来帮助管理和支持流程和质量计划的原因，以及日常使用 Oracle Test Manager for Web Applications 的方法。

Meridian QA：实施质量计划

众所周知，从头开始设计一个可以支持所有软件周期的流程是件繁重的工作。尝试定义所有的流程以连接生命周期的每个部分看似不可行。幸运的是，这个想法可以实现，实际并不像想象的那么困难。

2004 年，我们决定推倒重来，重新定义质量保证 (QA) 的责任和职能，因为这关系到新产品 (Meridian Global LMS) 和公司的总体形象。

实现此目标意味着不仅要为产品 QA 团队定义新方法，而且要找到在生命周期中将这些流程与来自其他团队的现有流程相结合的方法。我们的首要任务是使这些事情尽可能地简单和简化。“善用巧思，节省劳力”似乎是我们计划的绝妙理念。

我们利用在一般行业标准的基础上集中的和单个的流程以及自身在实际例子中多年积累的工作经验开工了。我们的部分核心流程源自领先企业的最基本和常见的行业最佳实践，如美国软件工程学院的能力成熟度模型集成方法。最后，我们希望确保新流程中不会重蹈以前的失误。

我们为更改控制流程开发了简单、合理的最佳实践、测试策略、文档实践、就绪状态检查过程，以及用于 QA 交付的支持模板和指导原则。这些都没有背离其他公司和组织在设置 QA 和生命周期计划时所做的工作。我们相信我们的优势在于对这些 QA 计划的承诺以及它们与开发、需求和管理流程良好协作的方式。

那么这些有趣的流程是什么，如何确定创建哪些流程呢？首先定义所需的基本流程，并用在需要时可以增加更多价值的可选流程进行补充。此外这些交付件包括正规详细的测试计划、最终测试报告和累积测试量度。一些可能很有利的流程包括测试就绪状态检查，发布就绪状态检查和正式的更改控制板 (CCB)。此外所有的这些均有助于建立 Meridian 意识和方法。

都设置好了，对吗？现在应该做什么？然后，最大的问题和顾虑就变成如何在维护和支持所有这些的同时尝试跟上不断的代码更改、需求更新和产品范围转变的步伐？

答案是 Oracle Test Manager for Web Applications：一个可以帮助我们无缝整合所有这些流程，同时利用常见门户协同支持通讯的工具。

Oracle Test Manager for Web Applications 体系结构

Oracle Test Manager for Web Applications 的最大优势是其简单性：所有软件生命周期的基础领域都可以通过简单、直观的界面提供。我个人使用过许多其他具有需求、测试和缺陷跟踪功能的应用程序，它们需要太多的时间交叉编写信息并尝试同步独立的应用程序。这些应用程序过去的实施和维护成本通常比 Oracle Test Manager for Web Applications 高，现在仍然如此。

QA 中最耗时却必不可少的流程是在需求、测试和缺陷之间创建可跟踪性的能力。这可能是 Oracle Test Manager for Web Applications 带给 Meridian 的最重要特性之一。通过允许用户将需求关联到测试（参见图 1）以及将测试关联到问题（参见图 2），从而自动地将问题关联到需求（参见图 3），Oracle Test Manager for Web Applications 提供了可跟踪性和映射，这无疑有助于我们的 CCB 流程、问题解决以及测试准备和执行。

下面，我们将介绍 Oracle Test Manager for Web Applications 体系结构及其独立的 Requirements、Tests 和 Issues 模块。基本的 Oracle Test Manager for Web Applications 设置使用专用的许可服务器和 Microsoft SQL Server 后端，这对我们来说是个简单的选择和便捷的设置。使用 Microsoft SQL Server 为数据库维护和备份支持提供了强大、简单的解决方案。此外，专用的 Oracle Test Manager for Web Applications 服务器与其他生命周期解决方案不同，对于基本操作无需过度强健。

Oracle Test Manager for Web Applications 的 Requirements 模块为设计和功能性需求的创建和维护提供了标准的平台。它即需即用的域和选项为即使是最复杂的应用程序提供了充分的支持。然而，在 Oracle Test Manager for Web Applications Administrator 中创建自定义域的功能为需求灵活性和管理提供了更强大的平台，并且支持自定义应用程序以便与您定义的流程匹配。为设计图像和功能工作流等附加文件的其他功能，通过允许开发人员和测试人员获取首次正确编写代码和测试所需的信息来提高生产率。此外，Oracle Test Manager for Web Applications 维护以往保存的所有需求版本，并且能够保存每个保存的版本的注释（通过自定义域实现）。

Issues 模块与 Requirements 模块共享所有相同的生产率、效率和灵活性标准。但它还为 Meridian 提供了我们需要用来有效、无缝地管理更改控制流程的平台。利用自定义域功能来随意增加我们所需的任何其他域和选项，以管理所有权以及对缺陷和改进更改的期望（参见图 4）。Issues 模块并不管理该流程，但没有它，我们的更改控制流程就无法成为我们现在所使用的高效、无缝的流程。此外，Issues 模块中包含的信息在管理发布就绪状态以及每个软件发布版本的量度报告方面给予我们很大的灵活性。

最后但相当重要的是 Oracle Test Manager for Web Applications 中的 Tests 模块。显然，从一个自然的 QA 角度看，这是应用程序的核心。通过文件夹和测试组来构建测试的能力是良好测试管理和维护不可或缺的一部分。但是管理单个手动、自动（从 Oracle Functional Testing for Web Applications）和第三方测试的能力是该模块的核心优势。对于任何将现有 QA 资料转换为 Oracle Test Manager for Web Applications 等受管理系统的人来说，手动测试流程仍然是首选。Microsoft Word、Microsoft Excel 或类似的应用程序中的现有测试可以简单轻松地转移到 Oracle Test Manager for Web Applications 测试结构。可以立即在中心位置管理测试并无限次重用（参见图 5）。有什么更好的方法可以在一个位置进行测试更新，并无缝地将更改应用于测试使用的所有实例？

更高级的 QA 部门的情况类似，从 Oracle Functional Testing for Web Applications 维护自动测试的功能也具有和手动测试相同的核心优势。最后，Tests 模块自身足以作为 QA 部门可以用来超越实施和维护成本的优势。它是一个很好的工具，使所有 QA 人员登录到 Oracle Test Manager for Web Applications 执行日常和长期任务，轻松地度过工作的一天。

总之，如前所述，这三个核心模块彼此之间进行了关联，完全涵盖了对多数组织至关重要的可跟踪性。有些人可能会说可跟踪性覆盖范围（在 Oracle Test Manager for Web Applications 中从本质来说几乎是无缝的）节省了我们团队每次发布的时间（如果非周末），从而确保涵盖了我们的所有功能。

手动测试与自动测试的比较

对于我们和所有其他 QA 组织而言，同样的问题依然存在：我们使用自动测试还是手动测试？毫无疑问，必须和其他受管理的 QA 部门做出相同的选择。自动化和维护这种类型的测试划算吗？如果划算的话，我们应该自动化多少测试？多长时间运行一次这些测试？我们如何适当地执行正确的自动化实践？问题永无休止，有关此主题的问题可以写满整张白纸，这一点毫无疑问。

自动测试的一个最大优势在于，可以通过一致的、预期的界面重复执行功能性测试场景。基本上，自动化的回归测试可能是最安全的途径。因为回归测试经常用于自动执行相对无变化的功能，因此更加安全，需要较少的维护。

我们花费这么多时间来添加新特性和更改陈旧的功能，因此我们自动化应用程序的机率很小。这绝对不是坏事情，特别是我们从一开始就识别出这种情况，不会陷入自动化可以从手动测试的“危险”中“拯救我们”的错误的期待。实际上，手动测试对我们一直非常有效。我们的特性经常更改、应用程序也可以自定义，且用户界面经常调整，因此我们必须仔细选择需要自动化的部分，以免产生不必要的维护。

那就是说，我们已经设计了一个正式流程以在利益最大化的级别实施自动化，因为我们的 QA 流程是多年前引入的。我们还将在适当的时候在基本功能级别放慢实施冒烟测试，从而可以简化维护，带来更多收益。因为我们经常在 QA 环境中应用新构建的代码，所以冒烟测试实际上将帮助我们更有效地在根源处识别低级缺陷，而非空等测试人员手动执行该流程。

与我们的所有流程一样，自动测试是一个强大的支持工具，但却无法控制流程和最终结果。使用 Oracle Test Manager for Web Applications 管理自动测试的执行和制定流程运行计划，将与我们在 Oracle Test Manager for Web Applications 中使用的其他模块良好对接。

报表和股东收购

最近的 Oracle Test Manager for Web Applications 版本对报表功能进行了极大的改进。主要是对报表的信息板样式设置进行了改进。过去，我们使用自己的协作信息板（以每周/每月量度的形式）向管理和所有者显示产品状态、缺陷解决率和测试/问题所有权等信息。这些对收购和流程说明是至关重要的；然而，当需要频繁展示这些信息时，则需要较长的创建时间。信息板报表特性可以极大增加收集这些数值的时间，尤其在很短时间内。

还有一个算是新增的但很强大的特性，就是能够为您创建新报表并将它们发布供其他人使用。我们产品团队的不同成员使用各自的私有报表来帮助跟踪内部流程，并在团队内发布一些实例以共享信息。这极大地方便了即时检查状态和其他信息，不用再打电话、发电子邮件或会见团队成员。

标准的即需即用的报表也不应忽略。我们不同程度地使用这些报表来上报诸如测试流程/发布就绪状态、问题解决方案/结果之类的事情，以支持最终的测试报告和前面阐述的对测试可跟踪性的要求。Reporting 模块是 Oracle Test Manager for Web Applications 提供的单个集成解决方案的另一大优势。

快速提示与技巧

所有应用程序都有一些快捷方式和技巧，可以帮助管理和维护效率并有利于在团队内传播知识。一下是我多年来在组织内使用 Oracle Test Manager for Web Applications 发现的一些提示和技巧。

最大的优势之意是在三个核心模块中尽可能多地重用自定义域。例如，我们在三个模块中统一使用了 Version 域。由于我们每天至少将新版本的代码应用到测试环境中一次，所以能够登录并在一个中心位置更新当前版本不仅可以节省时间，而且还可以杜绝各种错误。自然，正确的版本控制也有助于报表和量度的准确性。

Oracle Test Manager for Web Applications 新近包括了一个很好的工具 Screen Capture Utility。这是一个很棒的应用程序，可以加快包括错误屏幕截图和 GUI 捕获的速度。使用 Screen Capture Utility 可以简化问题输入流程或对包含针对需求或测试的 GUI 捕获的需要。与使用打印屏幕 (PrtScn) 按钮的老方法和 Microsoft Paint 等一些通用工具来粘贴、剪切和保存图片相比，这样效率更高。

我们发现的另一个有趣的技巧是不要弃用 Oracle Test Manager for Web Applications 桌面界面。随着对 Oracle Test Manager for Web Applications Web 界面的不断改进，令人不禁期待更加现代的界面。然而，继续使用桌面界面有一些主要优势。其中之一就是使用拖放功能。像我们这样进行大量功能性测试和测试群时，与使用 Web 界面中的向上/下/左/右移动的按钮相比，使用拖放功能将这些测试资源组织起来的功能可以节省大量时间。需求具有与此类似的相同优势。

最后但却相当重要的技巧是确保唯一的 ID 已开启。在 Tools > Options 菜单中，确保选中该复选框以显示唯一的 ID，而非使用默认的索引排序（参见图 6）。重新组织需求和测试时，默认的索引排序会更改，这可能会干扰密切监视可跟踪性的操作。为什么？因为索引值会随着实体的移动而改变。使用唯一的 ID 可以避免这个潜在的问题。唯一的 ID 会跟随 Oracle Test Manager for Web Applications 实体并通过移动维护标识。您还可以在 Options 下控制单个节点中显示的记录数量。

关于唯一 ID 需要说明的另一点是，在复制一个项目时（每个数据库一个项目）针对每个测试管理器项目使用不同的数据库。为什么？如果在同一个数据库中复制一个项目，则唯一的 ID 可能跳转。因为 ID 仍保持唯一，Project A 中的 TEST100 在 Project A 副本中现在将变成 TEST50。这很显然会在维护一致的可跟踪性时抛出一个缺陷。为避免这种情况，将项目复制到一个新的干净的数据库实例中，并使用同样的 ID 映射。在同一个数据库中进行复制在某些情况下当然有其优势，但是我们发现每个测试管理器项目中的新数据库实例是维护 Oracle Test Manager for Web Applications 归档流程和整体可跟踪性的最好方法。主要版本发布后，将测试管理器项目复制到一个新数据库。副本变成该版本的档案文件，我们仍旧在“主”项目中工作。

结论

最后，Oracle Test Manager for Web Applications 为 Meridian 提供了相对成本的解决方案（尤其和类似的供应商比较时），该方案几乎支持我们产品生命周期的所有方面。因为这个应用程序的维护成本极低且易于管理，因此我们可以充分发挥它的优势，而较少顾虑它的可靠性。需要着重说明的是，我们选择 Oracle Test Manager for Web Applications 作为支持性的解决方案来帮助推动和维护已识别和已定义的流程和计划。我相信，如果您将该流程逆转，先选择工具，则组织可能会过度依赖于解决方案，随着产品和组织的更改，流程将变得呆板不灵活。

总之，Oracle Test Manager for Web Applications 是一个可以帮助我们在一个集中的界面中输出决策、生产率和知识的工具。毫无疑问，如果没有即时可跟踪性、测试的简单重用和优化功能，我们的效率会大打折扣。Oracle Test Manager for Web Applications 是一个可行的、值得信赖的解决方案，任何组织都应该予以慎重考虑以帮助支持它们的生命周期工作。