openSUSE:工厂测试提案
概述
提供一个单一的、众所周知的地点，提供有关 Factory 是否损坏的信息，以及指向最后已知可用的 Factory 树的链接。
问题领域
有时 Factory 是损坏的。损坏通常表现为以下类型：
- 安装程序
- 安装镜像缺失
- 安装程序无法工作
- 仓库
- 元数据缺失
- 软件包/文件冲突
- 依赖问题
- 功能性
- “关键路径”软件包中的重大错误（参见 ）
当 Factory 损坏时，人们更难成为 Factory 测试人员，开发人员更难将修复程序交付给测试人员，以及其他不良情况。
建议方案
首先，我们应该为之前描述的每种类型的损坏创建测试用例。在可能的情况下，这些测试应该被自动化或脚本化。
这些测试应该由 QA 团队成员和其他感兴趣的人员定期（如果可能每天）运行。结果应该提交并在公共网站上突出显示。
当一棵树被认为可用（即，当它通过所有测试时），QA 的某人应该向 rel-eng 提交一个工单，为该 Factory 树创建一个“已知可用”符号链接。此链接应该是公开且众所周知的。建议将“Tumbleweed”（别名：factory-tested、factory-snapshot）命名为这个已知可用的 Factory。
范围
- QA 团队成员（即测试人员）需要进行定期（每天）测试
- rel-eng 需要在收到请求时移动符号链接
关键要素
- 定义良好与损坏的要求
- 编写测试用例以检查每个要求
- 自动化所有测试用例
- 公共网站显示每日 Factory 测试结果
- 根据这些测试结果设置一个已知可用的 Factory (“Tumbleweed”) 链接
- 公开“Tumbleweed”已知可用树的链接
路线图
...待办事项...
- 用于定义良好与损坏。
- 识别该测试计划中的测试用例
- 创建一个“isfactorybroken”页面
结果
- 许多重要的测试用例已在 openqa 上自动化
- 代码： [1]
- 在 http://download.opensuse.org/factory-tested/repo/ 上提供了一个快照仓库，用于更新和网络安装 - 这在您想使用 Factory 但又想降低系统恢复风险的情况下很有用（当然，风险仍然不是零）。此仓库会使用来自 Staging 项目的新软件包进行更新，只要测试显示基本功能（安装、更新、X11）仍然有效即可。
讨论点
需要列出需求/征求webapp的模拟图。
评论？
要发表评论，请使用此提案的讨论页。
所有者
: