bug管理流程：多名测试人员发现bug提交bug，给至测试经理进行规范审核，测试经理审核不通过则让测试重新提单，审核通过查看提交的bug 与已有bug重复则关闭，如不重复给至开发经理分配给具体的开发人员，根据项目的功能和项目的进度。开发及时修复bug（按照bug的严重程度，bug级别程度越高，优先进行处理）或延迟处理，待开发修复好bug 提交给测试经理分配给具体的测试人员或直接给到bug的提交人（发起人）进行回归测试，回归测试通过，则关闭bug，回归测试不通过，则重新提交bug给开发进行修复。（回归测试不通过，就重新提单，继续按流程走）
禅道是 bug 和用例、项目管理工具
提单：测试人员把发现的bug提交到bug管理工具
规范审核：TPM将TE提交的bug进行规范审核，bug内容是否表达准确。
仲裁：一般来说公司有话语权的老大（测试经理）对开发和测试这间关于bug的问题进行处理
注意：在公司发现bug一定要提单，不然后面出了和bug相关问题的生产问题，将由测试人员承担。
(禅道系统:3.0 运行比较快,图标是蓝色,比较贵, 2.0 的图标没有颜色,运行比较慢,比较便宜)
暂不处理的bug:
(需要把暂不处理的bug列成bug清单，经过测试经理审批同意方可留到下个版本修复。一般是通过把这个bug清单发邮件给到测试经理。
bug管理工具： QC JIRA bugfree(这三个要了解）
禅道是 bug 和用例、项目管理工具
发布人一般是测试经理
每个公司对用例的字段要求不一样，一般是八大要求 有的是不要 结果，要 创建人
用例编号 所属模块 用例标题 前置条件 步骤 预期 优先级 结果
导出数据： 文件名 csv cbk格式 选中记录 导出 在设置里选择，也可以自己创建 模版
查找导出文件路径 C:\Users\Administrator\Downloads
阴塞的情况：是因为测试环境影响，（后端一些配置还没有上线-后端服务器没有开（后端没有电了））导致无法执行下一个流程。 因为服务器没有开，属于外界因素，跟功能没有关系 ，不属于
bug.
禅道重现步骤
组织：部门-添加下级部门、用户-添加产品经理，项目经理，开发测试经理，测试和开发
产品：产品-添加产品、模块-维护子模块、计划-创建计划、需求-提需求（不评审）
项目：项目-添加项目、团队-团队管理、版本-创建版本、任务-建任务、需求-关联需求
测试：版本-提交测试、用例-导出模板上传用例、bug -提交bug（在设置里选择，可以创建模版）-导入用例-五项下拉选择框逐条选择后会出现下图选择字样，选择全部插入-保存-点击、执行（三角符号）-每个用例步骤一步一步选择通过或失败-小虫子--选择失败的一项--保存--填写弹出的页面，输入要抄送邮件的人-保存的同时信件已发出--最后在执行结果里选择通过
后台：后台-发信配置邮件发送（要在后台-发信那里输入smtp密码。下列第4步有讲 ，配置一次，以后每次提bug时保存即同时发邮件了）
提单时bug标注题尽量多写
Apache ：Apache是世界使用排名第一的Web(网页）服务器软件
一、禅道的使用：
1、定义：一款bug和用例、项目管理工具
2、安装
安装路径不能是中文
安装后打开选择"开源版"
默认账户 admin ，密码 123456
安装后若桌面没有快捷，到安装目录中找即可、或者把整个安装之后的目录移动
到桌面即可。
XAMPP介绍：XAMPP（Apache+MySQL+PHP+PERL）是一个功能强大的建
站集成软件包 双击启动禅道之后：把http://127.0.0.1/index.php 网址输入到
浏览器即可。
Apache ：Apache是世界使用排名第一的Web服务器软件。
MySQL：MySQL是最流行关系型数据库管理系统之一，目前属于oracle旗下产
品。
PHP：中文名：“超文本预处理器”）是一种通用开源脚本语言、PHP是将程序
嵌入到。HTML：（标准通用标记语言下的一个应用）文档中去执行。
Perl：一种功能丰富的计算机程序语言。
先配置发送邮件
一般企业都用自己的QQ，如果是QQ邮箱 邮箱-设置-账户-开启以下第二个-按要求发送短信-生成授权码 -将16位授权码填入禅道的 后台-发信-smtp里
1、市面上有哪些常用的bug管理工具？各有什么特点？
QC(Quality Center)
是原Mercury Interactive公司(现已被HP收购)生产的企业级基于WEB测试管理工具，需要安装配置IIS和数据库，系统资源消耗比较大；功能很强大，结合有BUG管理，需求管理及用例管理等功能；和其它的测试工具，比如Loardrunner测试工具的接口做得比较好，数据可以在它们中共享；英文版的且易用性不是很好，最重要的是收费且价格不扉；版的网上也很多但找起来和也比较费事，且性能就不那么稳定。
资源地址：Http://www.hp.com
a、 BugzillaBugzilla是由Mozilla公司提供的基于Web方式，免费的开源的一款功能强大的Bug管理系统，比如强大的检索功能，强大的后端数据库支 持, 丰富多样的配置设定等；安装需要Perl和配置MYSQL数据库，过程比较繁琐，修改配置文件比较麻烦；英文版的，能汉化但是汉化后容易出现乱 码； 资源地址：http://www.bugzilla.org
b、BugFree 基于WEB的，配置安装简单，只需到网上获取安装包，再配下PHP通用的环境即可；纯功能型的界面就无所谓美观；没有直接的截图功能但是可以以附件的形式存在；也有简单的报表统计功能；整体使用还是比较容易上手，而且是开源免费中文版的BUG管理系统。资源地址：http://www.bugfree.org.cn
c、 EasyBUG基于WEB的在线的，不用配置；界面很漂亮，操作容易上手，基本上只要是会上网的人一看就会用；区别其它工具且最实用的一点是截图功能强大，且是以图片的 形式直接存在，而不是以附件的形式存在；BUG解决流程也有记录在案；丰富的统计报表，一目了然；是国产的，有中英文版的而且免费的。资源地址：http://www.EasyBug.net
d、 Mantis一款基于Web的Php+Mysql的开源BUG管理系统，一款简单实用的系统，也有截图功能，不过是以附件的形式存在，报表功能比较强大，需要配置才可用，是英文版的，不过可以通过汉化包和配置来汉化，有邮件支持但也需要修改配置。资源地址：http://www.mantisbt.org 之所以贴出来大家共享，是为了让和我们一样还在决定使用什么BUG管理系统或打算换BUG管理系统的人做个参考，经过亲身体验，要知道这绝不是个简单省力的活。
e、iClap：该产品具有的bug管理工具可同步pc，手机端的bug信息，并且对系统崩溃时的bug信息收集采集自动的存档，便于开发，测试人员工作。
另一方面来看，批注工具可有效提高团队内部人员对产品功能，界面的建议等信息的反馈，利于团队内部沟通，同时可针对某个问题建立讨论组展开实时讨论，最后不得不说的一点是，所有的操作都是在自家的app产品上进行的，方便，简洁，更高效 f、Bugout，不需要自己部署或者配置服务器，自动上报问题与管理
2、bug的级别有哪些？
L1 level(等级） 致命 如打开软件后，系统奔溃，黑屏，死机。
L2 严重 如：银行利息原本8% 写成1%
L3一般 如只能写中文，不能体现英文。
L4建议（易用性的bug如，按钮用的蓝色，开发出来用的为绿色）
3、一条bug具体包含哪些信息？
bug 的编号
bug 的标题
bug 的重现步骤
bug 的实际结果
预期结果
实际结果
bug 的严重程度
bug 的截图和附件
bug 的状态
bug属于哪个模块
bug 的错误类型 （如代码 数据库还是 ui (高保真图)）
bug的发起人
bug 的优先级
4、bug的状态有哪些？
BUG状态标准（主要有如下7个状态）
1、待处理（new）：
测试人员或用户发现新问题后提交的状态
2、已确认（open）：
经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。
3、已处理（fixed）：
经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。
4、关闭（closed）：
测试人员认为问题已经修改，通过验证，由测试人员设置。
5、重新打开（reopened）：
测试人员认为BUG未修复成功，问题仍然存在，由测试人员设置。
6、无效问题（reject）：
研发人员确认不是BUG，或者建议与意见决定不采纳。
7、暂不处理（hold）：
当前版本不做修改，后续版本再考虑，由研发人员或测试人员设置。。(需要把暂不处理的bug列成bug清单，经过测试经理审批同意方可留到下个版本修复。一般是通过把这个bug清单发邮件给到测试经理。
5、你现在用的bug管理工具是禅道，那么请你具体介绍禅道的组织和结构是什么？
分为两大结构:1、用例结构2、缺陷管理工具
6、你负责模块一共出现过多少个bug？你认为有意义的bug是什么？你是怎么找到的？然后这个bug你是怎么解决的？
7、在公司你是怎么定位和发现bug的？
根据测试方法编写的测试用例，根据用例去发现的bug
一.web前端的bug分析定位。
a 测试内容：页面布局、用户功能、易用性、兼容性
b 测试方法：模拟用户输入，在浏览器页面上进行输入、点 击等行为
c 定位之前需要思考的问题：是否是浏览器设置问题？是否是浏览器cache的问题？ 在其他浏览器上是否可复现？ 用其他数据是否可以复现？ 是否是cookie相关的问题？ 是否正确发出了请求？ 是否得到了正确的应答？ 是否是网络原因？ 是否是跨域问题？ 是否是程序版本的问题？
d 常见bug：浏览器兼容性，浏览器按钮操作，字符编码，页面跳转，跨域，性能
二.后台的bug分析定位
a 测试内容：逻辑流、数据流、策略、接口、性能
b 测试方法：输入条件构造，网络通信包（驱动、桩、真实的上下游模块），数据文件，配置文件（包括词表，黑白名单等），共享内存，输出检查，网络通信包，数据文件，日志（尤其是异常日志），监控：系统监控：cpu、句柄、IO、内存模块级监控：内存结构体信息，调试DEBUG，JPDA打断点
c 常见bug：自顶向下排查（从系统入口模块开始），是内部逻辑问题还是下游数据问题？是否是某些配置下发生的问题？日志中是否发现线索？系统资源情况中是否发现线索？是否是边界值、并发等问题？下游模块是否交互正常？是否是多线程下的问题？是否是大压力下的问题？是否是不同模块间接口的定义不一致？是否和服务器软件版本及设置有关？自底向上排查（从系统末端模块开始），最底层的模块是否正常收到了请求？是内部逻辑问题还是上游请求问题
怎样找到bug
、熟悉你做的产品
不管你是Dev、Test或者PM，熟悉自己开发的产品越多越好，你不但应该熟悉自己开发的模块，也应改熟悉和自己模块相关的其他模块，他们之间是怎样协作的。比如数据库中的某个字段，是如何被各个模块使用的，这利于你在设计阶段就能够找到Bug，把修复的成本降到最低。
同样，你需要熟悉这个产品以前的版本，因为无法向后兼容和升级的产品恐怕很难获得用户的认可。在测试过程中，如果你发现你的产品和以前不兼容或者不一致，80％的情况，这是一个Bug。
b、尽早的去发现Bug
我们大家都知道，Bug修复的成本是和Bug被找到的时间成指数关系的。越早开始找Bug，你能找到的Bug也就越多，对项目的贡献也就越大。
c、每天Review别人的Bug
如果你的团队没有每日的Bug Report，我建议你们建立一个，其实技术上应该没有任何的难度，通过Bug追踪系统的API或者数据库，你完全可以得到你要的数据，这样，整个团队通过学习每天察看别人的Bug，你可以更加容易发现Bug，也不会发现那种Duplicated Bug。现在经常有人跑过来问我，某个Bug是不是一个已知的问题，因为我每天都看Bug Report。
d、在你的日常生活中多准备一些测试的模式
模式是一个很时髦的词，因为它很有用。在日常的测试中，多准备一些测试模式，你会有非常大的惊喜，有时候一个使用一个模式，你可以找到10来个Bug也不是不可能的。比如，使用特殊字符作输入数据；断开网络看UI是否会Crash；在本地化版本中，各个字符串提示是否被本地化；
e、多测试各个模块之间的合作
各个模块之间的测试往往是我们测试中的薄弱点，对于用户来说模块间的合作却至关重要。往往一个数据在模块A中是合法的，在B中却是非法的，一定要找出这些数据，往往者都是Bug
f、编写自动测试代码
你肯定不原意每天都去做同样的事情，那样太没有意思了，简直就是对你的智慧的侮辱。但是一旦我们不进行这些测试，突然有一天早上，我们发现我们的产品以前能够很好工作的功能突然就不工作了，于是大家乱作一团，有人急着修复它，有人在找是谁Check in的。
g、查看产品代码
通过查看产品代码，你往往能找到一些Dead Code或者逻辑上的Bug，这些Bug常常是你无法通过手工测试找到的
多测师社区 
