软件缺陷的优先级

严重性和优先级是表征软件测试缺陷的两个重要因素，它影响软件缺陷的统计结果和修正缺陷的优先顺序，特别在软件测试的后期，将影响软件是否能够按期发布与否。

对于软件测试初学者而言，或者没有软件开发经验的测试工程师，对于这两个概念的理解，对于它们的作用和处理方式往往理解的不彻底，实际测试工作中不能正确表示缺陷的严重性和优先级。

这将影响软件缺陷报告的质量，不利于尽早处理严重的软件缺陷，可能影响软件缺陷的处理时机。

什么是缺陷的严重性和优先级严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。

在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。

优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。

缺陷的严重性和优先级的关系缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。

它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

一般地，严重性程度高的软件缺陷具有较高的优先级。

严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。

但是，严重性和优先级并不总是一一对应。

有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

修正软件缺陷不是一件纯技术问题，有时需要综合考虑市场发布和质量风险等问题。

例如，如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。

另外，如果修正一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多潜在的缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。

另一方面，如果软件缺陷的严重性很低，例如，界面单词拼写错误，但是如果是软件名称或公司名称的拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。

处理缺陷的严重性和优先级的常见错误正确处理缺陷的严重性和优先级不是件非常容易的事情，对于经验不是很丰富的测试和开发人员而言，经常犯的错误有以下几种情形：第一，将比较轻微的缺陷报告成较高级别的缺陷和高优先级，夸大缺陷的严重程度，经常给人“狼来了”的错觉，将影响软件质量的正确评估，也耗费开发人员辨别和处理缺陷的时间。

第二，将很严重的缺陷报告成轻微缺陷和低优先级，这样可能掩盖了很多严重的缺陷。

如果在项目发布前，发现还有很多由于不正确分配优先级造成的严重缺陷，将需要投入很多人力和时间进行修正，影响软件的正常发布。

或者这些严重的缺陷成了“漏网之鱼”，随软件一起发布出去，影响软件的质量和用户的使用信心。

因此，正确处理和区分缺陷的严重性和优先级，是软件测试人员和开发人员，以及全体项目组人员的一件大事。

处理严重性和优先级，既是一种经验技术，也是保证软件质量的重要环节，应该引起足够的重视。

如何表示缺陷的严重性和优先级缺陷的严重性和优先级通常按照级别划分，各个公司和不同项目的具体表示方式有所不同。

为了尽量准确的表示缺陷信息，通常将缺陷的严重性和优先级分成4级。

如果分级超过4级，则造成分类和判断尺度的复杂程度，而少于4级，精确性有时不能保证。

具体的表示方法机可以使用数字表示，也可以使用文字表示，还可以数字和文字综合表示。

使用数字表示通常按照从高到底或从低到高的顺序，需要软件测试前达成一致。

例如，使用数字1,2,3,4分别表示轻微、一般、较严重和非常严重的严重性。

对于优先级而言，1,2,3,4可以分标表示低优先级、一般、较高优先级和最高优先级。

如何确定缺陷的严重性和优先级通常由软件测试人员确定缺陷的严重性，由软件开发人员确定优先级较为适当。

但是，实际测试中，通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。

确定缺陷的严重性和优先级要全面了解和深刻体会缺陷的特征，从用户和开发人员以及市场的因素综合考虑。

通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。

对于缺陷的严重性，如果分为4级，则可以参考下面的方法确定：1 – 非常严重的缺陷，例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。

2 – 较严重的缺陷，例如，软件的某个菜单不起作用或者产生错误的结果； 3 - 软件一般缺陷，例如，本地化软件的某些字符没有翻译或者翻译不准确； 4 -软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等；对于缺陷的优先性，如果分为4级，则可以参考下面的方法确定：1 –最高优先级，例如，...

软件测试中为什么缺陷越早发现越好？

1.缺陷标识(Identifier)： 缺陷标识是标记某个缺陷的一组符号。

每个缺陷必须有一个唯一的标识。

2.缺陷类型 (Type)： 缺陷类型是根据缺陷的自然属性划分的缺陷种类。

3.缺陷严重程度 (Severity) ：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。

4.缺陷优先级(Priority)： 缺陷的优先级指缺陷必须被修复的紧急程度。

5.缺陷状态(Status) ：缺陷状态指缺陷通过一个跟踪修复过程的进展情况。

6.缺陷起源(Origin) ：缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。

7.缺陷来源(Source)： 缺陷来源指引起缺陷的起因。

8.缺陷根源(Root Cause)： 缺陷根源指发生错误的根本因素。

F- Function ：影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。

并且设计文档需要正式的变更。

如逻辑，指针，循环，递归，功能等缺陷。

