什么是软件质量
软件的质量就是软件的生命，为了保证软件的质量，人们在长期的开发过程中积累了许多经验并形成了许多行之有效的方法。但是借助这些方法，我们只能尽量减少软件中的错误和不足，却不能完全避免所有的错误。
如果把所开发出来的软件看作一个企业生产的产品，那么软件测试就相当于该企业的质量检测部分。简单地说，我们在编写完一段代码之后，检查其是否如我们所预期的那样运行，这个活动就可以看作是一种软件测试工作。新的测试理论、测试方法、测试技术手段在不断涌出，软件测试机构和组织也在迅速产生和发展，由此软件测试技术职业也同步完善和健全起来。
什么是软件缺陷
软件缺陷（Defect），常常又被叫做Bug。从产品内部看，缺陷
是软件产品开发或维护过程中存在的错误、毛病等各种问题；
从产品外部看，缺陷是系统所需要实现的某种功能的失效或违
背。在软件开发生命周期的后期，修复检测到的软件错误的成
本较高。
对于软件缺陷的准确定义，通常有以下5条描述：
（1）软件未实现产品说明书要求的功能。
（2）软件出现了产品说明书指明不会出现的错误。
（3）软件超出实现了产品说明书提到的功能。
（4）软件未实现产品说明书虽未明确指出但应该实现的目
标。
（5）软件难以理解，不易使用，运行缓慢或者终端用户认
为不好
缺陷的分类
1.缺陷（defect）产品设计与需求设计部符合
2.错误（error）没有定义的或者未知的错误信息
3.故障（fault）由于一些原因导致产品失效，重新启动调整后可以恢复用户使用
4.失效（failure）由于一些原因产品失效，无法自行恢复
bug管理的目的
1.保证每个缺陷都被修改
2.保证每个缺陷都被回归
3.缺陷的完整性和一致性
4.避免纠纷，降低沟通成本
缺陷管理的意义
1.提高工作效率（BUG分类，状态负责人）
2.记录唯一的缺陷信息，保证BUG完整一致（通过设置权限实现）
3.记录中间环节，是BUG可追溯
4.为测试报告提供数据
参与缺陷管理的角色
测试工程师：发现和回归BUG
测试经理：判断BUG的有效性
开发经理：分配BUG
开发工程师：修改BUG
评审：解决矛盾
缺陷报告的要点
发现了软件缺陷，需要记录下来，不但要记录结果，同时需要详细描述发现的步骤，以备程序员重现问题，并解决它。
要求报告写的清楚明了和准确。有时利用截屏技术把当时的情况保存成图片，可以达到一图胜千言的效果。
软件缺陷的种类
软件缺陷表现的形式有多种，不仅仅体现在功能的失效方面，还体现在其他方面。软件缺陷的主要类型有：
1、功能、特性没有实现或部分实现。
2、设计不合理，存在缺陷。
3、实际结果和预期结果不一致。
4、运行出错，包括运行中断、系统崩溃、界面混乱。
5、数据结果不正确、精度不够。
用户不能接受的其他问题，如存取时间过长、界面不美观。
缺陷来源
1.Requirement：由于需求的问题引起的缺陷(需求不完全或逻辑错误)
2.Architecture：由于构架的问题引起的缺陷（登录session失效）
3.Design：由于设计的问题引起的缺陷（图片大小，页面元素显示问题等
4.Code：由于编码的问题引起的缺陷
5.Test：由于测试的问题引起的缺陷（软件测试的设计与实施发生错误。特别是系统级的功能测试，要求复杂的测试环境和数据库支持，还需要对测试进行脚本编写。因此软件测试自身也可能发生错误。另外，如果测试人员对系统缺乏了解，或对规格说明书做了错误的解释，也会发生许多错误。）
6.Integration：由于集成的问题引起的缺陷
缺陷分析主要参数
状态：缺陷的当前状态（打开的、正在修复或关闭的等）。
优先级：必须处理和解决缺陷的相对重要性。
严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。
起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件
缺陷状态
1.New：测试人员提交Bug
2.Open：确认“提交的Bug”等待处理
3.Assigned：相关人员分配Bug
4.Fixed：缺陷被修复
5.Closed：确认缺陷被修复，关闭缺陷
6.Reopen：缺陷被修复后，重新开启
7.Reject：Bug描述不清晰，被拒绝
8.Invalid：确认不是Bug，无需修复
9.Later：可以以后修改，但要明确日期
10.Postpone：延迟修改，未明确日期
11.Wontfix：被发现的Bug无法修改
12.Duplicate：重复的Bug
13.Abandon：被reject，invalid，duplicate后的Bug经测试人员确认没有问题，修改为该状态
14.Renew：被reject，invalid，duplicate后的Bug经测试人员确认Bug有效，修改为该状态
15.Typical：多次出现，具有代表性，可以提醒其他人注意
16.Remind：由于功能的变动，Bug无法验证，修改为此状态
缺陷优先级
按优先级别分类：P1----P5(同意 BUG可能会变)
缺陷的严重性分类
blocker阻碍的（不修改该BUG之后的开发测试无法执行）
Critical崩溃（系统部能用）
major严重的（严重影响功能使用流程）
anormal一般的（不会影响主要的功能流程）
minor轻微的（不会2影响业务流程也不影响使用）
trvival界面的
suggestion建议（可用性，易用性，侧重用户体验）
缺陷管理流程图
测试工程师（2个）
New
Fixed->Reopen
Fixed->Closed
测试经理（1个）
New->Open
New->Abandon
开发工程师（2个）
Open->Fixed
Reopen->Fixed
Assign->Fixed
开发经理（1个）
Open->Postpone
Postpone->Assign
Open->Assign
缺陷分析报告
1、可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；
2、也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。
3、这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据
BUG单写作准则（5C）
correct(准确)每个组成部分的描述准确，不会引起误解
clear(清晰)每个组成部分的描述清晰，易于理解
concise(简洁)只包含必不可少的信息，不包括任何多余的内容
complete(完整) 包含复现改缺陷的完整步骤和其他本质信息
consistent(一致)按照一致的格式书写全部缺陷报告
BUG描述的注意事项
1一定可以重现的BUG可以不写“重复几次操作，出现几次，我认为，标题里不能写步骤，不能用主观的话描述，我在。。。。的，不确定语句：某些好像，禁止使用”之后”，然后之类的语句”之类的话
2需求规格说明书以外的错误可以当建议报告，不当BUG报告，开发可以改，也可以不改
3若是随机出现的BUG，要写出操作几次，出现几次
4若被测软件是跨平台软件，要写上在其他平台下无误
5禁止写冗余的操作的步骤。常识性的步骤不用写进缺陷操作步骤
6写明环境数据，如何选择数据，数据如何被破坏
写在最后
如果对python自动化测试、web自动化、接口自动化、移动端自动化、面试经验交流等等感兴趣的测试人，可以关注微信公众号：【程序员二黑】，获取软件测试工程师大厂面试资料！我的学习交流群： 785128166 群里有技术大牛一起交流分享~
如果文章对你有感兴趣，麻烦伸出发财小手点个赞，感谢您的支持，你的点赞是我持续更新的动力。