其实很多测试的问题都是由于系统本身设计造成的。比方说，一个高耦合的系统总是牵一发而动全身，你让别人怎么区分公共模块？公共包的接口老是改，你让调用这些接口的模块怎么维护？开发特别是设计人员经常忽视软件的"可测试性",因为这在客户角度可见度很低。为什么我们要求测试贯穿始终？就是要所有人从需求开始到发布自始至终重视所有提交工件的“可测试性”。

　　好，解决这个问题以后我们可以从测试的角度来看看有什么策略可以采用，先从常规手工测试开始。

　　1、假定公共模块改变了实现方式但不改变签名接口，这个好办，单元测试就可以搞定。个人始终认为完整高质量的一套单元测试套件对于保证产品的质量是至关重要的。只要原有的单元测试100%通过了，我们就有理由信任现在的代码依然可靠。风险：低

　　2、单个公共模块的接口有改变，但不影响其它模块的接口。建议做全套单元测试，从索引中找到所有有调用关系的模块，做集成测试，回归测试。风险：中

　　3、多个公共模块同时有变动，常见于大规模的系统重构，如应用新的设计模式。这种变动万不得已是不建议的，因为风险太大。真的有了这种情况只能根据实际情况尽可能全面地重新测试。建议设计测试用例的时候一定要按严重度分级，测试时从高到低往下做，降低潜在的损失。同时建议为用例和代码模块建索引，有了代码变动相关联的测试用例就要升级为高优先级。风险：高

　　4、对于新的公共模块，在进行了较好的单元测试和接口测试以后，可以在优先级最高的测试用例中做全面的系统测试，对于其他测试用例可以当作第三方模块（假定无缺陷)来处理。风险：高

　　再说自动化测试，通常我们并不特别重视自动化测试的执行开销，因为经常是在夜里执行。所以我们不太在乎冗余度，但是极端重视用例的覆盖度和独立性。举个例子，对于业务对象我们常做的操作是C(增)R(读)U(写)D(删)，那从自动化的角度来说典型的测试场景就是：

　　1. C->validation

　　2. C->R->validation

　　3. C->U->validation->R->validation

　　4. C->D->validation

　　5. C->U->validation

　　6. C->D->C->validation

　　很容易看出冗余度是很高的。

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。

本文出自51Testing软件测试网，感谢会员goal1860在每周一问（08-09-08）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html