自动化测试的成本高效果差，那么自动化测试的意义在哪呢？

Posted 2023-04-05 测试界清流

有人问：自动化测试的成本高效果差，那么自动化测试的意义在哪呢？
 

我觉得这个问题带有很强的误导性，是典型的逻辑陷阱之一。“自动化测试的成本高效果差”是真的吗？当然不是。而且我始终相信，回答问题的最好方式是把问题本身弄清楚。也就是问关于问题的问题。楼主也学可以进一步 说明下面几个问题，有助于自己理解自己的问题，更有助于问题得到准确的回答：

1. 请定义“自动化测试”的范畴。自动化测试简单来讲，包括用例的撰写，代码的实现，环境的搭建，用例的执行，报表的生成，结果的分析，缺陷报告等等。每个项目自动化程度不一样，测试人员对自动化的理解有偏差，实际实行自动化的范畴差别很大
2. 请定义“成本“包括哪些
3. 请定义什么是“高”。高是相对的。比较对象可以是另外的项目或者项目组，也可以是他人的期望
4. 请定义什么是”效果“
5. 请定义什么是”差“。差也是相对的，可以是同手工测试比较，也可以是同老板的期望比较

如果楼主仔细思考并且回答了以上的问题，我有七成的把握楼主要么不想问这个问题，要么想换个问题。

换一种问法

好吧，为了避免灌水嫌疑，我且以最大的善意揣摩楼主的意图。楼主是想问：

如果有的项目的自动化测试，我们发现成本高于预期，效果不符合预期，那么问题可能出在哪里？怎么判断自动化测试是否有效？

-----------------这里是正文开始--------------

关于错误的预期

我一点都不奇怪有人会告诉我说：

我都不知道我或者我的老板对自动化测试有什么预期，没人跟我说过。

或者：

自动化不就是不用手工测试了吗？用例用代码实现都能自己跑，测试人员就可以去干别的了，可以少招几个不产生价值的测试攻城狮了。老板就是这样计划的。

这是两种非常典型的关于自动化测试的预期问题：

1. 根本就不清楚自动化测试的目标，以及为达到目标所计划的投入
2. 对自动化测试（通常是总监以上的老板，开发人员或者手动测试人员）抱有不切实际的幻想型期望，认为自动化测试能够干很多活同时省很多钱

自动化测试的第一目标从来都不是节省测试的人力成本。成功的自动化测试，作为软件测试的一种工具，从业务最终效果来看，应该是能够节省成本和提高产品质量的。但是把节省测试的人力成本作为自动化测试的直接目标是错误的，而且是致命的。

每个人对自动化测试理解都不一样，每个项目组做自动化的方式都不一样。我讲个故事，是我认识之前一个印度自动化项目的真实例子。这个项目95%以上的测试场景都是比较复杂的UI测试（Web +Windows Application）他们的自动化是这样做的：

1. 手工测试人员把测试用例录入到用例管理系统，精确到每一步的描述和每一个数据
2. 自动化测试人员用代码（java，python等）实现自动化用例，保存到SCM
3. 准备好测试环境
4. 打开Eclipse
5. 定位到要执行的用例的源代码
6. Run As Junit （因为统一用JUnit做封装）
7. 两眼直视显示器，目不转睛
8. 如果有步骤执行不成功，比如某个按钮点击不成功，手动帮助点击，继续
9. 一个用例执行完毕，重复步骤5到9

你觉得这个自动化做的怎么样？我当时的感觉是几乎要吐血了，因为这个项目是我要接手的。更加吐血的还在后面，这个部门的QA的VP对自动化测试的效果很不满意（绝对的），他的设想包括：

1. 自动化应该是一种Service（Automation As A Service)，所有的测试人员和开发人员都应该可以自己很方便的去跑自动化
2. 自动化测试的运行结果应该是可以自动分析的，占用很少的时间
3. 自动化测试的成功率应该是要很高的（比如95%以上）
4. 自动化应该是写一次，运行很多次，为什么你们花那么多时间还要去改自动化代码？

这个就是一个典型的不懂自动化的团队+期望脱离现实的老板。

关于什么是自动化

