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

版塊 |鑒源論壇 · 觀模

01軟件測試的“起源”和發(fā)展

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

圖1事故記錄

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

圖2瀑布模型

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

圖3軟件測試變化趨勢

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

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

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

據(jù)統(tǒng)計(jì)，軟件測試占所有軟件開發(fā)時間 40~50%，占所有研發(fā)費(fèi)用 50%以上。軟件測試作為一種有效的軟件質(zhì)量保障手段，其主要缺點(diǎn)在于測試成本很高（主要原因在于，一方面很多情況下測試過程離不開手工參與；在另外一方面，測試講究“大力出奇跡”，因?yàn)樾枰揽看罅康臏y試執(zhí)行去碰運(yùn)氣）。因此，如何實(shí)現(xiàn)高效、自動化的軟件測試技術(shù)成為了業(yè)界和學(xué)界普遍關(guān)心的問題。然而，無論軟件測試應(yīng)用場景是什么，實(shí)現(xiàn)軟件測試的關(guān)鍵要素有兩個：（1）測試輸入；（2）測試預(yù)言（Test Oracle）。下面以一個具體的代碼片段例子（該代碼片段選自于[5]）來解釋下。

圖4 代碼片段

上面這個程序是為了統(tǒng)計(jì)一個數(shù)組arr中元素0的個數(shù)。仔細(xì)看就會發(fā)現(xiàn)，這里隱藏著一個軟件錯誤：for循環(huán)中的迭代起始條件（int i=1）是錯誤的，應(yīng)該是（int i=0）。這就是一個具體的軟件錯誤（英文中稱為Software Fault）。

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

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

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

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

（3）Propagation：這個錯誤的程序狀態(tài)必須導(dǎo)致程序的最后輸出結(jié)果錯誤，或者最終的程序狀態(tài)錯誤（如，這里Count這個返回值為0，其實(shí)是錯誤的）；

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

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

參考資料：

[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.

審核編輯黃宇