代码拉取完成，页面将自动刷新
| 需求实现状态 | 定义 |
|---|---|
| 需求实现 | 1.需求对应的测试用例执行期间，未出现任何bug 2.需求对应的测试用例执行期间发现了相应的bug，但是bug均已完成修复 3.需求对应的用例中存在部分尚未修复的bug，但是该需求的核心功能均已实现。（核心功能实现，即该需求对应的优先级为1级和2级的用例，测试未发现任何bug，或者发现的bug均已修复） |
| 需求未实现 | 需求对应的核心功能，即优先级为1级和2级的用例中，还存在尚未修复的bug |
| 需求验证阻塞 | 1.从测试的角度，需求设计层面存在诸如描述含糊等情况，导致测试无法设计对应的用例来验证此类需求的是否实现，即需求不具备可测性 2.由于软件、硬件条件等限制，导致需求验证工作受阻，暂时无法开展的 |
| 需求无需验证 | 需求无需验证包括以下几种情况： 1.经研发、产品及测试确认，需求不适用当前版本的 2.经研发、产品以及测试确认，需求未进入当前版本的 3.部分涉及接口、代码改动类需求，经研发、产品及测试确认，无需进行测试的 |
测试状态包括测试准入、测试异常终止与测试准出。
| 分项 | 内容 |
|---|---|
| 单元测试对象 | 1. 独立模块或组件部分 2. 一般情况不接受单独某个缺陷解决后的提测，建议批量随版本提测 |
| 提测前提条件 | 1. 模块由于缺陷修复有较大改动，可能导致版本不稳定,或复杂需求研发完成，在其全部内容就绪后 2. 模块研发明确改动范围及影响域，确认提测计划 3. 对于非原定测试计划内的单元测试提测申请，QA sig组织相关会议对是否进行测试进行评审，根据评审结果而定 |
| 提测方式 | 1. 发送邮件方式提测，发送给QA sig qa@lists.openkylin.top 2. 如提测邮件有涉及敏感或者暂无法公开的信息，则指定发送fanwei@kylinos.cn |
| 提测邮件包含内容 | 1. 提测内容 1）新增内容：需求内容（如果有需求编号或网址链接需提供），以及需求实现情况 2）修复内容： A、是否存在issue修复，如果有则说明具体修复内容并给出需回归的issue list; B、相比上个版本是否存在非issue修复修改，如果有则请具体说明修改内容; 3）影响范围：当前代码变动的影响范围说明，从开发的角度可以备注一些除功能列表外的可能会受影响的内容 2. 提测版本：模块的版本号 3. 需要搭载的系统版本：镜像名称 4. 模块安装包：清晰的说明需要安装哪些包，以附件形式上传、或提供所有包的安装路径 5. 相关资料： 1）自测报告：需要写清楚自测搭载的ISO，以作为测试部测试的依据 2）模块说明文档或手册 |
| 测试内容 | 1. 功能测试（需求或解决的多个issue而形成的模块新版本）： 1）需求测试：集成进模块的需求及改动测试 2）模块全量测试： A、首轮测试时进行模块全量测试 B、如存在其他情况，可和研发、产品、模块组长以及测试负责人对齐测试方案 3）回归测试：集成进模块的已解决的issue改动测试、影响域测试、上轮阻塞用例测试等 4）发布前的回归测试增加模块核心功能测试 2. 测试架构：X86、ARM、RISC-V视情况而定 |
| 准入准则要求 | 判定方法 | 争议解决方式 |
|---|---|---|
| 准入材料齐全、有效，无明显数据、逻辑错误失 | 测试团队对材料进行齐套性审查、对研发自测的测试报告以抽查用例执行的方式进行审核 | 研发、测试、质量准入评审 |
| 测试团队冒烟测试用例集执行通过，未出现一个或多个阻塞/失败的情况 | 测试冒烟用例执行报告 |
| 测试异常终止（若出现列表中的任意一条，即终止该轮测试） |
|---|
| 1.测试过程中发现致命bug，且导致测试无法继续进行（例如无法正常安装、无法正常启动、核心功能未实现、测试过程中系统频繁闪退、测试前置条件不满足等） 2.主要需求未集成到当前送测版本导致需求无法验证的 |
| 分项 | 内容 |
|---|---|
| 禅道测试单 | 关联提测模块用例 |
| issue提交路径 | gitee中各仓库 |
| 测试报告 | 测试结果邮件，如需正式的测试报告则给出测试报告 |
| 测试异常终止 | 1. 不满足单元测试提测要求 2. 测试中出现异常导致无法继续执行测试，如重要功能未实现，软件包无法按照，软件或系统无法启动、闪退、崩溃等 |
| 测试准出（需满足列表中的所有条件） | 测算方法 |
|---|---|
| 需求实现方面： 1.核心需求全部实现 2.非核心需求实现60%（UKUI、窗管等由多个小需求构成的大需求，拆分时研发及需求评审时需要明确哪些是核心需求，哪些是非核心需求。以表格里重要程度列为准） |
见需求实现状态章节 |
| 总的BUG修复率不低于50%，其中: 1.严重级别为致命的缺陷，修复率为100% 2.严重级别为高的缺陷，修复率不低于70% |
修复率=已关闭的bug数量/bug总数。其中， bug总数指当前测试中发现的新增bug数+之前迭代版本测试中发现的bug中有明确解决方案指定到当前测试版本中解决的bug数量 |
| 测试团队提交完整的测试报告且评审通过 |
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
