软件测试自动化的探索与管理.docx

引言 辩证地看待“以人为本”　　若说起自动化测试， 可真是一千人有一千个说法，其实完全可以引用邓大爷的一句话来概括：不管是黑猫白猫，抓到老鼠就是好猫！无论是何种工具、何种框架或者体系，我们始终坚持 实用至上，能满足我们的测试需求才是王道。无论是商业工具还是开源工具，它们应该都有相同或相似的测试框架和流程、规范，所依赖的是一个较为完善的自动化 平台和体系。否则自动化测试只能依赖个别能力较强的测试专家去维持，而过于依赖个人能力对于组织来说则不具备稳定性和可靠性，对组织的可持续发展是个不小 的挑战。去年看新版三国的时候，还专门为此编了个顺口溜：人中吕布，三姓家奴；恩义持国，上将锦蜀！意思就是，一方面个人能力再强也可能有一天归入别人麾 下，只有靠着系统性的法则去维持系统的运转才有可能保证经久不衰；另一方面，能力发展要均衡，技术能力再强，意识理念如果落后或者停步不前的话，那就像吕 奉先一样有勇无谋，迟早要落得“身首异处”的下场。　　再看自动化测试，虽然我们不依赖某一两个人，但就对工具和测试手段的态度来说，笔者 始终坚信人毕竟还是制胜的决定性因素，不宣扬工具有多好或多不好。有人认为商业工具的对象与方法封装的很死，二次开发没有开源工具那么随心所欲；有人认为 开源工具使用起来编码难度更大、缺陷也多，只有少数的几个人能精通，很难在组织内推广。其实我们可以考虑一下：　　（1）有些人主张自动化只用来进行单元测试和集成测试，以追求更多的效益，那么请问我们平常需要做多少抛开页面的接口测试？而且这些接口测试难道不能、完全不能通过页面去测试么，例如开发接口模拟器？非敏捷的情况下大量需要UI自动化测试的现实可以被忽略么？　 　（2）有些人喜欢把不成功的自动化实现迁怒于测试工具，那么不妨让我们扪心自问：我们的工具使用起来效果不好问题在哪里？我们是否已经把这个自己觉得不 好用的工具用到极致了呢？我们的问题是否归咎于我们自己的测试设计质量不高呢？如果是测试设计的问题，那么既然VB用不好，JAVA就一定能用好么？　 　当然，不同的工具各自有各自的优缺点，所支持的需求类型和功能侧重点也有所不同，但是，绝无必要因为商业工具用的失败就去追求开源，也不必因为开源工具 用得不方便就去追求商业工具，必须先弄清楚自己为什么用的不好，问题在哪里，如何改进！盲目的赶潮流倒是能积累很多经验，但同时也势必会给组织带来无谓的 资源浪费。所以，自动化测试不仅要坚持以人为本，还要看立足点落在什么角度上，所讨论的是什么问题，所以需要辩证地看待这个问题。笔者的观点是：以人为 本，但不以某一人或几人为本。　　笔者有四五年的Web（自动化）测试经验，主要使用的是Mercury系列商业测试工具，故而所谈论的一些内容主要都是以自己的经验认识为基础的。不过笔者相信做任何事情原理本质上是相通的，而且我们讨论的自动化测试的原理都是基于测试基础理论和项目管理基础理论。本文只讨论理念，不讨论技术，只希望通过本文的探讨可以整理一下自己长久以来在自动化测试上混乱的思路，也希望笔者的观点不要成为束缚大家思维的罪恶黑手或者任何人说教的依据，“抛砖引玉”可，“抛砖引砖”亦可，希望诸位读者不吝赐教。第一章 自动化测试模式差异化　　1、产品、项目测试和运营测试　　（a）三种测试模式的异同　 　大部分从业人士可能都知道产品开发的模式和具体流程，但可能并不是所有人都了解产品开发和开发完毕之后的运营维护的实际情况。笔者曾有幸在“神码融信” 先后经历过东亚银行、兴业银行和国家开发银行这三个项目的测试，有现场实施也有基地化开发；之后进入平安集团信息管理中心，也就是现在的平安科技，这两份工作经历让笔者有幸简单了解了一下软件测试的不同模式。笔者理解，软件测试从项目类型上可以分为新产品开发项目测试、普通开发项目测试和运营测试（补丁需求版本）测试。本节简单阐述一下笔者心目中这三者的异同。　　1）新产品开发项目测试　　● 因适应新的市场或内部需求诞生或衍生一个或一组全新的系统。这些系统可能是经过深思熟虑而设计的，也可能是探索性的，但是无论对于开发还是测试和用户，它们都是从未操作过的。测试人员对系统的了解仅限于需求文档和页面原型，鲜有经验可供参考，像Windows 7和Office的一些新组件等。　　● 有着较为充裕的时间跨度，能够运用较多的新技术和新思想。为了满足业务需求开发时可能会引进新的技术或平台架构，对应的测试人员如果经验不是非常丰富，那么需要学习的东西就比较多，甚至有时会出现系统上线之后“才刚刚有了那么点感觉”的意思。　　● 一次性，项目发布之后，项目组大部分人将撤离，只留下部分同事做后期维护工作。所以它在时间概念上是以一种一次性的模式存在的。　　2）一般的开发项目测试　　所谓一般的项目开发，主要是指：　　● 技术、架构转平台项目，如某银行