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

版塊 |鑒源論壇 · 觀模

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

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

圖1事故記錄

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

圖2瀑布模型

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

圖3軟件測(cè)試變化趨勢(shì)

02軟件測(cè)試能做什么？不能做什么？

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

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

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

圖4 代碼片段

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

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

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

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

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

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

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

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

審核編輯黃宇