由概念上,我们通常说的测试设计,都只是说用例测试,从来没有说过“测试流程设计”。作者将“测试流程设计”和“测试组织的模式设计”提到了一起,统称为测试设计。
谈到测试流程设计,这局限于公司层面的组织结构(模式),从测试组的角度看,是测试在什么位置,是保护在开发部内部的?是和开发独立的,可以为开发提供服务的部门?作者介绍了不同模式的不同特点。但是我想,一般情况下,不是有我们测试组来或者能决定的,我们当然希望独立出来,有自己的权威,可一者是可能你没有这个权利和机会,二者测试从某种程度上说不产生效益,“独立核算”困难重重。当公司达到一定的规模后才能考虑这个问题吧,这是测试人追求的方向。
从总体上和自己的经验知道,“测试流程不是静止的,要不断的改进”,这其实也是CMM的精髓吧。这个在Relan的时候,感觉比较深,因为是一个创业的公司和新的团结,从零开始,大家有这样的意识,“我们不完善,我们需要改进”。我们的很多会议是在讨论流程,让流程为工作服务,使出现了问题后能得到解决。正如书中举例的“软件运行的和蜗牛一样慢了”,还没有人去反映问题,这是不对了,为了下次避免这样的问题,要在流程上改,我想流程,是让每个人都知道,当出现什么情况时,我该怎么做。这有点像“Switch语句”,当我们设计的时候,可能会想到5个case,但后来问题出了,“哦,这个没有想到”“OK,我们在这个switch语句中加一个case”,下次知道了。如此的改进,我们在前进了。
这让我想起了Relan那时候的发布流程(开发--》测试)。
1、开始的时候,开发给测试给压缩包,自己写个文档过来了。测试不得不连猜带蒙的部署环境,出了问题直接叫开发过来,测试累,开发麻烦。这样的开发觉得测试没能力,测试觉得开发不负责。
2、解决办法:OK,那我们改,首先开发先带测试部署,基本的部署步骤都是差不多的,测试写文档记录下了,以后参照。开发发版本的时候,规定格式,更新了哪些内容,模块,负责人。
3、部署顺畅了一下,但测试的时候,某个功能开发说改了,可测试发现没改。原因:开发没提交。或者测试数据有问题。
4、解决办法:开发给版本时,不但提交代码文件,还要提交数据字典,及数据库相关修改。
5、由数据库的表的了解,测试过程得到深入。但压缩包有个问题,是当测试--》运营时,运营在外网没法部署,不能全替换,只能更新文件。另外,外网部署的时候,显然不能重新安装数据库,只能对某个表结构进行更新。
6、解决办法:开发不给压缩包了,压根不给code;只给修改的文件列表,哪个文件修改了,目的模块,修改人。数据库给sql语句,给数据字典。测试拿到这个表,去cvs上下代码,只对现有系统更新开发给的列表文件;数据库只执行DBA给的sqlOK了。
7、这样,为了解决这个问题,我们不断的改,还对小的过程进行了微调,例如开发---》测试的发布通知,必须是邮件,必须记录开发给出时时间,测试部署完成后的时间,其中出现了哪些问题。这些问题是我们下次改进流程的依据。同时,根据时间差,能看出来哪个步骤的效率低,产生了阻碍。
一句话,测试流程是在不断的改进中。