自动化测试实践：基于AI赋能的动态测试链路设计

最新推荐文章于 2025-11-24 19:11:26 发布

原创最新推荐文章于 2025-11-24 19:11:26 发布 · 866 阅读

18 ·

CC 4.0 BY-SA版权

文章标签：

#职场经验 #深度学习 #测试工具 #自动化测试 #面试 #软件测试 #学习

程序员同时被 3 个专栏收录

1659 篇文章

订阅专栏

软件测试

1641 篇文章

订阅专栏

自动化测试

981 篇文章

订阅专栏

📝 面试求职： 「面试试题小程序」，内容涵盖测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

降本增效的时代，作为测试提升测试效率的重要手段，就是通过自动化提升测试效率。自动化是一个老生常谈的话题，只要你所处测试行业，对自动化都不陌生，我做测试自动化好多年了，UI、接口、单元都做过，今天想聊一聊好的自动化到底应该什么样，好的自动化到底应该怎么做。

优秀自动化评判标准

优秀自动化的第一个评判标准应该是，自动化覆盖率足够高；这个高是针对全部功能测试用例而言，举例来说，如果你测试一个需求编写了20条功能测试用例，针对这20条功能用例完全实现自动化，那么一定是个good job，曾经我的评判标准是针对回归测试做自动化覆盖，保证系统的 80%的核心功能，最近两年推翻了我的认知，因为随着技术的成熟，线上问题往往发生在非核心功能上。如果想要做将自动化做到极致，必须进行全量覆盖。

优秀自动化的第二个评判标准应该是，自动化执行稳定性足够强；将其作为次要评判标准，是个先有鸡后有蛋的哲学问题。但是毫无疑问，自动化覆盖率即使在高，但是如果稳定性差，每次需求测试的时候都用不上，那么自动化用例就显得毫无价值。久而久之也会大大削弱使用者的信心，从此自动化就会沦为花瓶，中看不中用。

优秀自动化的第三个评判标准应该是，自动化框架易用性好；框架易用性好应该体现在两个方面。一方面体现在新增、维护自动化脚本易上手，自动化用例编写简单易用不耗时间。另一方面体现在自动化对系统真的有帮助，能发现BUG，使用者发自内心的爱用自动化、信任自动化，帮助测试人员将测试工作变得甜甜的。

介绍完优秀自动化的评判标准，下面分享一下我的经验，看看具体实现优秀自动化的手段。

优秀自动化的实现措施

要想实现优秀的自动化，可以参考以下措施：

要有独立的自动化运行环境：工欲行其事，必先利其器。要想自动化执行稳健，建议搭建专属于自动化的稳定环境，这个环境从数据库缓存等中间件，到前、后端应用，应该完全独立于需求测试环境，这样做的好处有两个：

（1）避免环境交叉，误报问题；试想一下，哪天自动化用例执行失败，你通过业务排查、脚本排查都没有发现问题，最后浪费了大量的人力和时间，发现是因为他人修改了环境配置导致的失败，多么令人沮丧，而这种问题在日常工作中非常常见，为了规避类似情况，最好的办法就是将自动化环境完全隔离。

（2）避免不知轻重，造成线上问题：作为测试我想您可能遇到过，因为测试的操作而影响了线上。根本原因就在于测试对环境缺乏敬畏，而你一步一步的自己搭建出自动化测试环境，你就能从源头上杜绝此问题。

自动化用例要有容错自治愈能力：这体现在一条自动化用例偶然因为接口超时等原因执行失败了，会自动进行重试，重试的过程中会不断优化自己下一次的执行策略。

具体措施可以从两方面着手考虑：

一方面核心用例一定要预设重试次数，比如可以设置用例失败后重试5次，5次都失败才认为本次自动化用例执行失败。另一方面：每次重试的时间和请求可以进行调整，例如可以考虑将请求的参数做替换，每一次执行时间间隔通过hash的方式加一个时间梯次，简单来说：第一次超时2秒执行失败，第二次超时5秒认为失败，第三次超时8秒在认为失败，种种手段，给自动化用例增加自治愈能力。

实例展示

通过Testng的重试增强稳定性：实现IRetryAnalyzer接口的retry方法示例：

第一步：我们先基于源码开发一个失败重试三次的注

public class MyRetry implements IRetryAnalyzer {
　　    private int retryCount = 0;
　　    private static final int maxRetryCount = 2;
　　    @Override
　　    public boolean retry(ITestResult iTestResult) {
　　        if (retryCount < maxRetryCount) {
　　            retryCount++;
　　            return true;
　　        }
　　        return false;
　　    }
　　}

第二步：在用例里使用

@SpringBootTest
　　@Slf4j
　　@Listeners(EmailableReporter2.class)
　　public class TestclassSample extends AbstractTestNGSpringContextTests {
　　    @Test(retryAnalyzer = MyRetry.class)
　　    public void test1() {
　　        log.info("打印结果test1");
　　        Assert.fail();
　　    }
　　   @Test(retryAnalyzer = MyRetry.class)
　　    public void test2() {
　　        log.info("打印结果test2");
　　        Assert.assertEquals(2, 3);
　　    }
　　}

自动化组内要高内聚，组外低耦合

我们一般会将同一个场景下的自动化用例作为一个自动化用例组，组内的不同自动化用例之间可以进行参数的传递，可以进行相互依赖；而不同自动化用例组之间，一定从前置、数据等做充分的隔离，万不可将鸡蛋放在一个篮子里，即所有的自动化用例都只依赖一个前置类或者方法，导致一个用例失败即全部失败。

自动化用例要易维护：

自动化用例需要保鲜，需求迭代后要及时的维护自动化用例，大家都明白的道理，真正落到的时候，一般都是0，究其原因，并非大家不想维护，而是维护成本高，自动化用例复杂度高，前人栽树，后人无从下手，因此自动化用例务必做到易维护，推荐通过pipline的方式将每个用例步骤进行编排，而一条用例的组成是多个原子的组合结果，这样做以后，每次需求的迭代，只改原子，不改结果。

自动化用例要有好的反馈：

自动化用例执行完成，既要求有清晰的测试报告，呈现出本次自动化执行结果，还要求务必将执行结果及时触达到用户。传统触达用户的方式多以邮件为主，gpt的兴起，提供了一种新的可能，即通过聊天机器人实时触达用户。