一種符合Qt應用程序的軟件測試實現

黃仁歡

摘要：Qt是一個開源的、跨平臺的C++圖形用戶界面應用程序開發框架，使用其開發的應用軟件可以按照代碼走查、靜態檢查、覆蓋率統計、單元測試、軟件集成測試的測試步驟進行測試，有利于排查潛在的代碼缺陷和故障，提高代碼質量和健壯性。該文將闡述這一測試過程所使用的方法，總結實測經驗，為軟件測試人員提供借鑒。

關鍵詞：代碼走查;覆蓋率統計;單元測試;軟件測試實踐;Qt應用程序測試

中圖分類號：TP311? ? ? 文獻標識碼：A

文章編號：1009-3044（2021）16-0070-03

開放科學（資源服務）標識碼（OSID）：

1 概述

Qt作為現階段流行的跨平臺C++圖形用戶界面應用程序開發框架，它的軟件開發遵循著一般軟件開發的正常流程，其開發生命周期按照可行性研究報告、需求分析、風險分析、架構設計、組件設計、實現與測試、驗證與確認、部署與維護8個階段進行。缺少任一環節，那么這個軟件都是不完整的，不能投入市場進行部署運營。而軟件測試，是保障軟件質量最重要、最有效的方法[2]。作為一個優秀的、跨平臺的應用程序開發框架，由它進行編碼的軟件，也需要經過嚴格的、全面的、多方位的測試過程，從而發現和消除軟件內部隱藏的故障，只有這樣，軟件才會通過完整性、充分性測試。

本文涉及的項目需要通過SIL2等級的功能安全認證，由于項目本身只是一個應用層軟件，在進行SIL2認證工作時不考慮硬件相關的因素，根據既有的軟件開發的流程及參照《EN50128-2011》標準中對通用軟件開發的要求，對軟件開發的生命周期進行了微調，并且注重軟件的測試方法、過程和細節。

2 測試過程

軟件編碼人員根據詳細設計文檔進行代碼編寫，遵照模塊劃分圖、UML類圖、接口定義將軟件功能逐步實現，開發者會進行基本的功能驗證工作，保證程序運行正常和功能完整，然后將代碼提交SVN歸檔，完成開發工作。此后，便進入代碼的測試階段。

針對Qt應用程序軟件測試的不同階段，可以將測試過程劃分為代碼走查，靜態檢查，單元測試，覆蓋率統計，集成測試五大階段，這些階段具有先后順序，上一個階段完成后才可以開展下一個階段的工作。

2.1 代碼走查

代碼走查是以組為單位對代碼進行審查，是一系列規程和錯誤檢查技術的集合。在實際工作過程中，代碼走查是最容易被開發者或測試者省略的一個階段[3]。開展代碼走查工作具有一定難度的，原因有以下兩種：首先，代碼走查人員如何安排;其次，問題排查難及驗收標準模糊。代碼走查的意識和重要性往往被項目負責人忽視，這往往是不可取的。

在我們的項目中采取交叉走查的方式，即開發者A對開發者B的代碼進行走查，開發者B對開發者C的代碼進行走查，開發者C對開發者A的代碼進行走查。走查的內容分為三大塊：

1）對注釋進行走查;文件的注釋走查，需簡述文件要實現的功能、作者、修改日期等;函數的注釋走查，需描述函數的功能，參數含義，返回值信息等;變量的注釋走查，簡述變量的內容;注釋風格的走查，嚴格使用Doxygen風格注釋，保證后期可通過Doxygen插件自動生成項目源代碼幫助文檔;

2）對代碼的邏輯結構進行走查;每個走查者參照詳細設計文檔，找到每一個功能點對應的實現代碼，逐行解釋程序的數據結構、邏輯和調用關系，使某一個功能的實現方法與其他成員想法達成一致;

3）對異常處理的走查;包括運算錯誤異常走查、接口異常走查、輸入/輸出異常走查及重點數據的異常走查。

走查結果以表格的形式輸出，包含走查問題類型、問題個數及問題占比;并且記錄走查的工時，包含走查時間、問題修改時間、驗證時間。

2.2 靜態檢查

靜態檢查是指不需要編譯運行源代碼本身，僅通過分析或檢查源代碼的語法、結構、過程、接口等來檢查程序的正確性。開展靜態檢查的依據是基于業界認可或者標準化的規范，對于基于C++的Qt開發框架來說，目前我們采用的是汽車工業軟件可靠性協會于2008年發布的《MISRA C++：2008》編碼規范。

C++Test是Parasoft公司開發的一個針對C/C++源代碼進行自動化測試的一個工具，它可以對源代碼進行三種測試：白盒測試、黑盒測試以及回歸測試。此外，它還支持對源代碼進行靜態檢查。

