函數庫、組件產品的測試方法

2019-11-17 04:47:18

字體：大中小

來源：轉載

供稿：網友

　　這是我為公司的接口類產品制定的測試指南，文中列出了對于函數庫、組件等對象（下文統稱函數接口）的測試過程。這里描述的屬于確認測試過程，但由于從形式上類似于單元測試，而且也基本適用于單元測試的過程，所以放到單元測試欄目中。

　　1.1 概述

　　函數接口（或稱API）是公司的一個產品類型。目前包括：TRS Database為各類平臺提供的接口，以及TRS CKM工具包，以后有可能會繼續增加。本部分的測試指南，描述了對這類產品進行測試時的參考過程。

　　下面首先給出整體的測試過程，然后針對每個子過程需要進行的工作進行具體描述，最后是幾點補充說明。

　　1.2 測試過程

　　函數接口的整體測試過程如下：

　　* 制定測試計劃

　　* 設計測試用例

　　* 執行測試

　　* 編寫可復用的測試代碼

　　* 增強測試

　　* 結束測試

　　1.3 過程說明

　　下面是對各個子過程的具體說明：

　　1.3.1 制定測試計劃

　　分析被測試對象的具體情況，制定測試計劃，形成文檔。測試計劃至少要包括以下內容：

　　　測試范圍。測試要覆蓋哪些庫以及庫中的哪些函數，要覆蓋哪些文檔，包含哪些測試類型等等。

　　　測試工具。選擇什么工具組織測試代碼，是否還需要其它的輔助性測試工具。

　　　測試環境。都需要在什么環境下執行測試，環境指硬件類型、OS、DB等等。

　　　測試數據組織。對于測試代碼所需要的測試數據，以什么方式來組織和保存。

　　　進度安排。各個階段的工作內容、時間安排。

　　　測試尺度。測試的深度和廣度是什么。根據現有的資源情況，在計劃中設定一個標準，避免測試的盲目性和隨意性。

　　1.3.2 設計測試用例

　　按照函數接口說明文檔，依據測試計劃中的測試尺度來設計測試用例，形成文檔。

　　函數接口的測試用例設計，與傳統GUI界面產品的用例設計思路是一樣的，包括測試輸入（正常、異常輸入）和預期輸出兩部分，等價劃分、邊界值等設計方法也同樣適用，只是這時的界面變成了函數接口的輸入參數，而不再是GUI元素。

　　1.3.3 執行測試

　　依據測試用例設計文檔，編寫調試代碼，執行測試。這是函數接口測試中最為耗時的過程，Bug也主要是在這個過程中被發現的。開發人員修正Bug，測試人員進行回歸測試，直至Bug被關閉。

　　1.3.4 編寫可復用的測試代碼

　　當一個函數的bug修正基本完成后，整理調試代碼，將其轉化為可復用測試代碼。

　　函數接口最后的測試代碼與其測試用例設計應該是一致的，測試代碼是測試用例的具體實現。假如測試代碼需要獨立的測試數據，則要具體記錄下這些數據的相關信息。測試用例設計文檔、測試代碼、測試代碼所需測試數據，這三者構成完整的測試程序。

　　在編寫測試代碼的時候需要注重：不同測試部分的測試數據應該互不干擾，各部分的測試代碼，在測試結束時要負責恢復測試環境，以使下一個測試能正常運行，也便于測試代碼的維護。

　　1.3.5 增強測試

　　這是一個可選項目，不是必須的。是否進行這項工作，在制定測試計劃的時候就要考慮清楚。

　　對于函數接口的增強測試，可以考慮的測試內容包括（但不限于）：代碼測試覆蓋率的統計、函數接口的Run-time錯誤檢測。這類測試工作需要工具的支持，可選的工具如：Compuware的Devpartner，IBM的PurifyPlus等。

　　1.3.6 結束測試

　　結束測試階段的工作包括：編寫測試報告、測試資料整理。

　　完成測試計劃中羅列的所有工作，達到預期的測試目標后，進行測試報告的編寫。

　　對于測試過程中產生的測試資源——測試計劃、測試用例設計、測試代碼，這些是以后測試復用的基礎。假如這些資源本身不能說明自己，則需要整理一份單獨的說明文檔，供以后參考使用。

　　1.4 補充說明

　　1.4.1 測試過程的補充說明

　　對于上面描述的測試過程中的‘設計測試用例’、‘執行測試’、‘編寫可復用的測試代碼’這三個步驟，不是完成一項后，才開始進行下一項，而通常是一個交替進行、逐步迭代的過程。先制定好測試用例文檔的整體結構，然后設計一個函數接口的測試用例，接著執行對其的測試，最后整理成可復用的測試代碼。針對每個函數接口都重復這個過程，直至完成所有函數接口的測試。

　　1.4.2 測試過程中產生的測試資源

　　測試過程中產生，測試結束后需要存檔的測試資源包括：

　　測試計劃（文檔）；

　　測試用例設計（文檔）；

　　測試代碼及相關數據（代碼、數據）；

　　測試報告（文檔）；

　　其它的相關說明文檔（假如有的話）；

　　測試框架的介質（假如選用了第三方測試框架的話）。

　　1.4.3 函數接口測試的自動化

　　函數接口產品的一個特點就是對外表現比較穩定，因此一旦實現了對其測試過程的自動化，積累起可復用的測試資源，就會大大縮短以后該產品的測試周期。所以對于函數接口的測試，建議都能以測試自動化的過程進行組織。

　　為了實現函數接口的測試自動化，就需要選擇一個穩定、可靠的測試框架來組織測試代碼，在這里建議使用XUnit工具。

　　（注：針對不同的開發語言，Xunit提供了不同的版本，如Junit（for java），CppUnit（for C/C++），Nunit（for MS .Net）等等，每種主流的語言都有其對應的Xunit框架。Xunit是Open Source的工具，可以從http://sourceforge.net上下載。
）

　　1.4.4 測試代碼的維護

　　測試代碼并不是寫完后一次后就一勞永逸了。隨著被測產品的升級，測試代碼也需要作出相應的調整，以適應被測產品的變化。

上一篇：.NET異常代碼編寫

下一篇：代碼編寫中的心理學與美學