摘要：本文主要围绕自动化测试投资回报率Return On Investment（ROI）进行分析讨论，设计了一套计算模型配以工具进行介绍说明，分析构成自动化测试成本的多种因素，特别对比手工测试和其对应的自动化测试，探讨在不同情况下这些因素对项目ROI、成本、工期的影响和预测，以期帮助项目/部门/产品经理正确合理的规划自动化测试项目。
1、前言
1.1、背景
采用手工测试，还是自动化测试，在产品生命周期什么阶段开始自动化测试，各个阶段投入多少人力，如何构成最佳的人员（能力）配置，在实际的项目特别是大型软件产品项目实施过程中，由于涉及到的技术面较多，看起来比较简单的类似于1+1的问答题，却往往是困扰项目管理者的一道题目。拍脑袋的决策很多时候都被证明浪费了大量的人力物力，或者在产品质量出现问题时才考虑引入自动化测试加大测试频率，错过了抓虫（bug）的黄金时间点，最终影响软件产品的正常上线。自动化测试ROI的计算可以很好的在决策阶段起到重要的参考价值。
真实案例一：
某老牌W软件公司，上千人的研发团队，研发中心横跨三大洲，惯习了很多跨国企业决策慢的问题。新一代核心产品本意是为弥补其在SaaS上的缺失，研发过程中虽然采用敏捷开发模式，每天都有版本（build）集成发布，却一直主要依靠相对人数比例不高的手工测试团队进行软件测试/质量控制，无法最大程度尽早发现产品缺陷，工作量又让测试团队苦不堪言，最终产品缺陷technical debt越积越多，导致比预期的产品上线时间推迟两年以上。高层分析原因后，果断加大对自动化测试的人力物力投入，经过两年持续不断披星戴月的自动化进程推广和实施，产品质量总算步入正轨，在大刀阔斧调整后的新日期发布。虽未错过行业红利，但给了新入的后来者时间和空间。过晚引入自动化测试给未来的竞争带来诸多不确定的因素，由垂直行业的领头羊变为展开three kingdoms story。
· 选择适当的产品阶段开展自动化测试！
真实案例二：
某企业级D软件项目，在集成自动化冒烟测试（smoke test）中尝到了甜头，继续大力投入展开回归测试（regression test）的自动化，但由于产品业务复杂、组件众多、依赖外部服务，产品在当前集成阶段极不稳定，在数量呈几何级增加的regression test自动化脚本开发出来后，很多一周就遇到需求变更（feature change）或严重性能问题，自动化团队疲于修改脚本。加上测试团队与开发团队关于产品模块需求变更的信息不对称，长达半年的时间由测试脚本发现产品缺陷的目的变为由产品变更来完善测试脚本，可谓本末倒置。
· 可以尽早开展smoke test automation，但在产品feature ready数量较少时大量开始自动化测试危险，存在不必要成本花费！
真实案例三：
某大型跨国软件K公司，当决定上马自动化测试项目时，高层希望尽可能的将现有所有手工全部转为自动化测试，强调自动化测试率（Automation Ratio），考虑到某些内部管理因素一刀切先以数字作为目标驱动。某些项目/产品经理从部门/个人业绩出发，对于不适合的测试类型和业务仍进行自动化，例如某些业务逻辑非常复杂、涉及场景交互很多的scenario testing。且先不论花费不菲的人力财力，匆匆上马的决策导致这些脚本自从投入使用后通过率极低，由于涉及模块较多，任何一个模块的一点小问题都可能导致脚本不能通过。分析测试报告的错误running failure又带来看似无穷无尽的时间投入。这些开发人员费尽心血才孕育出来的测试脚本最后的命运自然是在数字运动后被束之高阁。
· 选择正确的业务和测试类型进行自动化！
1.2、计算Automation ROI的必要性
什么人需要/可以关注Automation ROI？
对于预算经理，通过 (Automation) ROI可对应不同相关类别的不同成本，得出成本预期，并划分到不同的月份进行预算预测；
对于产品/项目经理，通过ROI的计算和成本曲线在不同时期合理配置不同级别/要求的人员；
对于测试经理/组长，通过项目的实际情况计算ROI，反向校验项目安排（自动化测试运行周期等）的合理性，指出问题提出意见并进行调整；
对于有思想的自动化测试开发人员，我们做的是什么测试类型的自动化工作？在什么阶段进行？自动化测试的Scope是什么？我还可以做什么？除了代码外，再多问几个为什么，是职业生涯进阶的必经之路。
1.3、影响自动化测试ROI计算的因素
1.3.1 自动化测试ROI基本公式介绍
自动化测试ROI的基本公式为
ROIAutomation(in time t) = (Savings from Automation) / (Costs of Automation)
= (Savings from Automation) / (Costs of Automation)
= (Costs of manual - Costs of Automation) / Costs of Automation *100%
若不考量测试的覆盖率，大部分项目实施自动化测试主要目的是为了追求自动化测试的成本优势，但在某些条件下ROI值可能为负数。
在基本公式中未列出的影响自动化测试ROI的诸多因素，如下。
1.3.2 自动化测试主要成本项
· 自动化环境搭建（一次性成本）
包括CI工具（如Jenkins, TeamCity等）配置、测试管理工具（如HP ALM）配置关联、代码仓库（code repository）部署等。
· 自动化测试相关软硬件（一次性成本）
企业级的商用自动化测试工具（如QTP），大多license价格不菲，同时需要考虑与其相关的技术支持费用。因此即便是很多财大气粗的大型软件公司，也越来越多采用开源的自动化工具（如Selenium）并搭建自己的自动化测试框架平台。
· 自动化测试框架的开发/采购（一次性成本）
除个别小型项目外，目前商用自动化测试考虑模块重用、测试管理及其效率、统计报告和系统环境集成，大多会采用或搭建一套自动化测试框架（开源或商用）。本文不详述自动化测试框架的类别，但根据其框架feature复杂程度都可以将其成本换算为对应的人月成本。此成本可看作为一次性成本。
以web自动化测试框架为例，项目需求要求支持UI和API测试，移动端（mobile）测试，考虑断言（Assertion）、Selenium-PageFactory&WebDriver&Grid、Operations、TestNG-Wrapper、测试数据模型驱动、测试数据回滚、HTML报告及报告分析、自定义Selenium Actions、自定义元素Grid&日历、自定义utils-DateParser和DateGenerator、增强日志功能、集成持续集成（CI）工具、录屏工具和测试管理工具（例如ALM/TestRail/TestLink）、网页元素设计/控制、数据库支持等。
根据支持的功能数量和复杂度我们将其分别定义为基础框架、标准框架和高级框架，并赋予不同的项目人月成本/开发成本。
例如，对于Assertion模块，基于TestNG的assert进行加强，当发生断言failure时脚本仍可以继续执行。
在基础框架中封装TestNG的assert，在标准框架中支持软断言（soft assertion），在高级框架中支持soft and hard assertion。
· 自动化测试框架的维护（持续性成本）
框架开发完成后并非一劳永逸，跟变更导致的测试脚本的维护类似，框架也会因为设计或编码导致的defect、项目需求变更/情况变化、底层驱动变化等造成维护的工作量。此成本为持续性不间断发生成本，可分摊到每个迭代（iteration）中。
· 自动化测试脚本开发（主要成本 + 一次性成本）
为方便统计计算，这里我们将自动化测试脚本开发和维护的成本分拆为两个类目。
自动化测试脚本开发是自动化测试中主要成本，ROI计算中可在项目第一个迭代中即计入所有成本，或者（实际项目情况）根据预期项目周期分摊到每个迭代中。后续计算中暂采用第一种计算方法；若采用第二种计算方法，一般不影响项目整体的ROI，手工测试成本将更早突破自动化测试成本（若平均每个迭代自动化测试成本<手工测试成本）。
· 自动化测试脚本维护（持续性成本）
包括自动化测试执行、错误分析、复测（含手工和自动化复测校验）、缺陷提交、测试报告、脚本本身的bug或重构引起的脚本优化、框架/产品变更（含UI可见变更和不可见变更）引入的脚本维护等。
· 自动化测试执行（可忽略成本）
对于大多数的企业级自动化测试执行而言，由于在框架和环境搭建阶段已考虑并行运行（例如采用Selenium Grid），数据初始化也在脚本开发阶段实现，在实际的测试执行阶段，所需要的大多只是软硬件（例如虚拟机node）投入。本文主要集中对比手工测试和自动化测试的投入产出，对两者均会发生的类似软硬件投入暂不计入。投入更多的node，会进一步加快/节省运行时间。常规的自动化测试运行都是晚上自动运行，无需人工干预，第二天早上得到测试结果进行分析，因此可以认为基本是无需运行时间，无缝衔接，属于暂可忽略成本。
需要强调的是，此项虽在计算ROI时可记做隐形成本，却是自动化测试中非常重要的环节。
1.3.3 手工测试主要成本项
· 测试执行（主要成本）
包括测试环境准备/搭建，测试数据准备。手工测试的执行主要依赖人力，是必需人力成本。
2、模型介绍 Automation ROI Model Introduction
2.1、ROI计算及计算项分解
Automation test ROI = (Costs of manual - Costs of Automation) / Costs of Automation *100%
2.1.1 手工测试成本
Costs of manual = 手工测试执行时间
2.1.2 自动化测试成本
Costs of Automation = 框架开发 + 框架维护 + 环境部署 + 脚本开发 + 脚本维护 + 测试运行
2.1.3 影响成本/ROI的关键因素
前面小节所述的成本项指的是测试的工作项（work items）的成本，每一个工作项的成本都会受到各种因素的影响。
测试用例的数量
根据用例用途/复杂程度分smoke test, regression test和scenario test。数量越多，手工执行和自动化脚本开发的时间所需越长。
手工/自动化测试的运行周期
运行一个full cycle的频率，即测试完一轮/所有测试用例的时间频率。
大部分软件公司的build都是daily build，所以通常自动化测试每天一轮。当然你十天运行一次也行，不过每天运行也不花费额外的成本，一些简单的配置而已，何乐而不为呢？
对于手工测试，通常smoke test每天会做一轮，regression test有的项目/公司会每天一个full cycle，有的则会一个sprint（两周/三周等）一个full cycle。
自动化框架功能复杂程度
自动化脚本开发速度
自动化脚本维护量
本文采用每1000脚本所需要维护的人力（HC）/人天（man-day）数来进行衡量。
2.1.4 影响成本/ROI的其他因素
· 产品稳定性
产品稳定性会影响自动化脚本的运行效率。
· 产品阶段
产品的不同阶段决定测试框架/脚本的修改率（需求变更/重构），即框架/脚本的维护成本。
2.1.5 前提条件Prerequisites & Assumptions
下面汇总罗列一些关于自动化测试的常识/共识和约定，作为模型计算中的前提。在后续章节相关内容中会涉及，方便读者回溯查看。
· Environment deployment & Automation framework/script development are one-time efforts;
· Automation framework/script maintenance is a continuous effort;
· For easier calculation, count all costs of Automation framework/script development into 1st iteration;
· 为方便绘制ROI时间曲线，将每个迭代累计的手工测试和自动化测试成本进行比较。由于通常自动化测试频率FA≤手工测试频率FM，所以将手工测试的迭代作为基准迭代的时间长度进行计算。同时，纳入同一个时间长度的迭代后，可能存在每个迭代运行一个/轮手工测试full cycle的同时运行了多轮自动化测试；
· 同上，通常smoke test的运行频率FMS ≤FMR (regression test)，那么可能存在每个迭代运行一个手工regression test的full cycle的同时也运行了多轮smoke test；
· 自动化测试相关软硬件成本暂不纳入计算；
· 脚本开发工具软件大多采用同开发的IDE，所以IDE项成本可暂不考虑；
· 框架维护的成本根据项目对框架的需求等不同而不同，可根据经验和项目不同取不同值。在本文计算模型中不做详细分解；
· The time of Automation execution only replies on hardware/client cost and isn't counted into the calculation;
· 常规的手工功能测试的测试环境准备/搭建一般相对较简单，模型中列项但暂不计算；
· 测试运行频率以工作日计算；
· 一年记250工作日。
... ...
查看更多精彩内容，请点击下载：
版权声明：本文出自《51测试天地》第四十九期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
