缺陷基础知识与项目管理工具禅道介绍

目录

一、用例执行

二、软件缺陷（补充）

三、浏览器

四、项目管理工具——禅道

---

一、用例执行

说明：执行结果与用例的期望结果不一致（含义），为缺陷。

提示：用例执行不通过为缺陷，需要进行缺陷管理。

---

二、软件缺陷（补充）

原地址：https://blog.csdn.net/ouihsiad/article/details/125694663

1、缺陷产生的原因：

（1）需求阶段：需求描述不易理解，有歧义，错误等。

（2）设计阶段：设计文档存在错误或缺陷。

（3）编码阶段：代码出现错误。

（4）运行阶段：软硬件系统本身故障导致软件缺陷。

2、软件缺陷产生的根源

（1）需求的变更

（2）交流不充分

（3）软件的复杂性

（4）进度压力

3、软件缺陷的生命周期：

需求规格说明->设计->编码->测试->故障分类->故障隔离->故障解决

（1）回归测试：

• 常规项目回归：项目本次发布新增2个模块，最基本要测新增模块功能及新增模块关联的旧模块
• 非常规项目（银行、部队、航天）：新增功能，必须全部复测

（2）回归bug：上一个版本发现的缺陷，开发修复完毕，在下一个版本进行重新验证。

4、软件缺陷的基本内容

（1）缺陷的标题：描述缺陷的核心问题

（2）缺陷的预期结果：希望得到的结果

（3）缺陷的预置条件：缺陷产生的前提

（4）缺陷的实际结果：实际得到的结果

（5）缺陷的复现步骤：复现缺陷的过程

（6）缺陷的必要附件：图片、日志等信息（证据）

5、软件缺陷类型

功能错误
错误界面（UI）			兼容性
数据	易用性	改进/建议	架构

6、缺陷跟踪流程

 7、提交缺陷注意事项

（1）可重现：缺陷可以重复。

（2）规范性：符合公司或者项目的要求。

（3）唯一性：一个缺陷上报一个问题。

面试题：当你发现缺陷后，首先会怎么办？

答：确定缺陷是否可重现，确定是bug。提交时，要检查缺陷是否已存在。

8、缺陷编写规范

（1）准确：描述的信息是正确的。

（2）具体：有细节且是真实待定的。

（3）简洁易懂：描述简单容易理解。

（4）次序清晰：描述缺陷过程有条件，有先后顺序。

避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替；
避免使用情绪化的语言和强调符号；
避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果；
避免提交不确定的测试问题，自己至少需要重现一次再提交。

9、缺陷标题分析

（1）作用：能让人看明白哪里错了

（2）编写格式：

• 描述测试数据+实际结果（预期结果）
• 描述测试数据+预期结果（实际结果）
• 描述测试数据+实际结果（需求）

10、项目中缺陷管理流程

提交、验证、关闭。

11、缺陷分析需要注意的点

• 哪个模块问题最多
• 哪个测试工程师测试的缺陷最多
• 各类缺陷的数量占比
• 开发是否可以及时修复缺陷
• 开发人员一次修复缺陷占比
• 软件是否可以正常发布

---

三、浏览器

5大浏览器（内核）：

（1）谷歌

（2）火狐

（3）IE（淘汰）

（4）苹果

（5）欧朋（欧洲市场）

浏览器兼容性测试：正常显示、正常输入、正常操作

---

四、项目管理工具——禅道

1、网站

https://demo.zentao.net/user-login.html

2、特点

（1）国产、免费、开源、简单、轻量级

（2）三管融合（产品管理、项目管理、质量管理）

（3）三权分立（产品部门、研发部门、测试部门）

（4）四角协同（产品经理、项目经理、研发团队、测试团队）

3、使用流程图

 4、使用流程

（1）管理用例->创建用例->评审用例->执行用例

（2）管理缺陷->缺陷创建->缺陷跟踪->缺陷验证---重点