軟件測試方法常見誤區的思考

馮濟舟

（孔徑陣列與空間探測安徽省重點實驗室，合肥，230088）

交流園地

軟件測試方法常見誤區的思考

馮濟舟

（孔徑陣列與空間探測安徽省重點實驗室，合肥，230088）

文摘：根據實際項目經驗，分析軟件測試技術中存在的誤區，從測試原則、硬件指標、嵌入系統、軟硬件應用以及測評等方面歸納和總結出解決方法。

軟件測試；測試性能；質量保證。

隨著軟件規模和復雜度不斷提高，作為保障軟件質量的重要活動——軟件測試技術也不斷發展，軟件測試已成為除了評審手段外軟件質量保證的重要活動[1-2]，對軟件測試技術的要求更加苛刻。軟件測試是能力成熟度模型集成（CMMI，CapabilityMaturityModelIntegration）中驗證（Ver，Verification）與確認（Val，Validation）過程域的重要表現形式，是保障軟件可靠性的重要手段。如今各個軟件項目重視軟件測試過程，在增加軟件測試人力資源的同時，受測試門檻認知程度及測試人員系統培訓不到位的影響，未能及時發現軟件測試技術上存在的誤區，導致影響軟件測試質量下降，給產品可靠性帶來巨大隱患的現象時有發生。筆者根據工作實踐對軟件測試方法常見的誤區，提出了解決方法，以增強測試人員對軟件測試技術的正確認識，保證軟件測試順利而有效地進行。

1 測試有效性原則誤解

對于什么樣的測試才算是有效的測試認識不清，是只要發現問題，不需要可復現的測試就是有效性測試？還是用最少步驟、最直接方法發現的問題才是有效性測試？

測試的目的是發現問題，然后是解決問題，因此對測試有效性原則的討論可以軟件開發人員如何查找問題和解決問題為出發點。如果只發現問題而不能復現的測試，會導致無法定位，也就無法對問題進行修正，這種測試方法是無效的測試。如果使用最少步驟發現問題，雖然可以幫助開發人員將問題定位到具體代碼位置并進行修改，然而在實際測試過程中由于代碼間的強耦合性以及系統的邏輯關系比較復雜，測試執行的步驟很難達到最少、最直接的要求，造成定位的模糊，而且此種方法的測試往往也會耗費大量的時間和精力。有沒有什么有效的方法可以快速、準確地解決定位問題呢？

在開發環境中存在調試模式工具，利用開發環境調試程序方法，使用單步運行程序和斷點，觀察運行環境的變化，從而達到對所開發源程序運行過程的跟蹤和監控。只要保證被測問題是可復現的，那么無論測試步驟多么繁瑣，只要在此種模式下就可以跟蹤出異常問題的代碼行數以及定位軟件源代碼問題所在。

2 軟件性能測試中缺乏對硬件指標的考慮

軟件性能測試，即根據需求描述中對軟件的性能要求，在不核對被測軟件實際硬件環境與需求描述中的硬件需求指標要求的情況下進行測試。

在編寫軟件需求文檔時，開發人員往往把重心放在描述軟件的需求能力上，忽視了軟件對于硬件資源的需求；而測試人員常常把重心放在對功能、性能的驗證上，忽略了被測軟件所運行的實際硬件平臺與需求描述中對于硬件需求指標要求的核對。在此種情況下，對軟件所做的性能測試無法達到對軟件性能指標驗證的效果，因此所做的軟件性能測試無效。

同一個軟件的同一功能的處理性能在高配置硬件條件、實時操作系統下的運行效果與低配置硬件條件、分時操作系統下的運行效果肯定是截然不同的。高配置實時操作系統的處理效率一定會比低配置分時操作系統的處理效率高，脫離硬件資源需求的軟件性能測試是沒有意義的。

要做好軟件的性能測試，首先，開發人員重視需求描述中對于硬件資源要求的描述；其次，測試人員在軟件測試前核對實際硬件平臺與需求描述中所需要的硬件指標要求的一致性，在已有或可能出現的最低硬件配置條件下驗證軟件性能指標的實現情況。

3 嵌入式系統測試依賴硬件資源

嵌入式系統的運行、調試和測試必須依賴于嵌入式硬件資源，而嵌入式硬件資源的使用沖突，將導致項目進度延誤。出現嵌入式系統硬件資源使用沖突的主要原因如下。