James Bach 曾经在一篇博文提到，自动化测试这个名字是非常有误导性的。它让一般的人误以为就是测试完全被自动化了，就像一个自动的咖啡机一样，我只需要把杯子放在那里，按一个button就够了。James说更加准确的叫法应该是“工具辅助的测试”。当然他还有另一层意思，就是好的测试用例是没有办法100%被自动化的，测试人员的经验，逻辑判断和探索性的测试方法都不能被有效自动化。我非常同意这个观点。作为这个论断的补充和扩展，自动化应该是审视软件研发活动的每一个环节，去发现那些可以被工具化自动化的重复性活动，然后去实现。广义的自动化应该包括但不限于以下环节：

• 测试环境的搭建和管理
• 测试环境的检查，监控和报警
• 测试代码的编译和测试构建
• 测试代码的静态检查和报警
• 测试用例的分发和执行
• 测试结果的保存与管理
• 测试报告的生成
• 测试优先级的建议

自动化的成本与收益（ROI）

一个过于简化的公式可以这样写：

自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本

或者如果假设迭代次数和维护次数近视相等，这个在某些情况下可以成立，比如一个比较新的产品：

自动化的收益 = 迭代次数 * (全手动执行成本 - 维护成本) - 首次自动化成本

解读：

• 自动化的收益与迭代次数成正比
• 自动化收益可能为负数：即当自动化成本和维护成本比手动执行成本还高时
• 很多时候自动化成本并不比手动成本高，但是维护成本很高

为什么强调过于简化，因为这里的自动化收益仅仅考虑时间和资源成本的节省。好的自动化带来的迭代周期的缩短，是可以缩短项目周期，在某些时候能变不能做为能做，进而带来的机会收益是巨大的，也是很难量化的。这个就要求决策者对软件工程和自动化有比较正确的直觉和理解。片面追求自动化的资源节省，或者要求精确量化自动化的收益，本人觉得都不可取。

推论1：什么项目适合自动化

从ROI的简化公式可以看出，下面几中情况比较适合自动化：

1. 回归测试为主的Support Engineering项目，即需要长期做支持维护的产品。或者有过去版本需要长期做支持维护的产品。这种产品（比如企业软件，操作系统等）一个版本在发布之后往往需要支持好多年，做bug fix和patch。这个时候每次小版本的开发都会增加迭代次数，并且每次产品变动都非常有限，维护成本相对偏低，自动化收益就非常好。这也是很多企业级软件或者硬件产品有专门自动化团队的原因。因为产品的支持维护开发的回归测试基本靠自动化
2. 接口比较稳定的产品，同上
3. 手动测试特别费时费力，甚至无法达到测试目的的项目。比如压力测试，大数据或者大量重复数据测试，必须有自动化工具的支持

推论2：自动化的介入时间点

同样从ROI的简化公式推断出，一个项目的初期可能不太适合自动化。因为项目初期用户界面和接口没有稳定，自动化代码会被动的被要求频繁改变，维护成本非常高。自动化收益不好。而反而手动测试能够快速发现问题，反馈给开发人员。而到了项目后期和维护期，自动化再介入为回归测试做准备，可以最大化自动化收益。

推论3：自动化的程度和自动化率

这里自动化的程度是指整个软件研发活动中引入自动化的程度。推论2中说，有些项目早期可能不太适合高度自动化，但是项目早期仍然可以选定某些环节进行自动化。比如稳定的公用接口，软件的编译和部署，环境的搭建等从一开始就比较稳定的部分。

自动化率同样也要看产品和项目的特性，对于产品的UI部分如果会频繁改动，可以做比较低的自动化。对于接口比较稳定的服务组件可以提高自动化率。

你有什么样的团队，工具和基础设施

其实这个因素是做所有事情都必须考虑的。自动化测试本身就是软件开发。好的自动化测试框架，架构设计很重要。这些会决定自动化的开发成本和维护成本。这些都要求很强的开发能力。如果你的团队只有很有限的开发能力，那么怎么去做自动化，是做最原始的录制回放，还是数据驱动。复杂自动化也需要良好的基础设施支持。比如你有很好的DevOps的虚机管理系统，就不用自己去开发，省下的资源和人力也是很可观的。

