Test Management and Coordination During the Vera C. Rubin Observatory Commissioning and Early Operations Using Zephyr Scale
本文描述了薇拉·鲁宾天文台如何利用 Jira 原生工具 Zephyr Scale,通过管理测试用例、每日测试周期以及用于调度器的部分自动化 JSON 脚本,来协调调试和早期运行期间复杂的分布式集成与在轨测试。
原始论文采用 CC BY 4.0 许可(http://creativecommons.org/licenses/by/4.0/)。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性,请参阅原始论文。 阅读完整免责声明
想象一下,维拉·C·鲁宾天文台(Vera C. Rubin Observatory)是一艘停在智利山上的巨大且极其复杂的宇宙飞船。它的任务是拍摄数百万张宇宙照片,以绘制出一幅终极的宇宙图谱。但在开始执行主要任务之前,团队必须对其进行“试运行”(commissioning)——本质上,他们必须测试每一个按钮、每一个旋钮和每一个摄像镜头,以确保一切运转完美。
这篇论文讲述了一个由50多位专家组成的团队如何利用一个名为 Zephyr Scale 的数字工具(该工具最初是为测试软件而非巨型望远镜而设计的),在没有崩溃的情况下完成了数百项此类测试的故事。
以下是他们是如何做到的,通过简单的概念进行了拆解:
1. 问题所在:厨师太多,食谱也太多
想象一下,你正在经营一家餐厅的晚间服务,50位不同的厨师都在试图决定做什么菜、什么时候做以及怎么做,而厨房的环境也在不断变化。
- 现实情况: 天文台团队需要协调每日的变化、技术故障和新的科学目标。他们需要一种方法来告诉“厨房工作人员”(观测专家)每天晚上具体该做什么,并且需要一种方法来记录食物的味道是否达标。
- 解决方案: 他们采用了 Zephyr Scale。你可以把它想象成一本存在于项目管理应用(Jira)中的数字食谱。它并非为望远镜设计,但团队意识到它是组织这种混乱状态的完美工具。
2. 三大核心要素
论文描述了他们系统的三个关键部分,我们可以将其视为食谱、每日菜单和厨师日志。
测试用例(食谱):
这是一个单一的、可重复使用的指令集。它就像一份“如何烤蛋糕”的食谱。它包含标题、步骤列表以及预期的结果。- 类比: 如果测试内容是“将望远镜对准一颗恒星并拍照”,那么测试用例就是那份写着“第一步:启动电机;第二步:等待5秒;第三步:抓拍照片”的文字食谱。
- 复杂性: 有些食谱很简单,而另一些则非常复杂(涉及数百个步骤),它们被存储为 JSON BLOCKs——你可以把这些理解为预包装的自动化“半成品料理包”,计算机可以直接“插拔”并运行它们,无需人类逐字阅读。
测试周期(每日菜单):
每天,团队都会创建一个新的“测试周期”。这是当晚的菜单。它将所有计划在当晚尝试的具体食谱(测试用例)组合在一起。- 类比: 正如餐厅会有“周二特供菜单”一样,天文台也有“周二晚间测试计划”。
- 转折点: 他们经常计划的任务量超过实际能完成的任务。有时他们在菜单上添加了30个食谱,但最后只够时间烹饪23个。系统会精确追踪哪些菜已经做好了,哪些还留在货架上。
测试执行(厨师日志):
当人类实际执行食谱中的某一步骤时,他们会在系统中将其标记为已完成。这便创建了一次“测试执行”。- 类比: 这就像厨师在笔记本上记录:“我烤好了蛋糕。它蓬松度完美。我额外加了糖。”
- 为什么重要: 即使食谱后来发生了变化,这份日志也会被“冻结”在时间中。它证明了在那个特定的夜晚究竟发生了什么,这对于多年后想要了解为什么某张照片呈现出某种效果的科学家来说至关重要。
3. 团队如何协作
论文描述了他们日常工作中一种非常特定的节奏,就像一场编排精妙的舞蹈:
- 想法: 有人提出了一个新的测试想法(例如:“让我们检查一下相机处理热量的能力”)。
- 讨论: 他们在 Slack(一款群聊应用)上进行讨论。
- 正式化: 他们将那个聊天中的想法转化为 Zephyr 中的正式测试用例(食谱)。
- 评审: 一位资深科学家会对食谱进行评审,以确保其安全且清晰。
- 规划: 第二天早上,“测试规划师”会查看每日菜单(测试周期),并将经过批准的食谱添加到其中。
- 执行: 观测专家(实际操作望远镜的人员)遵循菜单,边做边勾选步骤。
- 每周检查: 每周一次,整个团队会开会决定本周的“风味主题”。我们是应该专注于修复一个损坏的部件?还是专注于拍摄更多的照片?他们根据什么能带来最多的收获来进行优先级排序。
4. 好、坏与丑
作者诚实地描述了该工具的优缺点。
优点:
- 它创造了永久记录: 与纸质文档或白板不同,该系统会记住每一次变更。如果食谱更新了,系统知道在哪个晚上使用了哪个版本。
- 它建立了关联: 因为它运行在 Jira 内部,它能将测试直接链接到错误报告或工程工单,因此每个人都知道为什么要进行这项测试。
缺点:
- 它有点笨重: 该工具并非为望远镜打造,所以有些功能很令人烦恼。例如,很难将两个版本的食谱进行侧向对比。
- 信息陈旧: 有时,为某晚编写的笔记会被误复制到下一晚的菜单中,从而迷惑工作人员。团队每天都必须手动清理这些内容。
- 链接失效: 如果食谱的版本发生了变化,链接就会断开,导致以后很难找到旧的指令。
5. 核心启示
论文总结道,虽然 Zephyr Scale 并不是一个完美的、为巨型望远镜定制的工具,但它之所以奏效,是因为团队非常有纪律性。
他们像对待严格的软件规则一样对待这个工具:
- 如果食谱没有被标记为“就绪”,它就不会出现在菜单上。
- 如果一个步骤没有被勾选,就意味着它没有发生。
作者承认,他们原本预计在望远镜完成“试运行”并平稳运行后就会停止使用这个工具。但他们意识到自己仍然需要它。为什么?因为网站上的简单清单无法实现规模化。当你每晚需要勾选数百个步骤时,你需要一个能够自动为每个夜晚创建一个全新的、干净的日志的系统,这样你就永远不会丢失关于发生了什么的记录。
简而言之: 他们将一个旨在处理软件漏洞的工具,用来运行一台巨大的科学机器,这证明了只要有足够的纪律和良好的工作流,你就能非常成功地让“方榫头”适配“圆孔”。
您所在领域的论文太多了?
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要,使用您的语言。