我們有一個客戶，正在根據(jù)IEC 61508 功能安全標準開發(fā)一個安全關(guān)鍵型項目，他與我們聯(lián)系。要求我們提供指導(dǎo)，通過進一步減少單元測試產(chǎn)生的干擾來提高開發(fā)人員的生產(chǎn)力，這些干擾就是由于缺乏打樁而產(chǎn)生的。

我們了解到，客戶進行單元測試的方式更接近于集成測試。在他們的過程中，要測試的單元沒有與其依賴組件（項目中的其他文件或功能）隔離開來，單元測試用例是針對大多數(shù)已完成的應(yīng)用程序執(zhí)行的。

Parasoft 產(chǎn)品免費試用

這種方法不是典型的單元測試。它通常被稱為集成級測試。集成測試在證明功能性和非功能性要求的良好測試覆蓋率方面非常有效。如果啟用了結(jié)構(gòu)代碼覆蓋，它還可以提供出色的測試覆蓋率。試中的打樁為何能改進集成測試

測試中的打樁是什么？

單元測試的做法通常是隔離功能、方法或程序。這種隔離是通過剔除依賴性和強制執(zhí)行特定的執(zhí)行路徑來完成的。

打樁取代了依賴于本函數(shù)外的代碼。它還為開發(fā)人員或測試人員提供了操縱打樁響應(yīng)或結(jié)果的能力，以便以各種方式和各種目的運用該單元，例如，確保該單元性能可靠，安全，并且在某些情況下，也沒有安全漏洞。

為什么要使用打樁？

解釋為什么要使用打樁及其帶來的價值的最佳方法是通過一個用例逐步說明。例如，看看下面的代碼：

在函數(shù)的開頭，有一個if語句，用于測試樣本緩沖區(qū)是否成功分配。這個函數(shù)的大多數(shù)測試用例都是在沒有任何打樁的情況下實現(xiàn)的，因為它們關(guān)注的是常規(guī)的控制流，除了測試用例，它在緩沖區(qū)分配失敗時檢查函數(shù)的行為。這個測試用例要allocateSampleBuffer 函數(shù)的打樁來模擬故障。

一旦添加了打樁，它將被一致地應(yīng)用到測試代碼中。在處理“分配失敗”測試用例的用戶將有一個簡單的方法將一個特殊的回調(diào)函數(shù)安裝到打樁中，這將模擬預(yù)期的效果：分配失敗或什么都不做，因為在默認情況下打樁返回一個空指針，這是測試用例的預(yù)期。但所有其他測試用例現(xiàn)在都需要注意，因為必須為它們添加一個打樁配置，以避免控制流中不必要的更改。

當(dāng)然，開發(fā)人員可以返回并重新配置他們的測試用例來解決打樁，但這意味著要花額外的時間分析失敗的原因，為打樁準備專用的回調(diào)函數(shù)，并消除測試過程中的干擾，這是客戶聯(lián)系我們時的主要關(guān)心的問題。

此外，醫(yī)療設(shè)備軟件開發(fā)中的風(fēng)險管理還需要深入了解醫(yī)療軟件缺陷可能造成的危害程度。這可以通過風(fēng)險索引來完成，風(fēng)險索引根據(jù)風(fēng)險的嚴重程度對風(fēng)險進行分類。

在醫(yī)療設(shè)備軟件方面，建立風(fēng)險指數(shù)有助于確定風(fēng)險管理指標，例如在軟件發(fā)布使用之前應(yīng)進行的所需測試、驗證和確認級別。它還可以幫助為確保軟件持續(xù)安全性和有效性所需的持續(xù)測試、監(jiān)控和維護定下基調(diào)。

在單元測試C和C++代碼中使用打樁

Parasoft C/C++test讓自動生成樁或手動創(chuàng)建樁變得更加容易。該選項在兩個地方可用：

1．對于自動生成的打樁：

測試配置->執(zhí)行->符號（tab）

2．對于用戶打樁和自動打樁：

打樁視圖的打樁設(shè)置面板

選中“插入對原始函數(shù)的調(diào)用”選項后，Parasoft C/C++test會更改打樁的默認生成方式。使用新選項生成的打樁將充當(dāng)代理并調(diào)用原始函數(shù)定義，除非用戶提供一個特定于測試用例的回調(diào)函數(shù)來執(zhí)行替代活動。

在默認情況下，不使用新選項生成的樁（包括遺留打樁）不會嘗試調(diào)用原始符號。如果沒有安裝特定于測試用例的回調(diào)函數(shù)，打樁將什么都不做，只是返回一個默認值，例如空指針或零數(shù)值。

何時使用打樁?

為了確保差異是明確的，讓我們將情況與用戶未提供專用回調(diào)時啟用和未啟用的“插入對原始函數(shù)的調(diào)用”選項進行比較。

這是為goo函數(shù)打的樁，不啟用“插入對原始函數(shù)的調(diào)用”選項。它的工作方式如下：

以下是啟用“插入對原始函數(shù)的調(diào)用”選項后為goo函數(shù)生成的相同打樁的查找方式：

正如我們所見，使用新選項添加的打樁對測試代碼是透明的。它們只是對原始定義執(zhí)行代理調(diào)用，除非有人提供需替代操作的回調(diào)代碼。

打樁限制和難點

在打樁函數(shù)沒有原始定義的情況下，會發(fā)生什么呢？如果沒有定義替代行為的回調(diào)，打樁會如何出現(xiàn)什么情況？

C/C++test的巧妙之處在于它會自動檢測這種情況。在測試構(gòu)建期間，打樁好的函數(shù)，即用戶樁將重新配置自己。當(dāng)沒有安裝回調(diào)函數(shù)時，它不會調(diào)用原始定義，并將返回一個安全的默認值。

集成測試中的打樁：示例和總結(jié)

在這種半集成測試中，同時處理測試用例時，C/C++test極大地減少了不同團隊成員之間的干擾。開發(fā)人員A添加的打樁代碼不會改變開發(fā)人員B添加的測試用例的測試代碼的行為。

如果開發(fā)人員B決定他們需要為其中一個測試用例的打樁函數(shù)配置替代操作，他們可以創(chuàng)建一個特定于測試用例的回調(diào)函數(shù)，為打樁函數(shù)實現(xiàn)所需的替代邏輯，并將該回調(diào)函數(shù)作為測試用例配置的一部分安裝在現(xiàn)有的打樁中。

這就避免了不同人員有著不同測試需求的難題了。如果您對以上內(nèi)容感興趣，請持續(xù)關(guān)注我們，

了解更多有關(guān)Parasoft產(chǎn)品咨詢，歡迎咨詢