前段时间经常抱怨公司不是软件公司，没有充足的软件测试来保障软件快速更迭带来的质量保障，导致软件质量有着严重的问题，最近仔细想了一下开源项目的质量保障机制，又有了一些新的收获。
在以前的软件开发公司，是有专门的测试人员和开发人员紧密合作，为了出同一个版本而共同奋斗，因为目的统一，所以大家的合作极其紧密，也相对不那么在意流程的约束，可以较为高效的快速修复问题。大部分时候都是看起来很美好的，不过也有不够好的时候，那就是这样的组合方式其实是养足了开发人员的惰性，想到反正有测试人员把关，所以也不用那么在意程序的质量。
现在的公司，不再是软件公司，基本上可以说是没有测试人员的，只有质量保证人员，他们的目的仅仅是站在客户的立场上来看系统是否能够正常运行，他们不再需要和开发人员一同为了某个时间点一同奋斗，因为他们拿到的版本就是认为基本上没有问题的版本，如果出现问题，他们也不需要和开发一同协同努力在某个时间点内完成，只需要报出问题，待开发完成修复后，拿到下一个版本后进行验证即可。这样做的确有个好处就是责任明确，分工细致，不好的就是哪怕一个小小的问题，可能都会耗上40+倍（这个是毫不夸张的数量）的时间去处理。
为此，我是想破了脑袋都想不出好的解决方案，大领导曾出过主意，公司不允许这种类型的测试人员存在，他也没有办法，不过可以考虑找实习生负责，不过比起软件公司开发人员和测试人员1：1的比例或者2：1的比例来说实在是太小了，实习生的不成熟，再加上测试工作本就不是一件简单的事情，使得这样的方案根本不可行。
其实我们现在面临的问题就是如何让开发人员可以自行完成测试工作，使得产品可以成熟的发布，然后结论就是只要开发人员的经验充足，素养足够高就可以达到了，但明显这种团队的成本极高，相当不合算，如果是我自己的公司，我一定会为我的开发人员们1：1的配备测试人员，这样的话，我不需要人人都是老手且素养高，会有测试人员去逼着他们前进，测试人员也不用人人都是精英，只要能按照测试用例忠实的一步一步执行那就可以上岗了。
好吧，绕了一圈又回去了，不过这样一绕让我明白了，为什么软件公司都喜欢这样的配置了，因为这样成本最低，且见效好。不过不管怎么说，这件事情其实对开发人员本身来说并不是很好，本来尚欠考虑质量的开发人员在保姆测试人员的娇惯下，更是难以提高了。
在这里我又想到一个特殊的个例，那就是开源项目，参与人员一多，那就一定不能保证每一个人都能如发起人那样的有经验和高素养，那开源项目是如何控制质量的呢？
综合起来看，主要是以下两个途径：
- 发起人
审查每一段签入主干的代码 - 用
测试驱动的方式配上持续集成的手段保证代码的质量
前者可以很好的保证质量，只要发起人有足够高的素养和足够的责任心，便能保证代码仓库中的每一段代码都如他自己写的一样，故代码质量便能得到相当好的保障。
而后者则可以更加轻松的保证代码的质量，只要整个系统的绝大部分（通常需80%以上）都被自动测试覆盖，于是任何的代码改动都需要通过自动测试的验证，在大覆盖率的前提下，只要能够通过所有自动测试，已经说明了这段新代码的质量，如果能辅以第一步的发起人代码审查机制，便能充分的保障代码质量。
这个是我在github上面常见到的场景，其实给我们提供了很好的借鉴意义，或许大幅度提高自动测试的覆盖率才是当前解决问题的核心。