最近在infoq上读到一篇讨论测试自动化的文章。虽然自己是一个开发工程师，
还是想谈谈对测试看法。
1.测试的分工
测试的分工上讲，我想可以分为：技术测试，业务测试，这两类测试各有所长。
从目前公司现在情况，或者国内测试的分布来讲，更多的是业务测试。但是从公司对
测试的发展规划来看，越来越看重测试在技术方面的认知水平。懂得技术实现的原
理，同时懂得测试技巧的测试，在工作中发挥的作用，确实是比较大。
个人认为，对测试技术能力进行强制的要求，是不太合理的。需要针对公司的技
术，业务场景；个人的技术，测试特点，进行综合的考虑。
业务测试，是通过不断积累的业务业务知识，测试技巧进行测试，对于业务模式
固定的产品，这类测试时不可或缺的；但是从另一个方面讲，业务模式固定的产品，
也应该能很好的进行自动化测试。
技术测试，对技术的掌握能力，能让测试在更多细节把握。技术测试能用比较
简洁有效的方式进行测试，而这种方式，往往高效。对于技术复杂对稍高的公司，比
如互联网公司，对稳定性要求较高的公司，对质量要求高的公司，懂得技术的测试往
往能更细节的关注业务流程和业务实现。
2.测试自动化
测试自动化，不仅仅是测试完成的自动化。为何这样讲呢？自己也感受过公司
的测试自动化，总体感觉自动化测试还是很苦逼。能用的自动化总是容易实现，好用
的自动化总是很难。个人觉得要实现自动化：
3.TDD
有些人在尝试这个，也有把自己搞的很苦逼。TDD的粒度一定不能太小，对一个
类或者小的功能点进行TDD，不太现实，而且耗时耗力。使用TDD一定是在比较成型的
业务功能点或者业务流程上面。
4.集成测试，单元测试
概念上面不讲了，也有很多文章讲怎么写好单元测试。单元测试时我们质量保
证的一个重要方法，当然这个是建立在写的好的单元测试上面。
个人认为，单元测试，更应该在基础模块，复杂实现功能点上进行。而在业务
流程的编程上面的测试，则不要使用单元测试。
个人更倾向于使用集成测试，集成测试需要在更好的高度对测试用例进行规划
和管理，只有这样，我们的测试才有效，能持续，有生命力。
不要为了覆盖率，而覆盖，这样开发很苦逼，更重要的测试没效果；但是好的
测试，可以通过覆盖率反向的分析代码：那些代码多了，那些代码可以重构等等。
暂且想到这么多。
