禅道笔记20211015

禅道zentao==》项目管理工具，我们测试人员用它进行测试管理（用例管理、BUG管理)

禅道的安装包:ZenTaoPMS.8.2.5.exePMS==项目管理系统

8.2.5==版本

部署禅道的服务端，安装之后你的电脑也就是禅道的服务器

xampp

x表示系统环境:Windows，如果是在Linux系统部署那么就是I

a==》Apache==》开源软件基金会

m==》mysql关系型数据库==》禅道网页上的数据会保存在mysql数据库中

p==》PHP==开发语言p==》perl==开发语言

禅道是基于PHP和perl进行开发的

禅道本地访问地址:

http://127.0.0.1/index.php

127.0.0.1==》本地IP，只能在你自己的电脑使用，表示本地电脑,每一台电脑的本地IP都是

127.0.0.1==》localhost也是表示本地电脑的意思

注意：禅道的安装路径不能存在中文

安装完成后在D盘找到zandao文件夹

编写用例的8大要素:

1，用例编号:用于对用例进行唯─编号的

2，所属模块:说明测试用例适用的功能模块

3，用例标题：简单描述测试用例执行的场景，要求尽量唯一

4，前置条件：执行测试用例步骤之前准备的一些动作或者准备的数据，用来简化测试步骤

5，步骤：用来详细说明测试需要执行的动作

6，预期：说明用例在执行之前的一个期望结果

7，优先级：说明测试用例的重要程度，用来区分测试用例的执行优先级

8，用例类型：说明测试用例的适用范围，如：功能测试、性能测试、安全测试、接口测试等等

面试题：当你认为这是一个bug，开发却认为不是bug，你会怎么去处理?

我会抱着电脑策去跟开发进行复现bug，以及根据需求去说明己对这个功能的理解。如果开发还是认为这不是bug。那么戈和和开发一起去找产品经理，然后产品经理进行仲裁，如果产品经理说这是一个bug那么开发就去修改，如果产品经理说文个不是bug，那么我会关闭这个bug

面试题：说说你们的bug流程（bug的生命周期）

以下两个流程只要回答一个：

一、     规范的流程

1、       测试人员提交bug到测试经理进行审核

2、       测试 经理审核无误后，提交给到开发经理，让开发经理分配bug修改任务

3、       开发人员接受并确认bug原因

4、       开发人员修改bug，修改完成之后，把bug指派给到测试经理，让测试经理安排对应的bug回归任务

5、       测试人员回归bug，验证通过则关闭bug；不通过则重新指派给对应的开发进行重新修改。

二，常用流程:

1、       测试人员直接把bug提交给到对应的开发人员

2、       开发人员接受并确认bug的原因

3、       开发人员修改bug，修改完成后，把bug指派给到对应的测试进行复测验证

4、       测试人员验证通过则关闭bug，不通过则重新指派给对应的开发进行重新修改。

.市面上有哪些bug管理工具，每个bug管理工具的特点是什么？

1.JIRA特点：

1. 针对问题其默认定义了丰富的字段来记录问题的各种信息，包括Issue Type, Issue summary, Issue Description, priority, assignee,reporter, resolutions等等；

2. 默认定义了工作流的一些状态: new, open, defer, pending, resolved, reopened, closed。 默认定义了一个简易的工作流, open-in progress-resolved-closed；

3. 支持邮件通知，邮件通知可以同工作流中和工作流之外的事件关联

2.Trac

Trac是以面向进度模型为项目管理模型的，很明显的特点就是它以里程碑(Milestone)方式进行项目管理的。每个里程碑中的具体要做哪些事情，就使用Ticket来进行定义、跟踪等。

3. Gitlab

特别方便管理bug，随时assign给相关开发，也可以看到开发提交bug时的Commits，每次发版可以对照相关提交，既方便测试，也可以在出现问题时找到对应开发。

4. Bugzilla

Bugzilla 是一个开源的缺陷跟踪系统（Bug-Tracking System），它可以管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期

5. Mantis

Mantis是一个基于PHP技术的轻量级的开源缺陷跟踪系统，以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上、实用性上足以满足中小型项目的管理及跟踪。

bug的状态有哪些？

New:（新的）

当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New

Assigned（已指派的）

当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

Open（打开的）

一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”

Fixed（已修复的）

当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组

Pending Reset（待在测试的）

当bug被返还到测试组后，我们将bug的状态设置为“Pending Reset”

Reset（再测试）

测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”

Closed（已关闭的）

如果测试人员经过再次测试之后确认bug已经被解决之后，就将bug的状态设置为“Closed”

Reopen（再次打开的）

如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”

Pending Reject（拒绝中）

如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”

Rejected（被拒绝的）

测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”

Postponed（延期）

有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”

Deferred（延期的）

有些情况一些特殊的bug显得不那么重要，同时也是可以消除的，这个时候我们可以将bug的状态设置为“Deferred”