2024年最新自动化测试的定位及一些思考_自动化成本收益曲线，2024年最新中高级软件测试开发应该要了解

2301_82242351

于 2024-05-08 17:24:41 发布

阅读量883

点赞数 21

分类专栏：程序员文章标签：自动化运维

本文链接：https://blog.csdn.net/2301_82242351/article/details/138579873

版权

程序员专栏收录该内容

192 篇文章 0 订阅

订阅专栏

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

（1）用例的驱动模式，涉及到怎么存放测试数据，怎么描述用例，又如何复用；
（2）考虑到效率的话还要支持并发；
（3）当然测试报告不能光记录成功和失败，还有用例执行耗时、接口调用耗时、场景的通过率等各项数值的统计。

说完单元测试、接口测试的自动化，我们现在来说说UI层自动化测试，这也是一直很火并且也是自动化概念先入为主的一块，毕竟市面上有不少成熟的自动化工具，如QTP、Selenium等。这块自动化一定是会有测试团队参与的，就算自动化框架是由开发来完成，那么具体测试工作也是由Tester全程参与的。UI层自动化测试真的不容易推行，无论有多么完善的自动化框架，在这一块维护的成本也是非常高的，特别是懂开发的人不懂测试，懂测试的人不懂开发，这一矛盾现象所带来的内部消耗就不少，再加上项目需求和UI层都在频繁变动，而且Web UI技术越来越复杂和多元化（UI层自动化需要基于对象识别技术），这些都导致很多公司不愿意投入这一块。即使这样，做为一个有上进心的测试人员，我们也是需要多想想这一块，毕竟这是离我们测试最近的一块“技术沃土”了（之一）。

现在我们来重点来谈下Web UI自动化测试（目前的系统大都通过Web UI来展示），一般成熟一点的自动化工具方案大体是这样：
　　1、开发语言：Python或Java；
　　2、开源测试框架：Selenium WebDriver；
　　3、Web元素定位：Xpath+cssSelector+findElement或findElements方法；

具体实施细节来讲重点是针对Web UI自动化测试的特点，将各层包装，分而治之的思想，各自相互独立，职责定义清楚，下面简要说明下：

1、测试用例业务流操作实现及测试数据分离管理；
　　2、页面元素定位及页面元素的操作分离；
　　3、可视化的日志查询系统；
　　4、跨浏览器支持如：IE,Firefox,Chrome；
　　5、可视化的的测试报告，可以具体查询到日志/截图等；
　　6、实现了通过Excel的数据驱动管理；
　　7、邮件发送管理，可以自定义具体时间及接受者等；

以上是一般Web UI自动化测试的一些实践要求，当然也是相对简易的，复杂的就是实现平台化管理，每天测试工程师，只需要选择具体项目、所测的测试用例集，然后执行，输出测试报告，邮件自动发送到相关开发/测试，框架的开发维护上也能够持续集成。

说完了这三个层面的自动化测试，那么我们再来分析一下，到底应该优先开展哪个层面的自动化测试，到底是哪个投入产出比最高，以下分享一篇网上文章的部分内容，人家已经给了答案：

众所周知，软件测试的边际成本会随着缺陷探测率的提高而提高，这就是软件测试的基本公理之一"测试的不可穷尽性"的经济学体现。这一规律也适用于自动化测试，也就是说随着自动化覆盖率的提升，自动化的成本也呈现指数式上升。按照这个思路进行拓展，可以分析下单元测试，集成测试和UI测试的自动化成本曲线如图2所示。与通常理解的一致，为了达到相同的自动化率(x0)，UI的成本最高、其次是API，Unit则最低。
　　经济学中有另外一个著名的理论叫做边际效益递减。当做一项投资，随着投资量的增加，单位投资增量所带来的单位收益是越来越少的，甚至在某个临界点之后，这个收益有可能是负数。而这个零界点，就是投资收益最大的点。在这个点之前的所有投资，都可以扩大总收益，而在超过之后继续进行投资，就不那么明智了。

图2 自动化成本/收益曲线

按照这个思路，在图2上，针对三种不同类型的自动化测试，可以获得三个零界点。而总收益最大的点在接口测试上，随后是单元测试，UI测试则最低。
　　如果从测试效果上看，接口测试和UI/单元测试相比，有很多优势。对于单元测试来说，通常单元测试是针对代码进行的测试，而接口测试是在测试一个活的，经过部署的系统。另外，单个接口测试与单个单元测试用例相比，也可以覆盖更多的代码。更重要的是，接口测试也可以是面向业务的测试，通过接口进行业务层面的测试。
　　而相比UI自动化用例，接口测试更加的简单直接，执行效率更高。除了部分如企业级应用软件，可能很多业务在前端进行之外，很多情况下，绝大部分通过UI完成的业务操作完全可以通过API端完成。某些情况下，API（接口）的测试条件覆盖率甚至可以多过UI。
　　综合上述的分析，笔者认为在自动化测试的初级阶段，适合奔小康的测试团队的自动化模式应该是中间层的接口最大，两端的UI和Unit测试适度实施。从图形上看，就是一个橄榄型（中间的接口测试效益比最高）。如果再加上一部分的手工测试，那就是一个不倒翁了。（题外话：接口测试可以由开发团队来做，也可交由测试团队去开展）