1.4　軟件測試發展展望

1.4.1　軟件測試面臨的挑戰

1.4.1.1　面向故障的軟件測試

1.故障模型

缺陷檢出、分析、處置是軟件測試發展的內生動力，故障模型是基于缺陷的軟件測試的理論基礎。對于任意軟件Software，假設是可能的任意故障集合，是一個確定的測試方法，CM是基于對給定和F所生成的測試用例集，是CM所能檢出的故障集合，是產生CM所花費的代價，譬如生成并執行CM所需的時間，我們期望通過最少的測試用例，以最小的代價達成測試目標，即獲得最小化的CM和。對于兩個不同測試方法和M2，若，且，則認為M1優于。顯然，這種方法未必會存在。通常，只要在可控范圍之內且不會無限擴大，且，則可以斷定優于。然而，由于對軟件失效機理認知的局限性、軟件缺陷描述的不確定性、軟件缺陷定位的不精準性，目前還難以建立統一或普適軟件故障模型，這是面向故障軟件測試及軟件測試理論發展的主要瓶頸之一。

2.單故障模型

假設軟件故障為“小故障”或可以分解為小故障。與所謂“正確”的軟件相比，軟件邏輯結構正確，其錯誤表現為變量替代錯誤、運算符遺漏、括號偏移等一個或幾個符號錯誤。面向單故障模型測試是基于單故障模型假設，對于任意給定程序，生成故障集合F={f1,f2,?,fn} ，基于面向故障的測試用例，生成故障模擬算法及能夠檢測中所有故障的測試用例，以檢測軟件中存在的小檢測概率故障，但精準的元素定位問題無法保證模型擬合度的無偏性。

3.系統崩潰測試

對于一個軟件系統，即使某個或某些缺陷被激活，亦未必會誘發系統失效，但在不可預知的條件下，如果缺陷被多次激發，則可能導致系統崩潰。例如，對于以C++實現的程序，雖然已有大量測試工具能夠檢出其內存泄漏、數組越界、空指針引用等靜態缺陷，但C++語言因其缺乏與內存安全相關的特性，存在緩沖區溢出、懸空指針等問題，特定觸發或場景下，可能導致程序崩潰、未定義的行為，甚至是安全漏洞。但C++語言廣泛使用帶來的高擴散性，使得針對這種情況的測試場景構建、觸發條件設置、數據閾值預置等可能處于不可控狀態。

4.域比較測試

假定軟件需求規格通過完備測試，而且能夠從需求規格和代碼DP兩個方面得到軟件的定義域，那么，“軟件正確”的必要條件就是，也就是軟件設計與實現同需求規格完全契合，軟件設計、編碼實現完整、準確地實現了軟件需求。反之，若，則表明軟件設計及實現同需求規格不一致。對于x∈(DS?DP)∪(DP?DS) 中的點，一般是軟件中一個特別的點，但往往可能會被開發人員所忽略或遺漏。例如，對一元二次方程求根的程序，設計及實現過程中，可能會忽略的情況。當然，除數為0的點，負數開平方的點，其他不該取值的點等，莫不如此。對于這類情況，可進行域比較測試，全面、系統地檢驗軟件不同輸入空間所對應輸出的正確性。但是，對于域比較測試，子域分割圖構建、邊界測試點選擇、子域內測試點選擇、測試結果比對等的理論解釋、實踐方法，尚待進一步深入研究。

1.4.1.2　基于規范的軟件測試

基于規范的軟件測試具有堅實的理論基礎，構建了較完備的技術標準體系，擁有豐富的測試工具支撐，且已通過廣泛的實踐驗證。邏輯覆蓋、路徑覆蓋、符號執行、邊界測試、組合測試、數據驅動測試、軟件成分分析等都是重要的基于規范的軟件測試技術。其中，被動測試、符號執行、組合測試、數據驅動測試、軟件成分分析還面臨著挑戰，在此予以簡述。

1.被動測試

主動測試是由測試人員向被測應用發送測試輸入，將測試輸出同預期結果比較，判定測試結果。對于主動測試，軟件系統處于被測狀態而非正常工作狀態，環境確定，場景預置，難以實現充分的系統動態行為測試、基于場景驅動的系統能力測試，尤其是對于多協議變量復雜系統，無法實現在線測試，難以實現真實運行狀態下的性能測試，環境差異會對測試結果產生重要影響。

