自动化测试的理解

说起来真是很丢人，做了这么多年的测试，其实对自动化测试理解还真是偏了很多~~一直以为自动化测试就是UI方面的测试自动化起来！抱着这种思想，也一直觉得如果有足够强大的框架，我们是可以实现高的覆盖率的，今天又读了几篇关于敏捷测试与自动化测试之间的关系，不得不反思一下，纠正下自己的想法了。

狭义上的自动化测试很多人会跟我有一样的理解，其实广义上来讲：单元测试、接口测试、性能测试、安全测试，只要实现了自动化都统称为自动化测试，想到这里，我忽然觉得思想又开阔了一点，为什么之前死死的纠缠在UI层面的自动化测试上不放，以为这是提升我们效率的救命稻草，而实际上，真正的UI测试起到回归作用是有的，但是并不能在项目中很好的应用，有多少次我们的项目都去尝试了UI自动化测试，又有多少次我们是没有任何产出的？几乎是100%没有产出，前期写脚本调试脚本花费的时间和后期维护时间加起来可能会比我们手工执行还要多，那么我们UI自动化在项目中的意义就比较小了，毕竟UI的一点变化都会引起我们一系列的脚本修改。那么如何让我们的测试自动化起来呢？就要从单元测试和接口测试入手了，单元测试既能做到将bug扼制在前期的作用，又可以比较稳定的运行，如果一个项目中稍微留给单元测试多一点时间，那么后期相信功能测试阶段节省的时间会更多一点。如果有这样的机会，我很希望可以拿一个项目去做这样一个实验：一个单元测试覆盖率高的项目，在后期花费时间和总体质量上是否会好很多？同时又有一个比较矛盾的问题，单元测试对业务的测试能力会比较差，再完美的单元测试覆盖率如果代码本身就脱离了业务，估计最后都是空！不过不管是否做单元测试，我相信开发都是这样写代码的，哈哈~~所以又好像没什么顾虑哦！总体来说，我们要推行敏捷或者要提高效率，单元测试是需要重视的。接口测试也是同样的道理。

反过来说，那么UI自动化测试意义在哪里呢？忽然觉得没有意义了，怎么办？可能最大的意义还是在回归上。所有从今往后，在UI自动化的规划上要多考虑考虑了。不一定拼死在项目中使用UI自动化，从其他角度上考虑，豁然开朗。