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