第一章 自动化测试模式差异化

　　1、产品、项目测试和运营测试

　　（a）三种测试模式的异同

　　大部分从业人士可能都知道产品开发的模式和具体流程，但可能并不是所有人都了解产品开发和开发完毕之后的运营维护的实际情况。笔者曾有幸在“神码融信”先后经历过东亚银行、兴业银行和国家开发银行这三个项目的测试，有现场实施也有基地化开发；之后进入平安集团信息管理中心，也就是现在的平安科技，这两份工作经历让笔者有幸简单了解了一下软件测试的不同模式。笔者理解，软件测试从项目类型上可以分为新产品开发项目测试、普通开发项目测试和运营测试（补丁需求版本）测试。本节简单阐述一下笔者心目中这三者的异同。

　　1）新产品开发项目测试

　　● 因适应新的市场或内部需求诞生或衍生一个或一组全新的系统。这些系统可能是经过深思熟虑而设计的，也可能是探索性的，但是无论对于开发还是测试和用户，它们都是从未操作过的。测试人员对系统的了解仅限于需求文档和页面原型，鲜有经验可供参考，像Windows 7和Office的一些新组件等。

　　● 有着较为充裕的时间跨度，能够运用较多的新技术和新思想。为了满足业务需求开发时可能会引进新的技术或平台架构，对应的测试人员如果经验不是非常丰富，那么需要学习的东西就比较多，甚至有时会出现系统上线之后“才刚刚有了那么点感觉”的意思。

　　● 一次性，项目发布之后，项目组大部分人将撤离，只留下部分同事做后期维护工作。所以它在时间概念上是以一种一次性的模式存在的。

　　2）一般的开发项目测试

　　所谓一般的项目开发，主要是指：

　　● 技术、架构转平台项目，如某银行使用的核心对公交易管理系统从字符终端（C/S）升级到J2EE的Web页面（B/S）、保险公司传统业务系统的Forms转换到J2EE；

　　● 较大的系统变更项目，就是说系统变更所需要的人力、财力已经达到了立项标准的程度从而走了项目管理流程。

　　相比较上文新产品开发测试提到的几点：

　　● 系统中保留了业务逻辑理念，架构转平台时UI发生极大的变更，而同平台下的大规模改造则会沿用较多的现有模型。对于测试来说，最实惠的是有经验可借鉴，主要参照现有系统的逻辑作对比的变更测试，目的更为明确。

　　● 已有技能和经验在测试过程中起到不少作用，测试人员上手速度比较快。同时系统改造或者技术转平台将会对没有发生变动的模块产生大量的关联影响，可能大家比较认同的是：每一轮向测试环境重要的发布都要经过全面的冒烟测试，即便关联影响在开发阶段得到了很好的控制，这种冒烟测试也不是多余的。

　　● 同项目开发测试，只不过多次改造、升级可能会连续进行，如每两、三年发生一次。

　　3）运营维护性需求测试

　　● 系统中绝大多数的规则和页面都没有发生变更，前台操作和后台的逻辑对于测试人员来说都是轻车熟路，不会有太多障碍，除非测试人员本身技能有问题；

　　● 变更的关联影响比较小，基本上能够通过SA、设计、编码和测试人员的共同评估就可以轻松得出变更范围和关联影响程度。事实上为了“保险起见”或者出于对这几方人员的不完全信任，让测试人员在发布前做一次全面的回归测试也是大多数公司和领导愿意去做的事情。

　　● 持续不断的，在系统运营中，为了满足新的业务需求或者解决已有生产缺陷，系统将持续不断的向生产发布补丁版本。区别在于周期是不固定的，有可能是每半个月、一个月发布一次版本，也可能是一个季度一次版本；可能也有版本管理不严格的公司，随时开发、测试完毕随时发布生产。

　　这里需要指出的是，在项目测试里面，只要是增量式移交模式，那么测试的工作内容也是增量的，除非每一阶段的代码完全独立、相互毫无关联。而事实上这是不可能的，也是违背目前开发设计理念的，因为很多好东西无法复用。为什么说增量式移交带来测试工作量递增呢？假设一个项目分三期移交，那么测试第二期移交的内容的同时就必须考虑第一移交内容受影响的可能性；在做第二期移交内容的完全测试的同时显然还要去做一期内容的测试，一旦发现问题就是反复好几次的移交……同理第三期移交将带来更加多的问题累积，传统的手工测试模式在同等的人力下很难支持这种移交模式。而在现代的先进开发模式里，敏捷开发占据了很大部分，恰巧敏捷开发基本都是增量式构建的，这就是对传统手工测试的最大挑战，之所以要在每日构建中引入自动化测试工具的使用，就是为了解决这种问题。

　　（b）对自动化测试的要求

　　1）新产品开发项目测试

　　前文提到新产品开发可能会引进全新的架构和技术平台，即将诞生的新系统对于测试人员来说也是完全陌生的，所以至少在首次移交测试环境之前，做自动化的分析调研难度都是非常大的。一般来说一个公司现有的自动化测试框架能否满足这种情况下的自动化开发也是个未知数。无论是否可以满足，参与该项目自动化构建的人至少应该包括一个对系统架构非常熟悉的人（无论是开发还是测试）、一个对业务需求十分了解的人、一个对测试整体过程和规范十分了解的人、一个自动化测试技术很好的人，当然测试经理和项目经理都能参与或许能给出一些较为有价值的、有大局观和前瞻性的建议。如果有一个同时熟悉环境架构、业务、自动化测试技术和测试规范的人，那么很幸运，让他来吃螃蟹吧。这个人在测试工具选取、框架设计修改上承担着很大的责任，这个时候丰富的经验和灵活的头脑将成为很重要的资本。在项目编码的初期，测试设计专家就要能够有效论证已经选择的方案和方法是行得通的，并且做好技术风险的评估，找出自动化实现过程中可能遇到的类如安全性、兼容性、可移植性等等技术性问题。通常对系统架构熟悉或者决定系统架构的是EA，熟悉整体业务能预知UI设计细节的是SA和设计编码人员，熟悉自动化测试技术和测试流程规范的是资深测试工程师，所以完美的这么个兼各家之长的人是很难找到的。那么测试人员能做的是把大家聚到一起，对将要实现的目标和已有的资源做一个理性的分析，评估完毕给出分析报告，由测试经理和项目经理给出意见和建议，在不影响到项目成本和项目任务关键路径的情况下由测试经理给出最终的裁决：工具选取、人员、资源配备、进度计划等等。