工具是另外一块，如果公司有实力支持商业测试软件和管理软件，就可以降低编程要求（当然这会带来一些其他问题）。如果没有办法用商业工具，只能考虑开源和自己开发，这个对自动化测试开发的能力要求就高。总之必须选择和团队，技能储备，基础设施与工具匹配的自动化策略。

管理层的理解程度和支持

这个就不再展开。我见过很糟糕的情况，一个带好几百人兼顾产品技术的VP，越3到4级直接给测试团队提技术需求和建议。你说是做还是不做，怎么做？还有一个团队，自动化测试人员从来没有写过Java或者其他OO语言的程序，被要求从头设计自动化框架，那就是一场灾难。还有一个团队，管理层几次要求更换自动化工具，相当于整体重写自动化脚本。
 

总结

以上应该是一个很粗浅的回答。自动化测试是一个很专门化的领域，自动化测试又是对工程师的技术广度深度要求很高的工作。对于团队管理和决策者来讲，请不要简单化和孤立看待自动测试。最重要的是确保听取真正理解产品，团队和自动化测试的技术人员的判断

自动化比手工测试成本高？使用Selenium评估测试自动化的ROI指标

跨浏览器测试是一种测试，需要大量的精力和时间。通过不同的浏览器，操作系统，设备，屏幕分辨率测试Web应用程序，以评估针对各种受众的Web内容呈现的过程是一项活动。

特别是如果手动处理，使用Selenium进行的自动跨浏览器测试可以帮助您节省例行测试活动的时间，并帮助您缩短回归测试的时间。但是，人们很少喜欢变化。如果手动测试在您的组织中很流行，那么当您要求他们实施测试自动化时，管理层显然会提出问题。

自动化比手工测试成本高？使用Selenium评估测试自动化的ROI指标
测试自动化虽然非常有益，但通常可能会证明是昂贵的，但值得吗？在说服高层管理人员的同时，您可能会发现这是一个难题。在开发Web应用程序时，将需要您提供使用Selenium进行测试自动化的有效ROI，并通过使用Selenium进行自动化跨浏览器测试来简化Web应用程序的自动化，从而突出显示自动化测试的好处，因为它可以更快地完成工作，而无需人工。

在本文中，我们将讨论使用Selenium评估测试自动化的ROI的不同指标，以及涵盖基础知识和高级技术的ROI计算技术。

使用Selenium评估测试自动化的ROI的指标

您和您的团队成员可以考虑某些度量标准和度量标准，这些度量标准和度量标准可以帮助您在计划从Web应用程序的头开始进行自动化测试时，分析使用Selenium进行测试自动化时的ROI。这些指标可能因组织而异。为什么？好吧，这是一个优先事项，有不同的度量标准，例如检测到的缺陷数量，时间增益或测试覆盖范围会直接影响项目的风险，成本，质量和交付进度。一些组织可能会优先考虑发现的缺陷数量，因为他们可能认为数量会带来质量。有些人可能会反之亦然，因为对于他们而言，质量意味着一切。你拿什么 您认为在测试用例的质量与数量之争中，更重要的是什么。在下面的评论部分中让我知道您的想法。

话虽如此，在您与高级管理层进行讨论之前，确定关键指标以使用Selenium进行测试自动化计算ROI至关重要。

Selenium测试自动化的范围

我们知道我们无法执行100％的测试自动化。那么，您可以执行多少自动化的跨浏览器测试，这是一个需要大量思考过程的问题？如果您希望为您的Web应用程序执行自动跨浏览器测试，则必须考虑并确定优先级，以及您应该在测试用例中涵盖哪些操作系统？因为您无法涵盖所有 情况。可能的方案总数可能导致数百甚至数千个测试用例。如果您的自动化测试脚本是如此之长，那么每天可能需要花费相当多的时间评估您的Web应用程序或网站。

简而言之，您需要在此处比较自动化测试用例的总数与可以实现自动化的测试用例的总数。

如果您希望减少使用复杂测试套件的时间，则还可以使用Selenium Grid进行并行测试。这样，您可以同时执行多个测试脚本。但是，为此，您可能还需要考虑多少个并发或并行会话足以满足您的要求？您可以通过我们的并发计算器进行操作。

