测试用例版本控制新范式:Onyx如何解决团队协作中的测试一致性难题
在软件开发中,测试用例的管理往往是团队协作的薄弱环节。你是否曾遇到过这些问题:多个测试人员同时修改同一测试用例导致版本混乱?测试结果与代码版本无法精确对应?历史测试数据难以追溯?Onyx作为一款功能丰富的自托管聊天界面,不仅支持与任何LLM(大语言模型)协同工作,还通过其内置的评估框架提供了强大的测试用例版本控制能力。本文将详细介绍如何利用Onyx的评估系统实现测试用例的高效管理与版本控制,帮助团队提升测试效率和协作质量。
读完本文后,你将能够:
- 理解Onyx评估框架的基本原理和核心组件
- 掌握使用Onyx进行测试用例版本控制的具体方法
- 学会配置和运行Onyx测试评估任务
- 了解如何利用Onyx的隔离会话机制确保测试环境的一致性
Onyx评估框架概述
Onyx是一个功能丰富、可自托管的聊天界面,能够与任何LLM协同工作。它易于部署,并且可以在完全离线的环境中运行。Onyx内置了高级功能,如智能体(Agents)、网络搜索、检索增强生成(RAG)、多智能体协作协议(MCP)、深度研究、以及与40多种知识源的连接器等。
Onyx的评估框架(Eval Framework)是其核心功能之一,主要用于测试和验证Onyx系统本身以及与其集成的各种工具和模型的性能。这个框架不仅可以用于Onyx自身的质量保证,还可以被用户扩展用于管理和控制自定义测试用例的版本。
Onyx的评估框架主要由以下几个核心模块组成:
- 评估配置(Eval Configuration):定义测试用例的执行环境和参数
- 评估提供器(Eval Provider):负责实际执行评估任务的组件
- 隔离会话工厂(Isolated Session Factory):创建隔离的测试环境,确保测试之间互不干扰
- 评估运行器(Eval Runner):协调评估任务的执行流程

