标签：帮助文档 模型 计算 质量 说明 创建 应用 问题 模块
[摘要] 随着计算机科学技术的快速发展，软件的应用领域逐步推广，软件规模和成本逐渐增大，软件设计的复杂程度不断提高,软件开发中出现错误或缺陷的机会越来越多,同时，市场对软件质量重要性的认识逐渐增强。所以，缺陷管理作为软件生命周期的一部分，其在软件项目实施过程中的重要性日益突出，是保证软件质量的重要手段。
本文对缺陷管理技术进行了详细的论述，总结了缺陷管理的流程，介绍了在缺陷跟踪过程中使用的工具以及如何进行缺陷分析。缺陷管理作为测试生命周期模型的一部分，不仅是人与工具的交流，也是人与人的交流。结合中国软件杯的赛题,详细阐述了在测试生命周期中如何进行缺陷管理和跟踪，如何尽快发现并解决 bug,如何应对突如其来的变更。在本次赛题的任务中，我主要负责的是对文本识别算法的研发。
[关键词]新闻文本分类，缺陷管理
一、赛题背景
本次赛题名为新闻文本分类算法，是对已经分类好的新闻标题进行训练，然后在调用模型使他能识别出新闻标题的分类。解题的主要难点在于数据集的爬取以及数据分析和算法的处理。第一期的主要开发目的是满足题目要求，达成输入一个标题可以输出相应的分类。并尽可能的把算法的准确率控制在80%以上，开发周期是从2021年4月20日开始，到2021年5月13日完成第一阶段的验收。到13日时已经基本完成了老师的要求。做成了一个可视化的界面，并采用贝叶斯分类算法，使得分类准确度达到了89%，另外我们还做了一个新闻app,在里面可视化的展示了在头条上爬取的新闻和视屏，并可以简单的实现他的分类，通过搜索引擎可以实现新闻标题的迷糊查询。在软件开发的第二阶段，我们想对软件内容进行整合，并添加新的板块可以在app上实现文本分类的可视化展示。但是在开发过程中遇到了很多的问题，这也就是本文要讲的软件缺陷管理技术。
二、软件缺陷技术的定义与流程
1.缺陷的定义
软件中的缺陷（Defect或BUG）是软件开发过程中的“副产品”。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。每一个软件开发团队都必须知道如何妥善处理软件中的缺陷，这关系到软件生存、发展的质量根本。可遗憾的是，并非所有的软件开发团队都知道如何有效地管理软件中的缺陷。软件缺陷一般有以下五种情况。
(1）软件未达到需求规格说明书的功能;
(2) 软件出现了需求规格说明书指明不会出现的错误;
(3）软件功能超出需求规格说明书的范围;
(4）软件未达到需求规格说明书未指出但应达到的目标;
(5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。
2.缺陷类型
(1)设计缺陷:由于软件设计或代码实现所产生的功能或流程的问题。
(2）界面问题:系统页面的展示的问题。
(3）数据问题:系统数据的来源，处理及处理结果的问题。
(4）需求问题:软件需求测试发现的问题，也包括之后需求变更的问题。
(5）安装部署:软件安装部署过程的错误。
(6）性能问题:软件性能相关的缺陷。
(7）文档问题:用户使用手册，软件帮助文档等出现的问题
(8）常识问题:系统用户的正常使用习惯相关问题。
(9）安全问题:系统漏洞安全问题。
(10）优化建议:针对操作过程逻辑或界面显示的优化性建议。
3.缺陷的严重性和优先等级
0级（致命)︰最严重等级，缺陷导致系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机等;
1级(严重)∶系统的主要功能部分丧失、数据不能完全保存，系统的次要功能完全丧失，系统所提供的功能或服务收到明显影响;
2级(一般)∶系统的次要功能没有完全实现，但不影响用户的正常使用。例如，提示信息不太准确;或用户界面差、操做时间稍长等问题;3级(微小)︰操作者不方便或遇到麻烦，但不影响功能的操做和执行，如字体不美观、按钮大小不很合适、字体排列不对齐等一些小问题,2、4.缺陷的优先级
立即解决（p1级)∶缺陷导致系统几乎不能完全运行、使用，或严重妨碍测试的执行，需立即修正、尽快修正;高优先级
(p2级)∶缺陷严重，影响测试，需要优先考虑修正，如不超过24小时修正;
正常排队(p3级)︰缺陷需要修正，但可以正常排队等待修正;
低优先级（p4级)︰缺陷可以在开发人员有时间的时候被修正，如果没时间可以不修正。
软件缺陷处理过程
(1)创建问题
在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项。
(2)指派问题
创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。
(3)确认问题
通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择°确认状态";如果认为非Bug，则注明原因并指派回创建者。当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它;如果不同意，则需要注明理由并指派回相关工程师。如果问题确认指派次数大于6次时，需要进入“争议处理"流程。
(4)解决问题
此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。
开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。如果Bug无法解决或修改影响比较大，可申请进入“延期解决"流程。
(5）验证问题
创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过，则可关闭Bug;如果验证不通过，则激活此Bug，系统将自动指派回给解决者。验证通过准则:相同的操作步骤，进行一定次数的验证测试都没有发生。验证不通过准则:相同的操作步骤，全部或部分实际结果还会发生，验证不通过则激活Bug。
(6)关闭问题
通过验证的Bug，验证者需要注明验证结果并进行关闭操作，系统将指派给Closed。如果关闭状态的Bug在之后版本又会发生，则激活此Bug，系统将自动指派回给解决者。
三、具体实施过程。
通过应用软件测试的缺陷管理技术，在第二阶段的开发中我们很快就发现了自己的问题。有以下几个方面：
1.算法的准确性问题
问题描述：虽然算法的准确度达到了80%以上，但是在进行可视化展示的时候，他的准确率却是，明显低于理论值。
问题类型：性能问题
问题等级：一级
优先度等级：p2
解决情况：已解决，检查后发现是模型提取有误，需要对他重新进行模型训练，另外也有训练数据过少的缘故。
2.界面展示问题
问题描述：虽然算法的准确度达到了80%以上，但是在进行可视化展示的时候，他的准确率却是，明显低于理论值。
问题类型：性能问题
问题等级：二级
优先度等级：p3
解决情况：已解决，通过模块整合将新闻分类和展示能够同时在app展示
标签：帮助文档 模型 计算 质量 说明 创建 应用 问题 模块
原文地址：https://www.cnblogs.com/w669399221/p/14925639.html
