CMM流程的总体思路,一是基于对人的不信任,所以设置各种流程、文档、CHECKLIST,来检查是否达到指标,只有达到指标才能往下走。二是下游的工作是基于上游的文档的,一般下游的工作不用管上游是否正确,所以对上游的工作要求更高,一旦上游工作出了问题,后续的工作中又没有人能指出来,则整个工作都有可能出问题。所以CMM流程试图将软件生产工作打造成传统制造业一样的流水线,但前期一旦跑偏则危险很大。
CMM的整个流程从开发来看一般包括需求分析、规格设计、概要设计、详细设计、编码、UT、ST、BBIT;从测试来看包括测试策略、测试方案、测试用例、自动化脚本、测试执行几个过程。
众所周知,测试理论分为两派,一派是证实,一派是证伪,但做为企业项目来讲,证伪的成本太高,一般以证实为主,也就是证明客户的需求是可用的,产品能满足客户需求即可。
测试想要证实产品满足客户需求,显然需要对需求有很充分的了解,要对需求有很充分的了解,最好的办法就是测试人员参与需求分析,参与客户需求的澄清,甚至方案设计,所以测试(参与需求分析、规格设计一般称为静态测试)开始得越早越好。前期静态测试,主要的目的一是熟悉需求,二是从测试的角度、客户的角度分析客户的显性需求和隐性需求,避免遗漏和跑偏,尤其是隐性需求,还有一个目的是提取测试需求,保证需求的可测试性。
测试策略的制定需要很高的技能和对系统的全盘了解,对需求的全盘了解,对人的要求较高,所以一般完成后再找开发、测试、甚至硬件、维护人员一起讨论;策略的目的是为了指导整个测试工作的开展,明确什么东西在什么时候测试,测试重点是什么,测试技术如何准备,测试环境如何规划,在资源人力冲突时重点保障什么,以指导后面的测试方案、测试用例写作、环境准备、测试执行等工作。
测试方案的写作相对容易,主要是运用一些测试工作方案,对需求、规格进行分析,结合经验,明确该特性的测试重点,难点,测试环境规划,自动化设计思路等,回答测什么和怎么测的问题,方案的最终除了明确这些内容外还是明确测试用例的标题,以指导后续的测试用例写作和自动化脚本编写。
测试用例和自动化脚本编写则更简单些,依照测试用例标题,明确测试的预置条件、测试步骤和预期结果,脚本则是依照这些条件、步骤和结果来编写。
接下来就是关键的测试执行,有人讲,测试用例设计的好的话,测试执行按步就班就可,实际上不是这样,软件生产毕竟不同于传统的制造,人的主观能动性起着关键性的作用,因为前期所有工作不可能都做到100%正确,所以最后一环测试执行肩负着补前期所有失误的责任。测试执行除了按照用例执行外,关键的是在充分了解需求的情况下主动思考,找出存在的隐患和不合理的地方。
测试工作的最后体现就是一份结论清晰、有数据支撑的测试报告,可以使用各种方法来确定软件是否达到质量目标,但最终要回答的还是功能是否可用、有没有风险、风险的大小、风险是否可以规避和控制几个问题。