Detailed sorting of software defects

To understand software defects, you must first understand the concept of software defects, then understand the detailed characteristics of software defects, and finally its attributes. A higher level is to learn to use tools for managing software defects. 1. First introduce the concept of software defects Software defects are those defects in a system or system component that cause the system or component to fail to perform its function. 2. Detailed characteristics of software defects a, single and accurate b, reproducible (requires software defects to have precise steps) c, complete and unified d, short and concise e, specific conditions f, complete and complete g, no evaluation 3. Attributes of Software Defects The attributes of software defects include defect identification, defect type, defect severity, defect occurrence probability, defect priority, defect status, defect origin, defect source, and defect cause. These properties are described in detail below: a. Defect identification: it is a unique identification to mark a defect, which can be represented by a digital serial number; b. Defect type: function, user interface, documentation, software package, performance, system\module interface Function: defects affecting various system functions and logic; user interface: affecting user interface and human-computer interaction characteristics, including defects in screen format, user input flexibility, result input format, etc.; documentation: affecting release and maintenance, Includes comments, user manuals, design documents; software packages: errors due to software configuration repositories, change management, or version control; performance: not meeting system measurable property values, such as execution time, transaction rate, etc.; system\module interface : Mismatch or conflict with other components, modules or device drivers, call parameters, control blocks or parameter lists, etc. c. Defect severity: Fatal, Critical, Major, Minor Fatal: Any major function of the system is completely lost, user data is destroyed, the system crashes, hangs, freezes or threatens personal safety; Serious: Part of the main function of the system is lost, data cannot be saved, the secondary functions of the system are completely lost, and the system provides The function or service is obviously affected; General: The secondary function of the system is not fully realized, but it does not affect the normal use of the user. For example: the prompt information is not very accurate or the user interface is poor, the operation time is long, etc.; minor: it makes the operator inconvenient or encounters trouble, but it does not affect the operation and execution of the function, such as individual products that do not affect the understanding of the product Minor problems such as typos, irregular text arrangement, etc. d. Possibility of defects: always, usually, sometimes, rarely Always: always produce this software defect, and its frequency is 100%; usually: according to the test case, usually this software defect occurs, and its frequency is about 80%-90%; sometimes: according to the test case , sometimes this software defect occurs, and its frequency is about 30%-50%; rarely: according to the test case, this software defect is rarely generated, and its frequency is about 1%-5%. e. Priority of defects: immediate resolution, high priority, normal queuing, low priority Immediate solution: The defect causes the system to be almost unusable or the test cannot continue, and needs to be repaired immediately; High priority: The defect is serious and affects testing, and needs to be prioritized; Normal queue: The defect needs to be queued normally for repair; Low priority: The defect can be developed again Personnel are corrected when they have time. f、缺陷状态：激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息 激活或打开：问题还没有解决，存在源代码中，确认”提交的缺陷”，等待处理，如新报的缺陷； 已修正或修复：已被开发人员检查、修复过的缺陷，通过单元测试，认为已经解决但还没有被测试人员验证； 关闭或非激活：测试人员验证后，确认缺陷不存在之后的状态； 重新打开：测试人员验证后，确认缺陷不存在之后的状态； 推迟：这个软件缺陷可以在下一个版本中解决； 保留：由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷； 不能重现：开发不能再现这个软件缺陷，需要测试人员检查缺陷再现的步骤； 需要更多信息：开发能再现这个软件缺陷，但开发人员需要一些信息，例如缺陷的日志文件、图片等。 g、软件缺陷的起源：需求、构架、设计、编码、测试、用户 在团建生命周期中软件缺陷占的比例：需求和构架设计阶段占54%、设计阶段占25%、编码阶段占15%、其他占6%. h、软件缺陷的来源：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码 需求说明书：需求说明书的错误或不清楚引起的问题； 设计文档：设计文档描述不准确。和需求说明书不一致的问题； 系统集成接口：系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷； 数据流（库）：由于数据字典、数据库中的错误引起的缺陷； 程序代码：纯粹在编码中的问题所引起的缺陷。 i、缺陷根源：测试策略，过程、工具和方法，团队\人，缺乏组织和通讯，硬件，软件，工作环境 测试策略：错误的测试范围，误解测试目标，超越测试能力等； 过程、工具和方法：无效的需求收集过程，果实的风险管理过程，不使用的项目管理方法，没有估算规程，无效的变更控制过程等； 团队\人：项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等； 缺乏组织和通讯：缺乏用户参与，职责不明确、管理失败等； 硬件：硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失，内存溢出等； 软件：软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，千年虫问题等； 工作环境：组织机构调整，预算改变，工作环境恶劣，如噪音过大。 4、学会利用管理缺陷的工具 例如TD、bugfree、bugzille等