咦，出BUG了

之前在使用某APP软件时，弹出了如下的错误信息。作为一个测试，看到这些信息，总会忍不住深挖下，也是蛮有意思的。

01

从上面的报错信息，至少可以得到以下几个信息：

• 这是个非常不友好的提示，对于非IT人员来说，这都是些什么鬼
• 出错地点：从错误代码中可以看到问题出现在连接数据库时，无法获取JDBC连接的地方；
• 使用的线程池：通过weblogic.jdbc.extensions.PoolLimitSQLException可以推测出使用的是WebLogic服务器中的线程池资源；
• 连接池的限制原因：通过异常信息中的no resources currently available in poolappds to allocate to applications"可以得知连接池中没有可用资源分配给应用程序，这可能是因为连接池资源已经全部被占用或达到了最大限制；
• 解决方案建议：异常信息中提到了解决方法，即增加连接池的大小并重试；
• 使用Spring和WebLogic进行应用开发：从异常的类型和堆栈信息可以判断出，应用程序使用了Spring框架和WebLogic服务器进行开发。

以上信息是否有用呢？对一般人来说，也没什么大用，但是对于从事安全的人员来说，问题可能就有点大，咨询过公司的安全人员，知道这个场景后，可以继续做更多的试探，进而获取到有用的信息，具体怎么玩的，我也不敢多问。

02

这个问题其实就是对系统的异常没有捕获到，或者捕获了没有处理，直接抛给前端，然后前端也没有做处理，直接丢到页面上去。类似的代码如下：

正确的处理方法应该包括异常捕获、错误信息记录、友好的用户提示以及对敏感信息的保护，如下图所示：

把真实的错误信息写到日志里去，然后根据指定的ERROR_CODE，给用户输出更为友好的信息。

同时，SpringBoot也支持通过@ControllerAdvice+@ExceptionHandler实现全局异常处理， 避免重复代码。

03

对于测试的同学而言，可以考虑以下几个方面：

• 边界测试：针对可能引发异常的边界情况设计测试用例。例如，在数据库查询时，可以测试一个查询语句中缺少必要的字段是否会引发异常，在数组操作中，测试访问一个超出数组长度的索引是否会引发正确的越界异常，等等。
• 异常情况测试：针对不同类型的异常情况设计测试用例。例如，在文件操作中，可以测试尝试读取一个不存在的文件是否会引发适当的异常。
• 非法输入测试：针对输入验证的异常情况设计测试用例。例如，在用户输入用户名时，可以测试输入一个超出允许长度的用户名是否会引发适当的验证异常。
• 并发访问测试：测试多个线程同时访问共享资源时是否能正确捕获并处理异常。例如，在使用多线程进行数据库操作时，模拟多个线程同时执行查询操作，观察是否能正确处理并发访问异常。
• 错误消息测试：测试异常处理代码中返回的错误消息是否准确和友好。例如，在输入验证失败时，检查返回的错误消息是否清晰地指示了验证失败的原因。

在设计这些测试用例时，要注意覆盖不同的异常情况和错误处理路径，以确保代码能够正确捕获和处理异常，而不仅仅是简单地通过catch块来吞掉异常

04

当然，这问题也没必要上纲上线，本文纯粹就是讨论，这类问题靠测试验证其实是无法全覆盖，也很低效。

这类问题最好的解决方案就是代码规范化以及及时的Code Review，大家都专注于各自领域。

研发遵循已有的代码规范和编程实践，解决技术问题。

测试专注场景设计及探索性测试，解决业务覆盖问题。

共勉。