此指标的改进表明，团队可以更快地发现缺陷并快速修复它们，从而在Selenium上实现自动化测试的风险低，投资回报率高。

将节省多少时间？

使用敏捷，每周或每两周交付一次，并且需求经常变化。在那种情况下，回归测试的重要性增加了。实施自动回归测试用例将减少测试所需的时间，从而获得更多的时间来投资开发或进行另一个Sprint。节省时间是几乎每个需要快速扩展其Web应用程序的组织（尤其是初创企业）的优先考虑。在评估测试自动化的投资回报率时，时间是您关注的问题之一吗？

的资源带宽

我们知道，使用Selenium进行测试自动化将帮助您快速推销Web应用程序。但是，没有哪个组织愿意在员工大部分时间都闲着等待脚本完成的情况下使用它。要使用Selenium来计算测试自动化的ROI，需要对您所拥有的每个自动化和手动测试仪进行彻底的工作分析。

资源和工具的投资预算

测试自动化可以节省时间和精力。但是，这涉及到价格的权衡。您需要考虑可以为多少工具，每个组织（尤其是初创公司）轻松分配多少预算，这些工具需要快速扩展其Web应用程序。在评估测试自动化的投资回报率时，时间是您关注的问题之一吗？

自动化比手工测试成本高？使用Selenium评估测试自动化的ROI指标

总缺陷数

每个回归周期完成后的总缺陷数表明了产品质量以及特定项目的有效自动化测试量。

找出自动化测试的真实投资回报率

根据在项目生命周期内需要执行的回归周期数，真实的ROI可以转移到正值区域。ROI通常通过以下公式计算：

ROI =（手动测试成本–自动测试成本）/自动测试成本

但是随着敏捷和DevOps进入市场，经典方法不再有效。另外，该度量标准也不现实，因为手动测试的次数永远不会与自动测试的次数相同。用Selenium自动化基于数量计算测试自动化ROI的真实价值并不是很多人的选择。但这也不是完全被忽视的。

缺陷质量

我认为，这是使用Selenium计算测试自动化的ROI时非常重要的指标。我相信，使用Selenium进行测试自动化的全部目的是不消除项目中对手动测试人员的需求。自动化测试的重点是减少测试人员狭窄的工作量，从而使他们可以提出更多的开箱即用的测试用例。提高测试用例的质量肯定会帮助您更好地构建Web应用程序。

在测试自动化上计算投资回报率时的一般错误

尽管计算ROI涉及使用一些简单公式进行基本计算，但是如果您错过了一些重要参数，则可能会发生错误。让我们讨论人们在计算ROI时常犯的一些错误。

真的不是完全忽略手动测试吗？

最大的错误之一就是仅保留自动化测试工作作为主要测量参数。手动测试将始终很重要。对于跨浏览器测试，可以自动执行某些方案，但是在某些领域中，您需要通过执行手动跨浏览器测试与Web应用进行实时交互。因为视觉缺陷比运行自动化脚本更容易手动检测。始终手动检查网站是否在所有浏览器中都看起来不错或某个导航菜单在特定浏览器中是否正常运行等事实。如果您使这些测试自动化，它们将无法在使用Selenium进行测试自动化方面提供很高的投资回报率。即使您不计算手动工作量，您仍然必须花费时间和金钱。

总是想着更大的图景

在使用Selenium测量测试自动化的ROI时，您必须考虑更长的时间。检查某种测试方法在短时间内如何使组织受益的做法并不理想。从长远来看，您必须检查它如何影响组织和团队。而不是几个月，而是要计算3到5年内的影响。例如，您应该选择左移测试吗？左移测试是一种方法，可让您集中精力从需求收集阶段尽快进行测试。背后的想法是考虑错误并尽快发现它们，因为据信与最初阶段发现的错误相比，在SDLC后期发现的错误会贵得多。

您是否同步了组织的功能？

您必须将组织的功能与测试自动化工具堆栈同步。为了成功实施自动化测试策略，既需要产品知识，又需要自动化知识。您的团队应该对如何使用计划的自动化工具以及应用程序的工作有清晰的了解。

测试维护是要考虑的重要因素

