① 软件缺陷的管理指南
缺陷管理的第一步是了解缺陷，为此，必须首先收集缺陷数据，然后才能了解这些缺陷，并且找出如何预防它们，同时也能领会到如何更好地发现，修复甚至预防仍在引入的缺陷。可以按照以下步骤收集关于缺陷的数据：
1.为测试和同行评审中发现的每一个缺陷做一个记录
2.对每个缺陷要记录足够详细的信息，以便以后能更好地了解这个缺陷
3.分析这些数据以找出主要哪些缺陷类型引起大部分的问题
4.设计出发现和修复这些缺陷的方法（缺陷排除）
通常为了收集缺陷数据，可以采用缺陷记录日志来登记所发现的每一个缺陷。
对于缺陷记录日志中的描述应该足够清楚，以便今后可以看出该缺陷的起因。修复缺陷一栏说明此缺陷是由于修复其他缺陷而引入的。引入阶级表示该缺陷的来源。
② 软件缺陷怎么描述
认识软件缺陷，首先要了解软件缺陷的概念，其次是了解软件缺陷的详细特征，最后就是它的属性了，再高一个层次就是学习利用管理软件缺陷的工具了。 1、首先介绍软件缺陷的概念
软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。 2、软件缺陷的详细特征 a、单一准确
b、可以再现（要求软件缺陷具有精确的步骤） c、完整统一 d、短小简练 e、特定条件 f、补充完整 g、不做评价
3、软件缺陷的属性
软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。 下面详细介绍一下以上这些属性：
a、缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示； b、缺陷类型：功能、用户界面、文档、软件包、性能、系统\模块接口 功能：影响了各种系统功能、逻辑的缺陷；
用户界面：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷；
文档：影响发布和维护，包括注释、用户手册、设计文档； 软件包：由于软件配置库、变更管理或版本控制引起的错误；
性能：不满足系统可测量的属性值，如执行时间、事务处理速率等； 系统\模块接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。
c、缺陷严重程度：致命（Fatal）、严重（Ceritical）、一般（Major）、较小（Minor）
致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危机人身安全； 严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；
一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题；
较小：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题 d、缺陷产生可能性：总是、通常、有时、很少
总是：总是产生这个软件缺陷，其产生的频率是100%；
通常：按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80%—90%；
有时：按照测试用例，有时候产生这个软件缺陷，其产生的频率大概是30%—50%；
③ 软件缺陷的步骤
为了有效地再现软件缺陷，除了按照软件缺陷的有效描述规则来描述软件缺陷，还要遵循软件缺陷分离和再现的方法，虽然有时少数几个缺陷很难再现、或者根本无法再现.
1.确保所有的步骤都被记录。记录下所做的每一件事、每一个步骤、每一个停顿。无意间丢失一个步骤或者增加一个多余步骤，可能导致无法再现软件缺陷。在尝试运行测试用例时，可以利用录制工具确切地记录执行步骤。所有的目标是确保导致软件缺陷所需的全部细节是可见的。
2.特定条件和时间。软件缺陷仅在特定时刻出现吗？软件缺陷在特定条件下产生吗？产生软件缺陷是网络忙吗？在较差和较好的硬件设备上运行测试用例会有不同的结果吗？
3. 压力和负荷、内存和数据溢出相关的边界条件。执行某个测试町能导致产生缺陷的数据被覆盖，而只有在试图使用浚数据时才会再现。在重启计算机后软件缺陷消失，当执行其他测试之后又出现这类软件缺陷，需要注意某些软件缺陷可能是在无意中产生的。
4.考虑资源依赖性包括内存、嘲络和硬件共享的相互作用等。软件缺陷是否仅在运行其他软件并与其他硬件通信的“繁忙”系统上出现？软件缺陷可能最终证实跟硬件资源、网络资源有相互的作用，审视这些影响有利于分离和再现软件缺陷。
5.不能忽视硬件。与软件不同，硬件Hi按预定方式工作。板卡松动、内存条损坏或者cPU过热都可能导致像是软件缺陷的失败。设法在不同硬件卜再现软件缺陷。在执行配置或者兼容性测试时特别重要。判定软件缺陷是在一个系统上还是在多个系统l产生。
开发人员有时可以根据相对简单的错误信息就能找出问题所在。因为开发人员熟悉代码，因此看到症状、测试用例步骤和分离问题的过程时。可能得到查找软件缺陷的线索。一个软件缺陷的分离和再现有时需要小组的共同努力。如果软件测试人员尽最大努力分离软件缺陷，也无法表达准确的再现步骤，那么仍然需要记录和报告软件缺陷。
④ 软件缺陷的有效管理
本文首发于【 林子的空间 】
“这次发布之前怎么这么多的缺陷，是不是需要分析一下啊？”
答案是肯定的，可是这个时候才想起要分析已经有点晚了，有可能这些缺陷很难分析了。这是发生过的一个真实场景，所记录的缺陷包含信息很有限，很难有效的做好分析！本文就来聊聊如何有效的管理和分析缺陷。
缺陷是一项非常有价值的资产，软件缺陷的管理分为两个部分：缺陷信息收集和缺陷分析。
无效的缺陷记录
信息繁冗
有的项目团队要求详细记录缺陷的多个维度信息，而且大部分都是必填字段，比如详细的重现步骤，对于有些特别简单的缺陷来讲是没必要的，关键是信息能够说明缺陷即可，过分详细的要求会带来更大的浪费。
曾经有个项目是在QC(Quality Center)里记录缺陷，需要填写很多必填属性字段，没有办法灵活根据具体缺陷调整，加上QC服务器在国外，访问速度非常的慢，每次记录缺陷成为了大家极其痛苦的一件事情。
信息缺失
也有的项目对缺陷的格式和属性没有严格要求，记录的时候很简单也很自由，这样记录的缺陷由于很多必要信息的缺失，对后续的跟踪和分析也是极为不利。
比如前面提到的在QC里记录缺陷的那个项目，由于太痛了，很多时候，QA发现了缺陷也不愿意往QC里填，而是直接写个纸条简单记录下，验证完了它的生命周期就结束了，这样后面就没办法去很好的跟踪和分析了。（题外话：当时采用脚本往QC里记录缺陷，稍微减轻了点痛苦。）
无效信息
还有一种情况就是记录缺陷时同样有一些属性要求填写，但是这些属性值可能不是那么有意义，导致存储的信息不仅没用，反而添加混乱，也是不利于跟踪和分析的。
比如，其中的“根因（root cause）”属性的值如下表所示，这些值根本就不是根因，这是一个没有意义的捣乱属性。
缺陷信息收集的正确做法
缺陷信息收集应该做到尽量简单，且包含必要的信息。
- 标题：言简意赅，总结性的语句描述是什么缺陷
- 详情：包括重现步骤、实际行为、期望结果等，根据具体情况确定其详细程度，必要时可以添加截图、日志信息等附加说明。
- 重要属性：优先级、严重性、所属功能模块/产品、平台（OS、Web浏览器、移动设备的不同型号等）、环境、根因等，这些属性对应的值需要根据不同项目的情况自己定义，其中“根因”是相当关键的一个属性，后面有示例可以参考该属性对应的值有哪些。
- 其他：每个项目对应的还会有其他信息需要记录的，自行定义就好。
缺陷报告时机
在敏捷开发环境中，测试人员可能随时在测试、随时都会发现缺陷，包括还在开发手里没有完成的功能。什么时候发现的缺陷需要记录呢？通常情况下，有以下几种情况：
- 开发还没完成的用户故事（story），测试人员发现缺陷只需要告诉开发修了，在该故事验收的时候一起检查就好了，无需单独记录；
- 在开发已经完成，交到测试人员手里正式测试的故事，再发现缺陷就需要记录来跟踪了；
- 后续的所有阶段发现的缺陷都需要记录。
比较推荐的一种缺陷分析方法是鱼骨图分析法，可以将跟缺陷相关的各个因素填写到鱼骨图里，对缺陷进行分析，如下图2示：
缺陷相关的各属性拿到了，就可以用表格、曲线图、饼图等统计各个属性对应的缺陷数量，分析缺陷的趋势和原因。下面是我在项目上做过的分析报告图：
分析完得到统计的结果就要采取对应的措施，从而防范更多的缺陷产生。比如：
- 修缺陷（上面示例中的“bug fixing”）引入的新缺陷比较多，可以在修复缺陷后添加对应的自动化测试；
- 浏览器兼容性问题相关的缺陷较多的话，可以在开发完成验收的时候在各个主流浏览器上验收等等。
什么时候该进行缺陷的分析也是需要搞清楚的一个问题。通常，推荐每个迭代周期分析一次，并且跟以往各个迭代进行对比，进行趋势对比。当然，有时候可能一个迭代发现的缺陷非常少，分析的周期可以适当延长，两个迭代合并分析一次也是可以的。还可能某个迭代突发紧急缺陷，那就可能需要立马分析。
缺陷记录是为更好的跟踪和分析缺陷做准备的，而缺陷分析是软件质量保证的重要环节，对于软件过程的改进，软件产品的发布来说具有十分重要的参考价值，建议各项目都把缺陷分析作为常规实践开展起来。
缺陷记录是为更好的跟踪和分析缺陷做准备的，而缺陷分析是软件质量保证的重要环节，对于软件过程的改进，软件产品的发布来说具有十分重要的参考价值，建议各项目定期都要做做缺陷分析。
⑤ 软件测试中针对缺陷采取怎么样的管理流程
简单的概括如下:
1. 找到缺陷后, 记录缺陷的各方面信息(如:日志, 图片, 测试步骤, 是否能重复等等).
2. 提交缺陷报告.
3. 跟踪这个缺陷, 看其何时修复.
4. 当缺陷修复后, 再对其进行测试. 并对因这个缺陷而受影响的其它功能进行测试.(如果没有就不测)
5. 如果这个缺陷测试通过, 关闭这个缺陷报告.
如果没有通过, 则再次指回修复缺陷人员, 重新修复. (以此循环, 直到缺陷修复或者其它结论)
⑥ 软件缺陷的处理流程
软件缺陷，这个时候需要及时的进行修复。
开启软件的设备流程，打开软件里进行软件的数据进行排查之后，就可以修复正常的操作。
⑦ 软件测试中如何处理缺陷，有哪些方法
首先判断是否是缺陷，若是缺陷，就记录下来并提交给开发人员修复，修复好了之后，再验证啊
⑧ 电脑软件工作缺陷怎么接收
电脑软件工作缺陷在新信息（New)新报告的软件缺陷进行接收。
打开（Open）：分配给相关开发人员处理：
修正（Fixed）：开发人员己完成修正，等待测试人员验证；
按设计（ByDesign)：开发人员按设计说明书设计的：
重新打开（Reopen)：旧缺陷在新的版本中出现，重新打开缺陷：
关闭(Closed）：错误已被修复：
备注：如果需要也可以添加Duplicate（重复的）、notrepro(不可重现）等状态。
⑨ 你发现了一个软件缺陷,但开发人员认为不是,就是不改程序,你如何处理
不知道你是软件的客户还是测试人员
如果是客户：一般来说你们是专业的，因为只有你们最了解需求，
所以不管软件是对还是错，只要你认为需求与软件不合理，你就是对的，尽管你的需求也许是错的或者不是最便捷的
如果是测试人员：大多数软件公司的测试人员与开发部都不是很和善。。。这点我想大家都清楚原因，如果因此遇到矛盾，错误是必须要改的，而需求的不定性你们也决定不了，从A点到B点的方式很多，每个人的理解也不一样，解决的办法就是找到使用软件的客户，他们有决定权，因为他们是上帝(至少针对你的老总)
好啦 打这么多 只是给你点解决问题的建议