在著名的软件瀑布模型中,软件测试处在“编程”的下游,在“软件维护”的上游,先有编程后有测试,测试的位置很清楚,但瀑布模型没有反映SDLC的本质,没能准确无误地反映测试在SDLC的位置,瀑布模型中的软件测试是狭义的测试,落后的测试观念。
如前所述,软件测试贯穿整个SDLC,从需求评审、设计评审开始,就介入到软件产品的开发活动或软件项目实施中了。测试人员参与需求分析和需求评审,通过积极参与需求活动,测试人员不仅能发现需求定义自身存在的问题,而且能更深入理解业务需求、特定的用户需求和产品的功能特性,为测试需求分析与设计等打下坚实的基础。更进一步,这个阶段可以确定产品测试的验收标准,可以制定验收测试的计划和设计验收测试用例(test case)。同理,在软件设计阶段,测试人员要清楚地了解系统是如何实现的、采用哪些开发技术以及构建在什么样的应用平台之上等各类问题,这样可以提前准备系统的测试环境,包括硬件和第三方软件的采购。更要针对一些非功能特性(如性能、安全性、兼容性、可靠性等)检查系统架构设计的合理性和有效性,发现设计中存在的问题,并着手研究如何测试当前的软件系统,完成系统测试用例设计、测试工具的选型或启动测试工具的开发,进一步完善测试计划等。所有这些准备工作,都要花去很多时间,应尽早开展起来。
当设计人员在做详细设计时,测试人员可以直接参与具体的设计、参与设计的评审,找出设计的缺陷。同时,完成功能特性测试的用例,并基于这些测试用例开发测试脚本。
编程阶段的单元测试是很有效的,越来越得到业界的关注和实施。有数据显示,单元测试可以发现代码中60%~70%的问题,充分的单元测试可以大幅度提高程序质量。其次,单元测试和编程同步进行,极其自然,可以尽早发现程序问题。
软件测试在SDLC中的位置,可以通过图0-1充分地体现出来(也可参考W模型)。软件测试和软件开发构成一个全过程的交互、协作的关系,两者自始至终一起工作,共同致力于同一个目标——按时、高质量地完成项目。
图0-1 软件测试和SDLC的关系
如果从团队来看,测试人员也是软件研发团队中的主力军。在软件研发团队中,虽然有很多角色,包括项目经理、产品经理、用户界面(User Interface,UI)设计人员、开发人员、测试人员、软件配置管理人员等,但从构成的人数比例来看,主要以开发人员和测试人员为主。在传统的软件开发开发中,特别是一些关键系统(如操作系统、银行业务系统、交通信号控制系统等),测试人员占的比例就比较高,以微软公司作为典型的例子,在其过去10~20年开发Windows操作系统和Office产品开发团队中,开发人员和测试人员比例是1:2。相反的例子就是Google和facebook等互联网软件,如Google研发团队中,开发人员和测试人员比例是10:1,而facebook没有专职的测试人员。开发人员和测试人员比例,也是经人们讨论的热门话题,为此我还写过两篇文章,在自己的博客 [28] 上发表,但基本观点是因为每个公司、公司的每个产品、产品的各个项目或各个阶段都不同,没法用一个比例来衡量不同的测试团队,因为这个比例受“开发人员做哪些工作(是否包括比较多的测试工作)、开发交付的质量、产品质量要求(不同的产品质量要求不一样)、开发模式”等多种因素影响,例如:
● 开发人员进行了足够的单元测试,测试人员可以大大减少;
● 非使命攸关系统、非生命攸关系统,对软件质量要求可以降低,测试人员可以继续减少;
● 如果是在线服务系统,可以随时交付新的版本,修复缺陷的成本低、速度快,测试人员还可以继续减少
总之,具体案例要具体分析。