测试用例的维护是人们在使用Selenium测量自动化测试的投资回报率时往往会错过的另一个因素。当您使用Selenium进行自动跨浏览器测试时，在成功实施测试策略之后，您将定期需要更新和维护测试用例。随着您添加新页面，增强或更新Web应用程序的功能，回归套件和测试用例将开始增长。确保这些测试用例在较长时间内的可用性将需要定期维护。

缺少正确的文档

这是一个非常常见的错误，不仅从自动化测试人员的角度来看，而且从管理角度来看。应将文档设置为每个组织的标准。当自动化测试人员编写测试脚本时，他们应该准备一份文档，解释该脚本的用途及其工作原理。应该提供一个公共知识库来收集有关组织活动的每个自动化脚本的文档。这将为参与该过程的每个萌芽资源奠定基础。这也将有助于消除因缺少任何高级测试自动化工程师而导致的Web应用程序可能遭受的附带损害，或者自动化测试人员打算从您的公司切换到另一家公司。

使用Selenium实现自动化测试时获得最大投资回报的操作项目

到目前为止，我们已经意识到了常见的错误，即使用Selenium在测试自动化上计算ROI的指标。接下来是什么？执行部分。使用Selenium在测试自动化上获得最大投资回报的最佳方法是什么？好了，这里有一些值得注意的可行见解，可以帮助您从测试自动化中获得最大的收益。

为新测试用例实现自动化

这是要考虑的非常重要的因素，尤其是当您从手动转换为自动化时。假设您要介绍Selenium WebDriver，以在组织中进行自动跨浏览器测试。

计算需要自动化的测试用例的数量

在此步骤中，检查哪些应该是自动化的，哪些应该保持手动。

不要将每个测试用例都转换为自动化。有些事情只能手动测试。

计算执行您的测试用例的测试人员的小时成本。

如果某些测试人员没有自动化经验，那么也要计算培训成本。

优先考虑自动化新测试用例的过程

我们都知道，回归测试始终被放在首位，尤其是涉及跨不同浏览器的Web应用程序的视觉回归测试以检查其跨浏览器兼容性时。

回归测试主要涉及对旧测试用例的重复执行，以确保某些新添加的功能或增强功能不会引入任何新的或旧的缺陷。随着时间的流逝，当您的Web应用程序在体系结构和功能方面不断增长时，保留回归测试手册的过程将证明是昂贵的。如果您想降低成本，则实施自动视觉回归测试很有意义。

在计算ROI时，假设每个新的测试用例都将很快成为回归测试的一部分。将它们保留为回归测试策略的一部分。

根据复杂性对测试用例进行排序，并在其中自动进行检查。

如前所述，请考虑维护旧测试用例的成本。

跨浏览器和OS的不同测试配置的测试覆盖率接近100％

自动化测试的主要目标是提高应用程序的质量。在计算投资回报率时，您还应该考虑以下事实：浏览网站的方式每天都在增加。市场上有成百上千的浏览器和设备，人们可以在其中查看您的Web应用程序，并且该数目正在定期增长。定义浏览器兼容性测试矩阵。

扩大覆盖率的最佳做法

通过执行烟雾测试，单元测试，回归测试，并注意缺陷泄漏，可以提高环境覆盖率。

单元测试–单元测试在运行Web应用程序的测试阶段时涵盖了最多的数量。当您投资并行测试机制以节省时间时，这总是有意义的。

冒烟测试–将修补程序推送到应用程序中时，并行运行冒烟测试是覆盖测试用例的最佳方法。自动化烟雾测试是每天评估Web应用程序的好方法。

回归测试–在当今的敏捷时代，快速部署需要越来越多的回归测试来测试版本控制。运行并行回归测试可确保每个最新版本都像以前的版本一样完美运行，从而帮助您在短得多的时间内扩展测试范围。

请记住缺陷泄漏–这是在生产周期中发生的错误数量，因为在先前的测试阶段未检测到它们。发生这些情况的原因可能是功能测试覆盖范围较小或测试环境不佳。

尝试使用左移测试方法。这涉及测试人员在应用程序开发之前对其进行验证。一旦完成特定模块的开发，开发人员还可以通过运行单元测试用例来参与其中。核心思想是尽早开始发现错误，最终将降低成本。

找出可重用和冗余测试用例的数量

