很多开发人员，特别是新入行的年轻人，我觉得最容易犯的一个错误就是对开发职能上的理解。很多新人谈到程序，感觉就只包含编码这部分工作，好像验证程序正确性都是测试人员的工作与他无关一样。
这种观点对项目组的工作和程序员自身的提高都是有害的，试想如果你写的程序连基本的正确性都满足不了，那还有谁会用这些程序。 所以作为一个软件开发人员，除了完成手上的开发任务外，很重要的一点就是如何保证所写的程序能够正常运行起来，并且运行的逻辑能够符合业务逻辑的要求。（抛开性能等指标暂不说，业务逻辑正确性算是最基本的要求）
另外，很多人会以为测试没有找出 bug，就证明程序是正确的。对此，我想说这种观点实在太乐观了，即便是软件巨头开发出来的程序，也是有 bug 的，比如说 windows 吧，用过的朋友都懂的。
为什么有了比较规范的测试，还会有bug的存在呢？说到这里不得不说一下测试的一些事情，因为测试人员很多时候使用自己构造的用例来运行程序，分析结果是否和预期一致，很多时候测试人员构建的用例都是通过等价类、边界值等方式构建的用例，很显然如果对每种情况都进行一下验证是不可能实现的，时间上都无法接受。所以，问题就出来了，如果测试人员分析的不准确，一些地方等价类或者边界划分有误，构建的用例的结果是不是就有误差。另外，更多的情况是调用的其它的库，有可能这个库本身有一些问题，或者一些参数等的使用上面没有理解透彻，导致调用不正确，当然更多的情况是开发人员本身代码写得比较差，在一些小的地方引入一些不该有的bug，像问题估计多半是不会体现到测试的用例中的，所以想在测试过程发现所有问题是不太现实的。
而且很多问题如果开发人员可以提早发现，那么测试人员测试的效率也能提升。试想一下，如果测试人员测了很多模块后才发现一个bug，提交给开发修改后，是不是又需要回测一遍。如果同时有很多bug，很多时候改完一个测半天发现还有，这样开发测试就不断地修改、回测，很多轮过去可能才勉强可以测试通过，这种方式显然不是一中高效率的方式。
所以呢，最好是开发人员也能够掌握一些测试知识，这样就可以尽可能早地发现一些测试不易发现的问题，既可以保证程序质量也可以提高团队的开发效率。像代码覆盖、判定覆盖、分支覆盖以及路径覆盖这些应该结合自身的业务场景尽早地确定好应该采取那种规格的测试。当然，开发人员在项目一开始就能考虑到如何方便测试，比如使用一些模块化、分层、Mock、自动化相关的一些手段来保证程序能够很方便和高效地完成常规的测试，并且可以将以前的测试数据尽可能多地利用起来，方便完成回归测试。这样子以后维护系统和做相关的改动等都更加有保障，也可以减轻测试人员的工作量，还可以提高开发人员和测试人员的工作的衔接度，提高项目组的效率。
