测试篇--V模型的讨论
V模型非常对称,从测试设计 到 测试执行 都有着严格的边界。
模型如图
----------------- --------------------
requirement acceptance testing
----------------- ---------------------
v ^
---------------- ---------------------
specification system testing
---------------- ---------------------
v ^
------------------------ -------------------------
architectural design integration testing
------------------------ --------------------------
v ^
----------------------- --------------------------
detail design unit testing
---------------------- --------------------------
v ^
-----------------------
code
----------------------
单元测试所检测代码的开发是否符合详细设计的需求,以及代码规范。集成测试检测各部分是否能完好地组合在一起。系统测试
测试组合在一起的产品是否符合系统规格说明书要求。 验收测试检测系统是否最终符合用户要求。
V模型的缺陷
人天生是一种不守规矩的动物,当年亚当和夏娃就是不守规矩才发展出来这么多子子孙孙。一个单线程很严谨的系统,你
完全可以认定它是不友好、保守、没有效率甚至令人生气的系统。V系统把设计和测试划分的泾渭分明,把测试各个阶段做的
前后有致。这本身就存在这问题。
在单元测试的环节,被划分的单元在测试时需要别的单元模块提供支持,这样就衍生出桩模块和驱动。进行单元的黑盒测试时,
是重新设计桩模块还是利用相关单元模块,这就很难取舍。开发桩模块,需要加大成本以及时间资源。利用相关单元测试,这样
等同于在做小规模的集成测试,可能又会因为在集成测试里排除单元模块的问题耗费更大。 这中间是一个权衡的关系。
一个测试,如果要发现一个特定的单元中的bug,最好是在该单元保持独立的情况下进行,并辅助桩模块和驱动进行测试。
而另一种方法则是让它作为子系统的一部分来进行测试,该测试的设计主要是为了发现集成的问题。
由于一个子系统本身也需要桩模块和驱动模块来模拟该子系统和其它子系统的联系,
因此,单元测试和集成测试可能被推迟到至少整个系统已经部分集成的时候。
在这种情况下,测试者可能通过产品的外部接口同时进行单元测试、集成测试和系统测试,同样的,
其主要目的还是为了减少总体生命周期的成本,对测试成本和延期进行测试及由此造成延期发现bug的代价成本进行权衡。
据此而言,"单元测试"、"集成测试"和"系统测试"的区别已经大大削弱了。