嵌入式系統一般是某個大系統的一個軟件配置項。按照規定，嵌入式系統軟件開發完畢后入受控庫，軟件測試人員根據入庫版本進行嵌入式軟件配置項測試，此時入庫的代碼是在大系統聯調之前，而大系統各配置項的功能都是在大系統聯調之后才能最終確定，在此期間會反復進行需求變更、功能完善、協議修改和指標調整，然而這些聯試的結果都依靠實裝環境來驗證。因此，研發人員不可能將僅有的嵌入式硬件設備在測試階段就給測試人員使用。

在這種情況下，可以規定大系統聯調完成后再進行嵌入式軟件配置項測試，這樣可以只使用一套嵌入式硬件設備完成測試。然而，在完成軟件配置項測試后又要進行系統測試，導致整個測試階段占用時間較長，如果對研發進度要求較高，往往會造成項目進度延誤。項目組可以為嵌入式系統提供兩套硬件設備，這樣在軟件入庫之后即可同時開展配置項的聯調和測試。這種情況雖然解決了項目進度問題，但也造成了硬件資源的浪費，嚴重消耗了項目的成本。

解決上述問題主要分兩步走。①可以引入虛擬技術，采用虛擬技術與真實環境相結合的方式來完成嵌入式系統軟件測試。在軟件入庫之后，即可使用軟件虛擬技術替代硬件環境的方法，使被測軟件在虛擬軟件平臺下完成嵌入式系統軟件的功能測試。②在系統聯調完成之后，借助真實環境，再完成嵌入式系統的性能和適應性測試。這樣將大部分嵌入式軟件測試工作在虛擬化平臺下完成，既不影響軟件研發對硬件資源的需求，也給嵌入式系統軟件測試提供了充足的時間和資源，并通過在后期實裝環境中驗證僅存少量的軟件性能和適應性測試，充分保證嵌入式系統的可靠性。

4 國產化硬件、軟件產品在應用時的問題判別

隨著國產化自主平臺品牌的不斷壯大，很多以前由國外壟斷、把持的硬件平臺和操作系統被國產技術突破，均擁有了國產化的替代產品。原先運行在國外硬件平臺和操作系統的應用產品，現在實現了在國產化硬件平臺上和國產化操作系統上運行。但是，在國產硬件平臺和操作系統上運行的應用軟件系統出現的問題，到底是國產化操作系統的問題？還是國產化硬件平臺的問題？還是應用軟件的問題呢？如何區分和判別呢？

考慮應用軟件的兼容性原則，使用目前行業中知名的、并被普遍認可的操作系統和硬件平臺作為評判標準，通過將應用軟件在公認操作系統和硬件平臺上運行實驗的對比測試，來定位問題所在。采用此種方式排查問題，不僅提高了所開發應用系統的通用性和可移植性，也便于硬件平臺、操作系統的升級和維護，更符合人們的正常思維認識，易于理解和接受。

5 第三方測評和定型測評的區別

在介紹第三方測評和定型測評之前，首先引入兩個概念：驗證和確認。“驗證”是指確保所選擇的工作產品滿足指定的需求；“確認”是指證實產品或產品部件被置于其預定環境中時，可以滿足預期的使用需求。

“第三方測評”屬于“驗證”方式的一種，一般在項目內部測試之后，由具有第三方測評資質的單位對項目的軟件工作產品進行獨立性的測試，其過程和驗證的工作產品與內部測試類似，不驗證各階段的管理工作。介入時機在項目結束之前，與內部測試介入時機相似。

“定型測評”屬于“確認”方式的一種，一般在項目的所有工作完成后，代表客戶對軟件生命周期模型中所產生的各階段管理工作內容、軟件工作產品進行的獨立性驗收測試。其確認的軟件工作產品不僅包括整個軟件生命周期模型中各階段管理工作記錄，而且還包括開發、測試所有過程產生的軟件工作產品的確認。介入時機在項目結束之后，客戶驗收之前。

本文根據實際工程經驗詳細總結和描述了軟件測試技術中常見誤區，希望能提高軟件測試人員對軟件測試技術的正確認識，排除軟件測試人員在實踐中的障礙，提高測試效率、提升軟件質量具有積極意義。

[1]萬江平，孔學東，楊建梅．集成能力成熟度模型（CMMI）的研究[J]．計算機應用研究，2001（10）．

[2]李興兵，李孟軍，譚躍進．軍用CMMI模型的建立初探[J]．兵工自動化，2003（06）．

馮濟舟（1984年—），男，碩士，工程師，現從事軟件工程化和軟件測試工作。