首先交代下背景：
在做软件的UT时候，框架使用继承的方式进行搭建，如下图所示：
类CTestCase是一个父类，包含了所有
测试中公用的方法。
其中虚函数RunTest()作为对外启动测试的虚接口。
Protect类型的CommonWorks()函数包含了一些必须的公用操作，包含了不可重入的一些变量和操作，将被具体
测试用例调用。
子类CConcreteTestCaseA是对软件产品具体某一个特性的测试：
其中属性mTestAPara是测试A所独有的针对A特性的一些配置参数；
SpecialWorksForCaseA是A特性特殊的一些操作封装；
继承的方法RunTest用来实现具体的对特性A的操作，包括对特殊操作封装函数SpecialWorksForCaseA的调用；
现在的问题是，新出现了一个特性B，测试它需要调用CConcreteTestCaseA::SpecialWorksForCaseA，
但是目前已知只有极少部分特性的测试需要调用这个操作，其他特性并不需要。
我们可以考虑将B继承自A，构成3层继承关系，如下所示：
这样做的好处在于所有不可重入的变量和方法都会被保护起来。
但是从逻辑上出现了 “B is a A” 的悖论。
另一种选择则是使用关联关系，A与B保持逻辑上的sibling的关系不变，但是使用关联来实现一种类似于单一Composite的结构，如下所示：
这样做的好处在于如下几点：
主要的优点是保持了A与B逻辑上的关系正确性，而非“认兄为父”；
当A已经存在的时候，不需要更多额外的修改就可以完成这种工作；
相比于直接复制SpecialWorksForCaseA中的操作，当A逻辑发生改变的时候，更加容易更新；
相比于将SpecialWorksForCaseA提取到父类的CommonWorks的做法，缩减了父类的复杂性和规模，逻辑上成立。
缺点在于：
当A中的mTestArgs依赖于父类的mTestConfiguration时候，类CaseA的实例化需要增加复杂度。
最新内容请见作者的GitHub页：http://qaseven.github.io/