被動測試則是在真實環境下運行被測軟件，在正常工作狀態下及應用場景中，被動接收輸入，在不干預軟件運行的情況下，根據I/O序列，判定軟件狀態，預測下一個輸出。一般地，被動測試過可分為自動導引（Homing）和故障檢測兩個階段。有限狀態機（Finite State Machine，FSM）是被動測試的重要方法，包括遍歷所有狀態轉移測試序列的T方法、構造測試輸入序列的D方法及狀態驗證的U方法，模型簡單且易于實現，但它僅考慮了系統的控制流而未考慮數據流，對于系統流程測試，力難從心。基于FSM、擴充輸入輸出參數、上下文變量、定義在上下文變量、輸入參數上的謂詞條件和操作，構造擴展有限狀態機（Extended Finite State Machine，EFSM），既可以表達控制流，也能夠表達數據流，能夠更加準確地描述復雜系統。但是，由于軟件系統可能處于隨機狀態，如何處理其變量，是EFSM面臨的難題之一。不確定的變量處理、變量區間表示及其處理是該技術領域研究的重點。

2.符號執行

符號執行是使用變量名稱的符號值而非真實數據作為程序輸入，采用前向擴展和后向回溯執行程序，對源程序進行詞法、語法分析，生成關于輸入符號的代數表達式，用于程序路徑檢查、程序證明、程序簡約及符號調試，檢出程序缺陷，較好地解決了定理證明、類型推導、抽象解釋、模型檢測、規則檢查等存在的問題，可為缺陷觸發提供具體輸入，是靜態分析的重要手段。如果代碼中存在數組元素、復雜數據結構、循環及方法調用等情況，自動定理證明需借助于各種判定程序，判斷被測算法是否為定理，不能直接用于程序分析；類型推導僅適用于函數式程序設計語言；抽象解釋只能作用于確定的抽象域；基于模型檢測的搜索算法效率較低，且可能導致狀態空間爆炸；規則檢查受制于規則描述機制，只能對特定類型缺陷進行分析。

3.組合測試

組合測試是基于多參數故障模型，基于系統參數的相互作用及取值組合，以較少的測試用例，實現測試目標，是基于測試性能及代價約束的優化問題。假設k個參數相互獨立，其中第個參數有個取值。表示第個參數的某個取值即水平，表示一個測試用例，表示所有可能的測試用例構成的集合，表示選定的某個測試用例集，，對這些參數的全部組合進行測試，需個測試用例。當參數個數或其取值個數ni很大時，測試用例數將會是一個龐大的數字，難以或無法實現全組合測試，需要從全部組合中選擇最少的測試用例，以達到確定的測試目標。

理論上，可以通過有限輸入空間表示無限輸入空間，但只能解決單個輸入的取值問題，必須為每個輸入確定相應的取值，驅動系統運行。如何通過不同輸入組合，解決測試組合爆炸問題，保證測試的充分性，是軟件測試所需面對的基本問題。

4.數據驅動測試

數據驅動測試（Data-Driven Testing，DDT）是一種從Excel表格、JSON文件、數據庫等外部數據源讀取測試數據，以參數形式輸入測試腳本，驅動測試的軟件測試技術。數據驅動測試將測試用例中的執行邏輯與數據分離，較好地解決了數據存儲、讀取、測試執行及測試結果寫入等問題，測試腳本簡練，可以靈活地添加測試數據，具有良好的可理解性、可重用性、可擴展性、可維護性，能夠顯著地提高測試覆蓋率和測試效率，廣泛地應用于接口測試、性能測試、網站測試等場景，是自動測試的重要組成部分。但是，數據驅動測試用例生成和執行強依賴于數據，對測試數據設計提出了非常高的要求。同時，冗余測試用例的優化處理，也是不得不面對的問題。

5.軟件成分分析

軟件成分分析（Software Compostition Analysis，SCA）是通過軟件源碼分析，提取項目依賴的第三方組件及其版本、許可證、模塊、框架、庫等特征信息，識別跟蹤項目中引入的開源組件，檢測相關組件、支持庫及它們之間的依賴關系，識別已知的安全漏洞及許可證授權問題，提高軟件系統抗惡意軟件包滲透、攻擊軟件和應用程序威脅的能力，規避開源軟件所帶來的合規性、知識產權等風險。

