KART-RERANK与软件测试结合自动化生成测试用例的优先级排序你是不是也遇到过这种情况项目急着上线测试团队却对着成千上万个自动化测试用例发愁。全部跑一遍时间根本不够。挑着跑又怕漏掉关键的Bug。这种“测不完”和“测不准”的矛盾几乎是每个软件团队的日常痛点。最近我们团队尝试了一种新思路把原本用在搜索推荐里的KART-RERANK模型搬到了软件测试的战场上。简单来说就是让AI来帮我们判断在代码刚改完、时间又紧张的时候应该先跑哪些测试用例才能最快地发现潜在问题。试运行了一段时间效果还挺让人惊喜的。这篇文章我就来聊聊我们是怎么做的以及它到底解决了哪些实际问题。1. 软件测试的“选择困难症”在聊技术方案之前我们先看看问题到底出在哪。现代软件开发尤其是采用了敏捷或DevOps流程的团队代码变更非常频繁。每次提交新代码都需要运行相关的自动化测试来确保质量。但现实往往很骨感。1.1 测试资源的瓶颈理想情况下每次代码提交都应该触发完整的回归测试套件。但动辄数万甚至数十万的测试用例跑一次可能需要几个小时甚至几天。这对于追求快速迭代的团队来说是完全无法接受的。于是大家只能妥协要么只跑一部分测试要么延长测试等待时间。前者带来了漏测风险后者则拖慢了开发节奏。1.2 传统优先级排序的局限为了解决这个问题测试领域早就有了“测试用例优先级排序”的概念。传统方法主要依赖几种策略基于覆盖率的排序优先执行覆盖了最新修改代码的测试。基于历史的排序优先执行历史上发现Bug较多的测试。随机或人工指定这就不用多说了基本靠感觉。这些方法各有各的问题。基于覆盖率的方法需要精确的代码覆盖分析工具而且它假设“覆盖了修改代码的测试更容易发现问题”这个假设并不总是成立。基于历史的方法则过于依赖过去的数据对于新代码或历史数据稀少的模块就不太灵了。最根本的问题是这些方法都是“单维度”思考。而一个测试用例是否容易发现问题其实是由代码变更内容、模块历史缺陷密度、开发人员习惯、甚至提交时间等多个因素共同决定的。这就需要一种更“智能”的排序方式。2. KART-RERANK模型从“搜索排序”到“测试排序”KART-RERANK这个名字听起来有点技术化但它的核心思想并不复杂。它最初被设计用来解决搜索和推荐系统中的“重排序”问题。比如搜索引擎先找到一堆相关文档再用更复杂的模型对这批文档进行精细排序把最可能满足用户需求的排在最前面。我们发现这个场景和我们的测试用例排序问题惊人地相似都有候选集搜索引擎有一堆相关文档我们有一堆相关的测试用例比如所有覆盖了修改文件的用例。都需要精细排序搜索引擎要把最好的结果排前面我们要把最可能发现Bug的测试用例排前面。都依赖多维度特征搜索排序看点击率、停留时间、内容质量等测试排序则可以看代码变更、历史缺陷、执行时间等。2.1 模型的核心思路KART-RERANK模型通常不直接从海量候选集中筛选而是接收一个“粗排”阶段提供的、规模较小的候选列表然后利用更丰富的特征和更复杂的模型进行重新打分和排序。把它迁移到测试领域工作流程就变成了粗排检索阶段根据本次代码提交所修改的文件快速找出所有与之相关的测试用例。这一步可以用简单的代码静态分析工具完成速度很快。精排重排序阶段对粗排得到的测试用例列表使用KART-RERANK模型进行打分。模型会综合考量每个测试用例的多种特征预测其“发现本次提交引入缺陷的概率”。输出与执行按照模型打分从高到低排序生成最终的测试执行队列。测试资源如执行机、时间有限时就优先执行队列前面的测试。这个过程的巧妙之处在于它把复杂的全局排序问题分解成了“快速检索”加“精准排序”两个步骤在保证效果的同时兼顾了效率。2.2 我们需要哪些特征模型的好坏很大程度上取决于你喂给它什么样的特征。在测试排序场景下我们主要构建了以下几类特征代码变更特征这是最直接的信号。包括修改了哪些文件、哪些函数、修改的类型是新增、删除还是修改、修改的代码行数、变更的代码复杂度等。一个测试用例如果覆盖了被修改的核心函数它的优先级自然应该提高。历史缺陷特征体现模块的“脆弱性”。包括被修改文件的历史缺陷数量、缺陷密度缺陷数/代码行、最近是否频繁出Bug、关联测试用例的历史失败率等。一个“黑历史”很多的模块其相关的测试用例需要更严格的审查。测试用例自身特征体现测试的“效力”。包括用例的执行时间、上次执行是否通过、历史发现缺陷的数量、测试的代码覆盖率深度如分支覆盖、条件覆盖等。一个又慢又从来没发现过Bug的测试优先级可以适当放后。开发上下文特征一些软性指标。比如代码提交者的历史提交质量、提交时间是否在深夜匆忙提交、提交日志的规范性等。这些特征可以作为辅助判断。把这些特征组合起来就构成了一个描述“本次代码提交”与“某个测试用例”相关性的多维向量。KART-RERANK模型的任务就是学习这个向量与“测试能否发现Bug”这个结果之间的复杂关系。3. 实战搭建智能测试排序流水线理论说得再多不如看看实际怎么落地。下面我分享一下我们构建这个智能排序流水线的关键步骤和示例代码。整个流程可以集成在CI/CD平台如Jenkins、GitLab CI中在代码提交后自动触发。3.1 第一步数据收集与特征工程一切的基础是数据。我们需要从代码仓库、缺陷管理系统、测试管理平台等地方收集历史数据。# 示例一个简单的特征提取函数 import git from datetime import datetime, timedelta def extract_features_for_test(test_case_id, commit_hash): 为某个测试用例和某次提交提取特征向量。 features {} # 1. 代码变更特征 repo git.Repo(/path/to/your/repo) commit repo.commit(commit_hash) modified_files [item.a_path for item in commit.diff(HEAD~1)] # 假设我们有函数能获取测试用例覆盖的文件 test_covered_files get_covered_files_by_test(test_case_id) # 计算交集相关度 features[files_intersection_ratio] len(set(modified_files) set(test_covered_files)) / len(modified_files) if modified_files else 0 # 2. 历史缺陷特征 # 获取被修改文件在过去90天的缺陷数 ninety_days_ago datetime.now() - timedelta(days90) bug_count 0 for file in modified_files: bug_count get_bug_count_for_file(file, sinceninety_days_ago) features[modified_files_bug_density] bug_count / len(modified_files) if modified_files else 0 # 3. 测试用例自身特征 test_history get_test_execution_history(test_case_id, limit10) features[recent_failure_rate] sum(1 for run in test_history if run[status] FAILED) / len(test_history) if test_history else 0 features[avg_execution_time] sum(run[duration] for run in test_history) / len(test_history) if test_history else 0 # 4. 开发上下文特征 author commit.author features[author_avg_bug_intro_rate] get_author_bug_intro_rate(author.email) # 该开发历史引入Bug的平均比率 return features # 注意get_covered_files_by_test, get_bug_count_for_file 等需要根据实际基础设施实现3.2 第二步模型训练与更新我们使用历史数据代码提交、当时运行的测试用例及其执行结果来训练KART-RERANK模型。标签就是测试用例是否在该次提交后执行失败即发现了Bug。# 示例使用LightGBM Ranker进行训练KART-RERANK的一种实现方式 import lightgbm as lgb import pandas as pd from sklearn.model_selection import train_test_split def train_rerank_model(training_data_path): 训练排序模型。 training_data_path: CSV文件每行是一次提交-测试用例对的特征和标签1表示失败0表示通过。 数据中需要包含一个 query_id 列标识属于同一次提交的所有测试用例即同一个待排序列表。 df pd.read_csv(training_data_path) # 准备LightGBM Ranker需要的数据格式 query_groups df.groupby(query_id).size().to_numpy() # 每次提交有多少个测试用例 X df.drop([query_id, label], axis1).values y df[label].values X_train, X_val, y_train, y_val, groups_train, groups_val train_test_split( X, y, query_groups, test_size0.2, random_state42 ) # 创建Ranker数据集 lgb_train lgb.Dataset(X_train, y_train, groupgroups_train) lgb_eval lgb.Dataset(X_val, y_val, groupgroups_val, referencelgb_train) # 设置参数使用LambdaRank排序目标 params { objective: lambdarank, metric: ndcg, # 使用NDCG评估排序质量 boosting_type: gbdt, num_leaves: 31, learning_rate: 0.05, feature_fraction: 0.9, verbosity: -1, seed: 42, } gbm lgb.train(params, lgb_train, num_boost_round1000, valid_sets[lgb_train, lgb_eval], callbacks[lgb.early_stopping(50), lgb.log_evaluation(50)]) gbm.save_model(test_case_reranker_model.txt) return gbm模型不需要每天训练可以每周或每两周用最新的数据重新训练一次以捕捉项目和团队动态的变化。3.3 第三步集成到CI/CD流程训练好的模型要能够在线使用。我们在CI流水线中增加了一个“智能测试选择”的步骤。# 示例在CI脚本中调用模型进行排序 import joblib import pandas as pd def prioritize_tests_for_commit(commit_hash, candidate_test_cases): 对一次代码提交的候选测试用例进行优先级排序。 commit_hash: 本次提交的哈希值 candidate_test_cases: 粗排阶段筛选出的测试用例ID列表 # 1. 为每个候选测试用例提取特征 feature_list [] for test_id in candidate_test_cases: feats extract_features_for_test(test_id, commit_hash) feature_list.append(feats) feature_df pd.DataFrame(feature_list) # 2. 加载预训练好的模型 # 假设我们使用joblib保存了模型管道包含特征处理 model_pipeline joblib.load(test_rerank_pipeline.pkl) # 3. 预测每个测试用例的“失败概率”得分 # 注意模型输出的是排序得分越高表示优先级越高越可能失败 scores model_pipeline.predict(feature_df) # 4. 将测试用例ID和得分组合按得分降序排序 prioritized sorted(zip(candidate_test_cases, scores), keylambda x: x[1], reverseTrue) prioritized_test_ids [item[0] for item in prioritized] return prioritized_test_ids # 在CI脚本中 commit_hash os.environ[CI_COMMIT_SHA] # 假设get_related_tests函数实现粗排获取相关测试用例 candidate_tests get_related_tests(commit_hash) top_k_tests 100 # 假设本次只允许运行100个测试 tests_to_run prioritize_tests_for_commit(commit_hash, candidate_tests)[:top_k_tests] # 接下来触发执行 tests_to_run 中的测试用例4. 效果怎么样我们看到了这些变化这套系统上线运行了几个月虽然还不能说完美但确实给测试流程带来了不少积极的变化。最直观的感受是测试反馈速度变快了。以前为了确保质量我们会在代码合并前运行一个中型的“门禁测试套件”大约500个用例需要跑40分钟。现在我们让模型从这500个用例中选出它认为最重要的100个先跑。这100个测试的完成时间缩短到了10分钟以内。开发者在提交代码后能更快地得到第一轮质量反馈。如果这100个高优先级测试都通过了我们心里会踏实很多如果失败了也能立刻定位到高风险问题。缺陷逃逸率有所降低。我们对比了引入智能排序前后三个月的数据发现发布到生产环境后由客户发现的严重缺陷数量平均下降了约15%。这说明模型在识别“高风险变更”和“脆弱测试”方面是有效的优先执行的测试确实抓住了更多关键问题。当然也有挑战。比如特征工程是持续的过程。一开始我们只用了代码变更和测试历史失败率效果一般。后来加入了模块缺陷密度、开发者历史数据后排序效果才有了明显提升。模型也需要定期用新数据重新训练否则会“过时”。5. 总结与展望回过头看将KART-RERANK这类重排序模型引入测试优先级排序本质上是用数据驱动的方法替代了原本依赖经验或简单规则的策略。它不要求测试人员去精确预判哪段代码会出问题而是让模型从历史数据中学习复杂的模式和关联。实际用下来它更像一个“测试辅助决策系统”而不是完全取代人类。它帮我们解决了在资源紧张时“先测什么”的决策难题让有限的测试资源能更精准地投入到风险最高的地方。对于追求高效和质量的工程团队来说这无疑是一个值得尝试的方向。未来我们还想探索更多。比如能否把代码变更的语义信息通过代码嵌入技术也作为特征能否实现更细粒度的“测试用例片段”排序而不是整个用例模型能否根据实时测试结果动态调整后续的排序这些都是有趣且具有实用价值的问题。技术总是在解决一个又一个的实际问题中前进的。如果你也在为测试效率发愁不妨从收集数据、构建最简单的特征开始试试看机器学习能带来什么改变。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
KART-RERANK与软件测试结合：自动化生成测试用例的优先级排序
KART-RERANK与软件测试结合自动化生成测试用例的优先级排序你是不是也遇到过这种情况项目急着上线测试团队却对着成千上万个自动化测试用例发愁。全部跑一遍时间根本不够。挑着跑又怕漏掉关键的Bug。这种“测不完”和“测不准”的矛盾几乎是每个软件团队的日常痛点。最近我们团队尝试了一种新思路把原本用在搜索推荐里的KART-RERANK模型搬到了软件测试的战场上。简单来说就是让AI来帮我们判断在代码刚改完、时间又紧张的时候应该先跑哪些测试用例才能最快地发现潜在问题。试运行了一段时间效果还挺让人惊喜的。这篇文章我就来聊聊我们是怎么做的以及它到底解决了哪些实际问题。1. 软件测试的“选择困难症”在聊技术方案之前我们先看看问题到底出在哪。现代软件开发尤其是采用了敏捷或DevOps流程的团队代码变更非常频繁。每次提交新代码都需要运行相关的自动化测试来确保质量。但现实往往很骨感。1.1 测试资源的瓶颈理想情况下每次代码提交都应该触发完整的回归测试套件。但动辄数万甚至数十万的测试用例跑一次可能需要几个小时甚至几天。这对于追求快速迭代的团队来说是完全无法接受的。于是大家只能妥协要么只跑一部分测试要么延长测试等待时间。前者带来了漏测风险后者则拖慢了开发节奏。1.2 传统优先级排序的局限为了解决这个问题测试领域早就有了“测试用例优先级排序”的概念。传统方法主要依赖几种策略基于覆盖率的排序优先执行覆盖了最新修改代码的测试。基于历史的排序优先执行历史上发现Bug较多的测试。随机或人工指定这就不用多说了基本靠感觉。这些方法各有各的问题。基于覆盖率的方法需要精确的代码覆盖分析工具而且它假设“覆盖了修改代码的测试更容易发现问题”这个假设并不总是成立。基于历史的方法则过于依赖过去的数据对于新代码或历史数据稀少的模块就不太灵了。最根本的问题是这些方法都是“单维度”思考。而一个测试用例是否容易发现问题其实是由代码变更内容、模块历史缺陷密度、开发人员习惯、甚至提交时间等多个因素共同决定的。这就需要一种更“智能”的排序方式。2. KART-RERANK模型从“搜索排序”到“测试排序”KART-RERANK这个名字听起来有点技术化但它的核心思想并不复杂。它最初被设计用来解决搜索和推荐系统中的“重排序”问题。比如搜索引擎先找到一堆相关文档再用更复杂的模型对这批文档进行精细排序把最可能满足用户需求的排在最前面。我们发现这个场景和我们的测试用例排序问题惊人地相似都有候选集搜索引擎有一堆相关文档我们有一堆相关的测试用例比如所有覆盖了修改文件的用例。都需要精细排序搜索引擎要把最好的结果排前面我们要把最可能发现Bug的测试用例排前面。都依赖多维度特征搜索排序看点击率、停留时间、内容质量等测试排序则可以看代码变更、历史缺陷、执行时间等。2.1 模型的核心思路KART-RERANK模型通常不直接从海量候选集中筛选而是接收一个“粗排”阶段提供的、规模较小的候选列表然后利用更丰富的特征和更复杂的模型进行重新打分和排序。把它迁移到测试领域工作流程就变成了粗排检索阶段根据本次代码提交所修改的文件快速找出所有与之相关的测试用例。这一步可以用简单的代码静态分析工具完成速度很快。精排重排序阶段对粗排得到的测试用例列表使用KART-RERANK模型进行打分。模型会综合考量每个测试用例的多种特征预测其“发现本次提交引入缺陷的概率”。输出与执行按照模型打分从高到低排序生成最终的测试执行队列。测试资源如执行机、时间有限时就优先执行队列前面的测试。这个过程的巧妙之处在于它把复杂的全局排序问题分解成了“快速检索”加“精准排序”两个步骤在保证效果的同时兼顾了效率。2.2 我们需要哪些特征模型的好坏很大程度上取决于你喂给它什么样的特征。在测试排序场景下我们主要构建了以下几类特征代码变更特征这是最直接的信号。包括修改了哪些文件、哪些函数、修改的类型是新增、删除还是修改、修改的代码行数、变更的代码复杂度等。一个测试用例如果覆盖了被修改的核心函数它的优先级自然应该提高。历史缺陷特征体现模块的“脆弱性”。包括被修改文件的历史缺陷数量、缺陷密度缺陷数/代码行、最近是否频繁出Bug、关联测试用例的历史失败率等。一个“黑历史”很多的模块其相关的测试用例需要更严格的审查。测试用例自身特征体现测试的“效力”。包括用例的执行时间、上次执行是否通过、历史发现缺陷的数量、测试的代码覆盖率深度如分支覆盖、条件覆盖等。一个又慢又从来没发现过Bug的测试优先级可以适当放后。开发上下文特征一些软性指标。比如代码提交者的历史提交质量、提交时间是否在深夜匆忙提交、提交日志的规范性等。这些特征可以作为辅助判断。把这些特征组合起来就构成了一个描述“本次代码提交”与“某个测试用例”相关性的多维向量。KART-RERANK模型的任务就是学习这个向量与“测试能否发现Bug”这个结果之间的复杂关系。3. 实战搭建智能测试排序流水线理论说得再多不如看看实际怎么落地。下面我分享一下我们构建这个智能排序流水线的关键步骤和示例代码。整个流程可以集成在CI/CD平台如Jenkins、GitLab CI中在代码提交后自动触发。3.1 第一步数据收集与特征工程一切的基础是数据。我们需要从代码仓库、缺陷管理系统、测试管理平台等地方收集历史数据。# 示例一个简单的特征提取函数 import git from datetime import datetime, timedelta def extract_features_for_test(test_case_id, commit_hash): 为某个测试用例和某次提交提取特征向量。 features {} # 1. 代码变更特征 repo git.Repo(/path/to/your/repo) commit repo.commit(commit_hash) modified_files [item.a_path for item in commit.diff(HEAD~1)] # 假设我们有函数能获取测试用例覆盖的文件 test_covered_files get_covered_files_by_test(test_case_id) # 计算交集相关度 features[files_intersection_ratio] len(set(modified_files) set(test_covered_files)) / len(modified_files) if modified_files else 0 # 2. 历史缺陷特征 # 获取被修改文件在过去90天的缺陷数 ninety_days_ago datetime.now() - timedelta(days90) bug_count 0 for file in modified_files: bug_count get_bug_count_for_file(file, sinceninety_days_ago) features[modified_files_bug_density] bug_count / len(modified_files) if modified_files else 0 # 3. 测试用例自身特征 test_history get_test_execution_history(test_case_id, limit10) features[recent_failure_rate] sum(1 for run in test_history if run[status] FAILED) / len(test_history) if test_history else 0 features[avg_execution_time] sum(run[duration] for run in test_history) / len(test_history) if test_history else 0 # 4. 开发上下文特征 author commit.author features[author_avg_bug_intro_rate] get_author_bug_intro_rate(author.email) # 该开发历史引入Bug的平均比率 return features # 注意get_covered_files_by_test, get_bug_count_for_file 等需要根据实际基础设施实现3.2 第二步模型训练与更新我们使用历史数据代码提交、当时运行的测试用例及其执行结果来训练KART-RERANK模型。标签就是测试用例是否在该次提交后执行失败即发现了Bug。# 示例使用LightGBM Ranker进行训练KART-RERANK的一种实现方式 import lightgbm as lgb import pandas as pd from sklearn.model_selection import train_test_split def train_rerank_model(training_data_path): 训练排序模型。 training_data_path: CSV文件每行是一次提交-测试用例对的特征和标签1表示失败0表示通过。 数据中需要包含一个 query_id 列标识属于同一次提交的所有测试用例即同一个待排序列表。 df pd.read_csv(training_data_path) # 准备LightGBM Ranker需要的数据格式 query_groups df.groupby(query_id).size().to_numpy() # 每次提交有多少个测试用例 X df.drop([query_id, label], axis1).values y df[label].values X_train, X_val, y_train, y_val, groups_train, groups_val train_test_split( X, y, query_groups, test_size0.2, random_state42 ) # 创建Ranker数据集 lgb_train lgb.Dataset(X_train, y_train, groupgroups_train) lgb_eval lgb.Dataset(X_val, y_val, groupgroups_val, referencelgb_train) # 设置参数使用LambdaRank排序目标 params { objective: lambdarank, metric: ndcg, # 使用NDCG评估排序质量 boosting_type: gbdt, num_leaves: 31, learning_rate: 0.05, feature_fraction: 0.9, verbosity: -1, seed: 42, } gbm lgb.train(params, lgb_train, num_boost_round1000, valid_sets[lgb_train, lgb_eval], callbacks[lgb.early_stopping(50), lgb.log_evaluation(50)]) gbm.save_model(test_case_reranker_model.txt) return gbm模型不需要每天训练可以每周或每两周用最新的数据重新训练一次以捕捉项目和团队动态的变化。3.3 第三步集成到CI/CD流程训练好的模型要能够在线使用。我们在CI流水线中增加了一个“智能测试选择”的步骤。# 示例在CI脚本中调用模型进行排序 import joblib import pandas as pd def prioritize_tests_for_commit(commit_hash, candidate_test_cases): 对一次代码提交的候选测试用例进行优先级排序。 commit_hash: 本次提交的哈希值 candidate_test_cases: 粗排阶段筛选出的测试用例ID列表 # 1. 为每个候选测试用例提取特征 feature_list [] for test_id in candidate_test_cases: feats extract_features_for_test(test_id, commit_hash) feature_list.append(feats) feature_df pd.DataFrame(feature_list) # 2. 加载预训练好的模型 # 假设我们使用joblib保存了模型管道包含特征处理 model_pipeline joblib.load(test_rerank_pipeline.pkl) # 3. 预测每个测试用例的“失败概率”得分 # 注意模型输出的是排序得分越高表示优先级越高越可能失败 scores model_pipeline.predict(feature_df) # 4. 将测试用例ID和得分组合按得分降序排序 prioritized sorted(zip(candidate_test_cases, scores), keylambda x: x[1], reverseTrue) prioritized_test_ids [item[0] for item in prioritized] return prioritized_test_ids # 在CI脚本中 commit_hash os.environ[CI_COMMIT_SHA] # 假设get_related_tests函数实现粗排获取相关测试用例 candidate_tests get_related_tests(commit_hash) top_k_tests 100 # 假设本次只允许运行100个测试 tests_to_run prioritize_tests_for_commit(commit_hash, candidate_tests)[:top_k_tests] # 接下来触发执行 tests_to_run 中的测试用例4. 效果怎么样我们看到了这些变化这套系统上线运行了几个月虽然还不能说完美但确实给测试流程带来了不少积极的变化。最直观的感受是测试反馈速度变快了。以前为了确保质量我们会在代码合并前运行一个中型的“门禁测试套件”大约500个用例需要跑40分钟。现在我们让模型从这500个用例中选出它认为最重要的100个先跑。这100个测试的完成时间缩短到了10分钟以内。开发者在提交代码后能更快地得到第一轮质量反馈。如果这100个高优先级测试都通过了我们心里会踏实很多如果失败了也能立刻定位到高风险问题。缺陷逃逸率有所降低。我们对比了引入智能排序前后三个月的数据发现发布到生产环境后由客户发现的严重缺陷数量平均下降了约15%。这说明模型在识别“高风险变更”和“脆弱测试”方面是有效的优先执行的测试确实抓住了更多关键问题。当然也有挑战。比如特征工程是持续的过程。一开始我们只用了代码变更和测试历史失败率效果一般。后来加入了模块缺陷密度、开发者历史数据后排序效果才有了明显提升。模型也需要定期用新数据重新训练否则会“过时”。5. 总结与展望回过头看将KART-RERANK这类重排序模型引入测试优先级排序本质上是用数据驱动的方法替代了原本依赖经验或简单规则的策略。它不要求测试人员去精确预判哪段代码会出问题而是让模型从历史数据中学习复杂的模式和关联。实际用下来它更像一个“测试辅助决策系统”而不是完全取代人类。它帮我们解决了在资源紧张时“先测什么”的决策难题让有限的测试资源能更精准地投入到风险最高的地方。对于追求高效和质量的工程团队来说这无疑是一个值得尝试的方向。未来我们还想探索更多。比如能否把代码变更的语义信息通过代码嵌入技术也作为特征能否实现更细粒度的“测试用例片段”排序而不是整个用例模型能否根据实时测试结果动态调整后续的排序这些都是有趣且具有实用价值的问题。技术总是在解决一个又一个的实际问题中前进的。如果你也在为测试效率发愁不妨从收集数据、构建最简单的特征开始试试看机器学习能带来什么改变。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
