好文章《走出自动化测试的乌托邦》第一章 引言

第一章 引言

若论起自动化测试来，可真是一千人有一千个说法，分歧争议多多，而剪刀石头布在这并不能解决任何问题。举例来说，对于“商业主义”和“开源主义”之争，则可以引用邓大爷的一句话来概括：不管是黑猫白猫，抓到老鼠就是好猫！在这个问题上，大部分的分歧都是因为想把自己的价值观和经验强加给别人，或许他们根本就没有仔细考察过别人的需求，没有弄明白别人为什么坚持不使用自己推崇的工具，泛泛空谈而已！无论是商业工具还是开源工具，自动化测试都应该有着完整的体系流程，可以细化研究，却不可因测试工具不同而在管理上区别对待。就像整数包含正数、负数，也包含质数、合数，但是在做加减运算的时候却不需要也不能够去做这么多维度的划分。类似的道理，无论是商业工具还是开源工具，它们应该都有相同或相似的测试框架和流程、规范，否则自动化测试只能依赖较强的个人能力去维持，而过于依赖个人能力对于组织来说则不具备稳定性和可靠性，对持续发展是不利的。最近看新版三国，不如捎带编个顺口溜：人中吕布，仅三姓家奴；恩义持国，得上将锦蜀！

就对工具和测试手段的态度来说，笔者始终坚信人才是制胜的决定性因素，不要轻言任何工具有多好或多不好。有人认为商业工具的对象与方法封装的很死，二次开发没有开源工具那么随心所欲；有人认为开源工具使用起来编码难度更大、缺陷也多，只有少数的几个人能精通，很难在组织内推广。其实我们可以考虑一下：

（1） 有些人主张自动化只用来进行单元测试和集成测试，以追求更多的效益，那么请问我们平常需要做多少抛开页面的接口测试？而且这些接口测试难道不能、完全不能通过页面去测试么（如开发接口模拟器）？大量UI需要（自动化）测试的现实可以被忽略么？

（2） 有些人喜欢把不成功的自动化实现迁怒于测试工具，请问你的工具使用起来效果不好问题在哪里？你们是否已经把这个你觉得不好用的工具用到极致了呢？你的问题是否只是脚本写的不好而已呢？如果是这样，那么A语言用不好，莫非B语言就更容易么？

总之，不要因为商业工具用的失败就去追求开源，也不要因为开源工具用得不方便就去追求商业工具，必须先弄清楚自己为什么用的不好，问题在哪里，如何改进！盲目的赶潮流倒是能积累很多经验，但同时也势必会给组织带来无谓的资源浪费。当然，如果已经在一种工具和平台下达到了较成熟的测试水平，那么再引进一些其他的工具技术来丰富一下自己的测试也是可取的。

笔者只有四年的Web（自动化）测试经验，主要使用的是Mercury系列商业测试工具，故而所谈论的一些内容主要都是以自己的经验认识为基础的。不过笔者相信做任何事情原理本质上是相通的，而且我们讨论的自动化测试的原理都是基于测试基础理论和项目管理基础理论。笔者不敢标榜自己“精通”或“谙熟”自动化测试，只是觉得有想法就要适时总结，与大家探讨、分享。笔者本文只讨论理念，不讨论技术，只希望通过本文的探讨可以整理一下自己长久以来在自动化测试上混乱的思路，也希望笔者的观点不要成为束缚大家思维的罪恶黑手或者任何人说教的依据，“抛砖引玉”可，“抛砖引砖”亦可，希望诸位读者不吝赐教。

为了不让读者为了这么又臭又长的文档浪费精力，笔者简述一下本文的核心思想：一是弄清楚自己需要什么样的自动化再去做自动化，二是如何避开在做自动化的时候因误解而带来的阻力，三是自动化应该通过科学的管理来解决技术（包括框架）和人才储备的问题，四是自动化的成本效益可以站在更高一些的层次上来看。