在Qt編譯的Debug目錄下，打開Makefile.Debug文件，添加如下代碼：

CC? = cpptestscan gcc

CXX = cpptestscan g++

重新編譯后，會生成一個bdf文件。由C++Test工具創建測試工程并導入該bdf文件，選擇與Qt相同版本的編譯器，設置靜態檢查規則，我們選擇《MISRAC++2008》規則239條加上《Qt最佳實踐》規則8條，值得一提的是，除了上述的247規則外，作為代碼復雜度的衡量標準-圈復雜度并不在其中，因此，通過過濾器搜索將圈復雜度限制在20之內的規則勾選，總共依據248條規則對項目軟件進行靜態檢查測試，然后執行靜態測試。在結果輸出窗體欄的質量任務可查看測試結果及對應的違規說明、案例示范，方便開發人員修正。最后，該工具會生成一個靜態檢查的報告文檔。

2.3 單元測試

軟件單元測試是通過編寫測試用例對一個模塊、一個函數或者一個類來進行正確性驗證的測試工作。對C++來說，通常是面向對象的編程方式，所以我們以單個類為一個測試單元，然后再對類內的函數逐一測試。QTest是Qt提供的一種簡單易用的單元測試框架，它不僅提供了單元測試框架的基本功能，還針對GUI（圖形用戶界面）的測試進行了擴展，如對鍵盤輸入事件、鼠標點擊事件等進行了模擬;并且QTest可以與Qt的工具鏈、基礎類庫、應用框架、集成開發環境（IDE）等良好地結合。

在QtCreator新建工程時選擇QTest單元測試工程，以子工程pri的形式導入源代碼工程;其次，針對每一個源代碼文件xxx.cpp，都創建與之對應的單元測試文件，命名為tst_xxx.cpp，使得每一個測試文件都可以通過修改測試入口函數（QTEST_MAIN（類名））進行獨立測試;然后基于每個函數的代碼內容編寫測試用例。

正常值測試：測試用例設置的值在數據類型的范圍內，例如，字符串類型的數據，可以設置為“abc”，整型類型的數據，可以設置為123，對于確定數值范圍的情況，還可以取數值的中間值進行測試;

邊界值測試：這類型的測試用例需要清楚的知道數據的上限和下限，取臨界點數據的左值和右值作為用例的數據，例如涉及旋轉的角度問題，上限為360°，下限為0°，在設計邊界值用例時，這個案例有4個邊界值數據，即361°、359°、1°和-1°，要測試超出合理數據范圍內的數值程序如何處理，是否有異常機制;

路徑測試：也叫分支測試，是指程序代碼中使用if…else、do…while、switch…case等關鍵字時需要編寫的用例測試，通過改變控制語句的值，從而執行不同的代碼。

異常測試：異常測試包含的范圍比較廣泛，所有不應該出現的情況都屬于異常的范疇，在這里我們重點關注數據的異常，一個是開發者對數值運算產生的異常值，一個是用戶輸入的數據異常，在設計測試用例時需要輸入異常數據來檢驗程序是否對異常數據進行處理。

QTest框架通過QCOMPARE宏來比較單元用例中期望值與實際值是否相等，從而判定該條用例是否測試通過，當兩個值相等時，表明測試通過，否則，測試不通過。

2.4 覆蓋率統計

在單元測試用例工程之后，我們可以進行覆蓋率統計。通過代碼覆蓋率審查，可以發現程序的未測試部分代碼，并且知道程序中哪一段代碼最耗時，能有效地幫助開發人員重構代碼，以提高代碼質量[5]。

代碼覆蓋率統計主要流程：

1）對單元測試工程增加編譯參數;

LIBS += -lgcov

QMAKE_CXXFLAGS += --coverage

2）重新編譯單元測試工程文件，生成gcno文件;

gcno文件包含重建基本塊圖和相應的塊的源碼的行號信息。

3）運行單元測試程序，生成gcda文件;

gcda文件包含弧跳變的次數和其他的概要信息。

4）使用gcov工具，生成gcov文件;

gcov文件包含代碼覆蓋率信息，但是可讀性較差。

為了對代碼覆蓋率的快速分析，有必要對覆蓋率信息進行可視化輸出。基于以上的流程，增加以下步驟：

5）使用lcov工具，生成info文件;

info文件包含一個或多個源代碼文件所對應的覆蓋率信息，但是可讀性較差

6）使用ghtml命令，生成html文件

html文件是我們想要的可視化輸出文件，如圖3所示。

