几周前发生了一个较为严重的线上问题，少量用户在打开App会出现白屏。这两周一直在思考如何针对这种隐藏很深的特定条件下触发的缺陷进行测试和预防。本文结合在金融App的特定业务场景下，进行思考如何使用业务异常注入的方式，快速、高效、可行的保障App版本质量。通过思考总结了四种常见的注入方式，以供大家学习交流，期待同行能够提出更多建议。
基于输入的异常注入
每一个业务都有其成立的隐含条件，在特定的输入条件下才会产生特定的结果集。对于输入异常注入，需要关注输入约束、输入异常，这一点对于测试人员来说是比较轻车熟路。
比如16岁以下儿童身份证有效期5年。
某系统设计：在性别栏中，如果只有男、女，出现其他情况时，可能就会导致系统出现异常。
基于输出的异常注入
输入是正确的，但输出不一定是想要的结果，特别是后一业务依赖前置业务时，通过多次输出输入转换，可能会出现各种业务异常。常见的程序员在处理业务过程中的代码缺陷和业务理解歧义导致的业务处理异常。
输网络异常导致，因为传输过程各种原因的丢包、延迟，序列化和反序列化等原因导致的输出异常。网络异常包含网络本身的异常以及软硬件故障导致到异常注入。
不管是业务异常还是因为传输异常导致的各种问题，都会影响整体程序的正常运行。
比如：在业务处理过程中，因为程序员的疏忽，导致业务处理返回code码返回错误，导致相关依赖其业务code码的相关业务处理异常或者失效。
因为网络延迟，响应时间变长，导致相关业务调用接口熔断，出现的程序或者业务失效。
基于计算的异常注入
输入输出都没有问题，但在计算某个值时，程序失效。基于计算异常的注入包含计算本身的问题，以及因为计算异常导致的操作系统异常等情况的注入。
例如：将两个很大的数相乘，乘积太大不能出来，导致程序不能处理。
基于存储（或数据）的异常注入
输入、输出、计算、网络都是正常的，但是操作是程序耗尽内存，或者产生的数据文件过大，甚至内存突然出现故障等原因，程序不能处理。
对于以上内容在性能测试和乐高平台数据验证等测试中有一些实践，但目前没有全方位的、系统化的应用和实践在项目中，期待未来能够围绕异常注入进行系统化的高标准的质量建设和探索。
