软件缺陷的定义软件缺陷，通常又被叫做Bug或者defect,即为软件或程序中存在的某种破坏正常运行能力的问题、错误、其存在会导致软件产品在某种程度上不能满足用户的需求。 软件缺陷是指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题。
软件缺陷的表现形式1、软件未达到需求规格说明书标明的功能2、软件出现了需求规格说明书指明不会出现错误的地方3、软件的功能超出了需求规格说明书指明的范围4、软件出现了需求规格说明书虽未指明，而应该达到的目标5、软件测试人员认为软件难以理解，不易使用，运行速度慢，或者最终用户体验不好。具体表现形式如下: 1、 软件未达到需求规格说明书标明的功能
1、计算器说明书一般声称该计算器将准确无误地进行加、减、乘、除运算。2、如果测试人员或用户选定了两个数值后，随意按下了“+”号键，结果没有任何反应。
2、软件出现了需求规格说明书指明不会出现的错误 1、若在测试过程中发现，因为电池没电而导致了计算不正确。2、但软件需求规格说明书中明确指出在任何情况下都不允许出现计算不正确的情况出现。3、软件的功能超出了需求规格说明书指明的范围 1、若在进行测试时，发现除了规定的加、减、乘、除功能之外，还能够进行求平方根的运算，而这一功能并没有在说明书的功能中规定。4、软件未达到需求规格说明书虽未指明而应该达到的目标 1、假如计算器说明书指明计算器不会出现崩溃、死锁或者停止反应，而在用户随意按、敲键盘后，计算器崩溃了。5、 软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为不好 1、测试人员或最终用户发现计算器某些地方不好用，比如，按键太小、显示屏在亮光下无法看清等。软件缺陷产生的原因软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下： 1、需求解释、记录或者定义错误 2、设计文档说明存在错误或者拼写错误 3、编码说明、程序代码有误 4、硬件或者软件系统上存在错误
软件缺陷产生的根源需求的变化 需求说明书、设计文档、程序的变更
交流不充分 客户与开发人员、开发人员与测试人员等
软件的复杂性 功能复杂、开发复杂、测试复杂
开发人员的错误 对需求的理解、开发压力、能力与经验
进度压力 项目周期比较紧
软件缺陷的信息为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、
修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。
缺陷的状态测试人员新建缺陷，称之为“new”状态。
开发人员接收到缺陷后确认该缺陷，并且会打开，称之为“open”状态。
开发人员打开缺陷后进行修复的状态称之为“fixed”状态。
测试人员发现该缺陷已被开发人员修改，并且修改正确，会关闭该缺陷，称之为"closed"。
开发人员接收到测试人员新建的bug后,不认同该bug,可以拒绝修改，称之为“rejected”
开发人员接收到测试人员的bug后，如遇到临时有事的情况，可以延后修复，称之为“postpone”
缺陷的严重程度
缺陷的优先级
缺陷的分类
软件缺陷修复相关并不是所有的缺陷，开发人员都会进行修复
开发人员拒绝修改的缺陷 程序员无法重现或者现象难以捕捉 --- 缺陷详细描述
没有明确的报告以说明重现缺陷的步骤---缺陷报告
程序员无法读懂的缺陷报告 ---标题
由不受信任的测试人员提出---缺陷提交人
不是所有缺陷都会修改 市场的压力使得产品最终发行有时间限制
测试人员错误理解或者不正确操作引出的缺陷(FAQ)
错误的修改影响的模块较多，带来的风险较大(遗留)
修改性价比太低
缺陷报告中提出的问题很难重现
认识缺陷报告
1、 缺陷报告的重要性清晰准确的软件缺陷描述可以减少开发人员退回来的缺陷数量，可以节省开发人员和测试人员的时间。
提高软件缺陷修复的速度，使项目组能够有效地工作。
提高测试人员的可信任程度，可以得到开发人员对有效缺陷的及时响应。
加强开发人员、测试人员和管理人员的协同工作，让他们更好的工作
2、 缺陷报告的注意事项尽量确保缺陷可以重现 如果提交的缺陷无法重现，会影响开发人员的工作效率。
简洁、准确、完整 测试人员在提交缺陷报告时，要站在开发人员的角度上思考问题，要确保开发人员能迅速定位问题，而不会产生理解上的歧义。
一个缺陷一个报告
有的测试人员喜欢在一个缺陷报告里提交多个缺陷，这种习惯不提倡，原因有以下两点：
不便于分配。
比如缺陷报告有2个缺陷，分别属于不同的开发人员，到底该分配给谁呢？
不便于验证。
比如一个缺陷报告里面有2个缺陷，缺陷1已经解决，缺陷2还没有解决，那么这个缺陷报告该不该关闭呢？
3、 缺陷书写规范尽量按缺陷发生的原因与结果的方式书写；
避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状；
为了便于他人理解，避免使用俚语或过分具体的测试细节。
为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。常见问题：
包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解；
包含的信息过少，丢失了操作的必要步骤；
提供测试的环境信息；
简单地一步步引导复现该缺陷，一个步骤包含的操作不要多；
每个步骤前使用数字对步骤编号；
尽量使用短语或短句，避免复杂句型句式；
复现的步骤要完整、准确、简短；
将常见步骤合并为较少步骤；
按实际需要决定是否包含步骤执行后的结果。
实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。
缺陷症状的截图；
测试使用的数据文件;
选择合适的缺陷严重性属性；
按相应的规定，填写相应的字段信息
3、1 避免常见错误避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替
避免使用情绪化的语言和强调符号；
避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果；
避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息；
避免提交不确定的测试问题，自己至少需要重现一次再提交。
反面的示例：
上海人：哪能查询到的结果和查询条件不搭噶的。
北京人：哥们好不容易输入一堆个人详细信息后，点击保存后全瞎了
3、2 缺陷报告
3、3 缺陷处理流程
3、4 缺陷跟踪新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。此时就需要测试人员对缺陷进行回归测试，验证问题是否修复。 如果问题仍然存在，则测试人员将该缺陷的状态修改为重新打开； 如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如“该缺陷已解决”。 还有一种情况：开发人员认为缺陷在当前版本可以暂不修改，而考虑在后续版本中再做修正，缺陷的对应状态为延期。 对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意则延期，如果不同意，则重新打开缺陷。
3、5 缺陷统计
缺陷按引入源分布
3、6 缺陷数据分析1）缺陷数据分析关注的问题
2）缺陷数据分析的重要性
3）缺陷数据分析的数据指标
3、7 缺陷数据分析关注的问题正在测试的软件哪个模块的问题最多
测试人员中谁报告的软件缺陷最多
各类缺陷所占的数量百分比分别是多少
开发人员能及时修复软件缺陷吗
开发人员一次正确修复缺陷的百分比是多少
正在开发的软件能否在计划的时间内正常发布
|
