利用UML来理解系统，生成测试

UML是为面向对象而生，但UML其实给我们一个机会用图形化的方式描述你的设计，不管这个设计是关于什么的，是不是面向对象的，我们都有机会用UML来展现它。

 

但是现实是很少有developer会使用UML来描述自己的设计，特别是在design specification里，大量的文字描述，加上几个自己随笔画出来的不知所云的图形；潜在的带来的危害就是，当测试人员阅读完文档后，基本上30%的歧义和误解已经产生了，再加之writer和reader对英语自然的困惑，结果就是导致测试人员以为产品是这样，直到bug file了，开发人员才指着文档说，你看我是这个意思，QA说，我操，我以为是那个意思。

 

大量文字描述的design specification带来的第二个坏处就是文档的可维护性很差，本来就没几个人愿意写文档，过期的文档要把它改成最新的，对段落的调整和内容的增减，不亚于参加一次高考，所以基本上文档都只有被写一次的机会，大部分的时间里都处在永远过期的状态。

 

如果developer可以用UML来描述他们的设计，情况应该就会好的多，从动态，到静态到状态，QA可以有很多的视图去理解系统并设计测试用例，developer对于UML的维护也一定比维护文档要来的简单，加几个方块，调整一下连线，总好过大段的文字录入吧。

 

但是说实话，UML本身有点太复杂了，复杂到记住它里面的很多表述会让人望而却步，这是个实际的问题。