A- Assignment： 需要修改少量代码，如初始化或控制块。

如声明、重复命名，范围、限定等缺陷。

I- Interface： 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。

C- Checking： 提示的错误信息，不适当的数据验证等缺陷。

B Build/package/merge ：由于配置库、变更管理或版本控制引起的错误。

D- Documentation： 影响发布和维护，包括注释。

G- Algorithm ：算法错误。

U-User Interface：人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。

P-Performance：不满足系统可测量的属性值，如：执行时间，事务处理速率等。

N-Norms：不符合各种标准的要求，如编码标准、设计符号等。

软件测试错误严重程度1.Critical：不能执行正常工作功能或重要功能。

或者危及人身安全。

2.Major：严重地影响系统要求或基本功能的实现，且没有办法更正。

(重新安装或重新启动该软件不属于更正办法)3.Minor：严重地影响系统要求或基本功能的实现，但存在合理的更正办法。

(重新安装或重新启动该软件不属于更正办法)4.Cosmetic：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。

5.Other：其它错误。

同行评审错误严重程度1.Major：主要的，较大的缺陷2.Minor：次要的，小的缺陷 1.Resolve Immediately：缺陷必须被立即解决。

2.Normal Queue：缺陷需要正常排队等待修复或列入软件发布清单。

3.Not Urgent：缺陷可以在方便时被纠正。

1.Submitted： 已提交的缺陷2.Open ：确认“提交的缺陷”，等待处理3.Rejected： 拒绝“提交的缺陷”，不需要修复或不是缺陷4.Resolved ：缺陷被修复5.Closed ：确认被修复的缺陷，将其关闭 1.Requirement：在需求阶段发现的缺陷2.Architecture：在构架阶段发现的缺陷3.Design：在设计阶段发现的缺陷4.Code：在编码阶段发现的缺陷5.Test：在测试阶段发现的缺陷 1.Requirement： 由于需求的问题引起的缺陷2.Architecture： 由于构架的问题引起的缺陷3.Design： 由于设计的问题引起的缺陷4.Code： 由于编码的问题引起的缺陷5.Test： 由于测试的问题引起的缺陷6.Integration： 由于集成的问题引起的缺陷

软件测试 毕业论文

本科论文还是硕士论文？ 我估计是本科论文可能性比较大，硕士论文作这个就太那个了。

测试的目标说白了，不过是确认产品功能是否正确，进一步还可以确认性能等。

1、论文首先得讲你做了什么，开宗明义2、背景，这里就是你测试的产品，大体介绍一下，就是copy，注明出处3、这里需要根据产品的需求文档，逐一列出需要测试的各个功能，注明出处4、对各个功能一一设计测试用例，这个需要自己来写，对应的代码工作是编写测试的子程序(如果需要)5、确认对各个功能测试的结果，做了哪些测试，测试正确性如何，产品质量如何6、总结7、致谢8、原创性说明就这些了，一般的院校都会有自己的格式要求，但大多数不会差得太多，照着套就行了，呵呵

软件测试时问我在生活中哟哦你过得软件有什么缺陷,我应该怎么回答...

原则1——测试显示缺陷的存在，但不能证明系统不存在缺陷。

测试可以减少软件中存在未被发现缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的。

2)原则2——穷尽测试是不可能的。

由于有太多的输入组合、有太多的路径，而且时间是有限的，无法做到完全的测试(100%测试覆盖率)。

通过运用风险分析和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。

3)原则3——测试尽早介入。

软件项目一启动，软件测试就应开始，也就是从项目启动的第一天开始，测试人员就应参与项目的各种活动和开展对应的测试活动。

测试工作进行得越早，软件开发的劣质成本就越低，并能更好地保证软件质量。

例如，在代码完成之前，可以进行各种静态测试，主导或积极参与需求文档、产品规格说明书等的评审，将问题消灭在萌芽阶段。

4)原则4——缺陷集群性。

版本发布前进行测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。

一段程序中发现的错误数越多，意味着这段程序的质量越不好。

错误集中发生的现象，可能和程序员的编程水平、经验和习惯有很大的关系，也可能是程序员在写代码时情绪不够好或不在状态等。

如果在同样的测试效率和测试能力的条件下，缺陷发现得越多，漏掉的缺陷就越多。

这也就是著名的Myers 反直觉原则：在测试中发现缺陷多的地方，会有更多的缺陷没被发现。

假定测试能力不变，通过测试会发现产品中90%的缺陷。

如果在模块A 发现了180 个缺陷，在模块B 发现了45 个缺陷，意味着模块A 还有20 个缺陷没被发现，而模块B 只有5个缺陷未被发现。

所以，对发现错误较多的程序段，应进行更深入的测试。