本节书摘来自华章出版社《软件测试价值提升之路》一书中的第3章，第3.4节，作者：杨晓慧编著，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
3.4 随机出错
3.4.1 问题案例
十多年前我曾经参与解决一个产品的随机问题，这个问题导致产品宕机，重启后就能正常处理业务，但是宕机在一个月内总会发生，时间不固定，也没有发现和哪些操作有关系。这个问题持续影响客户的应用长达几个月，一直无法定位解决。后来公司在面对各方的巨大压力下，暂停新特性的开发，让整个团队花了一个月的时间，终于定位了这个由于魔鬼数字引起的问题，仅仅问题重现就花了差不多3周。
这类问题典型的有：产品偶尔无规律地宕机；用户偶尔无规律地无法操作或操作出错；进行简单恢复后，不再必然出现的故障。
3.4.2 解决问题的思路
【一般处理原则】
通常这类错误的解决思路，是提升代码质量，并为产品加上故障检测和自动恢复的能力（即检测到宕机或长时间无心跳就复位重启），而不是试图通过测试把这些缺陷都挖出来。
【解决方法】
发生这类问题的必然条件没有被找到，因而也无法根据问题分析找到测试流程或方法的薄弱点，也就无法进行有目的测试设计或改进测试执行方法。
根据以往经验，这类缺陷通常是编码质量存在问题，因此第一选择是提升代码质量。即使用静态测试工具对代码进行检查，排除容易引起越界、空值一类的问题，如果问题的影响比较大，还会进行代码走查，排除代码逻辑上的错误。
针对故障检测和自动恢复能力的测试在前一个章节介绍可靠性测试中已经描述。如果这类问题出现得比较多，那么在常规测试（指功能测试、性能测试等）中就需要能够对这些错误进行后台的、自动的检测，一旦检测到错误，还需要能够回溯一段时间的操作序列，并且能够对错误现场进行快照，以方便问题的定位解决。
3.4.3 利用工具提高错误检出率
在我们的产品中，当需要减少随机出错时，首选的方法就是代码静态测试。对用户量大的产品，如果随机出错比较严重（比如每周都出现一两次），会组织代码质量改进的专项工作，采用的方法一般是利用工具进行静态检查，加上人工的代码审查。代码静态检查可选的工具比较多，但代码审查就没有广泛应用的、成体系的工具。
代码静态测试一般是以开发工程师为主体开展，测试参与的比较少。
很多随机问题在实验室测试也曾经出现过，但是测试时没有检查到，或者偶然出现没有被捕捉到，或者捕获到了但是没有引起开发组的重视。因此，也有一些产品在解决这个问题时采用的方法是：开发错误检测工具。在所有测试环境上部署这个工具，在整个测试过程通过后台的、自动化的检测，确保能够发现偶然问题。错误检测工具应具备的功能有：
数据一致性。用户数据的变动、业务数据、统计表数据的一致性。例如，销售收入统计与支付记录表的支付情况、以及用户账户的变动情况一致。
异常宕机core dump文件。扫描操作系统和产品的文件夹，发现新出现的core文件。
告警。扫描告警接口，捕获告警消息。
文件数目和大小。扫描产品的文件夹，发现文件列表持续增长、单个文件大小持续增长、文件数目和大小超过门限的问题。
数据表大小。扫描产品的数据库表，发现表记录数持续增长、记录数或单条记录大小超过门限的问题。
产品和系统异常日志。扫描操作系统和产品的日志文件，发现新出现的错误记录。
业务流程阻塞或挂起或未正常释放。检测产品进程心跳或看门狗，扫描正在处理的事务，发现长时间无运算的事务。这个功能需要产品中有相应的功能，仅仅依靠工具无法实现。
系统资源异常波动：监控系统的CPU、内存、网络带宽、文件句柄等资源，产品的存活事务数等资源，发现资源占用持续增长或异常波动。
常规测试中进行后台的、自动的宕机检测，很多产品都能够做到，但是回溯操作、现场快照则鲜有产品能够做到。对于Web应用，操作录制和回溯有商用和开源的工具可选择。
如果是采用错误检测工具来拦截缺陷，这个工作可以以测试为主体开展，但是测试团队必须与开发团队达成默契：每一个捕获到的异常都必须进行问题定位，如果开发和测试工程师不能谨慎地对待每一个问题，则工具起到的作用很有限。
3.4.4 通过测试解决这类问题不是好方法
有时候，由于研发经理面对太大的客户压力，他们会对测试人员说：你们能不能想办法在实验室把这些问题发现了？这样的方法不是没有，但是代价大到不可接受。比如把代码静态检查的所有报错、告警全部改掉，这甚至比重做一遍产品研发还要费劲。或者对重要的类和函数进行基于函数接口的故障注入测试，这样测试的效率非常低，我的经验是一天能测试不超过10个用例，但是用例总数很可能数以千计。
所以，当测试经理面对这样的期望的时候，最好是根据实验室测试的情况以及问题的特点，和研发经理澄清并理出更可行的方案。如果实验室也经常出现随机且无法重现的错误，那么需要具备后台错误检测和回溯的能力及其工具；如果实验室从未发现这类错误，那么需要根据问题发生的特点增加一些测试内容，通常是长时间稳定性测试、构造系统忙时的业务场景测试等。
无论如何，通过测试发现这类问题无异于大海捞针，发现了是运气，漏过了是必然，顺着研发经理给的绳子，测试很多生僻的用例绝不是什么好的方法。
事实上，想发现这类问题，不仅系统测试是吃力不讨好，单元测试也不一定有效，代码的静态测试可能才是最经济的方法。
