服务虚拟化-超越现实-第十一章：最佳实践4：数据管理.docx

第十一章 最佳实践4：数据管理 一些团队在集成，回归和性能测试中用于设置和清理测试数据的时间常常占到整个周期的40%到60%。我们已经谈到混乱的数据问题和开发和测试团队遇到的巨大困难，在管理自己的项目时遇到控制范围外的不断增加的易变的数据问题。 如果你曾经在半夜与一些开发人员和测试人员开发布前的电话会议。当其中一个系统复位，所有人都在期待的信号“GO！”，开始导入特定的测试数据场景到他们的屏幕上，你已经知道我们在说什么了！ 软件开发团队要验证是否满足业务需求，需要同步真实的数据场景到所有应用涉及到的系统中。我们称这个过程为“校对天上的星星。” 。当我们的软件变得更加分散以及每天变化都很快时，实现这种同步水平变得几乎不可能，在这个问题上投入更多的人帮助并不大。 应该用服务虚拟化为开发和测试环境提供所需的系统。包括供应范围外系统的数据，以及在一段时间内保持系统之间使用场景的上下文。 vTDM：就是你所需要的数据 正如服务虚拟化对应于服务器虚拟化一样，也有一个成熟的工具集可用于常规测试数据管理（或TDM），允许你的团队从可访问的系统中提取并导入数据。 但对组合应用的大多数开发活动而言，，大部分所需的数据存在于那些“范围外”的系统中，并不在你的控制之下。因此，不是试图直接从这些源中提取数据，而应该使用SV来捕捉和模拟范围外系统的行为。为你正在开发的系统提供足够动态和适当的数据。让它认为是和真实的系统数据进行交互。 我们称之为虚拟测试数据管理（或vTDM）。 使用vTDM，而不是真正的TDM虽然显得过于简单，但其实开发团队用这种轻量级的更健康的形式可以获得稳定，相关的测试数据。 SV通过自动捕获相关场景可以更方便地从下游系统收集所需要的数据，可以智能地解释得到的数据，并在SV中对其进行遮掩和处理。 基于虚拟服务的数据可以让所有的团队都能按需获取被测系统所需的数据集，并且数据是可以被扩展至几乎无限的有效数据场景，可以支持高容量的性能和回归测试需求。 消除数据上的冲突 今天商业应用的组合特性很适合为多个团队划分开发和测试任务。每个团队负责自己所分的功能。如果我们可以应用SV克服测试数据冲突的祸害。这种方法是非常有利的， 传统的TDM是一个非常耗时的过程，往往涉及几支团队，因为某些情况下必须跨多个系统协调和加载数据。一旦所有的数据同步好，就可以给性能或端至端的测试使用，数据用完后，必须重建之后才能被其它人使用。 每个数据设置活动是相当脆弱的，所以，如果一个新的版本出现在预生产环境或其他团队进行其它的测试，用到测试中所使用的数据源，它会立即损坏的测试数据，使测试结果存疑。 使用SV，许多传统TDM旧的冲突完全消失（图11-1）。您不再需要对齐星星，当你需要时，数据会以一个适当的结构和格式出现。 图11-1。范围外的测试数据冲突通过虚拟服务的形式为每个团队提供所需的场景，并独立于其他团队运行或在架构上灵活配置场景条件。 使用服务虚拟化可以很容易配置一些特殊情况，如边界条件，异常测试场景和错误处理，并且永远不会烧毁，因为虚拟服务只是给出适当的响应。最重要的是，每个团队可以随时部署自己的虚拟服务，这个虚拟服务已经配置和同步好了。 当新的软件做好后，团队使用下游系统的现有vtdM方案作为基线起点，然后针对新的需求快速添加新的场景。由此产生更新的虚拟服务提供了经过团队验证过的业务案例文档。同时代表了对下游组件所需的更改。现在，当多个测试周期或团队有不同的测试数据的需求，他们就不会在测试环境中发生冲突了。 数据遮掩：信任，但虚拟化 让我们来谈谈vtdM的一个方面，也是我们一直强调的，尤其是我们的软件开发活动愈加分散，分布到不同的团队，公司，甚至不同的国家：这就需要对数据进行脱敏*，去掉标识信息，或遮蔽测试数据。 许多行业关于他们如何处理客户的私人数据、如何存储，访问和传输有非常严格的标准；何时何地需要是私有的；以及谁可以看到它。例如，医疗保健行业在美国已经对病人的数据如何传播和使用有非常具体由联邦政府规定的管制，如HIPAA。美国国防部对数据问题的规定甚至更极端。 即使不是法律规定，所有的企业显然也需要高标准的数据隐私和安全，防止欺诈和数据的滥用，否则将在市场上付出代价。这当然延伸到当今的分布式软件开发和测试领域。 如果我们的公司有开发人员在加拿大和德国的贸易伙伴工作，还有一个大的团队在印度做测试工作，这些团队并不需要有客户实际地址和身份证号码的真实测试数据才能做好本职工作。在最终的客户验证过程中，他们只需要有有效的测试数据，可以支持所需的场景，数据格式可以在构建应用和测试中使用。 如果使用得当，SV提供了一个很好的解决这个问题的方案。从实时交易或日志中捕获的数据元素应该好好利用，但需仔细将其混淆 - 我们不是在在此谈论“随机化”的响应，因为那样只是重新引