CMM流程的总体思路，一是基于对人的不信任，所以设置各种流程、文档、CHECKLIST，来检查是否达到指标，只有达到指标才能往下走。二是下游的工作是基于上游的文档的，一般下游的工作不用管上游是否正确，所以对上游的工作要求更高，一旦上游工作出了问题，后续的工作中又没有人能指出来，则整个工作都有可能出问题。所以CMM流程试图将软件生产工作打造成传统制造业一样的流水线，但前期一旦跑偏则危险很大。

　　CMM的整个流程从开发来看一般包括需求分析、规格设计、概要设计、详细设计、编码、UT、ST、BBIT；从测试来看包括测试策略、测试方案、测试用例、自动化脚本、测试执行几个过程。

　　众所周知，测试理论分为两派，一派是证实，一派是证伪，但做为企业项目来讲，证伪的成本太高，一般以证实为主，也就是证明客户的需求是可用的，产品能满足客户需求即可。

　　测试想要证实产品满足客户需求，显然需要对需求有很充分的了解，要对需求有很充分的了解，最好的办法就是测试人员参与需求分析，参与客户需求的澄清，甚至方案设计，所以测试（参与需求分析、规格设计一般称为静态测试）开始得越早越好。前期静态测试，主要的目的一是熟悉需求，二是从测试的角度、客户的角度分析客户的显性需求和隐性需求，避免遗漏和跑偏，尤其是隐性需求，还有一个目的是提取测试需求，保证需求的可测试性。

　　测试策略的制定需要很高的技能和对系统的全盘了解，对需求的全盘了解，对人的要求较高，所以一般完成后再找开发、测试、甚至硬件、维护人员一起讨论；策略的目的是为了指导整个测试工作的开展，明确什么东西在什么时候测试，测试重点是什么，测试技术如何准备，测试环境如何规划，在资源人力冲突时重点保障什么，以指导后面的测试方案、测试用例写作、环境准备、测试执行等工作。

　　测试方案的写作相对容易，主要是运用一些测试工作方案，对需求、规格进行分析，结合经验，明确该特性的测试重点，难点，测试环境规划，自动化设计思路等，回答测什么和怎么测的问题，方案的最终除了明确这些内容外还是明确测试用例的标题，以指导后续的测试用例写作和自动化脚本编写。

　　测试用例和自动化脚本编写则更简单些，依照测试用例标题，明确测试的预置条件、测试步骤和预期结果，脚本则是依照这些条件、步骤和结果来编写。

　　接下来就是关键的测试执行，有人讲，测试用例设计的好的话，测试执行按步就班就可，实际上不是这样，软件生产毕竟不同于传统的制造，人的主观能动性起着关键性的作用，因为前期所有工作不可能都做到100%正确，所以最后一环测试执行肩负着补前期所有失误的责任。测试执行除了按照用例执行外，关键的是在充分了解需求的情况下主动思考，找出存在的隐患和不合理的地方。

　　测试工作的最后体现就是一份结论清晰、有数据支撑的测试报告，可以使用各种方法来确定软件是否达到质量目标，但最终要回答的还是功能是否可用、有没有风险、风险的大小、风险是否可以规避和控制几个问题。