從圖中我們可以清晰明了地看到源代碼的覆蓋率，包括行覆蓋、函數覆蓋及分支覆蓋信息。對于每一個文件，還可以精確的看的哪一行代碼、哪一個分支沒有覆蓋。這助于引導測試人員設計更合理的用例，實現代碼覆蓋，這對提高代碼質量有著重大的作用。

由于lcov工具與Windows平臺不兼容，考慮到Qt框具有的跨平臺特性，將Windows下的Qt應用程序的源代碼、編譯生成的gcno、gcda文件放到Linux平臺下，使用lcov工具生成info文件，該info文件會包含Windows平臺下的路徑，因此，需要對info文件進行如下修改：

1）刪除包含第三方庫的信息;

2）刪除包含Qt源碼的信息;

3）將源代碼路徑修改成Linux風格的路徑。

最后，再使用ghtml工具生成html文件，也能實現圖3的可視化輸出效果。

如果發現源代碼有未被測試用例覆蓋的行，需要進行編寫單元測試用例，使其覆蓋。在我們的項目中，只需要滿足行覆蓋和函數覆蓋即可，分支覆蓋要求則更高，在這里不進行展開描述。

2.5 軟件集成測試

軟件集成測試是軟件測試中處于組件測試和系統測試之間一個非常重要的環節，這是因為所有組件都經過單元測試并能正常運行并不意味著這些組件放到一起經過集成后還能正常運行[7]。

軟件集成測試的依據是系統的概要設計文檔，概要設計文檔定義了的所有公共接口，需要將各個接口模塊串聯起來形成一個個獨立的功能點，也是我們要設計的測試用例，用來覆蓋系統需求規范里的功能。軟件集成測試過程如圖4所示。

與單元測試的測試用例不同的是，軟件集成測試需要多個模塊間相互配合，模塊間有數據交互，形成數據流，由數據驅動達到某個功能點的測試目的。集成測試的實施方案有多種，如自底向上集成測試法、自頂向下集成測試法、三明治集成測試法等。對于Qt應用程序的軟件集成測試，同樣可以使用QTest框架進行測試，工程創建、用例編寫、測試執行、結果審查等都與單元測試過程一樣，此處不再贅述。

2.6 回歸測試

在軟件生命周期的任何一個階段，只要軟件代碼發生了改動，我們就必須重新測試現有的功能，以便確定修改是否達到了目的[8]，這就是回歸測試。進行回歸測試時，需要重新對用例庫進行審查，比如：1）修正不適用的測試用例;2）刪除冗余的測試用例;3）增加與新需求相適應的測試用例。可用于回歸的測試用例準備完成后，應對回歸測試的范圍進行評估，使用恰當的方法進行測試，常用的回歸測試方法有：1）全用例再測試;2）基于風險進行測試;3）基于操作進行測試;4）僅測試修改部分。

回歸測試是一個不斷按照“計劃->執行->檢查->改進”過程進行的工作，每一輪的測試結果恰好可以作為下一輪回歸的依據，以使得回歸測試更精準和高效。

3 結束語

本文闡述了一個完整的軟件測試過程，通過該過程可以有效的發現和挖掘可能存在的錯誤和異常，能提高軟件的質量和保證軟件的安全，這一軟件測試過程被成功應用于功能安全認證SIL2等級的認證中。

一個軟件產品的上線，除了以上闡述的軟件測試階段的所必需方法，還需要通過嚴格的系統集成測試階段、驗收測試階段，這樣才能保證軟件能夠滿足用戶的需求。本文的立腳點是傳統軟件行業的測試，對于互聯網、手持終端的軟件測試，上述列舉的測試過程不一定適用，這是本文的欠缺之處。

參考文獻：

[1] 朱健.基于Qt Test的自動化單元測試[J].價值工程，2017，36（14）：216-219.

[2] 鞠秀娟，趙明.軟件自動化測試概述及應用工具分析[J].計算機應用，2007（S1）：317-318，321.

[3] 周玫.有效開展代碼走查工作的實踐過程分析[J].現代信息科技，2019，3（1）：190-191.

[4] 毛子晏.對計算機軟件測試技術的幾點探討[J].電腦知識與技術，2020，16（18）：77-79.

[5] 朱少民.全程軟件測試[M].3版.北京：人民郵電出版社，2019.

[6] Jorgensen P C.基于模型的測試：一個軟件工藝師的方法[M]. 王軼辰，王軼昆，曹志欽，譯.北京：機械工業出版社，2019.

[7] 侯艷芳，楚書來.探析軟件測試之集成測試[J].計算機光盤軟件與應用，2012（3）：78-79.

[8] 李龍，黎連業.軟件測試實用技術與常用模板[M].北京：機械工業出版社，2018.

【通聯編輯：謝媛媛】