1、bug定义软件的bug，狭义的概念是指软件程序的漏洞或缺陷
广义的概念除此之外，还包括测试工程师和用户发现并提出的软件可改善的详细情况(扩展性、建议性)，以及与需求文档不同的功能实现等。
我们的作用是发现这些bug，并将其提交给开发人员，以便开发人员可以进行修复。
2、bug类型确定一个bug的类型需要对项目(或产品)有深刻的理解。 这种划分对开发定位问题影响不大，但对问题类型的统计很重要。 -测试报告
常见错误类型分类(以禅道系统为例，可定制) :
代码功能(错误)最多、最常见的错误
界面优化— U|测试，易用性兼容性
设计缺陷-修改不符合用户习惯的设计-满足用户需求==建议性错误
按照公司的具体规定分类！
3、bug级别-优先级如何判断bug级别(严重程度)，可参考以下判断条件：
(1)致命错误：
1 .正常操作导致系统崩溃、死机、死循环、闪回
2、可能导致数据泄露的安全问题，如恶意攻击泄露帐户隐私信息
3 .涉及金钱计算
4、断路性测试，所有测试都无法进行(冒烟测试) ) ) ) ) ) ) ) ) ) ) ) ) )。
5 .权限问题
(2)严重错误： — critical
1 .关键功能无法实现1
2、错误波及面广，影响其他重要功能的正常实现；
3 .非正常操作导致程序崩溃、死机、死循环、闪回
4、外观(界面)难以接受的缺陷
5、密码清晰显示；
6、少见致命臭虫
(3)一般错误：
不影响产品运行，不会导致故障，但会对产品外观和下一工序产生较大影响的缺陷
1 .次要功能不能正常实现
2、操作界面错误(包括数据窗口中列名定义、语义不一致-原因)；
3 .查询错误，数据错误显示：
4、简单输入限制最后放在前端控制；
5、删除操作无提示；
6、罕见的严重臭虫
(4)细微错误： — minor
程序与一些表示无关，是不符合用户习惯或者是一些文字错误的用户体验
1、接口不规范：
2、辅助说明说明不清晰；
3、提示窗口文字未采用行业术语；
4 .界面有文字错误
(5)改进建议nhancement
提高产品质量的建议，包括改善新的需求和需求。 -在此版本中不进行修改，而是在下一个版本中进行修改
4、错误生命周期(管理流程) -重点！ 错误的生命周期是指发现错误并关闭该错误的过程。
这个过程有哪些步骤？
生命周期中-常见缺陷状态：发现-新建-错误-分配-E解决-未验证-关闭。 正常
如果验证中的错误未解决，则必须重复“重新打开”“启用”“分配”“已解决”“等待验证”流程。
其他状态：拒绝、延期等
3358www.Sina.com/-验证错误：是否存在操作问题。 环境问题提交错误错误管理工具
** 1.发现bug开发/开发博斯测试-开发
2.指派bug:他人曾驾驶过公司尽量避免(浪费时间) :确认有添加重复bug id (开发额外的bug )的错误确认中：是否存在重复(发表评论)
3.重复bug-- duplicated) -这可能是由于操作问题、环境问题或对产品的错误理解造成的。 绝对必须避免。 -充分了解产品并确认后再现-不是bug -备注美闭； 依然是个臭虫。 添加注释，重新激活开发修复： --。 我认为开发不是臭虫。 我该怎么办？ ”无法理解需求处理步骤： 1 1.列举需求文档中的证据2 .站在用户的角度——说服用户修复错误的证据3 .确认产品，项目经理——是开发修复：否——添加注释=责任分类：
4.不是缺陷： invalid (无效: 1)测试中发现错误，不可开发的再现(a )检查测试环境是否仍然可再现，帮助开发不可再现的： b )测试环境不可再现(偶然)多个版本的连续5 )版本)签出(做了)做了哪些事情偶现bug=偶现率(3/10 ) -影响开发修复bug的优先级；
3358www.Sina.com/(1)水平不高的小错误2 )建议的错误I处理方式： 1)站在用户的立场上列举证据。 没有开发修理的成果： 2 )说服产品项目经理确认=如果结果被记录在错误中，则进行评论
5.无法重现unreproduced
太高|测试确认: 1)确认bug的严重级别，会不会影响用户使用- -定修复，版本延后发布，加班修复2) 如果不是特别影响用户，真的修复成本，风险太高-可以不惨==产品和项目经理确认–风险+情况说明= =决定–备注里再bug8.修复之后(resolved-fixed) 开发一>测试 :验证bug: 1)拿到正确的版本验证bug (包含了开发修复代码的版本) 2)确认bug跟你之前开bug 的步骤是一致–验证关闭:一扩展新的为难题-开成给一个新的bug = =回归测试
9.没有修好：同样的步骤，还存在= 重新打开–reopened
10、修复好了- verifed :关闭dosed 5、bug的跟踪管理-状态处理
1.已经指派的bug–已经指派给开发的，请大家注意自己bug的走向，随时关注并进行跟踪!如果一直未修复，提醒开发修改,以免开发忘记;如果已经修复等待测试环境更新后进行验证。催着改bug
2.已解决的bug-等待测试环境更新后进行验证，验证通过则关闭;验证不通过则重新打开指派给开发
3.重复bug–先去查看下是否跟开发指定的bug重复?如果确定是重复则关闭;如果不重复，说明原因,重新打开指派给开发,
4.不是缺陷–再次依据需求确认，是否是bug,如果依然觉得是缺陷跟开发沟通，列举出来觉得是bug的点，沟通未达一致找产品确认，确认是bug注明情况并再次指派给开发，产品确认不是bug，就不纠结，直接关闭bug，但是，会拿小本本把这个bug记录下来,等到测试任务结束后，再来研究研究。
5.无法重现–确认开发环境是否跟测试环境一致? 包括操作步骤、浏览器、环境、特定账号、输入数据等如果多个版本验证之后，如开发所说重现不了，依据bug的严重程度跟产品、开发-起确认关闭;如果找到重现原因，注明清楚并再次指派给开发
6.不予解决-找产品经理进行确认。确认不予解决进行关闭;确认需要解决请备注原因并打开指派给开发
7.设计如此-找产品经理进行确认。确认设计如此进行关闭;确认是问题，备注原因重新指派给开发
8.延期修改–请看下bug严重程度,是否影响当前版本发布?与产品经理进行确认。不予延期请根据情况进行激活与情况说明;确认延期则做好记录，后续版本进行关注一不关闭
bug标题一标题要清晰简洁， 写明bug描述;如果没有选择功能模块，最好在标题中标注功能模块。让查看bug的人员清楚知道你所表达的意思。bug的功能模块 + bug的操作+ bug的结果
重现步骤一详细写 下发现bug的测试过程。能指导开发重现这个bug。附上测试数据
实际结果一出现bug的结果， 粘贴bug截图、日志截图
预期结果记得写清楚预期
bug类型和严重程度一便于后续测试结果分析, bug的统计
bug测试环境一例如: 什么系统，哪个版本等。兼容性问题、难以重现问题
附件一一日志文件, 文件测试数据。图片、崩溃日志文件等