综上所述，新产品项目开发的自动化测试在项目前期要做很多的调研和探索分析，一般需要选取一个或几个典型案例场景做出范例，论证其可行性。这样做的目的其实很简单：不让自动化成为项目的负担，让所有干系人明白自动化上的投入时值得的；让项目经理和测试经理放心、让参与自动化开发的同事树立信心。这一点无论对于什么模式下的测试都是十分重要的，但是在项目测试中显得尤为重要，因为这从根本上牵动着项目的铁三角：时间、成本、质量。如果投入的人力和资源没有给系统质量带来提高，或者中途反反复复，无疑是对项目的巨大打击。
2）一般的开发项目测试
相比之下，一般的系统开发项目倒因为自动化测试人员对现有技术平台和业务需求都是比较熟悉而变得稍微简单一些。
① 对于系统改造和大规模的补丁需求立项来说，如果这个系统（群）从未进行过自动化测试，那么笔者个人认为最好不要为了这么个项目做过多的自动化投入，至少在项目周期内不要做。因为项目周期一般没有那么长，人力资源配备远不如新产品开发，这样的情况下进行自动化首先要考虑已经成熟应用是否也要同步完成。如果需要完成整个系统的自动化那么对项目进度的影响和测试资源的占用是比较大的；如果只完成现有项目测试内容，那么前文提到的每次向测试环境的重要发布的回归测试可能不够全面，而且这样部分手工部分自动化执行对于测试分析和度量统计是一件较为麻烦的事情。
② 同上一点，如果这个系统（群）已经进行过自动化测试，在现有成熟的框架下已经有足够多的测试用例，那么自动化就非常简单。所要做的是：
<a> 在原有的框架体系下扩展自动化测试的内容，完成项目测试的自动化；
<b> 在SA或者BA的协助下重新梳理已有场景、流程，整合原有的、新增的自动化测试案例或者场景，分析项目变更重点和关联影响重点，为项目测试组建一套完整的自动化测试集合，用于每次版本发布测试环境的冒烟和回归测试。
③ 对于技术升级和架构转平台，如果项目经理和测试经理决定在项目中大规模进行自动化测试，无论之前的系统（群）是否已经完成自动化，整个自动化测试都要重头再来。同新产品开发项目测试的自动化类似，新架构、技术平台下的自动化分析、调研是必不可少的环节。之后的整个过程也是类似的，但是由于这种项目的周期可能不会有新产品开发那么长，资源也未必有那么充足，所以在论证自动化的可行性的时候一定要多关注在项目周期内的投入和产出是否协调的问题。
3）运营维护性需求测试
相比项目的两种测试模式，运营测试是铺开大规模的、系统化的全面自动化测试比较经济的一个模式，因为系统投入运营之后已经有了完善的文档和非常成熟稳定的界面，测试人员已经对系统业务流程和所采用的技术及其对应的测试技术非常熟悉了。显然项目阶段频繁的需求变更和界面改动在这个阶段内是比较少的，自动化开发和维护的成本非常低，并且应用于冒烟测试、回归测试的效果是立竿见影的。
① 如果在项目测试阶段已经完成自动化开发，那么在系统运营的时候只需稍微整理现有的功能点、场景和流程分支，搭建用于每次发布的冒烟和回归测试集合即可。当然，补丁需求带来新的功能点和关联的变更也是需要自动化工程师进一步自动化开发和维护的，不过比起整个系统自动化测试的组建，这部分内容将不会消耗很多人力资源。
② 还有一种情况是项目阶段某个（些）系统没有进行自动化功能测试或者没有进行完全的自动化测试。这种情况下的自动化开发需要了解如下几点：
<a> 固定时间内，版本发布的周期和测试环境的修复移交次数将直接作用于投入产出比例。版本发布越频繁冒烟、回归测试的次数自然也就越多，自动化测试带来的直接价值越大；测试环境的修复移交次数越多，冒烟次数越多，用于每次移交版本的质量评估操作越简单。例如，版本部署窗口在17点，部署1小时内完成，18点半开始大规模的自动化运行，次日早上即可得出一份较完整的测试报告。
<b> 反之，相同周期内版本发布的次数越少……那么从上一段的论述是不是可以得出这么一个结论呢：由于使用次数少自动化变得没有价值或者价值不大？事实上并不是这样的，看自动化的价值不仅仅是看投入和产出在开发时间和运行次数上的比例！在项目周期内这一点非常重要是因为它牵动着项目的各个方面，但是在项目之外除了单纯的考虑自动化开发和应用时间比例之外还要考虑管理成本和质量目标，后者往往被大家所忽略，这一点后文会继续分析。
如果已经有了成熟的自动化测试体系框架，建议自动化工程师不要过多的参与运营测试阶段内的自动化开发。首先，一般测试人员对系统逻辑更加熟悉，对测试过程中使用自动化的需求更迫切。其次，让每个测试负责人都有机会学习一下自动化开发是一件好事，尤其是在有锻炼机会的情况下测试技术和测试理念的提升会很快。第三，无休止的开发和维护会把自动化测试工程师陷在某些系统中，虽然实践的机会比较多，但是或许有很多更重要、难度更大的自动化开发在等着他们，把他们的精力分散在长期的多系统的补丁测试开发和维护不利于人力的随时调度。第四，自动化测试工程师本身的职责应该偏向于测试框架的修补升级、自动化测试管理协助、新技术和疑难技术的研究和解答、自动化测试工具的开发，而不是单纯的做自动化测试的开发。
版权声明：本文出自 lyscser 的51Testing软件测试博客：http://www.51testing.com/?68857
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
