导读：SDO规范把SDO定义为服务数据对象，是一种编程架构和API。SDO的逻辑结构：是model，数据的存储是Tree形的结构，有Java实现，也有C++的实现。

　　关键词：SDO；服务数据对象；编程架构；API model；Java

　　上周有测试提到测试页面流时由于测试人员对SDO不是很了解，有些问题测试得不是很深，由于我对SDO比较了解，所以希望我能提供一点SDO技术性测试思路。写下了这么点东西，不知是否合大家的胃口，有必要的话，我们再对某些点进行更详细的探讨，先抛个砖，也期望大家抛些玉啊。

　　前言

　　我们知道，测试人员考虑测试的实施，一般主要是从技术性、创造性、批判性和实用性来考虑的。简单的来讲，技术性思考是理解软件输入和输出的因果关系，进行技术建模的能力，包括预测系统行为的能力，这还是有难度的，除了开发经验以外，理解软件的思考方式可能也是比较重要，下面我结合SDO及其实现，从技术性的角度作些思考，期望能提供一种帮助测试人员理解软件系统思考方式。

　　理解SDO的前世今生

　　为什么需要SDO

　　具体的内容大家大家可以从网上了解到，但大家需要注意的一点是SDO的为了SCA服务的，理解SDO的特性，需要从SCA整个体系架构上来理解。

　　SDO的几个引人瞩目的特性：

　　1、动态数据API

　　何谓动态的数据API？我们熟知的JavaBean的API"静态的"，因为预先定义好的具有一系列属性（或getter/setter方法）的数据类型已经存在了。但有时候，例如在许多动态查询中，返回数据的形式并不是已知的预先类型，不能使用JavaBean来访问；还有有些XML数据的数据结构是可扩展的，解析该XML数据之前，通常不知道它的精确类型。可以类比的是JDBC接口中的ResultSet吧。

　　2、混合数据的统一访问方式

　　即可以通过XPath访问各种对象的属性，这个特性使数据的操作统一、变得更容易。

　　3、变更跟踪的能力

　　是Sequence和ChangeSummary。部分特性目前我们没有实现，不说也罢。

　　其它的规范上有介绍，我不罗嗦了。

　　SDO的数据结构

　　记得老早读书的时候，书上是这么定义程序的：算法+数据结构。SDO规范把SDO定义为服务数据对象，是一种编程架构和API（Service Data Objects （SDO） is a data programming architecture and an API）。实际上，我们把SDO理解为一种数据结构可能没那么抽象。

　　这可以从3个方面来理解SDO的数据结构。

　　1、SDO的逻辑结构：是model，通常是那个xsd文件了，也可以是xml文件。在实际应用中，如果使用动态API，是不需要定义xsd文件，但不意味着没有model，只不过约束更宽松，在Java中是Object而已，因为Java中Object可以代表任意对象。在理解SDO的逻辑结构是，我们需要了解SDO的25种基本数据类型（我们只使用了14种），以及SDO数据类型和xsd的类型的对应关系。

　　2、SDO的存储结构： 总的来看，数据的存储是Tree形的结构，有Java实现，也有C++的实现，我们只关心Java的实现。

　　这里需要知道SDO数据类型和Java的8种基本类型的对应关系，同时，SDO本身也是一种混合容器，它本身可以容纳任何Java对象。

　　有经验的测试人员可能已经想到：由于具体到了语言，必然需要考虑到数值的长度、数值边界、数据类型兼容性转换等问题。

　　3、SDO的数据运算： SDO的数据运算既简单、又复杂。简单的是都可以使用get/set方法对数据的访问，但同时需要考虑支持的xpath的多种形式组合