- 综合排序
- 最热优先
- 最新优先
- 来自专栏啄木鸟软件测试
智能回归测试 vs 传统回归：测试专家必读
引言 在持续交付与高频迭代成为行业常态的今天，回归测试正从‘质量守门员’演变为‘效能加速器’。 当一次主干合并触发2000+用例执行，却因3个页面元素ID变更导致47%用例失败时，问题已不在‘是否自动化’，而在‘如何智能地自动化’。 本文将从技术本质、落地效能与组织适配三个维度，深度对比智能回归测试与传统回归测试，为测试专家提供可落地的升级路径。 例如，修改支付模块Java类时，系统自动关联3年前在此模块爆发的‘优惠券叠加失效’缺陷模式，优先执行相关测试链路。 未来三年，不具备AI协同能力的回归测试体系，将如同没有CI/CD的开发流程一样，成为技术债黑洞。现在开始评估你的回归策略：你的测试是还在‘跑完所有用例’，还是已经学会‘只跑该跑的用例’？
13210编辑于 2026-04-13 - 来自专栏FunTester
敏捷回归测试
通常，执行回归测试的常见触发因素包括： 由于添加了新功能或需求和业务流程发生了更改 重大缺陷修复（功能性或非功能性），需要质量保证 连续回归测试（每天/每周）以降低风险 敏捷战略中的回归测试 构建测测试自动化是一项具有挑战性的任务 ，但却是持续测试和回归测试的关键推动力。 测试工程管理需要专注于回归套件的持续维护并确定以下内容： 哪些测试用例已经过验证，需要包含在回归套件中，哪些应该排除在外？ 回归和子集回归套件的执行时间计划是什么？ 不断分析测试的价值，脆弱性等等。 敏捷回归测试建议和基础 在阐明了有关回归测试的一些基本战略考虑和见解之后，以下是一些最佳实践和建议以供参考： 将选择性回归测试与完整回归测试周期区分开来。 充分利用回归测试 高度稳定的测试自动化可实现连续测试，回归测试也越来越依赖于强大而值得信赖的测试自动化。
79121发布于 2020-08-04 - 来自专栏啄木鸟软件测试
回归测试VS重新测试
什么是回归测试？ 从根本上讲，回归测试是保证当应用的代码，UI，或者其他会产生高度影响的操作的任何的变化之后仍然能发挥其功能的软件测试的一种。回归测试能帮助回答“更改是否导致了新的bug”的问题。 回归测试VS重新测试：最主要的区别是什么？ 换言之：回归测试=找到新bug。重新测试=验证bug是否已修复。 回归测试在更新或者对代码、UI变更后定位bug。 回归测试 重新测试 发现新bug 确认就bug已修复 自动的 手动的 低优先级 高优先级 广泛执行 分散执行 非计划性工作 计划性工作 回归测试是广泛执行，遍及应用以识别新的问题。 因为它是用于解决已知问题的，它比回归测试有更高的优先级。 最后，跟回归测试的发现新问题并且导致一些你没有计划或期待的工作相比，重新测试更加的可预测。 Regression Testing vs Retesting Agile Example 回归测试VS重新测试自动化敏捷案例 当你有一个无需编码的自动化测试工具的时候进行回归测试更加的简易，并且能让你同时在不同的浏览器同时执行回归测试套件
1.3K34发布于 2020-09-23 - 来自专栏程序员阿常
回归测试如何确定测试范围？
读者提问： 『阿常你好，想请教一下，回归测试如何确定测试范围，如何避免遗漏 ？』 阿常回答： 三种方式，可以结合起来使用。 2、测试根据经验分析 如果开发修改的是模块A，回归测试时就覆盖模块A，根据测试经验判断模块 B 关联了模块A，回归测试时就覆盖模块A和模块B。 ３、用例关联矩阵分析 用例中标识与之关联的其他用例，回归测试时，此用例回归，与之关联的其他用例也回归； 建立代码块和用例对应的矩阵，回归测试时，根据修改的代码块，找到对应的回归用例。 阿常碎碎念： 以上，１２应该是企业中常见做法，３落地有些难度。 看完今天的分享对你是不是有所启发呢，有任何想法都欢迎大家后台私信阿常，一起探讨交流
1.2K30编辑于 2022-12-07 - 来自专栏老齐教室
回归分析（3）
然后用上述数据，利用statsmodels中的·.OLS`得到一元线性回归模型。 从对图示的观察可知，如果用现在所得到的一元线性回归模型作为机器学习模型，对于数据(alpha, beta)而言，并不是一个好模型。 除了估计回归系数之外，在严格的统计学中，还要估计 ，并进行相关的假设检验，并给出置信区间。这些内容通常依据上述定理中各参数分布特点解决。 coef 回归系数估计值 std err 回归系数估计值的标准误差 t t检验值。度量统计学上重要程度的量。 P > t P值。 No 多重共线性检验（如果与多个参数拟合，则参数彼此相关） 如此，即可实现统计中的线性回归模型构建。
1.7K20发布于 2021-03-11 - 来自专栏贝克街的捉虫师
什么是回归测试？
因此，回归测试变得必要。可以使用以下技术执行回归测试： 重新测试全部 这是用于回归测试的方法之一，在该方法中，应重新执行现有测试用例或套件中的所有测试。这是非常昂贵的，因为它需要大量的时间和资源。 回归测试选择 与其重新执行整个测试套件，不如选择一部分测试套件来运行 所选的测试用例可以分类为1）可重复使用的测试用例2）过时的测试用例。 可重用的测试用例可用于后续的回归循环中。 成功的测试用例样本 故障测试用例样本 回归测试工具 如果您的软件进行频繁更改，则回归测试成本将上升。 为了确保有效的回归测试，请注意以下几点： 正在回归测试的代码应在配置管理工具下 在回归测试阶段，不得更改任何代码。回归测试代码必须不受开发人员更改的影响。 用于回归测试的数据库必须是隔离的。 回归测试意味着对您的软件应用程序进行代码更改时对其进行测试，以确保新代码不会影响软件的其他部分。 回归测试中的挑战： 以下是进行回归测试的主要测试问题： 随着连续的回归运行，测试套件变得相当大。
4.9K41发布于 2020-05-15 - 来自专栏从流域到海域
什么是回归测试？
回归测试很多时候面对的是薛定谔的bug，就是回归测试很大程度上可能不会发现bug，但这部分测试工作又不能被省略掉，因为一旦存在bug，bug的严重程度可能会很高。 回归测试是软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。 因此回归测试的自动化将能够大幅度降低系统测试、维护升级的成本。 回归测试用例抽取技巧 如果系统目前为止已经比较稳定，那么可以根据8/2（80%的缺陷出现在20%的模块中）的原则来挑选回归测试的用例。 业务程度比较复杂的情况下，对用户频繁使用的功能模块进行回归测试。 开发对某个模块的功能进行来小规模的修改时，也需要进行回归测试。 参考文献 Regression Testing - wikipedia 回归测试 - 百度百科 什么是回归测试？
84830编辑于 2021-12-06 - 来自专栏sktj
python 回归测试脚本
The subprocess module spawns and controls streams (much like os.popen3 in Python 2.X), and is cross-platform
1K20编辑于 2022-05-13 - 来自专栏IT技术精选文摘
回归测试策略概览
本文要点 回归测试不同于其他类型的测试。 回归测试分为多种类型，因为不同的原因，采取不同的方法。 建立回归测试的策略，重点是要考虑上下文和其他一些因素。 回归测试有很多方式和方法。 为什么要进行回归测试 软件的回归是指某个事件（例如，一个软件补丁或升级）发生后出现的一个缺陷。回归测试则确保了最近变更的代码不会影响其他代码，从而防止软件回归。 变更是回归测试中的关键概念。 回归测试策略：基本因素 分析了回归测试的原因及其类型后，我们可以开始制定一个有效的回归测试策略。在设计回归测试策略时，团队依赖于两个因素： 产品的本质。 回归测试方法 回归测试遵循两种实现方法：手工和自动。 手工回归 无论采用何种方法论（瀑布、敏捷和其他），手工回归测试是对产品进行回归测试的基本方法。 回归测试实现方式 回归测试提供了两种可能的实现方式： 完全回归 这种回归测试方法包含了覆盖所有产品的回归测试案例。质量团队通常在产品交付流程的最后阶段，或主要版本发布前执行此操作。
1.9K51发布于 2018-03-20 - 来自专栏授客的专栏
测试思想-测试执行 如何进行回归测试？
如何进行回归测试？ by:授客 QQ：1033553122 如何进行回归性测试？这个问题似乎很简单，不就是新功能测试，对未关闭的旧bug验证，对bug可能影响模块进行测试么？ 举个简单的例子：在线教育系统中，有个课程查询功能，该查询功能中，某个按条件“状态”查询结果不准确的bug，开发进行了修改，测试的时候，我们第一件事情是验证是否修复，第二件事情是验证该条件“状态”查询与其他条件的组合查询是否正常 ，该缺陷的修改是否影响了组合查询 3、步骤2完成了再往下验证下一条 注意： 由于时间有限，所以要分轻重缓急，，也就是说，先验证严重程度最高的，然后次之。。。。。 注：对于新功能的测试也要考虑类似的问题 这里虽然只是多了一步，但是要知道这一步的重要性，bug数少点还好办，但是bug数要是多点，你会一条一条的倒回来看，它可能影响了哪些功能、模块么？
1.2K20发布于 2019-09-11 - 来自专栏程序员阿常
回归测试怎么做
读者提问：回归测试怎么做 ？ 阿常回答：这个问题我分两点回答1、什么是回归测试2、怎么做回归测试一、什么是回归测试有些同学对于冒烟测试和回归测试拎不清，冒烟测试与回归测试是有区别的，下面阿常分别和大家说说两者的区别。 回归测试，是正式测试过程中，对已修复的问题或软件环境发生改变后进行的测试，一般是验证已修复的问题及测试问题相关联模块。 二、怎么做回归测试回归测试策略如下：1、全面回归测试--每一个大版本的发布，或者一次较大规模的调整，都需要在预发布环境做一次全面的回归测试。 2、选择性回归测试--小版本的迭代，对可能影响到的功能点进行选择性的回归测试。3、自动化回归测试--测试环境、预发布环境、生产环境发布之后进行现有自动化测试用例的执行。
1K30编辑于 2022-06-29 - 来自专栏程序员阿常
回归测试怎么做
读者提问：回归测试怎么做 ？ 阿常回答：这个问题我分两点回答 1、什么是回归测试 2、怎么做回归测试 一、什么是回归测试 有些同学对于冒烟测试和回归测试拎不清，冒烟测试与回归测试是有区别的，下面阿常分别和大家说说两者的区别。 回归测试，是正式测试过程中，对已修复的问题或软件环境发生改变后进行的测试，一般是验证已修复的问题及测试问题相关联模块。 二、怎么做回归测试 回归测试策略如下： 1、全面回归测试--每一个大版本的发布，或者一次较大规模的调整，都需要在预发布环境做一次全面的回归测试。 2、选择性回归测试--小版本的迭代，对可能影响到的功能点进行选择性的回归测试。 3、自动化回归测试--测试环境、预发布环境、生产环境发布之后进行现有自动化测试用例的执行。
93310编辑于 2022-09-01 - 来自专栏测试人生
如何进行回归测试
回归测试（Regression testing）是指代码在发生修改之后重新测试之前的测试以保证修改的正确性。 理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的缺陷是否在软件新版本上再次出现 关于如何做好回归测试，大体上的人都是认为是先验证bug，然后回归和本次修改相关的地方。 在我们平时的回归测试中，是如何做这一点呢？ 一、和项目中的DEV以及项目负责人沟通确认。 这是一个很关键的环节，好的开发人员在提交测试时就会注明可能影响的地方。 二、关键点的测试。 导致修改后，引起的2次bug较多，这个时候就需要加大测试力度，可能的话要整个模块基本功能进行回归。 四、项目初期对测试用例的维护。 一个项目在开始时，编写测试用例时往往是对这个系统全面了解的过程，这个时候时间也较为充裕，所以写测试用例时，尽可能标注关联测试用例。这在大型项目里是尤其重要的。
1.2K50发布于 2021-07-09 - 来自专栏测试开发技术
回归测试，有什么高效的测试方法?
1、什么是回归测试 回归测试（Regression testing） 指在发生修改之后重新测试先前的测试以保证修改的正确性。 （3）选择性执行关键功能点的测试用例 XYC邮箱的第三轮回归测试中又发现了12个Bug，那么在第四轮的回归测试过程中，除了测试这12个Bug之外，还可以选择性地执行一些关键功能点的测试用例，其他测试用例可在时间充足的情况下选择性执行 至于回归测试的策略，初级软件测试人员可通过先学习测试经理制定的策略，再从执行回归测试策略过程中进一步提升自己的测试经验。 3、对Bug起争议时的处理 测试人员和开发人员因Bug起争议的事情常有发生，例如开发人员认为这不算是一个Bug，或认为这个Bug不重要，不需要修改，而测试人员认为这是一个很严重的Bug，需要开发人员修改 （3）如果Bug单写清楚了，但开发人员还是不愿意修改的话，可以找一个合适的时间，心平气和地与开发人员沟通，说明此Bug对产品质量可能产生的不良影响，测试人员在沟通过程中不能意气用事。
1.1K20编辑于 2022-09-28 - 来自专栏啄木鸟软件测试
测试专家必看：智能回归测试未来展望
引言：回归测试的‘甜蜜负担’正在被AI重塑 在敏捷与持续交付成为标配的今天，回归测试早已不是‘可选项’，而是每次代码提交前的‘守门人’。 这揭示了一个残酷现实：传统回归测试正陷入‘越测越累、越累越错’的恶性循环。 所幸，一场静默却深刻的变革正在发生：AI不再只是测试报告里的关键词，而是真正嵌入测试生命周期的‘认知引擎’。 本文将从技术落地、能力跃迁与组织演进三个维度，剖析智能回归测试的现在与未来。 二、从‘脚本维护’到‘自我进化’：自愈式UI测试的落地实践 UI回归测试长期被诟病为‘脆性测试’——前端微调常导致数十个用例因定位器失效而集体崩溃。智能回归的突破在于赋予测试‘自愈能力’。 三、从‘测试执行’到‘质量预言’：回归结果的根因穿透与风险预判 当AI开始读懂测试失败日志，回归测试就从‘问题发现者’进化为‘风险预言家’。
24510编辑于 2026-03-09 - 来自专栏量化小白上分记
单因子测试（下）——回归测试法
之前两篇分别总结了因子数据的预处理和单因子测试的分层测试法，本篇总结回归测试法，相较于分层测试法，回归测试法更简洁。 ---- 因子预处理 与分层测试法不同，回归法测试时，因子可以不进行中性化处理，只进行异常值处理和标准化（zscore）处理，将中性化的过程包含在测试过程中。 得到的回归结果中，因子暴露的系数即为因子收益率，通过多期回归后，就可以得到因子收益率序列及回归的t值序列，通过这两个序列可以构造指标分析因子的表现。 因子测试实例 测试因子：pb_lf，需倒数 测试区间：2010年1月-2018年5月 ? ? ? MultiPeriodFactorTest(factor,DateStart,DateEnd,if_reciprocal,if_neutral_industry=True, if_neutral_mktcap=True): 2 3
6.4K12发布于 2019-01-22 - 来自专栏FunTester
敏捷团队的回归测试策略
为了避免这种情况，需要通过从开发周期开始就创建适当的回归测试策略来制定“逃脱”计划，并且在每次出现Sprint时都需要修改该策略。 建立回归测试策略之前 在建立该回归测试策略之前，事先收集一些信息。 建立回归测试策略 在敏捷开发中执行回归测试的最大挑战是保持敏捷开发与回归测试之间的平衡。因此，我们需要遵循一些快速有效的方法，以便在不影响质量的情况下执行回归测试。 自动化回归测试 快速跟踪回归测试的最佳方法之一是使回归测试的某些部分自动化。我们可以创建一个回归测试脚本，并应在每次更新时对该脚本进行修改和审查，以确保其正常工作。 一旦设置了此付款修复程序，您就可以执行一轮端到端回归测试。 确保您弄清楚聪明工作和辛苦工作之间的区别。 敏捷环境中回归测试 当回归测试策略中实现，就能够执行回归测试并保持敏捷开发的步伐。完美的回归测试结果将帮助用户保持对您产品的信任，以便为他们提供更好的产品。
1.1K20发布于 2020-02-17 - 来自专栏搜狗测试
方便的回归测试——diffy平台
背景 前段时间，公司运维又双叒叕在迁移机房，带来的又是大量的回归测试，虽然负责的项目case还算健全，但是被迁移机房仍然存在大量的历史接口，有些甚至不知道是什么业务在用，但仍然在有少量请求，既然还在为少量用户提供服务 ，那就不能断然下线，但是这种服务该怎么回归呢？ 解决方案 这种情况最简单的方案就是copy线上流量，通过工具diff结果来回归；之前配合部门的开发做了一个结果diff工具，但是功能简陋，无界面，操作十分复杂，结果diff全靠手动，用了几次实在忍不了； '\ -service.protocol='http'\ -serviceName='ExampleService'\ -summary.delay='3' case可使用大量线上流量（通过goreplay等工具）进行回放；或已有的接口测试用例；或构造大量随机用例；优点是不用关注结果正确性； 结果页面 ?
3.6K51发布于 2019-12-10 - 来自专栏互扯程序
性能测试执行：测试，调优，回归形成闭环
测试场景执行及监控 3. 测试结果收集及分析 4. 问题分析定位 5. 调优及回归测试 6. 测试报告编写 7. 测试资料归档总结 1. 3. 测试结果收集及分析 测试场景运行完成后对测试结果进行收集，包括LR结果及各种监控结果。 调优及回归测试 针对性能测试发现的问题及性能瓶颈进行调优，根据具体系统及测试情况，可能的调优点有： 优化程序，修改程序bug，优化业务处理逻辑，优化算法等； 优化数据库表结构及SQL语句，优化表结构（不使用大表 调优后进行回归测试，进行分析对比，确认调优结果是否达到预期。 6. 测试报告编写 测试执行及调优完成后进行测试报告编写，主要包括测试过程、测试结果、问题及调优情况等内容。 测试报告主要包括： 测试背景、测试目的、测试内容、测试环境（硬件环境、软件环境、逻辑架构等）、测试方法（测试场景、测试执行、测试监控等）、测试结果（性能指标、测试结果等）、测试结果分析、测试问题说明、测试结论和建议等
1.2K21发布于 2020-01-16 - 来自专栏啄木鸟软件测试
测试专家必看：智能回归测试技术深度解析
引言：回归测试的‘甜蜜负担’正在压垮传统测试体系 在敏捷与持续交付成为标配的今天，一个典型中型应用每周可能经历3–5次上线，每次变更平均触发800+用例回归。 回归测试正从质量守门员，异化为交付瓶颈与质量风险源。破局关键，已不在‘加人、加班、加机器’，而在‘智能回归’——让测试真正理解代码、感知风险、自主决策。 一、为什么传统回归策略注定失效？ calculate_discount()`函数时，CIG不仅标记直接调用者，还会识别： - 被该函数影响的数据库查询SQL模板（通过ORM日志关联）； - 依赖此折扣计算结果的前端React组件props流； - 过去3个月内与此函数同路径失败过的测试用例 3. 自愈式测试脚本（Self-Healing Test Scripts） UI元素定位器失效是回归失败主因（占比约42%）。 我们观察到三个高频误区： × ‘All-in-One’幻想：试图用单一AI模型解决全部问题，忽视领域特异性（如嵌入式系统回归需结合硬件仿真）； × 数据冷启动陷阱：未积累3个月以上高质量测试执行日志
14810编辑于 2026-04-13
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号