探討如何為受法規監管的產業選擇合適的單元測試框架，並評估 GoogleTest 是否適用於此類情境。同時了解 C/C++test CT 經 TÜV SÜD 認證的 GoogleTest 版本，如何補足缺少的功能，以簡化認證流程並降低合規成本。
對於開發安全關鍵（safety-critical）C 與 C++ 軟體的團隊而言，選擇合適的單元測試框架至關重要。ISO 26262、DO-178C 與 IEC 61508 等標準，皆要求具備需求可追溯性（requirements traceability）、結構化程式碼覆蓋率（structural code coverage）以及工具認證（tool qualification），以確保符合法規要求。
傳統上，企業多半依賴專為這些需求打造的商業專有框架。如今，許多團隊開始採用 GoogleTest 等開源方案，原因包括能降低訓練成本並加速導入：
- 彈性
- 可無縫整合 Bazel 與 CMake
- 開發者普遍熟悉
即便如此，單靠 GoogleTest 仍缺少關鍵的合規功能。若要符合安全關鍵開發需求，仍需額外擴充其功能與相關文件能力。
安全關鍵環境中選擇單元測試框架的關鍵評估標準
在安全關鍵開發中選擇單元測試框架，本質上是在合規性、生產力與成本之間取得平衡。
開源工具雖然具備成本優勢，但通常缺乏認證支援與工具資格認證套件（qualification kits），因此在受監管環境中會帶來風險。試想，如果在產品即將發布前發生工具相關問題，卻沒有原廠可提供協助，將會是很大的風險。
另一方面，商業專有框架通常提供完整的合規功能，也具備原廠支援。但其僵化的格式與使用規範，往往會拖慢開發效率。
有些商業工具甚至強制使用圖形化介面建立測試，這通常是開發者相當排斥的做法。
要做出正確選擇，團隊必須綜合評估合規準備程度、測試建立便利性、整合成本，以及長期維護性。以下列出選擇框架時應評估的重要項目。
重點1. 安全標準對單元層級測試的要求
ISO 26262 等標準要求單元測試工具不只是能執行測試，還必須提供證據、可追溯性與覆蓋率資料，以證明系統符合安全目標。
符合規範的單元測試框架必須支援：
- 需求導向測試（requirements-based testing）：支援將每個測試對應到特定需求。
- 可追溯性報告（traceability reporting）：產出需求、實作與測試結果之間的對應報告，作為合規證據。
- 結構化覆蓋率指標（structural coverage metrics）：提供已執行程式碼的覆蓋率報告，包括 statement coverage、branch coverage，以及多數情況下的 MC/DC coverage。
- 故障注入與強健性測試（fault injection and robustness testing）：驗證系統在發生非預期錯誤時的反應，並確保系統能安全失效（fail safely）。
一般的開源單元測試框架（例如 GoogleTest）通常不具備上述功能，唯一例外是故障注入測試，可透過 mocking framework 協助實現。
程式碼覆蓋率、可追溯性報告與相關功能，則需額外搭配外部工具。
工具資格認證（tool qualification）也是另一個重要議題。所有安全標準皆要求工具認證，而若要自行為開源工具完成這項流程，通常會耗費大量時間。
許多商業工具已預先完成認證，可大幅簡化資格認證流程。因此，在評估候選框架時，務必完整了解其提供的認證支援內容。
重點2. Build 與 Pipeline 整合便利性
在安全關鍵專案中，單元測試框架必須能順利整合現代化 build system 與 CI/CD pipeline。複雜的 C++ 專案通常依賴 Bazel 等工具進行分散式建置（distributed builds）。若框架能自然融入這些環境，將可降低維護成本並加快回饋循環。
GoogleTest 等開源框架在這方面特別有優勢。其採用輕量、以程式碼為核心的方式，避免使用專有格式，因此更容易整合進既有的 build 與 CI 自動化流程。
這種彈性也是 GoogleTest 成為大型 C++ 開發（包括 ADAS 與自動駕駛專案）事實標準（de facto standard）的原因之一。
許多商業專有框架在複雜系統中的整合難度較高。它們通常會將測試資產與設定分散於不同檔案中，並強制採用其特定方式建置測試 binary。因此，若要為大型複雜專案選擇框架，務必要先了解 build 與 CI pipeline 的整合成本。
重點3. 開發者訓練成本
在選擇單元測試框架時，訓練成本是重要考量。商業專有方案通常要求團隊學習特定廠商的 API 或格式，這會拖慢導入速度並提高 onboarding 成本。對大型組織而言，這項因素尤其重要。
相較之下，GoogleTest 採用標準 C++ 語法結構。由於許多開發者早已熟悉它，特別是在大型 C++ 團隊中，因此使用 GoogleTest 可：
- 降低學習曲線。
- 縮短上手時間。
- 降低整體訓練成本。
因此，在高度重視生產力與成本效益的商業專案中，GoogleTest 具備明顯優勢。
重點4. 測試案例建立與維護成本
長期來看，單元測試的成本通常不是來自工具授權費，而是來自建立與維護測試案例所需的人力成本。
商業專有框架可能提供自動化測試產生功能，但其僵化、資料導向（data-driven）的 API，往往讓現代 C++ 程式碼的測試撰寫與維護變得繁瑣。
相較之下，GoogleTest 採用乾淨且原生於 C++ 的 API，使開發者更容易表達複雜測試情境，並長期維護。這能降低額外負擔，協助團隊跟上持續演進的程式碼架構；而在安全關鍵專案中，測試本來就必須隨需求與設計變更同步演進，因此這點尤其重要。
重點5. 既有測試案例遷移成本
對於已有大量單元測試的團隊而言，更換框架時的遷移成本可能相當可觀。商業專有工具通常依賴特定廠商格式或腳本語言，因此難以重複利用既有測試案例，成本也會較高。
若專案中已經有大量 GoogleTest 測試案例，這可能會成為重要決策因素。相較於導入新的商業專有框架，並將所有既有 GoogleTest 全數遷移過去，直接擴充 GoogleTest 以符合安全標準需求，往往更具成本效益。
若原本已使用商業專有框架建立大量測試案例，並考慮更換工具，那麼將測試遷移至像 GoogleTest 這種使用原生 C/C++ 格式的框架，通常會比在兩套不同商業框架之間遷移來得便宜許多。
根據選擇標準評估 GoogleTest
下表整理上述評估項目，並比較 GoogleTest 與典型商業／專有單元測試框架的差異。
| 評估項目 | GoogleTest | 典型商業框架 |
| 需求導向測試與可追溯性報告 | 不支援，需搭配外部工具 | 完整支援，包含 traceability report |
| 程式碼覆蓋率支援 | 未內建，需搭配外部工具 | 內建且具安全認證 |
| 故障注入測試 | 可透過 GoogleMock 實現 | 完整整合支援 |
| 工具資格認證／認證支援 | 不提供 | 提供，通常包含認證 |
| Build system 與 CI/CD pipeline 整合 | 簡單且支援良好 | 明顯更複雜且耗時 |
| 測試案例建立與維護成本 | 低 | 較高，尤其是複雜或 heavily template 化的 C++ 程式 |
| 測試案例自動產生 | 不支援 | 通常支援基本 input/output 組合產生 |
| 既有測試遷移成本與工作量 | 低 | 高 |
乍看之下，商業專有框架似乎更具優勢，特別是在安全關鍵需求支援方面更完整。確實，對於 C 專案與較小型、較不複雜的 C++ 系統而言，這些工具通常能直接提供完整且符合規範的解決方案。
但對於大型且複雜的 C++ 專案，情況就完全不同了。
現有商業框架在整合現代 build system、CI/CD 自動化，以及管理較高測試開發成本等方面的挑戰，很快就可能超過其原本帶來的好處。
在許多情況下，相較於持續承受商業專有框架帶來的額外負擔（例如不理想的測試格式與有限的開發彈性），直接擴充 GoogleTest 缺少的能力，並依需求進行工具資格認證，往往是更務實的做法。
隨著 Parasoft C/C++test CT 的出現，這種做法變得更加可行。該產品專為擴充 GoogleTest 而設計，可補足缺少功能，並簡化符合安全標準所需的工具資格認證流程。
C/C++test CT 如何補足 GoogleTest 的功能安全合規能力
C/C++test CT 擴充了 GoogleTest 的能力，使其成為適用於現代 C++ 開發、完整且符合安全需求的測試解決方案，具備：
- 完整的需求可追溯性報告
- 完整的程式碼覆蓋率監控，包括 MC/DC 指標
- AI 驅動的測試產生功能，可加速並提升測試建立效率
整合於 C/C++test CT 中、業界首個通過 TÜV 認證的 GoogleTest framework，已獲准用於安全關鍵開發，支援 ISO 26262、IEC 61508、IEC 62304 與 EN 50716 等標準。
此項認證可免除額外工具資格認證需求，大幅簡化合規流程並降低行政負擔。
下表說明 C/C++test CT 搭配 GoogleTest，如何成為傳統商業框架之外，一套完整且現代化的安全關鍵 C++ 軟體測試方案。
| 評估項目 | GoogleTest + C/C++test CT | 典型商業框架 |
| 需求導向測試與可追溯性報告 | 完整支援，包含 traceability report 與測試結果同步至 RMS | 完整支援，包含 traceability report |
| 程式碼覆蓋率支援 | 完整支援 | 內建且具安全認證 |
| 故障注入測試 | 可透過 GoogleMock 實現 | 完整整合支援 |
| 工具資格認證／認證支援 | 提供 TÜV 認證 | 提供，通常包含認證 |
| Build system 與 CI/CD pipeline 整合 | 簡單且支援良好 | 明顯更複雜且耗時 |
| 測試案例建立與維護成本 | 低 | 較高，尤其是複雜或 heavily template 化的 C++ 程式 |
| 測試案例自動產生 | AI 驅動，用於補足 coverage gap | 通常支援基本 input/output 組合產生 |
| 既有測試遷移成本與工作量 | 低 | 高 |
總結
對於開發現代化大型 C++ 應用程式的團隊而言，C/C++test CT 搭配 GoogleTest 能在開發效率、安全合規與工具鏈簡潔性之間取得理想平衡。它補足了開源框架的彈性與商業認證方案的嚴謹性之間的落差，提供一條兼具技術最佳化與實務效率的解決方案。
簡單來說，透過 C/C++test CT，你不再需要在開發敏捷性與安全合規之間做取捨，而是能同時兼顧兩者。
歡迎前往 ➤ 與 FSG 功能安全專家們繼續深入探討
本文由Parasoft提供