基于構建文件的軟件成分分析是通過提取開源組件特征信息，識別開源組件及第三方依賴項風險，但SCA并不查找自定義代碼中的安全漏洞，不檢測不安全的網絡配置，無法緩解SolarWinds供應鏈等漏洞，對于安裝痕跡模糊或用戶選擇性安裝的組件，存在分析結果準確性偏差；基于代碼相似度的軟件成分分析依賴于分析算法及已知漏洞數據庫和組件數據庫，雖然能夠在大規模組件庫支持下進行快速計算，檢測潛在的安全風險，但受限于數據源及其更新及時性等問題，可能無法發現最新的安全漏洞或某些特定的組件；基于靜態軟件成分分析，無法對已投入生產或動態加載的組件進行識別和分析，可能導致一些重要的安全風險被忽略。

1.4.1.3　基于架構的軟件測試

1.移動互聯測試

移動應用種類繁多的移動設備、復雜多變的應用環境、千差萬別的應用場景、持續引入的新特性，對移動互聯測試提出了新的要求。基于邏輯、數據、剖面的測試為移動互聯測試提供了基礎支撐，解決了基本的測試需求；基于軟件即服務（Software as a Service，SaaS）系統的多租戶架構，負載均衡、容錯處理、備份恢復等技術手段，身份認證、訪問控制、漏洞管理等安全策略，構建移動互聯測試平臺，集成Monkeytalk、Appium等自動化測試工具，模擬用戶真實的終端操作方式，將應用提交到平臺中，實現全量功能性能測試、全鏈路壓測、流量回放、跨地域跨時區測試、安全性測試，支持應用在不同平臺上的多版本適配，較好地支撐了移動互聯測試的工程實踐。但即便如此，移動互聯測試還面臨著設備和操作系統的多樣性、平臺及操作系統不斷更新、網絡環境下的系統性能和穩定性、用戶體驗及手勢操作測試、系統安全性及隱私保護等挑戰。

2.云服務測試

將測試服務部署到云上，即可根據需求使用云端資源，將云平臺和容器技術結合，能夠快速構建可擴展、可伸縮的測試環境，基于使用場景驅動測試，對基于彈性伸縮模型的云計算服務設施的彈性能力及基于故障注入的云計算服務設施進行測試，減少用戶的基礎設施投入，降低成本。

云服務包含私有云、公有云、混合云等不同形態，規模龐大、架構復雜、配置困難、計算及存儲量巨大，其高負載、高擴展、動態部署等特點，對云服務測試提出了新的更高要求。首先，軟件測試人員必須深入分析云架構的結構及技術特征，開發基于云架構的測試技術及測試策略，構建符合云平臺質量要求的測試工程能力和質量保障能力；其次，對于云計算平臺功能性能、可擴展性及彈性測試，傳統軟件測試工具力難從心，通過負載測試、壓力測試、基準測試及系統的可伸縮性驗證，能在一定程度上避免超大規模云端壓力模擬所帶來的困難，但需要網絡運營商、CDN服務提供商支持，代價高昂；再次，云計算環境中，錯誤類型眾多、錯誤信息表達形式各異、相同的錯誤在不同云產品上表達不一致、業務錯誤碼與HTTP錯誤碼含義不匹配、錯誤碼超越可枚舉集合，如此等等，無一不是云服務平臺容錯性和可靠性測試難以逾越的障礙；最后，云計算環境中，配置參數及其組合數量巨大，雖然我們可以采用組合測試技術縮減組合數，但如何完成巨量的組合測試，保證其覆蓋率，存在較大質量風險。

3.區塊鏈測試

