淺談嵌入式軟件測試

測試是傳統軟件開(kāi)發(fā)的最后一步。整個(gè)軟件開(kāi)發(fā)過(guò)程，需要收集要求、進(jìn)行高層次的設計、詳細設計、創(chuàng )建代碼、進(jìn)行部分單元測試，然后集成，最后才開(kāi)始最終測試。

最佳的開(kāi)發(fā)實(shí)踐應包含代碼檢查這個(gè)步驟。然而代碼檢查一般只能找出70%的系統錯誤，因此完美的測試環(huán)節絕對必不可少。測試就像個(gè)復式記帳系統，可以確保將缺陷扼殺在最終推出的產(chǎn)品之前。

在所有其它的工程實(shí)踐中，測試都被視為基本環(huán)節。比如，在美國，每一座聯(lián)邦政府出資修建的橋都必須經(jīng)過(guò)大量的風(fēng)洞測試。而在軟件領(lǐng)域，測試并沒(méi)有很受重視。盡管測試是所有工程實(shí)踐準則的關(guān)鍵部分，但編寫(xiě)測試程序卻感覺(jué)是在浪費時(shí)間。好在嵌入式系統設計界內的許多領(lǐng)域已經(jīng)將測試作為其工作的核心部分，他們認識到將這個(gè)關(guān)鍵步驟放在項目末期極不明智，因而主張同步地編寫(xiě)測試程序和應用程序。

嵌入式系統軟件測試在諸多方面都與應用軟件測試一樣。不過(guò)，應用測試與嵌入式系統測試之間還是存在一些重要差異。嵌入式開(kāi)發(fā)人員一般會(huì )用到基于硬件的測試工具，而這類(lèi)工具通常不會(huì )用于應用開(kāi)發(fā)過(guò)程中。此外，嵌入式系統一般都有些獨一無(wú)二的特性，這些特性應該在測試計劃中得以體現。本文將介紹測試和測試案例開(kāi)發(fā)的基礎知識，并指出整個(gè)嵌入式系統測試工作的特有細節。

何時(shí)測試以及如何測試

從圖1可以看出，在可行的條件下，測試應盡早展開(kāi)。一般來(lái)講，最早的測試是由最初的開(kāi)發(fā)人員進(jìn)行的模塊或單元測試。遺憾的是，開(kāi)發(fā)人員大多對如何建構一整套測試例程以進(jìn)行測試所知不足。由于精心設計的測試例程通常直到集成測試時(shí)才能使用，因此許多在單元測試過(guò)程中就能找出的缺陷直到集成測試時(shí)才會(huì )被發(fā)現。比如，硅谷的一家大型網(wǎng)絡(luò )設備廠(chǎng)商為找出其軟件集成問(wèn)題的關(guān)鍵原因，進(jìn)行了一項研究。這家廠(chǎng)商發(fā)現，在項目集成階段找出的缺陷中，有70%是由在集成之前從沒(méi)被執行過(guò)的程序所產(chǎn)生的。

圖1：改正問(wèn)題的成本。

單元測試：開(kāi)發(fā)人員在單獨進(jìn)行模塊級測試時(shí)一般是編寫(xiě)存根代碼(stub code)取代余下的系統軟硬件。在開(kāi)發(fā)周期的這個(gè)環(huán)節，測試主要側重于代碼的邏輯性能。

通常，開(kāi)發(fā)人員會(huì )分別使用某些平均值、高值或低值、以及某些超出范圍的值(以測試代碼的異常處理功能)進(jìn)行測試。但這些基于“黑匣子”的測試僅能對模塊中整個(gè)代碼的一部分進(jìn)行測試。

回歸測試：測試不應是一勞永逸的。每次修改程序后都應該重新進(jìn)行測試，以確保這些更改不會(huì )無(wú)意中“誤傷”某些不相關(guān)的行為。

稱(chēng)為回歸測試的這類(lèi)測試，一般是通過(guò)測試腳本自動(dòng)進(jìn)行的。比如，如果你設計了一組100個(gè)輸入/輸出(I/O)測試，回歸測試腳本會(huì )自動(dòng)執行這100個(gè)測試，然后將輸出與一組“黃金標準”輸出進(jìn)行對比。每次對代碼的任何部分進(jìn)行修改時(shí)，都要對包含被修改代碼的整個(gè)程序運行整套回歸測試程序包，以確保修改過(guò)程中不會(huì )“誤傷”其余代碼。

測試什么

