功能测试

测试管理提供测试用例管理、测试计划跟踪等功能，同时支持以树形结构管理各功能模块对应的测试用例。测试过程中可通过测试报告跟踪测试进度，识别项目风险。

测试用例

添加测试集

平台采用树形结构管理测试用例，通常使用测试集命名区分版本和业务域，例如 Erda 1.0。

根目录中的测试集建议以下列两种方式划分：

• 按业务结构划分：模块—子模块—功能
• 按开发团队划分：团队—业务—功能

添加测试用例

为提高测试用例的可读性、可执行性及合理性，建议您在编写测试用例时遵循以下规范。

用例编写规范

• 测试用例应全面覆盖需求文档中的各项功能。
• 测试用例应划分系统模块，按模块分类进行编写。
• 一条测试用例仅针对一个功能点或一个流程。
• 每条测试用例必须有至少一条操作步骤和预期结果。
• 操作步骤应描述清晰，例如在某页面、点击某按钮、输入某数据等。
• 一个功能的正常流程应对应编写一条测试用例。
• 一个功能中若有多个异常流程，应分别编写多条测试用例。
• 同一功能若有不同的测试数据，应分别编写。
• 操作步骤描述应简单清晰，每个步骤应有可执行操作点，一般不超过 5 步，若步骤过多，可拆分测试用例或组合测试用例步骤。
• 用例描述不允许含糊其辞，例如不能使用大概、可能、 如果等不确定词汇。
• 测试用例设计应有级别（P0 级、P1 级、P2 级、P3 级等）。
• 测试用例编写应能被别人理解，且容易执行。

用例添加方式

平台支持直接添加测试用例或导入本地已编写完成的 Excel 和 Xmind 的文件。

测试计划

创建测试计划

一次完整的项目测试包含冒烟测试和功能测试。各阶段需建立单独的测试计划并指定相应责任人执行。测试计划的命名也需遵循规范，建议以版本/模块_测试类型的形式命名，例如 V1.0 DOP 冒烟测试。

• 开发冒烟测试 开发在完成具体需求开发后，根据测试提供的冒烟用例执行冒烟测试，由测试跟进执行进度，冒烟用例全部执行通过后发起提测。

• 测试冒烟测试 测试基于冒烟测试计划进行冒烟测试，冒烟测试通过后进行全量测试。

• 版本功能测试 测试根据版本测试计划进行功能测试，执行过程中若发现用例缺失需及时补充，用例执行失败则创建缺陷跟踪。

执行测试计划

测试计划的负责人和参与人根据测试计划中分配的测试用例执行测试。测试过程中记录用例的执行结果，若用例执行失败或阻塞可选择关联缺陷，便于缺陷解决后迅速定位至具体用例继续执行计划。

缺陷管理

测试过程中发现的缺陷可在 项目协同 > 缺陷 中进行管理，同时可通过标签管理统计项目中各模块的缺陷数据。

为缩短缺陷修复的时间，降低缺陷带来的负面影响，建议遵循创建缺陷的规范如下：

• 缺陷需注明环境、访问链接、账号、测试数据、重现步骤、预期结果、实际结果和截图（即可根据描述快速定位问题）。
• 明确缺陷优先级（紧急、重要、一般），阻塞流程的缺陷设为紧急，紧急缺陷需日清。
• 定义缺陷严重程度。
  • 致命：导致业务主要服务不可用，造成业务资损或系统崩溃，例如严重的数据计算错误和破坏，造成数据库死锁、测试工作无法继续进行等。
  • 严重：主要功能部分未实现，或与产品需求不符，阻塞完整业务流程，例如数据流错误、程序接⼝错误、轻微的数据计算错误，以及性能问题导致的服务器 RT 过⻓和内存溢出等。
  • 一般：次要功能未实现，或与产品需求不符，例如界⾯出现错误、格式错误、未明确特殊的限制和要求、删除内容未做提示等。
  • 轻微：建议或优化性问题，例如错别字、提示信息、语法、日期显示格式不正确、界⾯不美观、可输入区域和只读区域无明显的区分标志、操作不方便或不习惯等。
• 定义缺陷优先级。
  • 紧急：阻塞主流程测试的缺陷必须立即解决，否则系统无法达到预定的需求目标。
  • 高：条件允许需立即解决，关系到系统的主要功能模块能否正常工作。
  • 中：不影响需求实现，但影响其他使用方面，例如页面调用出错等。
  • 低：在系统发布前必须确认解决或确认可不予解决。
• 建议开发修复缺陷后备注缺陷产生的原因、缺陷修复的影响范围并关联对应合并请求，便于测试进行代码审查，以及根据影响范围进行更精准的回归测试。

查看测试报告

在测试过程中，可通过测试报告跟踪测试进度，查看测试计划中用例执行结果分布及个人用例执行情况，从而识别整体测试风险。