重复的测试用例是可能导致测试预算增加的重要因素。重新创建您先前用于不同模块的相同测试用例没有任何意义。重用测试用例会导致测试速度提高和测试周期缩短。

计算此费用涉及检查

重复测试用例数

具有重复组件的测试用例

检测和开发所有这些冗余测试用例所需的时间。

计算使用测试用例管理工具的成本

减少冗余的最佳做法

使用测试用例管理工具查找重复的脚本。您可以使用这些工具来存储带有自定义字段的测试，然后可以根据您的要求对其进行个性化设置。使用测试用例管理工具将帮助您快速搜索冗余。

您还可以开发模块化测试脚本，以后可以重用。找出经常执行的测试。例如，登录我们的退出功能。为了检查这两个是否完美，您必须测试多种变体。创建一个模块化的测试用例，可用于每次登录和注销变体。

使用云端的Selenium网格执行无忧的自动跨浏览器测试

执行方法围绕着使用Selenium进行测试自动化计算ROI的必要领域。众所周知，Selenium是一个开放源代码测试自动化框架，旨在促进Web应用程序测试。现在，您可以自行在本地使用Selenium进行自动化测试，也可以使用提供Selenium Grid的基于云的工具之一进行自动化测试。

当您通过自己的基础结构使用Selenium执行自动化测试时，在扩展自动化测试套件时，您必须牢记预算。您将如何引入新设备？新的浏览器版本？您现有的计算机还需要大量硬件升级，才能支持Selenium Grid的并行执行。但是，如果要通过云上的Selenium Grid执行测试自动化，则可以随项目需求轻松扩展。

Selenium本身不提供测试报告功能。您可以根据所使用的语言，使用测试自动化框架来提取测试报告。如果您使用的是LambdaTest基于云的Selenium Grid，则可以通过我们的Open Selenium API提取这些报告。

两种方法之间的另一个主要区别在于并行测试。使用在本地计算机上定义的Selenium Grid，您将只能在该本地计算机上安装的浏览器上运行测试用例。但是，如果您使用的是基于云的Selenium Grid（例如LambdaTest），则可以跨多种实际浏览器和浏览器版本进行测试。

ROI计算技术

现在，我们已经涵盖了基础知识，让我们了解用于计算ROI的计算方法。

效率投资回报率

由于自动化测试用例可以全天候运行，因此ROI的计算以天为单位。另一方面，对于手动测试，仅计算测试人员的工作时间，平均为8个小时。构成计算投资回报率基础的公式是

（a）自动化测试脚本开发时间=（每个测试的每小时自动化时间自动化测试案例数量）/ 8

（b）自动化测试脚本执行时间=（每个测试自动化测试执行时间自动化测试案例数量ROI周期）/ 18

（c）自动化测试分析时间=（试验分析时间 ROI的周期）/ 8

（d）自动化测试维护时间=（维修时间ROI的周期）/ 8

（e）手动执行时间=（手动测试执行时间的手动数测试用例*投资回报期）/ 8

注意： ROI的周期是要计算ROI的周数，如果需要手动操作，则除以8。只要完成自动化，就可以除以18。

在效率计算中，主要重点是对组织进行多少有效的自动化测试。金钱因素被认为是次要因素，并非必须包括测试人员的小时计费费率。

降低风险的投资回报率

这涉及独立计算自动化的收益。我们将再次以使用WebDriver进行跨浏览器测试为例，以了解其工作原理。在手动测试期间，整个测试团队过去通常会花费大量时间在多个浏览器上重复运行相同的测试用例。引入自动化之后，他们有很多额外的时间来执行生产性工作，例如设计测试用例，分析应用程序等。总之，降低风险的ROI解决了以前未解决的问题。

随着自动化的实施，测试覆盖率增加。完全取决于手动测试将导致不必要的错误，这些错误可能会在交付后出现。因此导致产品质量降低以及测试效率降低。这种可能的损失被认为是一种风险。投资成本没有变化。仅计算组织可能在没有实施自动化的情况下可能面临的金钱损失。

最后:【可能给予你帮助】

这些资料，对于考虑【软件测试】技能进阶的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你

关注我的微信公众号【程序媛木子】免费获取

我的学习交流群：644956177群里有技术大牛一起交流分享~