上周有测试提到测试页面流时由于测试人员对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的多种形式组合

　　理解SDO的实现

　　我们没有实现规范定义的所有内容

　　ChangeSummary、sequence、静态接口API等功能我们没有实现

　　SDO的实现关键点

　　我们抛开SDO的API不谈，因为我们不是从接口的角度来分析SDO的实现。我觉得SDO的实现主要包括如下的内容:

　　1.数据类型转换

　　简单类型转换、普通的JavaBean转化为SDO等等，这是SDO能被用来处理异构系统之间数据传输的能力必要的基础

　　2.XPath访问

　　xpath大家很熟悉了，但特别的地方是实现对JavaBean对象使用xpath形式进行访问

　　3.序列化

　　SDO要在网络间传输，就要实现序列化；普通的Java对象实现序列化是非常简单的，只要声明实现java.io.Serializable就可以了。但SDO实现的是Externalizable接口，类完全负责序列化和恢复数据成员。

　　4.数据更新(增、删、改、查)

　　SDO本身是一个Tree形结构的，每个枝干、叶子节点都要能访问到

　　5.特别属性的支持，如readonly属性、动态属性(OpenContent)的支持、约束

　　readonly对数据更新有许多限制

　　OpenContent对应的是xsd中定义的anyType属性类型，它能放置任何java对象，如果xsd中如果定义了约束，在将其转为SDO对象实例后，需要支持这种约束，但需要注意的是：这种约束只有在调用Validate的方法之后才会起作用，例如你定义某个字段的长度为10，在使用中之间set为20，普元的SDO实现不会进行检查这中约束，但调用SDOUtil.Validate方法来校验的时候，就能检查到这种冲突。

　　6.动态数据API的支持

　　动态API使用的定义是common.sdo.DataObject类，使用studio的属性编辑器的时候可以看到。

　　7.异常处理

　　SDO规范中详细定义了数据运算的行为，当出错时该抛出什么异常，实际测试中我们发现抛出的异常都没有遵循规范来做

　　测试时该重点考虑的地方

　　1.数据类型及其兼容性的转换

　　这不用说大家应该都知道，这是基本功能，也是实现其它特性的基础。如果从定义业务流（好像被改为了逻辑流？）/页面流的角度考虑，就是利用属性编辑器的时候要考虑，SDO的数据类型与Java类型的映射关系

　　2.复杂xpath的支持

　　包括xpath多层、对象多层自引用嵌套；xpath的下标带数组形式

　　3.对象的序列化/反序列化

　　前面提到，SDO序列化实现的是Externalizable接口，类完全自己负责序列化和恢复数据成员，因此这应该是个测试的重点，如果从使用的角度来考虑，ajax调用会使用到这方面的功能；此外这会带来安全性的问题，例如：一个远程调用，当恶意的客户端返回一个与服务器端不同版本的序列化对象时，如果不妥当处理，会抛出ClassCastException，严重时会导致系统崩溃；还有恶意类读取和写入对象数据，造成敏感信息泄漏等等。不过目前SCA的版本似乎关注的安全性不多，安全性的问题似乎可以放一放，不过将来会应该会出的，就像出来了WS后，要加一个WS-Security一样。

　　还有，要考虑被测的SDO对象应包含所有的Java基本数据类型及其数组形式、复杂对象及其数组形式。

　　4.opencontent属性的支持

　　opencontent属性就是xsd文件中定义的anyType了，需要注意的是由于opencontent属性的特别性，目前的实现保存opencontent属性是一个SDO对象共用一个List来保存的，而不是每个枝干、叶子节点下建一个。这种实现中比较特别的地方，可能会造成并发访问时出问题。实际测试中我们可以在页面流/逻辑流中大量地操作一个有opencontent属性的SDO对象，来模拟这种情况的发生。

　　上述的描述可能展开的不够，如果有兴趣，不妨再进行更详细的探讨，就先介绍到这吧。