區塊鏈是一種去中心化、跨越多個子網、多個數據中心、多個運營商甚至多個國家的分布式系統，通過一系列基于時間順序排列的數據塊即所謂“區塊”記錄數據，通過加密技術確保數據的不可篡改、不可偽造性，規模龐大、邊界模糊、交易復雜、安全性要求高。區塊鏈測試不僅涉及前端API與某個區塊鏈節點之間的測試，還涉及大量區塊鏈節點之間的測試，不僅需要測試驗證其功能、性能、安全性、兼容性、容錯性、數據一致性等特性，還需要對共識算法的合法性、完整性、可終止性及智能合約等進行測試驗證。首先，區塊鏈涉及網絡、存儲設備等基礎設施安全性、網絡協議安全性、加密算法安全性、共識算法漏洞等共識機制安全性，智能合約安全性，Web、移動客戶端軟件、數字錢包等應用安全性及身份認證與鑒別等極高的安全性要求，其安全性測試極具挑戰性。其次，區塊鏈網絡采用工作量證明（Proof of Work，PoW）、權益證明（Proof of Stake，PoS）等共識機制，這些共識機制算法復雜，對測試提出了極高的要求。再次，智能合約類似于法律，在執行過程中，一切均聽命于事先設定好的代碼，而事先設定好的代碼一旦上線就不能輕易修改，如何通過測試，確保智能合約百分之百正確，本來就是軟件測試領域的一個悖論。最后，公有鏈、私有鏈、聯盟鏈等不同類型的區塊鏈，其網絡節點、共識機制、智能合約、身份認證、運行管理等方面存在著較大差異，如何進行一致性測試驗證和分析評價，是區塊鏈測試面臨的又一難題。

4.物聯網測試

物聯網（Internet of Things，IoT）是一個集大量網絡設備、感知設備及計算、存儲等基礎設施于一體，人?機?物互聯融合的復雜巨系統（Complex Giant System，CGS）。其廣泛使用諸如MQTT、OPCUA、ModBus-TCP等工業協議，規模龐大，結構復雜，系統元素及其之間的關系具有不確定性，使用場景復雜多變，解決方案多元化，無一不對IoT測試帶來挑戰。首先，測試環境復雜，如異構互聯、M2M互聯、軟硬件緊密耦合，需構建全新、規模龐大的測試環境，基于IoT場景仿真，盡管可以在少量物理設備上創建不同類型的虛擬設備，構建不同協議的虛擬連接，模擬應用場景，但難以甚至無法針對所有loT設備、連接協議、服務節點，實現全域、全業務鏈路的測試覆蓋。其次，對于IoT系統測試，必須基于系統所有設備時間同步，雖然基于實踐敏感網絡（Time Sensitive Network，TSN），建立通用時間框架，支持實時數據采集、實時數據同步傳輸，但如何在網絡震蕩的情況下保持高度的時間同步？如何實現基于多系統、多設備、對協議協調的整網配置？在賦能客戶同步迭代升級的同時，如何平滑地切換至TSN？如何優化流量傳輸的確定性？都是目前尚待進一步研究解決的問題。最后，網絡安全策略、配置組合、通信協議兼容、系統可伸縮性、系統可擴展性、協同感知、大數據處理性能、智能特性測試及可靠性評估，是一個測試技術創新與應用，測試有效性與效率平衡的系統工程，也是IoT測試面臨的重大挑戰。

1.4.1.4　大數據及應用測試

傳統軟件測試技術和方法難以在確定的條件下、給定的時間內獲得大數據及應用系統期望的目標結果，甚至無法找到問題的入口到底在哪里。大數據及應用測試包括對數據本身及大數據應用測試兩個維度。大數據測試是對數據的完整性、準確性、一致性、及時性、可用性等進行的測試驗證，旨在剔除缺省、重復、錯誤數據，獲得理想的數據集，保證數據質量。對于海量、多源非結構化大數據測試，需要搭建可擴展、具有良好伸縮性的測試平臺，模擬大量測試客戶端，對測試數據的完整性及數據備份、數據管理提出了前所未有的新要求。同時，面對大數據多場景下輸出的不確定性、大數據結構的多樣、動態性等，定位數據的關聯關系面臨著巨大挑戰。

基于分布式集群環境及數據相關性分析、數據分類、數據聚類、個性化推薦、趨勢預測等典型應用場景，大數據應用系統輸出的正確性、有效性不僅與大數據質量、架構及算法等密切相關，還有賴于輸入數據及其分布特性，具有未知性和不確定性。針對大數據特征及其應用需求，基于大數據架構及層次分解，對大數據算法、數據架構、大數據應用性能、成功處理海量數據的能力及安全性等進行測試驗證，是大數據應用測試的重要內容。

