从需求开始说起，正如我们所知需求是一个项目的灵魂，如果需求偏离了，后面的开发测试可能要走很多弯路。需求不明确，迫使开发人员按照他自己的想法去设计，可能出来的结果不是客户所需的。导致大量的无效代码写出来，被推翻，然后再继续，又被推翻……有句老话叫：失之毫厘，谬以千里就是这个意思，如果为了抢进度，而在需求这部分挤时间的话，到了项目的后期就必须要花成倍的人力，物力来弥补。测试在需求不明确的情况下测试，有些早期可以规避的设计问题在后期发现，无疑于亡羊补牢而非未雨绸缪。

　　那么微软是怎么样做的呢？一个大的项目，分成若干子模块。每一个模块对应一个需求人员，一个开发人员和一个测试人员。微软的项目是没有概要需求的，从长期总结下来的经验看，概要需求的设计作用不是很大，因为没有什么内容也很容易导致概要需求的评审大家也都是很happy就通过。直接就是详细需求文档，要详细到每个接口的定义，甚至每个输入框可输的数据类型。这个模块的需求文档出来之后，都有什么人参与评审呢？其中包括，此模块的开发人员和测试人员；开发经理和测试经理（评审需求用来保证和其他模块兼容）；市场人员（从用户角度考虑）；大头（据说是比尔.G直接的下属）这六个人去评审这个模块的需求，这六个人一起去看需求文档是否合理细致，实行一票否决制，任何一个人不Sign Off都不能通过。之后就是这个模块的详细设计文档（开发人员）和详细测试计划（测试人员）。这就保证了开发和测试的并行。同样，详细设计文档和测试计划也都是六人评审制。为什么需要那么多的人评审？是要在做事之前，让其他人帮助你看你想清楚了没有，人无完人，一个人想的再全面也有可能有疏漏的地方，所以聚集其他人的力量帮你想清楚避免走弯路。假设某个项目有30个模块的话，意味着大头要看30个模块的需求文档，30个模块的详细设计文档和30个模块的详细测试计划。他将需要看90份文档，这样，就能够保证了整个项目了然于心。我听到老师讲的很震撼的话就是，在微软是没有QA的，因为在微软每个人都是QA.

　　接下来是开发过程。因为不是重点，讲的不是特别细致。主要的核心点是如果来预防缺陷要高于如何解决缺陷。严格按照详细设计文档来编码，就不会产生之前的大量无效代码的情况。开发团队还需要有Code Guide Line编码规范。认真执行编码规范。开发人员在check-in之前要保证自己的编码为有效代码。如何保证开发人员的编码为有效代码呢？这就引入了自动化测试，为了保证编码有效，就要利用自动化测试工具来保证。思路是用程序来检查程序。在编码的过程当中，运行自动化测试工具能帮助开发人员边编码边检查。提交上去的代码自然要比没有经过编码检查的质量要高很多。这样就做到了边开发边测试，也就是所谓的“极限编程”。当然微软的自动化测试工具都是自己开发的，量身为项目本身所打造。

　　自动化测试，它是软件质量的保障体系，自动化测试最大的优点就是把重复性的劳动交给计算机去做，包括review静态代码，每个版本更新后都需要重复测试的功能，或者是大量的数据的重复操作。这些如果在项目之前都开发完成的话，对于软件的效率会有极大的提高。但是有利有弊，自动化测试也有一定的局限性：

　　● 自动化测试前期投入很大，包括编写自动化测试工具，开发自动化测试脚本。如果项目周期短，没有可持续性不适合自动化测试。

　　● 自动化测试的技术门槛相对较高，测试团队整体水平不高的情况下无法完成工具的发开，心有余而力不足。

　　● 对于没有预期结果的测试，不适应自动化。

　　● 对于用户体验的测试，主观性比较强的不适应自动化。

　　下面就从测试计划开始：

　　基于前面详尽的需求文档，测试人员开始制定详细测试计划，和详细设计可在同一时间完成。完美的测试是90%的测试任务和开发并行完成，10%的测试任务在开发之后完成，还是刚才说的，预防缺陷要比解决缺陷效果好的多。让开发人员边开发就边测试自己的代码使之都是有效代码。测试计划中除了包含常见的测试内容，功能测试，性能测试，健壮性测试，安全测试，界面测试等，还应该考虑到UE用户体验测试，因为用户体验的好坏是决定商业上是否成功的标准。不仅把产品做到能用，还要把产品做到好用。所以产品开发完成之后积累用户的反馈也很重要。还有风险的方面，包括自动化测试工具的使用，售后升级是否有保障等。需求不明确所导致的测试时间的延长，这些都要计算到测试风险之中。关于架构的测试是十分重要的，一定要提前到需求层面上。当然系统架构师需要极高的技术壁垒来保证系统的架构。