RefStack/UseCases

用例是识别软件项目需求的强大方法。在 Refstack 定义的初始阶段，这些用例已被用于驱动设计和架构。它们目前也用于驱动开发里程碑。

RefStack 用例

以下是原始 RefStack 用例的链接，首次通过标记为 **。**
https://etherpad.openstack.org/p/DefCoreRefStackUseCases2015

在以下章节中，首次通过的用例以 粗体 突出显示。

Ops：私有云运营商

我希望

• 在结果公开发布前预览结果
• 比较我随时间推移的测试运行
• 将我的测试运行与具有相似特征的云进行比较（标签）
• 能够忽略不重要的测试
• 将测试分组到功能中，这样我就不会感到不知所措
• 突出显示对运维至关重要的测试
• 能够将我的 tempest 结果上传到 refstack 进行分析
• 能够删除结果

User：OpenStack 用户

我希望

• 确保我所需的功能可用
• op 3, 4, 5 和 6
• 能够发布我自己的测试结果
• (foundation 7)

Prospect：潜在的 OpenStack 用户

我希望

• 在不上传测试的情况下比较结果
• 不要强制创建 lp 帐户才能获取数据
• 看不到不准确的结果（仅批准的结果）

Vendor / Organization：OpenStack 供应商

我希望

• 控制可以应用于针对我的云的测试运行的标签
• 对我不一致的结果提出异议
• 能够将结果标记为官方
• 知道测试提交来自经过验证的用户
• 能够排除我们尚未实现的功能的测试（ops 4）
• 能够向客户提供关于我的兼容性的信息（ops 3）
• 我无法控制的结果在统计上相关
• 向潜在客户展示汇总结果（如果结果有利）

Foundation：OpenStack 基金会

我需要/想要

• 确定我的安装基础中哪些测试通过的方法
• 社区指示重要功能的方法
• 按版本确定哪些测试“必须通过”的方法
• 证明结果包含所有“必须通过”测试的方法
• 指示符合要求的组织
• 解决争议的方法（ops 3）
• 突出显示功能覆盖范围的差距
• 确保发布的结果准确
• RefStack 结果与适当版本文档之间的链接

Vendor：依赖 OpenStack API

我需要

• 能够验证我的产品将在哪些云上工作（user 1）
• 能够上传超出上游范围的测试结果