1.4.1.5　軟件測試分析

軟件測試性分析與設計是減少測試復雜性、提高測試效率的重要手段之一，是軟件測試復雜性度量的重要方法學。20世紀90年代以來，業界提出簡明性、復雜性度量等測試分析設計方法，測試覆蓋及缺陷傳播、感染、執行（Propagation-Infection-Execution，PIE）等定量分析技術得以深入研究，取得顯著成效。

1.測試覆蓋

測試覆蓋是指測試系統覆蓋被測系統的程度，即一項或一組給定測試，對于確定系統或構件的所有指定測試用例進行處理所達到的程度，是測試終止及測試充分性的重要度量，也是測試質量評價的重要依據。一般地，測試覆蓋包括需求、邏輯、功能、能力等覆蓋目標、測試度量及分析方法。

設是程序P的任意缺陷集合，E是程序中某個元素，如語句、分支、路徑、謂詞、分支-謂詞、C-應用、P-應用、ALL-應用等，是程序P中所有符合元素定義的集合，T是測試用例集，是T對PE的覆蓋率。邏輯覆蓋包括語句、判定、條件、判定?條件及修正條件判定等覆蓋類型，分支?謂詞、ALL-應用具有良好的測試覆蓋性。邏輯覆蓋研究的問題是：當為一個確定值如RPEC=1 時，執行測試用例集，能夠檢測到的缺陷集合為FT，邏輯覆蓋分析就是和FT的相關性分析。測試覆蓋解決的主要問題就是如何使及當RPEC=1 時，獲得的取值。

2.PIE技術

在特定環境及條件下，缺陷代碼能感染其他代碼，生成錯誤的程序狀態，當被感染代碼執行時，將導致軟件功能異常、性能下降，甚至失效。跨站腳本（Cross-Site Scripting，XSS）攻擊是一種基于代碼注入的網站應用程序的安全漏洞攻擊手段。例如，針對Popup Builder插件的XXS漏洞（CVE-2023-6000），攻擊者通過構造惡意輸入，將惡意腳本注入網站的自定義JavaScript中，惡意腳本在瀏覽器中執行，當用戶訪問受感染的網頁時，就會被重定向到惡意目的地，用以竊取用戶信息、安裝惡意軟件或進行其他形式的網絡攻擊。感染亦可能向下傳播和蔓延。

執行給定的測試用例，觀察軟件的執行狀態及輸出，將每個缺陷的檢測劃分為故障的元素以執行概率Ef被執行，執行時以變異概率If發生變異，的變異以傳播概率Pf傳播到輸出3個部分，得到故障f的檢測概率為Df=EfIfPf，由此對軟件中可能存在的故障進行估計，分析失效產生的上下文，識別可疑代碼及“缺陷-感染-失效”鏈，查找失效根源，消除缺陷。

3.信息屏蔽分析

程序中，當一條語句向另一條語句過渡時，有些缺陷可能被一些特別的語句屏蔽。這種情況常見于多對一函數中如關系表達式、BOOLEAN表達式、特殊算術表達式如mod()函數等。一般地，我們難以通過測試檢出這些表達式中所包含的錯誤。盡管通過增加測試點，能夠屏蔽缺陷，但測試點增加具有隨機性，基于隨機模型的測試將帶來不可預知的不確定性因素，進而大幅增加工作量。

4.綜合評價

基于目標?問題?度量元（Goal-Question-Metric，GQM）建立綜合評價模型，是一種有效的評價策略。GQM是一個繼承性結構，自上而下，逐層分解，逐步求精，最終基于特定目標得到所需度量。基于確定的度量，將測試類型作為評價的目標和判斷依據，通過一個可操作的定義考察每個測試類型中測試用例的執行情況，建立GQM結構，構造評價指標體系并將其逐級分解為所需解決的問題，細化到具體問題需要用到的度量元，對指標進行評價。

模糊評價將評價目標看成由多種因素組成的模糊集即因素集μ，設定因素所能選取的評價等級，組成模糊集，分別求出各單一因素對各評價等級的歸屬程度，構造模糊矩陣R，然后確定各主因素下的單因素權重A和主因素權重，根據各個因素在評價目標中的權重分配，計算模糊矩陣合期（A, R），給出評價的定量值。