因為沒(méi)有一個(gè)實(shí)際的測試集可以證明一個(gè)程序是正確的，因此關(guān)鍵問(wèn)題變成了哪個(gè)測試子集最有可能檢測到最多的錯誤。選擇合適的測試例程的問(wèn)題被稱(chēng)為測試例程設計。雖然存在數十種測試案例的設計方法，但它們通?？蓺w為兩種截然不同的方法：功能測試和覆蓋測試。

功能測試(也稱(chēng)為黑匣子測試)選擇可評估實(shí)現與需求規格符合程度的測試。覆蓋測試(也稱(chēng)為白匣子測試)選擇可執行代碼某些部分的測試例程。(過(guò)后，將詳細討論這兩種方法。)

這兩種測試都是對嵌入式設計進(jìn)行嚴格測試所必需的。其中，覆蓋測試表示代碼的穩定性，所以這種測試是用于已經(jīng)完成或將近完成的產(chǎn)品的。另一方面，可在編寫(xiě)要求文檔時(shí)，同時(shí)編寫(xiě)功能測試。

事實(shí)上，從功能測試開(kāi)始入手，可以最大限度地降低重復勞動(dòng)和重寫(xiě)測試案例的工作。因此，在我看來(lái)，要先考慮功能測試。

每個(gè)人都同意先編寫(xiě)功能測試這個(gè)觀(guān)點(diǎn)，有人認為，功能測試在系統集成階段(而不是在單元測試時(shí))最有用。以下是整合功能測試和覆蓋測試方法的一個(gè)簡(jiǎn)單處理流程：

1.找出哪些功能未被功能測試完全覆蓋。

2.找出每個(gè)功能的哪些部分沒(méi)被執行。

3.找出需要哪些額外的覆蓋測試。

4.運行新增的額外測試。

5.重復以上步驟。

何時(shí)停止測試?

最通用的停止標準(按可靠性排序)如下：

1.老板命令停止測試

2.新的測試周期找到的新缺陷少于X個(gè)

3.在沒(méi)有發(fā)現任何新缺陷的情況下已經(jīng)滿(mǎn)足了某個(gè)覆蓋閥限

無(wú)論你多么徹底地測試了程序，都無(wú)法保證找出所有缺陷。這引發(fā)了另一個(gè)有趣的問(wèn)題：你可容忍多少缺陷?假設在極端軟件壓力測試過(guò)程中，你發(fā)現系統每進(jìn)行大約20小時(shí)的測試就會(huì )鎖定。你仔細地檢查程序，但是仍無(wú)法找出這個(gè)錯誤的根源。這個(gè)時(shí)候你應該交付產(chǎn)品嗎?

多少測試才“足夠好”?這個(gè)我說(shuō)不好。但遵循一些久經(jīng)時(shí)間考驗的規則總是好的：“如果方法Z預估Y行代碼中的缺陷少于X個(gè)，那么就可放心地發(fā)布程序了。”也許有一天會(huì )出現這種標準。編程行業(yè)仍然相對年輕，還達不到類(lèi)似建筑業(yè)那樣的成熟度。

許多厚厚的建筑手冊和大本規范是多年經(jīng)驗的結晶，它們可為建筑師、土木工程師和結構工程師提供按工期在預算內、建造一棟安全建筑所需的全部信息。偶爾雖仍會(huì )有建筑倒塌，但畢竟很少見(jiàn)。在編程行業(yè)制定出類(lèi)似標準前，“多少測試才足夠?”就是個(gè)主觀(guān)判斷問(wèn)題。

選擇測試案例

在理想情況下，你可能想要測試程序中每一個(gè)可能的行為。這意味著(zhù)每一種可能的輸入組合或者每一種可能的判定路徑至少測試一次。

這是個(gè)崇高但完全不切實(shí)際的目標。比如，Glen Ford Myers在其《軟件測試的藝術(shù)》一書(shū)中就描述了一個(gè)只用五個(gè)判定條件就可有1014個(gè)不同執行路徑的小程序。他指出，如果你能夠每五分鐘就能編寫(xiě)、執行并驗證一個(gè)測試例程的話(huà)，那么全面徹底地測試完這個(gè)小程序需要10億年時(shí)間。

顯然，理想的狀況是無(wú)法實(shí)現的，因此你必須采用接近這種理想狀況的標準。如你所見(jiàn)，功能測試與覆蓋測試相結合可以提供合理的次優(yōu)選擇方案?；痉椒ㄊ沁x擇最有可能發(fā)現錯誤的測試(一部分功能測試，一部分覆蓋測試)。