2002 年，美國國家標準與技術研究所 (NIST) 發布了一份報告，詳細介紹了軟體測試不足所造成的經濟影響（NIST Report，2002）。報告的結論是：
“…軟體測試基礎設施不足造成的國家年度成本估計為 222 億美元至 595 億美元。”
NIST 報告也指出，軟體測試實踐的狀況嚴重缺乏。
七年後，Wong 等人在 IEEE 可靠性協會報告（Wong 等人，2009 年）中回顧了 15 個廣為人知的軟體故障，其中幾個導致了傷亡，並得出結論：
“……需要實施更好的測試程序和實踐，對於與安全關鍵系統相關的軟體尤其如此。”
在最近的一篇文章中，Wong 等人研究了多個行業的一系列軟體故障（Wong 等人，2017），並提出了一個相當發人深省的觀點：
“……令人失望的事實是，軟體遠非沒有缺陷，每年都會花費大量資金來修復或維護（有缺陷的）軟體。”
文章分析了 1985 年到 2015 年 30 年間的軟體故障；確定導致故障的軟體錯誤的性質以及其他影響因素，例如使用者錯誤；並將故障分為兩類：致命的（導致生命損失）和非致命但造成重大經濟損失的。致命的失敗包括 1985 年的 Therac-25 事件（至少有 6 名患者接受了過量輻射）以及 1995 年至 1997 年間的民航事故（導致 650 多人喪生）。其中還包括2014年的伊波拉事件，電子健康記錄軟體故障導致一名感染伊波拉的患者被誤診，導致隨後死亡。非致命故障包括導致 200 萬美元損失的核電廠軟體故障以及導致 70 億美元損失的阿麗亞娜 5 號軟體故障。在結論中，作者提出了以下觀察：
「......嵌入式軟體在公共基礎設施、交通系統、消費產品等領域的普遍存在讓[我們]難以置信，從事複雜軟體系統工作的人會相信可以毫無故障地建立這樣的系統……”
可悲的是，儘管對我們越來越依賴的軟體系統類型進行了這些發人深省的描述，但這些討論中仍然缺少一個關鍵點。也就是說，大多數軟體故障都未被發現和報告。在某些情況下，故障是微妙的，甚至是間歇性的，因此很容易被忽略。例如，統計軟體應用程式可能會顯示錯誤計算的統計資料。這種錯誤計算的統計數據是失敗的，但可能不會立即顯現出來，尤其是對於非專家而言。然而，此類失敗可能會導致錯誤或次優的決策，因此可能會產生非常嚴重的後果。
顯然，無論所使用的整合開發環境的複雜性、程式設計方法的複雜性或程式設計師的技能如何，編寫軟體的工藝都是不完美的，並且會導致錯誤。這一現實意味著在軟體發布之前需要透過嚴格的軟體測試工作來發現這些錯誤。正如 NIST 和 Wong 等人所言。等人指出，不這樣做可能會導致嚴重後果。軟體工程界的標誌性人物Barry Boehm 在他關於軟體工程經濟學的開創性論文（Boehm，1984）中指出，軟體部署後發現並修復錯誤的成本通常比識別和修復錯誤的成本至少高出100 倍。
在這樣的背景下，軟體測試方法是否就顯得不夠充分了呢？我認為事實並非如此。事實上，軟體測試研究 50 多年來一直是個活躍的研究領域。 2014 年，Orso 和 Rothermel 撰寫了論文發表之前的 15 年中在開發軟體測試方法方面取得的實質進展（Orso 和 Rothermel，2014）。 2000年之前的15年也是軟體測試方法急遽發展的時期。 Glenford Myers (Myers, 1978) 和 Boris Beizer (Beizer, 1984) 這兩位軟體測試界的標誌性人物在 70 年代和 80 年代做出了開創性的工作。遺憾的是，主要問題是測試方法的採用，而不是充分性。多年來，軟體開發社群在採用嚴格的軟體測試方法方面進展緩慢，儘管有可用的經驗證據證明其實用性（Kuhn 等人，2015 年，Morgan，2018 年）。兩個軟體開發現實加劇了這種情況。眾所周知，軟體測試工作資金和資源不足。此外，近年來軟體開發工作的速度和複雜性急劇增長
軟體系統現在比以往任何時候都更加普遍，並且在我們的生活中發揮著越來越重要的作用。健壯的軟體測試方法的重要性是顯而易見的，並且是所有軟體開發從業者都需要更加了解的軟體開發的一個方面。為了滿足這項需求，我們撰寫了這一系列部落格文章。這篇文章是該系列的第二篇文章，以後還會有更多文章。
引用的作品
貝澤爾、鮑里斯.軟體系統測試和品質保證。範諾斯特蘭德萊因霍爾德公司，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。
摩根，J.（2018）。 “組合測試：一種基於覆蓋數組的系統和軟體測試方法。”系統和軟體測試中的分析方法，131-158。
美國國家標準技術研究所報告。 “軟體測試基礎設施不足的經濟影響。”國家標準與技術研究所規劃報告 2002 年 5 月 2-3 日。
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 。
摩根，J.（2018）。 “組合測試：一種基於覆蓋數組的系統和軟體測試方法。”系統和軟體測試中的分析方法，131-158。
很棒的博客 @JosephMorgan ，期待下一篇。
當使用覆蓋陣列並且您受到可以執行的測試集數量的限制時，您的第一個測試的結果/分析是否可以說強度2（覆蓋了一些強度3）允許您計劃具有某些因素的第二個覆蓋陣列掉在第一個，這樣你就能獲得 4 或以上的力量？是否有任何正在開發的方法可以允許透過覆蓋陣列進行分析和順序測試工作流程？
謝謝！
@Vins ，開發中有一些方法可以做到這一點。所以，答案是「是的，是的」。就在幾週前，在 MEMOCODE-2024 ( https://memocode2024.github.io/program.html ) 上，我們的同事就此發表了演講。其想法是使用貝葉斯分析來指導後續測試案例的選擇（即順序測試用例設計方法）。論文的標題是：
“MaLT：機器學習引導的測試案例設計和複雜軟體系統的故障定位。”
MEMOCODE-2024 會議的會議記錄即將發布，但如果您對標題進行 Google 學術搜索，也許可以找到論文。我可能會在我的組合測試部落格中對此進行一些討論。
我確實同意@JosephMorgan和@hogi關於軟體測試的重要性以及進行測試的巨大可能性的觀點。
事實上，每個組織或使用者可能都有其獨特的操作結構來測試軟體。
因此，我認為，當在新的 JMP 版本中發現新技術問題時，應該允許重新使用舊軟體版本（用戶已經習慣了）的替代方案，因為此修復不可能一蹴而就。
