作者 |蘇亭 華東師范大學軟件工程學院教授

版塊 |鑒源論壇 · 觀模

01軟件測試的“起源”和發展

從狹義的角度說，軟件測試是軟件開發中的一個流程，即通過把程序實際運行起來并試圖找出其中可能存在的錯誤。軟件錯誤一般被大家通俗地稱為“bug”。事實上，“bug”這個詞最早起源于Grace Hopper（她是美國海軍準將、計算機科學家，也是世界上最早的一批程序員之一）的一個真實故事。1947年9月9日，Grace和同事們在檢查哈佛二號電腦(Harvard Mark II)總是出錯的原因，大家仔細檢查程序仍找不出錯誤，最后才發現原來是一只飛蛾意外飛入電腦內部的繼電器而造成短路，他們把這只飛蛾移除后便成功讓電腦正常運作[1]（下圖就是當時事故的記錄和那只飛蛾）。從此以后，“bug”一詞就被拿來指稱軟件錯誤，“debug”一詞被拿來指稱調試查找軟件錯誤。

圖1事故記錄

后來，隨著人們對軟件錯誤的認識逐步加深，軟件測試也經歷了多個階段的發展。最初Grace所在的年代，人們只是為了找出軟件錯誤的原因（Debugging Period）；后來1957年開始，人們強調需要設計軟件測試集來驗證/確保軟件符合設計時提出的需求規范和軟件功能（Demonstration Period）；從1979年開始，人們開始主動地去尋找能觸發軟件錯誤的測試集（Destruction Period）；再后來，軟件測試成為了保障軟件質量的重要手段，成為軟件開發流程中一個必不可少的階段[2]。比如，下圖是經典的軟件開發生命周期模型（SDLC）之一的瀑布模型（Waterfall Method），軟件測試是其中的重要一環。

圖2瀑布模型

值得注意的是，在經典的軟件開發生命周期模型中，如上圖的瀑布模型中，軟件測試是處于比較“靠右”的階段。現如今，軟件測試越來越強調“左移”測試（Shift-Left Testing，最早由Larry Smith在2001年提出[3]），其主要目的是為了讓軟件測試盡早地介入到軟件需求分析、設計等階段，能盡早地在這些階段就能發現軟件缺陷（而不是在軟件實現結束后才介入測試），以期望進一步降低軟件錯誤的修復成本。下圖（引用于[4]）形象地給出了這種變化趨勢（下方左邊的圖給出了傳統開發生命周期模型中，軟件測試所在的位置和比重比較靠右；下方右邊的圖逐步演化為把測試階段左移，讓軟件測試階段更早地接入到軟件開發的早期階段，如需求、設計和開發）。

圖3軟件測試變化趨勢

02軟件測試能做什么？不能做什么？

軟件測試是業界使用最普遍的質量保障手段。因為，軟件測試在適應性和可擴展性方面比較強，在特定的領域場景下，如果軟件測試方法和技術設計得當，能夠有效地找到潛在的軟件錯誤。但是，我們也需要注意，它也有其局限性，即軟件測試沒法保證找到被測對象程序中所有的軟件錯誤（“Testing shows the presence, not the absence of bugs.” By Edsger W. Dijkstra）。與之相對應的，軟件形式化驗證技術能夠嚴格地證明某個軟件程序沒有軟件錯誤的存在（當然，這句話也是在一些特定的假設下才成立）。

03找到軟件測試錯誤需要滿足什么條件？關鍵要素在哪里？

據統計，軟件測試占所有軟件開發時間 40~50%，占所有研發費用 50%以上。軟件測試作為一種有效的軟件質量保障手段，其主要缺點在于測試成本很高（主要原因在于，一方面很多情況下測試過程離不開手工參與；在另外一方面，測試講究“大力出奇跡”，因為需要依靠大量的測試執行去碰運氣）。因此，如何實現高效、自動化的軟件測試技術成為了業界和學界普遍關心的問題。然而，無論軟件測試應用場景是什么，實現軟件測試的關鍵要素有兩個：（1）測試輸入；（2）測試預言（Test Oracle）。下面以一個具體的代碼片段例子（該代碼片段選自于[5]）來解釋下。

圖4 代碼片段

上面這個程序是為了統計一個數組arr中元素0的個數。仔細看就會發現，這里隱藏著一個軟件錯誤：for循環中的迭代起始條件（int i=1）是錯誤的，應該是（int i=0）。這就是一個具體的軟件錯誤（英文中稱為Software Fault）。

針對這樣一段軟件代碼，一個可能的測試用例（Test Case）可以是：{arr=[2,7,0],expected_output=1}（這里arr=[2,7,0]稱為測試輸入，expected_output=1稱為預期輸出或測試預言）。軟件測試中，判斷一個測試輸入是否找到了一個軟件錯誤，最簡單的辦法就是判斷測試輸入在執行后的實際輸出是否符合預期輸出。顯然，這個測試用例是無法找到該軟件錯誤的，因為實際輸出就是等于1，與預期輸出是一樣的。相反，一個能找到該錯誤的測試用例可以是：{arr=[0,2,7],expected_output=1}。因為這個測試用例的執行后的實際輸出是0，與預期輸出是不相等的。

這里，我們可以理解下為什么后一個測試用例能找到這個軟件錯誤，而前一個測試用例卻不能找到錯誤。因為軟件測試找到一個軟件錯誤必須滿足的四個條件：

（1）Reachability：測試輸入受限必須到達Software Fault所在的代碼位置（如，這里的int i=1）；

（2）Infection：這個測試輸入必須使得軟件程序的狀態出錯（如，這里i的值在第一次循環迭代的時候被錯誤地賦值為了1）；

（3）Propagation：這個錯誤的程序狀態必須導致程序的最后輸出結果錯誤，或者最終的程序狀態錯誤（如，這里Count這個返回值為0，其實是錯誤的）；

（4）Reveal：測試預言必須能否觀察到程序的最后輸出或者最終的程序狀態是錯誤的（如，這里通過對比Count的值和預期輸出值1是能判定程序出錯了）。

根據上面的這四個條件，我們很容易發現，前一個測試用例只滿足了（1）和（2），沒有滿足（3）和（4）；而后一個測試用例滿足了上述四個條件。因此，通過上面一個例子，可以看到，為了實現高效的軟件測試，最需要解決的是生成有效的測試輸入、以及寫出（甚至是自動生成）有效的測試預言。這也構成了設計開發自動化軟件測試方法和技術的主要挑戰。

參考資料：

[1] Grace Hopper - Wikipedia. https://en.wikipedia.org/wiki/Grace_Hopper.

[2] History of software testing. https://davidmoremad.medium.com/history-of-software-testing-cfa461c4ae0a.

[3] Shift-Left Testing By Larry Smith. https://www.drdobbs.com/shift-left-testing/184404768.

[4] Shift Left Testing: What, Why & How To Shift Left. https://www.bmc.com/blogs/what-is-shift-left-shift-left-testing-explained.

[5] "Introduction to Software Testing", Paul Ammann and Jeff Offutt.

審核編輯黃宇