| 原因分析案例:上线后缺陷比较多 |
| 现象描述 | 上线后缺陷比较多,导致客户满意度下降。 |
| 现象的定量刻画 | 1.2023年1季度上线了20个版本,比2022年4季度暴露的缺陷密度增加了50%。 2.客户三次找公司领导抱怨系统的问题。 3.对缺陷类型做了80-20分布分析,易用性问题的数量超过了30%,是客户抱怨最多的问题,其次是软件的性能问题,超过了20%。 |
| 技术 | 技术原因 | 1.软件的功能设计不合理,导致软件难用。 2.对于大数据量的处理算法不合理,没有对大数据表进行拆分、数据表的索引设计不合理。 |
| 纠正措施 | 1对功能设计重构,减少菜单嵌套层次,减少操作步骤。 2优化数据库设计与查询算法。 |
| 预防措施 | 1在设计指南中增加关于易用性设计、数据库设计的指南。 2在需求文档中给出非功能性需求的描述案例。 3 对需求人员、开发人员、测试人员进行非功能性需求描述、设计、实现与测试技术的培训。 |
| 检测措施 | 1在测试策略与测试计划中单独识别对非功能性需求的测试活动。 2在确认测试时,必须增加对非功能性需求的测试。 |
| 固化措施 | 1需求文档、设计文档中非功能性需求章节不允许为空。 2 非功能性需求的测试用例不允许为空。 |
| 管理 | 管理原因 | 1在功能设计时忽略了对易用性与性能的设计。 2在设计评审时,没有评审易用性设计与性能设计。 |
| 纠正措施 | 记录上线后的问题,并对这些问题跟踪技术纠正措施的关闭情况。 |
| 预防措施 | 1修改组织级的设计指南、需求模板、测试用例编写模板、测试报告模板,体现出来非功能性需求的应对。 2在需求评审、设计评审、测试用例评审中将对非功能性需求的评审列为一个单独的活动。 |
| 检测措施 | 1在测试策略与测试计划中单独识别对非功能性需求的测试活动。 2 在确认测试时,必须增加对非功能性需求的测试。 |
| 固化措施 | 1QA检查时,增加对非功能性需求的描述、设计、测试的检查项。2EPG定期采集在非功能性需求方面的经验教训。 |