一些关于测试的思考

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

还是想谈谈对测试看法。

1.测试的分工

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

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

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

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

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

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

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

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

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

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

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

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

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

2.测试自动化

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

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

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

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

3.TDD

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

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

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

4.集成测试，单元测试

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

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

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

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

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

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

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

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

暂且想到这么多。