一、版本
什么是版本呢？测试人员和开发人员，他们所接触的版本有什么不同？
我们被测项目是有多个版本进行迭代的。
比如我们的QQ上市，它是最初的版本 V3[大版本].1[中版本].2[小版本]
如果我当前被测项目的版本号是V3.1.2，测试员在这个版本上发现了bug，此时开发去修复这个Bug可能是在V3.2.1上，因为开发和测试是两个不同的环境，所以此时当我们测试人员去验证这个bug的时候，我们应该是在V3.1.1这个版本上验证。
在上一篇博客中，我们就提到bug的一个跟踪管理，那么在此处我们对其进行一些补充如下：
二、Bug的跟踪管理-状态
1、已经指派的bug
我们已经指派给开发的Bug，那么请注意自己Bug的走向，随时关注并进行跟踪，如果这个Bug一直未得到修复，要提醒开发修改，以免开发忘记，如果已经修复，我们就等待测试环境更新后进行验证。【催着改Bug】
2、已解决的bug
对于已解决的bug，我们测试人员等待测试环境更新后进行验证。验证通过之后则关闭bug，如果验证不通过则重新打开指派给开发。
3、重复bug
开发说你这个bug是重复bug，那么我们测试人员首先去查看一下该bug是否跟开发指定的bug重复，如果确定是重复bug则关闭bug，如果不是重复bug，那就请说明原因，然后重新打开指派给开发。
4、不是缺陷
如果开发说你这个bug不是缺陷，那么测试人员应该再次依据需求确认是否是bug，如果测试人员仍然觉得这个是bug，但开发他觉得不是，此时我们就跟开发沟通列举出来觉得是bug的点。如果沟通未达一致的话，就找产品确认，如果产品确认是bug，那么就注明情况并再次指派给开发。如果产品确认不是bug，就不用纠结，直接关闭bug，但是要拿小本本把这个bug记录下来，等到测试任务结束之后再来研究研究。
5、无法重现
如果我们找到的这个BUG，开发说这个bug我重现不出来，那么对于测试人员我们首先确认开发环境是否跟测试环境一致，包括操作步骤，浏览器环境，特定账号，输入数据等。如果多次版本验证之后，如开发所说的重现不了，那依据bug的严重程度，跟产品开发一起确认，然后再关闭。如果找到了重现的原因，注明清楚，并再次指派给开发。
6、不予解决
不予解决，那我们(测试人员)找产品经理进行确认，产品经理确认说不予解决的话，那就关闭bug。经理确认需要解决的话，那就请备注原因，并打开指派给开发。
7、设计如此
如果开发说这设计本来就是如此，这不是bug，那此时我们测试人员就需要找产品经理进行确认，如果产品经理确认设计就是如此的，那就关闭bug。如果产品经理确认是有问题的，那就备注原因，并重新指派给开发。
8、延期修改
他说他要进行延期修改，那我们首先看一下bug的严重程度，是否影响当前版本的发布。然后呢再与产品经理进行确认，如果产品经理不予延期，那请根据情况进行激活与情况说明；如果确认可以延续的话，则做好记录，以及后续版本进行关注，不关闭这个bug，你延期的话，bug没处理完就不关闭。
三、Bug的跟踪管理-缺陷管理工具
常见的缺陷管理平台有很多，比如:
- 禅道(zentao)
- bugzilla
- bugfree
- readmine
- easybug
- Mantis
不管是开源的还是商业的缺陷管理工具，他们的本质都是一样的，他们都是用来管理bug的生命周期，我们掌握其中一款工具，其他的自然也就会了。
我们本期主要是介绍禅道的使用。
链接：禅道
下载和安装步骤官网：下载和安装
登录
修改密码
我们主要使用测试这一块
点击过来之后发现没有什么bug列表，那么此时就需要我们先添加产品。
什么所以产品？什么是项目？
一个产品包含多个项目。
比如我们的微信这个产品：他涵盖很多项目(有app端，还有pc端)，那么无论是app端还是pc端，这两个项目都属于同一个产品，微信。
项目和模块？
一个项目是有多个模块的，比如我们的图书管理系统，包有用户管理模块和图书管理模块等。
回到我们的禅道：禅道的核心逻辑是：产品 → 项目 → 需求 → 用例 → Bug，所有测试相关操作都必须依附于一个已存在的产品。没有产品，就无法创建任何测试相关的记录。
- 创建产品：点击页面中间的 + 添加产品 按钮，填写产品名称、代号、描述等信息，完成产品创建。
- 关联项目（可选）：创建产品后，可进一步创建项目并关联到该产品。
- 提交 Bug：产品创建完成后，回到 Bug 页面，就可以正常点击 "提 Bug" 按钮，选择对应的产品并填写 Bug 信息了。
Bug单包含哪些元素？
1、bug类型
- 代码错误
- 界面优化
- 设计缺陷等。
2、bug标题
编写规范：bug的功能模块[位置]+bug的操作+bug的结果。
比如：测试/提交bug这个地方，选择影响版本，出现无法选择的情况。
3、bug严重程度
数字越小，严重程度越高。
1是致命，2是严重，3是一般，4是是细微。
4、优先级
也是分为1234，数字越小，紧急程度越高。
一般由开发去选。
5、重现步骤
例如：
6、抄送给谁
7、附件
目的：更好的辅助开发确定问题及复现bug
提交的东西：辅助开发定位解决问题图片或日志文件。
如何填写bug单？
✅ 必填项（带 * 号）------ 必须填
1. 所属产品
- 保持默认：个人测试Demo（无需修改）
2. Bug标题（Title）
- 要求：一句话精准概括问题，不能模糊。
- 示例 ：
登录功能：输入正确密码点击登录，页面无响应图书列表：分页查询时，第2页数据显示错误
3. 重现步骤（复现步骤）
- 要求 ：按序号写清楚，让开发能100%复现问题。
- 格式 ：
- 操作步骤1
- 操作步骤2
- 操作步骤3
- 示例 ：
- 打开图书管理系统登录页
- 输入账号：
admin，密码：123456 - 点击「登录」按钮
4. 实际结果（Result）
- 要求 ：写清楚实际发生了什么错误。
- 示例 ：
点击登录后，页面没有任何跳转，停留在登录页，无提示信息分页第2页显示了第1页的数据，且数据条数不匹配
✅ 选填项（学习建议默认留空/选中等）
| 字段 | 建议填写/选择 | 说明 |
|---|---|---|
| 所属项目 | 留空 | 初学可先不关联具体项目 |
| 所属模块 | 留空 / / |
没有模块可直接选 / |
| 影响版本 | 创建发布 | 自动填充即可 |
| Bug类型 | 代码错误（默认） | 学习通用 |
| 严重程度 | 中 / 一般 | 不影响核心功能选"中" |
| 优先级 | 3 (中) | 数字越小越紧急，初学"3"即可 |
| 当前指派 | 留空 | 由负责人后续指派 |
📝 完整填写示例
- Bug标题 ：
登录功能：输入正确账号密码后，点击登录无响应 - 重现步骤 ：
- 访问系统登录页面
- 输入账号：
test，密码：123456 - 点击「登录」按钮
- 实际结果 ：
页面无任何反应，没有跳转到首页，也没有报错提示 - 预期结果 （可填可不填，填了更专业）：
输入正确账号密码后，应成功跳转到系统首页
补充描述
Bug的跟踪管理-提交bug的注意事项【重点】
发现bug后，接下来你提交到bug管理平台，提交一个bug包含哪些内容？
- bug标题 ：标题要清晰简洁，写明bug描述；如果没有选择功能模块，最好在标题中标注功能模块。让查看bug的人员清楚知道你所表达的意思。标题技巧：
bug的功能模块+bug的操作+bug的结果 - 重现步骤：详细写下发现bug的测试过程。能指导开发重现这个bug。附上测试数据
- 实际结果：出现bug的结果，粘贴bug截图、日志截图
- 预期结果：记得写清楚预期
- bug类型和严重程度：便于后续测试结果分析，bug的统计
- bug测试环境：例如：什么系统，哪个版本等。兼容性问题、难以重现问题
- 附件：日志文件，文件测试数据。图片、崩溃日志文件等
提交完之后注意随时跟踪我们的bug
四、测试计划介绍
回顾测试的流程：项目立项->测试需求分析->测试计划->测试设计->测试执行->测试评估->项目结束。
1、是什么测试计划
测试计划他就是对测试工作的统筹和安排的一份测试文档。
这个计划由谁来写：一般由测试组长或项目经理来写。
需要看测试计划的有哪些人：
- 测试成员
- 组长
- 开发
- 产品
- 销售推广人员
2、测试计划包含哪些内容？5W+1H
2.1测试的目的 Why
2.2测试的范围 What
2.3测试进度安排 When
- 测试计划 -- 1天
- 测试需求分析
- 用例设计
- 测试执行
- 测试报告--1天或半天
时间：
1. 测试需求分析和用例设计的时间比例是3:4。
-
需求分析+测试用例设计与测试执行的时间比例接近1:1。 -
我们的组长在写测试计划的时候，我们在做测试需求分析，他两个可以算是同时做的
举个例子:
我们两周发布一个版本(有双休)：
- 测试计划 -- 1天(测试组长负责)
- 测试需求分析-2天
- 用例设计-3天
- 测试执行-[第二周]，分多轮进行测试执行时间比例是4:3:1：
- 第一轮---1天半
- 第二轮---2天半
- 第三轮---半天
- 测试报告--0.5天
2.4测试人员安排 Who
2.5测试的环境 Where
- 硬件环境
- 软件环境
2.6测试的方法 How
2.7风险的评估
3、测试计划编写
根据测试计划模板来进行编写
4、测试方案
测试方案是独立一份文档，有些测试方案合并在测试计划中。【测试方案如何写，我们下一期博客中再谈】
老铁们，如果你觉得这篇文章对你有帮助，别忘了👍点赞⭐ 收藏👀 关注，🦀🦀各位老铁的支持~~