最近在infoq上读到一篇讨论测试自动化的文章。虽然自己是一个开发工程师,

还是想谈谈对测试看法。

 

    1.测试的分工

    测试的分工上讲,我想可以分为:技术测试,业务测试,这两类测试各有所长。

从目前公司现在情况,或者国内测试的分布来讲,更多的是业务测试。但是从公司对

测试的发展规划来看,越来越看重测试在技术方面的认知水平。懂得技术实现的原

理,同时懂得测试技巧的测试,在工作中发挥的作用,确实是比较大。

    个人认为,对测试技术能力进行强制的要求,是不太合理的。需要针对公司的技

术,业务场景;个人的技术,测试特点,进行综合的考虑。

    业务测试,是通过不断积累的业务业务知识,测试技巧进行测试,对于业务模式

固定的产品,这类测试时不可或缺的;但是从另一个方面讲,业务模式固定的产品,

也应该能很好的进行自动化测试。

     技术测试,对技术的掌握能力,能让测试在更多细节把握。技术测试能用比较

简洁有效的方式进行测试,而这种方式,往往高效。对于技术复杂对稍高的公司,比

如互联网公司,对稳定性要求较高的公司,对质量要求高的公司,懂得技术的测试往

往能更细节的关注业务流程和业务实现。

 

     2.测试自动化

     测试自动化,不仅仅是测试完成的自动化。为何这样讲呢?自己也感受过公司

的测试自动化,总体感觉自动化测试还是很苦逼。能用的自动化总是容易实现,好用

的自动化总是很难。个人觉得要实现自动化:

  •       不能脱离实际的业务场景进行自动化
  •       需要从整个软件的生命周期进行自动化规划。
  •       自动化需要是持续,有生命周期的运行。

 

     3.TDD

     有些人在尝试这个,也有把自己搞的很苦逼。TDD的粒度一定不能太小,对一个

类或者小的功能点进行TDD,不太现实,而且耗时耗力。使用TDD一定是在比较成型的

业务功能点或者业务流程上面。

 

     4.集成测试,单元测试

     概念上面不讲了,也有很多文章讲怎么写好单元测试。单元测试时我们质量保

证的一个重要方法,当然这个是建立在写的好的单元测试上面。

     个人认为,单元测试,更应该在基础模块,复杂实现功能点上进行。而在业务

流程的编程上面的测试,则不要使用单元测试。

     个人更倾向于使用集成测试,集成测试需要在更好的高度对测试用例进行规划

和管理,只有这样,我们的测试才有效,能持续,有生命力。

     不要为了覆盖率,而覆盖,这样开发很苦逼,更重要的测试没效果;但是好的

测试,可以通过覆盖率反向的分析代码:那些代码多了,那些代码可以重构等等。

 

      暂且想到这么多。