当您一直保持 甲骨文BRM (账单和收入管理）配置一段时间后，您开始意识到配置的实体数量在不断增加。此时，您很可能还开发了一些定制功能，并与其他解决方案集成。环境的演变导致了复杂的交织对象集群。这时，您或您的客户决定改变某些东西。起初，新功能的开发似乎很容易。但事实上，它很可能会与现有功能相冲突，或者也需要更新现有配置。看似简单的更改，却会影响整个系统。这种情况有时很难避免，但做好准备可以省去很多麻烦。功能测试方案和测试多样性可以改变游戏规则。
持续开发流程
在 Tridens，我们建立了持续的开发流程。我们所有的 BRM 配置、定制和其他集成组件都在分布式版本控制系统（Git）上进行了适当的版本控制和跟踪。通过这种做法，我们的开发人员可以随时查看所需的组件版本并开始工作。目前一切正常，但我们如何应对新功能破坏当前构建的可能性？
我们建立了一个部署和测试流程，可以跟踪源代码的远程存储库。因此，每次开发人员提交并向版本控制推送一些变更时，都会启动测试流程。部署流程会在本地（或远程）环境中为所有相关组件构建最新版本的 docker 镜像，并执行自动测试，以确保构建稳定。只有测试成功后，我们才能将新版本发布到生产环境中。这一过程有助于我们确保新功能与现有功能无缝衔接。执行的测试是我们开发的 Oracle BRM TestToolkit 的一部分。BRM TestToolkit 具有预定义的步骤和场景，并带有背景胶水代码。这些步骤描述详细，使用方便，使我们的开发人员或任何其他用户都能快速编写新的测试方案。下图为测试方案示例。
用于自动测试的BRM TestToolkit
起初只是简单的账户创建和产品购买测试场景，如今已成为我们测试 BRM TestToolkit 的主机。说明一下，我们现在有多个不同的测试用例和边缘情况，以确保最大限度地覆盖已实施的功能。自动化测试使我们的开发人员能够专注于手头的工作，而无需花费大量时间进行手动测试。当然，有时我们会发现自己开发的新功能尚未被测试方案覆盖。在这种情况下，测试步骤定义及其后台代码将作为该功能的一部分实施，并在将来使用。
测试工具包可以与不同的组件通信，因此也可以对其他系统进行快速调整。我们还为其他组件重新设计了 BRM TestToolkit 版本。我们添加的最新功能之一是模块化，开发人员可以将不同的测试方案标记为一个组的一部分。然后，每个组都有自己的脚本和独立的逻辑，如果需要，一次只能并行执行特定数量的测试。此外，模块化使我们能够将预付评级测试从后付评级测试中分离出来，或将附加购买测试从杂项购买中分离出来。您可以在下图中看到测试流程。
测试场景覆盖率
BRM TestToolkit 与我们的应用程序接口（API）通信，我们将其与 Oracle BRM 集成，以简化更复杂的操作。测试工具包还可以与 BRM RestBridge我们的 BRM 封装解决方案允许通过 REST API 使用 JSON 或 XML 格式，从而简化了与 BRM 的通信。测试步骤定义支持以下操作：
- 创建和管理账户
- 交易购买和其他交易业务
- 余额检索和检查
- 产生流量 - 使用事件
- API 调用
- CDR 辍学
- 实时流量工具（直径协议）
- 评级检查
- BRM 测试工具包将不同的使用事件和购买量与预期值进行比较
- 每个不同的计划或产品都可拥有自己的评级文件集，确保复杂产品设置的通用性
通过编写用户友好型测试步骤，每位开发人员都可以为开发中的功能编写场景。在许多情况下，我们的开发人员会选择在开发功能之前提前设置测试场景。提前准备测试方案遵循的是行为驱动开发（BDD）模式。BDD 的基本含义是，场景决定开发流程，并应预先存在。这些场景描述了系统的行为方式，开发人员必须根据这些场景开发新功能。我们可以分别执行每个测试场景，从而生成指定格式的报告。下面是 HTML 报告的示例。
报告
当系统作为新开发构建的一部分运行测试场景时，通常会充分发挥其潜力--包括所有测试。在不同的环境中，这可能需要一些时间，但它能让你大致了解新功能对其他现有实施的影响。我们可以通过 BRM TestToolkit 在测试运行结束时生成的测试报告来评估构建的稳定性。测试报告包含每个测试场景的详细信息，但也提供一些有关所有测试的总体统计和分析。我们可以利用这些分析发现构建之间的差异，并确保构建工作正常。请看下面的报告示例。
总结
拥有正确的测试解决方案可以节省大量时间，防止出现任何不必要的错误。因此，如果您遇到本文提到的任何困难，或者您对我们的测试 BRM 工具包感兴趣，请随时联系我们。我们很乐意向您详细介绍我们的解决方案，并就如何改进您的部署和测试流程制定最佳计划。
