如果测试是一项微不足道的工作，为何国外大型IT公司对此如此重视？

　　如果测试是一项没有技术含量的工作，为何微软的测试工程师个个技术顶尖？

　　是否我们对于测试的理解始终存在着误区，从未真正阐述过其背后的真理？还是我们整个行业对软件工程的理解就是不健全的？

　　三驾马车，项目经理是质量保证，测试是质量控制，开发时质量造就。

　　今天，我们就谈谈质量控制。我们先不去谈质量，质量是名词，它实实在在的存在，就像一个苹果，就放在那里，不论我们从哪个角度看它，不论我们把它摆在哪里，它都是苹果，哪怕变成了烂苹果，它也还是苹果，它是不会变化的，但吃苹果的方法却是可以变化的，因为吃是动词，而控制也是动词。

　　我们常讲控制饮食，控制音量，控制情绪，控制经费，但凡提到控制的时候，一定是和量或程度有关的，饮食的多少，音量的大小，情绪的激动或是平静，这些都是和量或程度有关的。那么控制的目的是什么呢？我们下一个简单点的定义：防止事物在发展过程中性质或状态发生偏离。我没有去百度，我希望这个定义能更好的为下面的论述做铺垫。

　　我最初想到这个解释的时候觉得定义的很好，但马上意识到，这个定义中缺少了什么。偏离，偏离了什么？这个偏离和我们经常讲的“满足”有什么关系？

　　偏离的那个东东，一定是我们所希望的，所预期的，所能接受的，它就是标准。它可以是一个值，也可以是一个范围，不管它多么的模糊，它都是一个参考，是我们判断事物性质或状态是否发生偏离的依据。

　　现在，问题来了，什么是测试的标准？我们最先想到的是需求，所有的测试都是为了验证软件是否满足需求。说需求是标准似乎合情合理，但我不这么认为。

　　不论采用哪种开发模型，我始终认为，测试的工作永远处于整个工作过程中的下游，不管测试工作多么早的介入，在上游工作没有完成的时候，测试就没有标准。而我之所以不赞同测试的标准就是需求这个观点的原因则是，我们似乎忽略了设计。需求应当是设计的标准，而需求和设计共同为测试的标准。

　　综上，测试是在验证软件是否满足需求，检查软件是否偏离设计。这两者既有共通之处，也有不同之处。共通是因为需求是设计的标准，不同在于，设计可以有多种方法满足需求。

　　新的想法或许总是离经叛道，我的行业知识仍是非常欠缺，观点难免有所偏漏，如有不当之处，欢迎大家指正。