测试用例版本控制的核心组件
评估配置模型
Onyx的评估配置模型(Eval Configuration Model)是实现测试用例版本控制的基础。该模型定义了测试用例的执行环境、参数设置和预期结果,从而确保测试用例在不同版本之间的可重复性和一致性。
评估配置模型的核心代码位于backend/onyx/evals/models.py文件中。该文件定义了以下几个关键类:
- EvalConfiguration:表示一个完整的评估配置,包括内置工具类型、角色覆盖配置、LLM设置、搜索权限邮箱和允许的工具ID列表。
- EvalConfigurationOptions:评估配置的选项类,提供了默认值和配置方法。
- EvalationAck:评估结果的确认类,用于表示评估任务是否成功完成。
- EvalProvider:评估提供器的抽象基类,定义了评估任务的执行接口。
下面是EvalConfigurationOptions类的核心代码片段:
class EvalConfigurationOptions(BaseModel):
builtin_tool_types: list[str] = list(
tool_name
for tool_name in BUILT_IN_TOOL_MAP.keys()
if tool_name != "OktaProfileTool"
)
persona_override_config: PersonaOverrideConfig | None = None
llm: LLMOverride = LLMOverride(
model_provider="Default",
model_version="gpt-4.1",
temperature=0.0,
)
search_permissions_email: str
dataset_name: str
no_send_logs: bool = False
def get_configuration(self, db_session: Session) -> EvalConfiguration:
persona_override_config = self.persona_override_config or PersonaOverrideConfig(
name="Eval",
description="A persona for evaluation",
tools=[
ToolConfig(id=get_builtin_tool(db_session, BUILT_IN_TOOL_MAP[tool]).id)
for tool in self.builtin_tool_types
],
prompts=[
PromptOverrideConfig(
name="Default",
description="Default prompt for evaluation",
system_prompt="You are a helpful assistant.",
task_prompt="",
datetime_aware=True,
)
],
)
return EvalConfiguration(
persona_override_config=persona_override_config,
llm=self.llm,
search_permissions_email=self.search_permissions_email,
allowed_tool_ids=[
get_builtin_tool(db_session, BUILT_IN_TOOL_MAP[tool]).id
for tool in self.builtin_tool_types
],
)
这个类定义了评估任务的默认配置,包括要使用的内置工具类型、LLM模型设置、数据集名称等。通过修改这些参数,我们可以创建不同版本的测试用例配置,从而实现测试用例的版本控制。
隔离会话机制
为了确保不同版本的测试用例之间互不干扰,Onyx提供了隔离会话机制(Isolated Session Mechanism)。这个机制通过创建独立的数据库会话和事务,确保每个测试用例都在一个干净的环境中执行,不会对其他测试用例或生产环境产生影响。
隔离会话机制的核心代码位于backend/onyx/evals/eval.py文件中,主要通过isolated_ephemeral_session_factory函数实现:
@contextmanager
def isolated_ephemeral_session_factory(
engine: Engine,
) -> Generator[Callable[[], Session], None, None]:
"""
Create a session factory that creates sessions that run in a transaction that gets rolled back.
This is useful for running evals without any lasting db side effects.
"""
tenant_id = get_current_tenant_id()
schema_translate_map = {None: tenant_id}
conn = engine.connect().execution_options(schema_translate_map=schema_translate_map)
outer_tx = conn.begin()
Maker = sessionmaker(bind=conn, expire_on_commit=False, future=True)
def make_session() -> Session:
s = Maker()
s.begin_nested()
@event.listens_for(s, "after_transaction_end")
def _restart_savepoint(
session: Session, transaction: SessionTransaction
) -> None:
if transaction.nested and not (
transaction._parent is not None and transaction._parent.nested
):
session.begin_nested()
return s
try:
yield make_session
finally:
outer_tx.rollback()
conn.close()
这个函数创建了一个会话工厂,该工厂生成的会话运行在一个会被回滚的事务中。这意味着,在评估过程中对数据库所做的任何修改都不会被永久保存,从而确保了测试用例的执行不会对系统状态产生持久影响,为不同版本的测试用例提供了干净、隔离的执行环境。
评估运行器
评估运行器(Eval Runner)是协调评估任务执行的核心组件,负责加载测试用例数据、配置评估环境、执行评估任务并收集结果。评估运行器的核心代码位于backend/onyx/evals/eval.py文件中的run_eval函数:
def run_eval(
configuration: EvalConfigurationOptions,
data: list[dict[str, dict[str, str]]] | None = None,
remote_dataset_name: str | None = None,
provider: EvalProvider = get_default_provider(),
) -> EvalationAck:
if data is not None and remote_dataset_name is not None:
raise ValueError("Cannot specify both data and remote_dataset_name")
if data is None and remote_dataset_name is None:
raise ValueError("Must specify either data or remote_dataset_name")
return provider.eval(
task=lambda eval_input: _get_answer(eval_input, configuration),
configuration=configuration,
data=data,
remote_dataset_name=remote_dataset_name,
)
这个函数接受评估配置、测试数据(或远程数据集名称)和评估提供器作为参数,然后协调执行评估任务。通过将不同版本的测试用例数据传递给这个函数,我们可以实现对不同版本测试用例的控制和执行。
实现测试用例版本控制的步骤
1. 准备测试用例数据
测试用例数据可以是本地文件或远程数据集。本地测试数据通常是一个JSON格式的文件,包含多个测试用例对象。每个测试用例对象定义了输入参数和预期输出结果。
2. 配置评估环境
使用EvalConfigurationOptions类配置评估环境。你可以指定要使用的工具类型、LLM模型参数、搜索权限等。通过创建不同的EvalConfigurationOptions实例,你可以定义不同版本的测试环境配置。
3. 执行评估任务
使用run_eval函数执行评估任务。你可以通过传递不同的测试数据或远程数据集名称来执行不同版本的测试用例。例如:
# 执行本地测试用例
local_data = load_data_local("path/to/test_cases_v1.json")
config = EvalConfigurationOptions(
search_permissions_email="test@example.com",
dataset_name="test_cases_v1"
)
result = run_eval(config, data=local_data)
# 执行远程测试用例
config = EvalConfigurationOptions(
search_permissions_email="test@example.com",
dataset_name="test_cases_v2"
)
result = run_eval(config, remote_dataset_name="test_cases_v2")
4. 比较评估结果
评估完成后,你可以比较不同版本测试用例的执行结果,分析系统性能的变化趋势,或者验证新功能是否符合预期。
在VS Code中运行和管理测试用例
Onyx提供了便捷的VS Code集成,使得在开发环境中运行和管理测试用例变得非常简单。以下是具体步骤:
- 打开Onyx项目的VS Code工作区
- 打开VS Code的"运行和调试"面板(Ctrl+Shift+D或Cmd+Shift+D)
- 从顶部的下拉菜单中选择"Run All Onyx Services",然后点击绿色的播放按钮
这个配置会启动所有必要的Onyx服务,包括数据库、缓存、API服务器等,为测试用例的执行提供完整的环境。
总结与展望
Onyx的评估框架为测试用例的版本控制提供了强大而灵活的解决方案。通过利用评估配置模型、隔离会话机制和评估运行器,团队可以轻松管理测试用例的不同版本,确保测试的一致性和可重复性。
随着Onyx的不断发展,其评估框架也将不断完善。未来可能会增加更多高级功能,如测试用例的分支管理、自动化版本比较、测试结果的可视化分析等。这些功能将进一步提升团队的测试效率和协作质量。
无论你是Onyx的用户还是开发者,掌握其评估框架都将帮助你更好地利用这个强大的工具,提升软件质量和开发效率。现在就开始探索Onyx的测试用例版本控制功能,体验更高效、更可靠的测试流程吧!
要开始使用Onyx,只需运行以下命令(或查看下面的部署部分):
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/onyx-dot-app/onyx/main/deployment/docker_compose/install.sh)"
详细的部署和使用说明,请参考Onyx的官方文档和项目教程:README.md
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考



