文档介绍：周末的时候听了微软测试的培训,颇有感触,主要是测试的方面的培训,也包含了微软做项目的流程和方法。从微软做项目的流程上,如何使上千人或更多的人有良好的协调,保证项目的质量,可见一斑。从需求开始说起,正如我们所知需求是一个项目的灵魂,如果需求偏离了,后面的开发测试可能要走很多弯路。需求不明确,迫使开发人员按照他自己的想法去设计,可能出来的结果不是客户所需的。导致大量的无效代码写出来,被推翻,然后再继续,又被推翻……有句老话叫:失之毫厘,谬以千里就是这个意思,如果为了抢进度,而在需求这部分挤时间的话,到了项目的后期就必须要花成倍的人力,物力来弥补。测试在需求不明确的情况下测试,有些早期可以规避的设计问题在后期发现,无疑于亡羊补牢而非未雨绸缪。那么微软是怎么样做的呢?一个大的项目,分成若干子模块。每一个模块对应一个需求人员,一个开发人员和一个测试人员。微软的项目是没有概要需求的,从长期总结下来的经验看,概要需求的设计作用不是很大,因为没有什么内容也很容易导致概要需求的评审大家也都是很happy就通过。直接就是详细需求文档,要详细到每个接口的定义,甚至每个输入框可输的数据类型。这个模块的需求文档出来之后,都有什么人参与评审呢?其中包括,此模块的开发人员和测试人员;开发经理和测试经理(评审需求用来保证和其他模块兼容);市场人员(从用户角度考虑);大头()这六个人去评审这个模块的需求,这六个人一起去看需求文档是否合理细致,实行一票否决制,任何一个人不SignOff都不能通过。之后就是这个模块的详细设计文档(开发人员)和详细测试计划(测试人员)。这就保证了开发和测试的并行。同样,详细设计文档和测试计划也都是六人评审制。为什么需要那么多的人评审?是要在做事之前,让其他人帮助你看你想清楚了没有,人无完人,一个人想的再全面也有可能有疏漏的地方,所以聚集其他人的力量帮你想清楚避免走弯路。假设某个项目有30个模块的话,意味着大头要看30个模块的需求文档,30个模块的详细设计文档和30个模块的详细测试计划。他将需要看90份文档,这样,就能够保证了整个项目了然于心。我听到老师讲的很震撼的话就是,在微软是没有QA的,。因为不是重点,讲的不是特别细致。主要的核心点是如果来预防缺陷要高于如何解决缺陷。严格按照详细设计文档来编码,就不会产生之前的大量无效代码的情况。开发团队还需要有CodeGuideLine编码规范。认真执行编码规范。开发人员在check-in之前要保证自己的编码为有效代码。如何保证开发人员的编码为有效代码呢?这就引入了自动化测试,为了保证编码有效,就要利用自动化测试工具来保证。思路是用程序来检查程序。在编码的过程当中,运行自动化测试工具能帮助开发人员边编码边检查。提交上去的代码自然要比没有经过编码检查的质量要高很多。这样就做到了边开发边测试,也就是所谓的“极限编程”。当然微软的自动化测试工具都是自己开发的,量身为项目本身所打造。自动化测试,它是软件质量的保障体系,自动化测试最大的优点就是把重复性的劳动交给计算机去做,包括review静态代码,每个版本更新后都需要重复测试的功能,或者是大量的数据的重复操作。这些如果在项目之前都开发完成的话,对于软件的效率会有极大的提高。但是有利有弊,自动化测试也有一定的局限