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