为什么这个程序有缺陷，求不了1到100除了2的素数，会多出4个不是素数的数，求大神指点迷津！

一个大于1的自然数，如果除了1和它本身外，不能被其他自然数整除(除0以外）的数称之为素数(质数） 否则称为合数。根据算术基本定理，每一个比1大的整数，要么本身是一个质数，要么可以写成一系列质数的乘积 而且如果不考虑这些质数在乘积中的顺序，那么写出来的形式是唯一的。在自然数域内，质数是不可再分的数，是组成一切自然数的基本元素。

你的判断设计符合要求？

软件缺陷(software defect)分类标准缺陷属性属性名称 描述 缺陷标识(Identifier) 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识 缺陷类型 (Type) 缺陷类型是根据缺陷的自然属性划分的缺陷种类。 缺陷严重程度 (Severity) 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。 缺陷优先级(Priority) 缺陷的优先级指缺陷必须被修复的紧急程度。 缺陷状态(Status) 缺陷状态指缺陷通过一个跟踪修复过程的进展情况。 缺陷起源(Origin) 缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。 缺陷来源(Source) 缺陷来源指引起缺陷的起因。 缺陷根源(Root Cause) 缺陷根源指发生错误的根本因素。缺陷类型（Type）缺陷类型编号 缺陷类型 描述 10 F- Function 影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷。 20 A- Assignment 需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。 30 I- Interface 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。 40 C- Checking 提示的错误信息，不适当的数据验证等缺陷。 50 B Build/package/merge 由于配置库、变更管理或版本控制引起的错误。 60 D- Documentation 影响发布和维护，包括注释。 70 G- Algorithm 算法错误。 80 U-User Interface 人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。 90 P-Performance 不满足系统可测量的属性值，如：执行时间，事务处理速率等。 100 N-Norms 不符合各种标准的要求，如编码标准、设计符号等。缺陷严重程度（Severity）131 软件测试错误严重程度 # 缺陷严重等级 描述 1 Critical 不能执行正常工作功能或重要功能。或者危及人身安全。 2 Major 严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法） 3 Minor 严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法） 4 Cosmetic 使 *** 作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。 5 Other 其它错误。132 同行评审错误严重程度 # 缺陷严重等级 描述 Major 主要的，较大的缺陷 Minor 次要的，小的缺陷缺陷优先级（Priority）# 缺陷优先级 描述 1 Resolve Immediately 缺陷必须被立即解决。 2 Normal Queue 缺陷需要正常排队等待修复或列入软件发布清单。 3 Not Urgent 缺陷可以在方便时被纠正。缺陷状态（Status）缺陷状态 描述 Submitted 已提交的缺陷 Open 确认“提交的缺陷”，等待处理 Rejected 拒绝“提交的缺陷”，不需要修复或不是缺陷 Resolved 缺陷被修复 Closed 确认被修复的缺陷，将其关闭缺陷起源（Origin）缺陷起源 描述 Requirement 在需求阶段发现的缺陷 Architecture 在构架阶段发现的缺陷 Design 在设计阶段发现的缺陷 Code 在编码阶段发现的缺陷 Test 在测试阶段发现的缺陷缺陷来源（Source）缺陷来源 描述Requirement： 由于需求的问题引起的缺陷 Architecture： 由于构架的问题引起的缺陷Design： 由于设计的问题引起的缺陷 Code： 由于编码的问题引起的缺陷Test： 由于测试的问题引起的缺陷 Integration： 由于集成的问题引起的缺陷

The First “Computer Bug” | 首个“计算机Bug”

1947年9月9日，哈佛大学测试马克II型艾肯中继器计算机， *** 作员在电板编号为70的中继器触点旁发现了一只飞蛾。然后 *** 作员把飞蛾贴在计算机日志上了，并写下了“首个发现bug的实际案例”。他们提出了一个词，“debug（调试）”了机器，从而引入新术语“debugging a computer program（调试计算机程序）”。

In 1988, the log, with the moth still taped by the entry, was in the Naval Surface Warfare Center Computer Museum at Dahlgren, Virginia

1988年，这个仍然贴着飞蛾的日志，保存于弗吉尼亚州达尔格伦的海军水面作战中心计算机博物馆。

以下的两句话明确了缺陷的产生。

软件缺陷的产生主要有软件产品的特点和开发过程决定的。比如需求不够清晰，频繁变更等；或者软件由于竞争非常激烈，技术日新月异，使用新技术也容易产生问题。大致有以下几种主要原因：

软件测试就是为了更早、更快的发现缺陷。换句话说，缺陷的发现可以看作是测试工作的主要成果之一。软件缺陷管理的实施，至少有如下三个基本目的：

软件缺陷（Defect），常常又被叫做Bug。 所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

bug 和 defect

飞蛾或者虫子爬进主机引起短路，造成计算机失效的事件中，我们可以看到bug就是虫子或者是虫子引发失效这样的事件。那么defect又是什么呢？

真正的Defect是计算机维护工程师提出来的那个问题：在主机的散热孔那里可以加装一层更加细密的金属网，即不影响散热，又可以防止虫子爬到主机里。这是计算机设计人员疏忽的地方，是产品真正的Defect。而虫子引发的那个故障只是这个Defect导致的故障的其中一种表现形式。也就是说，Bug是Defect的一种表现形式，而一个Defect是可以引起多种Bug的。

软件测试使用各种术语描述软件出现的问题，通用的术语如下：

在可以预见的时期内，软件仍将由人来开发。在整个软件生存期的各个阶段，都贯穿者人的直接或间接的干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。

软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一个逗号、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。

软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如，软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无时当的措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。

软件失效是指软件运行时产生 的一种不希望或不可接受的外部行为结果。失效是指功能部件执行其规定功能的能力丧失。软件失效是指软件运行时产生的一种不希望或不可接受的外部行为。

软件错误是一种人为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障如果没有集市的容错措施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。

测试执行过程中，发现软件失效后，提出书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。

软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初并且最好的机会。一个好的描述，需要使用简单、准确、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。因此，准确的报告软件缺陷是非常重要的。

软件缺陷的属性从大的方面包括以下几部分：

综上所述，一个完整的缺陷报告需要包括以下内容。

| 缺陷的状态 | 描述 |

| ---------------------------- | ----------------------- |

| 激活的或打开的（Active or Open） | 缺陷的起始状态，问题还没有解决，等待修复 |

| 已修正的或已修复的（Fixed or Resolved） | 已被开发人员检查和修复，等待验证人员验证 |

| 关闭的或非激活的（Close or Inactive） | 验证通过，确认缺陷已经可以关闭 |

| 重新打开 （Reopen） | 验证不通过，需要 |

| 推迟 （Deferred） | 缺陷不严重，在下一个版本中解决 |

| 保留 （On hold） | 由于技术原因或者其他原因，暂时无法解决 |

| 功能增强 | 发现的缺陷符合当前说明书。是一个有待改进的问题 |

| 不是缺陷 | |

| 不能重现 | |

| 需要更多信息 | |

| 缺陷的严重级别 | 描述 |

| ------------ | -------------------------------- |

| 致命（Fatal） | 系统的主要功能完全失效，用户利益受到损失、系统崩溃、死机等 |

| 严重（Critical） | 系统的主要功能部分失效，数据无法保存、提供的服务受到影响 |

| 一般（Major） | 系统的次要功能没有完全实现，不影响用户的正常使用，如提示不准确等 |

| 较小（Minor） | 用户体验不好，不影响功能实现 |

| 缺陷的优先级 | 描述 |

| -------- | ----------------------- |

| 立即解决（P1） | 缺陷导致系统不可使用，无法测试或者测试无法继续 |

| 高优先级（P2） | 缺陷严重，影响测试，需要优先考虑 |

| 正常排队（P3） | 缺陷需要正常排队等待修复 |

| 低优先级（P4） | 缺陷可以在开发人员有时间的时候被修正 |

缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

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

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

生命周期的概念是从诞生到消亡所经历的过程。软件缺陷经历了从被发现、报告、到其被修复、验证、直至最后关闭的过程。为了完整的描述这个过程，设定了不同阶段的缺陷状态来体现缺陷不同的生命阶段。对于测试人员来说，需要关注软件缺陷状态的变化，并和开发人员保持良好的沟通，使缺陷能够及时得到处理和修正。

缺陷状态的跟踪

缺陷趋势的分析

缺陷分布分析

累计缺陷趋势分析

以上就是关于为什么这个程序有缺陷，求不了1到100除了2的素数，会多出4个不是素数的数，求大神指点迷津！全部的内容，包括:为什么这个程序有缺陷，求不了1到100除了2的素数，会多出4个不是素数的数，求大神指点迷津！、软件缺陷分类的标准、软件缺陷管理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！