2002 年，美国国家标准与技术研究所 (NIST) 发布了一份报告，详细说明了软件测试不足对经济的影响（NIST 报告，2002 年）。该报告的结论是：
“……全国因软件测试基础设施不足而导致的年度损失估计在 222 亿美元至 595 亿美元之间。”
NIST报告还指出，软件测试实践状况严重不足。
七年后，Wong 等人在一份 IEEE 可靠性协会报告 (Wong et al., 2009) 中回顾了 15 起广为人知的软件故障，其中几起导致了人员伤亡，并得出结论：
“……需要实施更好的测试程序和实践，对于与安全关键系统相关的软件尤其如此。”
在最近的一篇文章中，Wong 等人研究了多个行业的一系列软件故障（Wong 等人，2017 年），并提出了一个相当发人深省的观点：
“……令人失望的事实是，软件远非没有缺陷，每年都要花费大量金钱来修复或维护（有缺陷的）软件。”
这篇文章分析了 1985 年至 2015 年 30 年间发生的软件故障，确定了导致故障的软件错误的性质，以及其他促成因素，例如用户错误；并将故障分为两类：致命故障（导致生命损失）和非致命故障，但造成了重大经济损失。致命故障包括 1985 年的 Therac-25 事件，至少有六名患者接受了过量辐射，以及 1995 年至 1997 年之间的民航事故，造成 650 多人丧生。它还包括 2014 年的埃博拉事件，当时电子健康记录软件故障导致一名感染埃博拉病毒的患者被误诊，随后死亡。非致命故障包括核电站软件故障，造成 200 万美元的损失，以及阿丽亚娜 5 软件故障，造成 70 亿美元的损失。在结论中，作者提出了以下观察：
“……嵌入式软件在公共基础设施、交通系统、消费产品等领域的普及让[我们]难以置信，一个曾经从事过复杂软件系统开发的人竟然会相信可以构建出没有故障的系统……”
遗憾的是，尽管这些关于我们越来越依赖的软件系统类型的描述令人警醒，但这些讨论中却遗漏了一个关键点。那就是，大多数软件故障都未被发现和报告。在某些情况下，故障很微妙——甚至是间歇性的——因此很容易被忽略。例如，统计软件应用程序可能会显示错误计算的统计数据。这种错误计算的统计数据是故障，但可能不会立即显现出来，尤其是对于非专家来说。然而，这种故障可能会导致错误或次优的决策，因此可能会造成非常严重的后果。
显然，编写软件的工艺——无论使用的集成开发环境有多复杂、编程方法有多复杂或程序员的技能有多高——都是一门不完美的工艺，会导致错误。这一现实意味着，在软件发布之前发现这些错误取决于软件测试工作的严谨性。正如 NIST 和 Wong 等人指出的那样，未能做到这一点可能会导致严重后果。软件工程界的标志性人物 Barry Boehm 在其关于软件工程经济学的开创性论文（Boehm，1984）中指出，在软件部署后查找和修复错误的成本通常至少是部署前识别和修复错误的 100 倍。
鉴于这种背景，那么软件测试方法是否就完全不够用呢？我认为并非如此。事实上，软件测试研究 50 多年来一直是一个热门的研究领域。2014 年，Orso 和 Rothermel 撰写了一篇论文，介绍了他们发表论文之前 15 年软件测试方法开发方面取得的重大进展（Orso and Rothermel，2014 年）。2000 年之前的 15 年也是软件测试方法飞速发展的时期。Glenford Myers（Myers，1978 年）和 Boris Beizer（Beizer，1984 年）是软件测试界的两位标志性人物，他们在 70 年代和 80 年代做出了开创性的工作。遗憾的是，主要问题在于采用，而不是测试方法是否充分。多年来，尽管有经验证据表明软件测试方法很有效，但软件开发社区在采用严格的软件测试方法方面进展缓慢（Kuhn 等人，2015 年，Morgan，2018 年）。这种情况因两种软件开发现实而加剧。众所周知，软件测试工作资金不足、资源不足。此外，近年来软件开发工作的速度和复杂性急剧增加
软件系统现在比以往任何时候都更加普及，在我们的生活中发挥着越来越重要的作用。强大的软件测试方法至关重要，这是所有软件开发从业者都需要更加注意的软件开发方面。为了满足这一需求，我们撰写了这一系列博客文章。这篇文章是该系列的第二篇，后续还会有更多文章。
参考文献
Beizer, Boris。软件系统测试和质量保证。Van Nostrand Reinhold Co.，1984 年。
Boehm, Barry W.“软件工程经济学。” IEEE 软件工程学报(1984): 4-21。
Kuhn, DR、Bryce, R.、Duan, F.、Ghandehari, LS、Lei, Y. 和 Kacker, RN (2015)。“组合测试：理论与实践。”计算机进展， 99，1-66 。
Myers, Glenford J.“程序测试和代码走查/检查中的受控实验。”《ACM 通讯》 21.9（1978）：760-768。
Morgan, J. (2018)。“组合测试：一种基于覆盖阵列的系统和软件测试方法。”系统和软件测试中的分析方法，131-158。
NIST 报告。“软件测试基础设施不足对经济的影响。”国家标准与技术规划研究所报告 02-3。2002 年 5 月。
Orso, A. 和 Rothermel, G. (2014)《软件测试：研究游记 (2000–2014)》，载于《软件工程未来论文集》 ，ACM，2014 年 5 月，第 117–132 页
Wong, W. Eric、Vidroha Debroy 和 Andrew Restrepo。“软件在近期灾难性事故中的作用。” IEEE 可靠性协会 2009 年度技术报告59.3（2009 年）。
Wong, W. Eric、Xuelin Li 和 Philip A. Laplante。“更加熟悉我们的敌人并铺平前进的道路：回顾错误在软件故障中所扮演的角色。” 《系统与软件杂志》 133（2017 年）：68-94。
如果一个软件提供成千上万种不同的功能，就很难保证它们能够协同工作，而且很难保证两个功能与第三个功能协调一致。
这可以在Jmp 和 JSL 中的 Tiny Traps中看到。
有时，2 或 3 个很酷的功能的组合会带来意想不到的结果。
测试所有这些微小的交互非常困难 - 但用户的群体智能有机会；）
非常感谢 JMP 支持团队为组织和引导用户反馈所做的努力！
感谢开发人员热心为我们提供如此出色的软件！
组合测试（请参阅下文中的帖子参考资料）是一种专注于因交互而导致的故障的测试方法。底层数学对象是一个覆盖数组，因此它是一种非常高效的方法，即使有数千个输入！这将是未来博客的主题。
Kuhn, DR、Bryce, R.、Duan, F.、Ghandehari, LS、Lei, Y. 和 Kacker, RN (2015)。“组合测试：理论与实践。”计算机进展， 99，1-66 。
Morgan, J. (2018)。“组合测试：一种基于覆盖阵列的系统和软件测试方法。”系统和软件测试中的分析方法，131-158。
很棒的博客 @JosephMorgan ，期待下一次。
当使用覆盖阵列时，您受到可以进行的测试集数量的限制，第一次测试的结果/分析是否表明强度为 2（覆盖了一些强度为 3 的因素），这是否允许您计划第二个覆盖阵列，并在第一个覆盖阵列中删除一些因素，以便您可以捕获强度为 4 或更高？是否有任何正在开发的方法可以允许使用覆盖阵列进行分析和顺序测试工作流程？
谢谢！
@Vins ，有正在开发的方法可以做到这一点。所以，答案是“是的，是的”。就在几周前，在 MEMOCODE-2024（ https://memocode2024.github.io/program.html ）上，我们的同事就此发表了演讲。其想法是使用贝叶斯分析来指导后续测试用例的选择（即顺序测试用例设计方法）。论文标题是：
“MaLT：机器学习指导的复杂软件系统测试用例设计和故障定位。”
MEMOCODE-2024 会议的论文集即将发布，但如果您使用 Google Scholar 搜索标题，也许可以找到该论文。我可能会在我的组合测试博客中对此进行一些介绍。
我确实同意@JosephMorgan和@hogi关于软件测试的重要性以及进行测试的可能性的巨大领域。
事实上，每个组织或用户可能都有自己独特的操作结构来测试软件。
因此我认为，当在新版 JMP 中发现新的技术问题时，应该允许重新使用旧软件版本（用户已经习惯的版本），因为这些修复不可能在一夜之间完成。
