从另外角度来说，抽象工厂允许进行2个不同纬度的抽象。 比如对于一类功能进行一个抽象纬度。而各类功能的不同的实现依赖又是另外一个纬度。 举例来说同样的“文本编辑”框，可以是一个类;但是其在Linux中和windows中的实现是不同的，所以第一个纬度是功能，第二个纬度是操作系统。 通过抽象工厂类，使用者可以创建一类功能的不同实现。

　　质量特性视角

　　从功能角度看，抽象工厂这种设计模式主要用来作对象的创建。 所以一般对功能的属性没有特别大影响。

　　抽象工厂模式在易用性上是提供了比较好的优势的。

　　如果单纯的运用该模式，只要不涉及到过于频繁的创建/释放动作，一般来说对系统性能也不会有特别大的影响。避免在应用抽象工厂模式中附加自己实现的动态绑定，基本可以比较好的确保代码的性能。

　　从稳定性角度来讲，抽象工厂模式带来的风险与创建动作带来的风险基本上是一致的， 即需要确认对象创建是否成功。当程序中对动态创建的对象进行足够的合法性检查时，该模式不会带来更多额外的稳定性风险。

　　抽象工厂模式对于可维护性方面提供了2个纬度中一个纬度的可扩展性。但是直接在抽象工厂中定义的纬度的扩展性将会受到很大限制。 所以在确定抽象工厂类定义的纬度时，应该仔细考虑是否有比较大的扩展可能性--> 设计内的测试的分析对于这点，应该从过往的项目经验出发;从客户需求的历史出发;从该纬度本身的“自然特性”出发提出可能的扩展点。(这里列出的扩展点是测试需求)对这些扩展点发生的可能性进行评估和讨论(而这样的评估和讨论是测试执行)。 注意这里明确的提出可能的扩展点，以及对这样的扩展点进行讨论，正是测试活动之一。 所以必须对扩展点，以及其相关讨论，结论进行记录。简单讲，当认为不发生这种扩展的可能性很大时，对应测试项是Pass;否则是fail.

　　实现特性视角

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

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

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

　　错误模型视角

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

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

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

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

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