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