开发者社区 > 博文 > 不存在的场景真的不存在吗?
分享
  • 打开微信扫码分享

  • 点击前往QQ分享

  • 点击前往微博分享

  • 点击复制链接

不存在的场景真的不存在吗?

  • jd****
  • 2024-06-26
  • IP归属:北京
  • 100浏览

    背景:

    近期在跟进业务中发生了一些问题,并从中学习了一些避免问题产生的经验。通过这些问题也引发了我的一个疑问:“不存在的场景真的不存在吗?”,本篇文章将探讨这一问题,并尝试分析问题产生的原因。

    场景举例:

    在项目研发和测试过程中,常常会出现以下几种场景:

    场景一:

    测试人员:有一个数据为空的场景还没有验证。

    研发人员:这个场景不会出现,因为没有删除逻辑。

    场景二:

    研发人员:本次需求时间紧任务重!这里肯定不会出现数据为空的情况,异常处理来不及加,先不加了或者忘记加了。

         场景三:

    测试人员:逻辑删除了所有的测试数据,认为测试到了数据为空的情况。但实际上,底层数据逻辑会查询所有数据,然后在逻辑层根据“是否被删除”字段做处理,未能真正验证空数据的异常情况。

    场景四:

    主表信息存储子表信息,使用时直接拿主表存储信息,未对子表信息作双重验证,结果发现子数据不存在。

    场景五:

    在数据计算中,处理数字和NULL时遇到问题,例如:

    SELECT number + NULL FROM table_name;
    
    Integer value1 = null;
    Integer value2 = 5;
    Integer result = value1 + value2; // 这将导致空指针异常
    

    ······ 当然还有其他情景存在,欢迎评论区补充

    案例分析

    分析了过去十年中因空指针异常(NullPointerException, NPE)而导致的多起著名互联网公司事故。

    友商A 2016年API故障

    • 描述:2016年,友商A的API因空指针异常导致部分第三方应用无法正常使用,影响了许多依赖Twitter数据的应用程序。

    • 影响:此次故障影响了开发者的信任,导致部分开发者转向其他社交平台,增加了Twitter的获客成本,并导致用户流失。


    友商B 2017年消息丢失

    • 描述:2017年,友商B因空指针异常导致部分用户的消息丢失或无法发送。

    • 影响:用户对平台的信任度下降,部分用户转向其他社交媒体,增加了获客成本,并导致用户流失。


    友商C 2018年乘车系统中断

    • 描述:2018年,友商C因空指针异常导致乘车系统中断,用户无法呼叫车辆。

    • 影响:影响了用户的出行计划,导致用户对平台的可靠性产生质疑,增加了获客成本,并导致部分用户流失到竞争对手平台。


    友商D 2019年“双11”购物节故障

    • 描述:在2019年“双11”购物节期间,友商D因空指针异常导致系统崩溃,部分用户在支付环节遇到问题。

    • 影响:此次故障导致部分用户无法完成支付,影响了销售额并导致用户体验不佳,间接导致了客户流失。


    友商E 2020年购物车故障

    • 描述:2020年,友商E的购物车系统因空指针异常导致用户在结账时出现错误,无法完成购买。

    • 影响:影响了用户的购物体验,导致销售额损失,并增加了获客成本和客户支持成本。


    友商F 2020年服务中断

    • 描述:2020年,友商F发生了一次大规模服务中断,原因是代码库中出现了空指针异常。此次中断导致全球数百万开发者无法访问其项目和代码。

    • 影响:影响了全球开发者的正常工作流程,友商的声誉受到损害,导致用户对平台的稳定性产生质疑。


    友商G 2021年支付系统故障

    • 描述:2021年,友商G因一处空指针异常在高峰期出现支付系统故障,用户无法进行支付操作。

    • 影响:此次事故导致用户在支付时受到阻碍,影响了用户体验和平台的可信度,增加了获客难度,并导致部分用户转向竞争对手的平台。

       上诉这些事故不仅对用户体验产生了比较大的负面影响,导致用户满意度显著下降,还对公司的业务运营和品牌声誉造成了严重损害。更为关键的是,这些问题直接导致了获客成本的大幅上升,公司不得不投入更多资源来吸引新用户,增加了运营负担。同时,由于频繁的系统故障和服务中断,许多忠实客户也因失望和不满而流失,进一步削弱了公司的市场竞争力。这些案例警示我们,预防和解决空指针异常问题不仅是技术层面的挑战,更是关乎公司生存与发展的重要任务。

    那么结合上诉案例和,我们尝试分析以上问题产生的可能性,主观认为是不是可能存在以下方面(分析的不一定对,仅供参考):

    是否存在侥幸心理

    侥幸心理在开发和业务处理中是常见的,尤其是在面对复杂系统和紧迫的项目期限时。开发人员和项目管理者可能会认为某些异常场景不太可能发生,从而忽略了对这些场景的处理。这种心理可能源于以下几个方面:

    1. 过度乐观:相信系统已经足够健壮,罕见的异常情况不会出现。

    2. 时间压力:在项目截止日期临近时,优先处理主要功能,忽略对异常场景的详细处理。

    3. 历史经验:基于过去的经验,未曾遇到过某些问题,因此认为这些问题不会发生。

    是否有行为大意

    行为大意是指在开发过程中由于粗心或缺乏细致的检查而导致错误。即便是经验丰富的开发人员,有时也会因为大意而忽略潜在的异常场景。例如:

    1. 未进行充分的单元测试:由于测试覆盖率不足,某些异常场景未被发现。

    2. 忽略代码审查:在代码审查过程中,未能全面检查所有可能的异常情况。

    3. 疏于文档记录:未能详细记录所有可能的异常场景及其处理方法,使得后续维护和开发时容易忽略这些情况。

    是否有未考虑到异常场景

    有时,开发、测试人员可能根本未考虑到某些异常场景。这种情况可能是由于以下原因:

    1. 缺乏经验:对于新手开发人员,未能预见和处理复杂系统中的各种异常情况。

    2. 知识盲区:某些异常情况可能涉及到开发人员不熟悉的领域,导致未能预见这些情况。

    3. 系统复杂性:在复杂系统中,可能存在多种交互和边界条件,使得某些异常情况难以预测。


    结合上诉案例分析和产生问题的可能性,QA能做哪些来弥补或者帮助研发同学降低存在问题的概率。以下JS是整理的存在空指针的异常场景以及对应的测试方法,欢迎指正!!!

    为空场景和测试方法

    1. 未初始化的对象

    • 场景:尝试调用未初始化的对象方法。

    • 测试方法:确保所有对象在使用前都已正确初始化。

    2. 空返回值

    • 场景:方法返回null,而不是预期的对象。

    • 测试方法:对所有方法的返回值进行null检查,特别是在接收外部数据或API调用的地方。

    3. 集合中的空元素

    • 场景:集合(如List、Set、Map)中包含null元素。

    • 测试方法:在操作集合时添加null检查,避免对null元素进行操作。

    4. 外部库或API调用

    • 场景:调用外部库或API时返回null。

    • 测试方法:对所有外部调用进行null检查,确保返回值不为空。

    5. 对象属性未初始化

    • 场景:访问对象的属性时,属性未初始化。

    • 测试方法:在对象初始化时确保所有属性都已赋值,或添加null检查。

    6. 依赖注入失败

    • 场景:依赖注入框架未能正确注入依赖对象。

    • 测试方法:在使用依赖对象前进行null检查,确保依赖已正确注入。

    7. 多线程环境

    • 场景:多线程环境下的竞争条件导致对象未初始化。

    • 测试方法:使用同步机制确保对象在多线程环境中安全初始化。

    8. 用户输入

    • 场景:用户输入为空或非法值。

    • 测试方法:对用户输入进行验证和检查,确保输入值不为空。

    9. 数据库查询结果

    • 场景:数据库查询返回null结果。

    • 测试方法:对所有数据库查询结果进行null检查,避免操作null结果。

    10. 配置文件或环境变量

    • 场景:配置文件或环境变量中缺失关键配置。

    • 测试方法:加载配置时进行null检查,确保所有关键配置已正确加载。

    11. 文件读取

    • 场景:文件读取操作返回null(例如文件不存在)。

    • 测试方法:在读取文件前检查文件是否存在,确保文件读取操作返回非null值。

    12. Web请求参数

    • 场景:Web请求中缺少必需的参数。

    • 测试方法:对所有Web请求参数进行验证,确保所有必需参数均已提供且不为空。

    13. 缓存失效

    • 场景:缓存失效或未命中时返回null。

    • 测试方法:在使用缓存结果前进行null检查,确保缓存命中返回非null值。

    14. 序列化/反序列化

    • 场景:对象序列化或反序列化时出现null值。

    • 测试方法:在序列化和反序列化操作时进行null检查,确保过程正确完成。

    15. 后台服务返回值

    • 场景:调用后台服务接口时,返回null。

    • 测试方法:对所有后台服务调用的返回值进行null检查,确保返回值不为空。

    16. 事件驱动系统

    • 场景:事件处理过程中,事件对象为null。

    • 测试方法:在事件处理代码中检查事件对象,确保其不为空。

    17. 迭代器

    • 场景:使用迭代器遍历集合时,迭代器的next()方法返回null。

    • 测试方法:在遍历集合时检查每个元素,确保其不为空。

    18. 回调函数

    • 场景:回调函数的参数为null。

    • 测试方法:在回调函数中添加参数检查,确保传递的参数不为空。

    19. 配置对象

    • 场景:加载配置对象时,某些配置属性为null。

    • 测试方法:在使用配置对象前,检查其所有属性,确保不为空。

    20. 定时任务

    • 场景:定时任务执行时,所需的依赖对象为null。

    • 测试方法:在定时任务执行前检查所有依赖对象,确保其已初始化。

    21. 动态加载类

    • 场景:通过反射或动态加载类时,类实例为null。

    • 测试方法:在动态加载类后检查实例对象,确保其不为空。

    23. 分布式系统

    • 场景:分布式系统中,远程调用返回null。

    • 测试方法:对所有远程调用的返回值进行null检查,确保返回值不为空。

    24. 日志记录

    • 场景:日志记录过程中,日志对象为null。

    • 测试方法:在记录日志前检查日志对象,确保其不为空。

    25. 错误处理

    • 场景:错误处理过程中,错误信息对象为null。

    • 测试方法:在处理错误时检查错误信息对象,确保其不为空。

    26. 依赖链

    • 场景:多个依赖对象中的一个为null,导致整个依赖链失效。

    • 测试方法:在使用依赖链中的每个对象前进行null检查,确保所有依赖对象都已正确初始化。

    27. 多语言支持

    • 场景:多语言支持时,语言资源对象为null。

    • 测试方法:在加载多语言资源时检查资源对象,确保其不为空。

    28. 插件机制

    • 场景:插件机制中,加载的插件对象为null。

    • 测试方法:在加载插件后检查插件对象,确保其不为空。

    29. 缓存机制

    • 场景:缓存机制中,缓存对象为null。

    • 测试方法:在使用缓存对象前检查其是否已正确加载,确保不为空。

    30. API网关

    • 场景:通过API网关调用服务时,返回值为null。

    • 测试方法:在API网关处理请求时检查返回值,确保不为空。

    思考

    不存在的场景真的不存在吗?”这一问题提醒我们在开发和业务处理中,不应忽视任何可能的异常情况。通过不断优化测试、记录、审查和学习,我们可以更好地预见和处理异常情况,提升系统的稳定性和可靠性。通过加强测试覆盖率、详细记录异常场景、定期代码审查、加强培训和学习是否真的能解决这些问题这不仅是对开发、测试人员的要求,也是对整个团队和项目管理的提醒。只有在充分考虑和应对所有可能的异常场景,我们才能真正保证系统的健壮性和可靠性。


    文章数
    1
    阅读量
    0

    作者其他文章