测试分析与设计模式(2)

　　实现特性视角

　　从实现特性角度上讨论抽象工厂，其要注意的是与动态绑定如plug-in等等方式的合用。动态绑定方式虽然在实现上提供了非常灵活的运行时的行为决定能力;但是其带来的稳定，效率，易读和维护性上的风险。 特别是抽象工厂模式将使用者与实现者在2个不同纬度上隔离开，这将使得问题的定位变得困难。

　　从测试角度分析要测试的点时，应该对抽象和继承的对象创建方法进行测试。 特别是与动态绑定合用时。同时应该特别注意对抽象工厂和继承的具体工厂类进行对象创建的回归测试。因为代码的变更和维护比较容易引起方法语义的变化，从而对抽象工厂的使用者带来影响。

　　所有的创建相关的模式在具体实现上都应该考虑内存/资源的分配，竞争，以及并发的情况。

　　错误模型视角

　　对于上层语义来说，抽象工厂应该特别考虑，避免抽象类定义中混淆进继承类的特性。比如方法中包含特定继承类实现的功能的定义和依赖。 在测试分析中应该对抽象工厂类，以及继承于该抽象工厂类的具体工厂类中的方法，属性进行推敲，确定只有不依赖于特定实现的方法和属性才能存在于抽象工厂类中。 具体到测试分析活动中，对方法和属性的语义进行“测试”，“测试”其是否对于各种具体实现是“通用”的。

　　对于逻辑算法来说抽象工厂一般不包含复杂的业务逻辑。 具体的业务逻辑往往存在于具体的工厂类中。所以对于逻辑的正确性的测试应该更多的对具体工厂类进行。

　　对于抽象工厂模式，由于其根本上是创建对象的方法。所以从可能的错误情况来看，对象创建的失败情况是必须要仔细测试的。 对于创建失败的情况，不仅仅要测试当获取资源失败的情况下的创建失败，还应该测试在不合适的环境/前提下的创建失败。(比如在Linux环境下创建为windows适配的对象)

　　对于对象的创建失败，在一个对象包含多个资源的情况下，应该设计测试用例测试某个资源获取失败后，对已经获取的资源的释放情况。

　　更加进一步，取决于实现逻辑和方法，当实现逻辑中运用到或者有可能受外部环境(软件/硬件)影响时，考虑对象创建中的单态，中断，并发，超时，溢出等等情况。

原文转自：http://www.ltesting.net