嵌入式軟件測試基礎(chǔ)知識

圖1：改正問題的成本。

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

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

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

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

測試什么

因?yàn)闆]有一個實(shí)際的測試集可以證明一個程序是正確的，因此關(guān)鍵問題變成了哪個測試子集最有可能檢測到最多的錯誤。選擇合適的測試?yán)痰膯栴}被稱為測試?yán)淘O(shè)計。雖然存在數(shù)十種測試案例的設(shè)計方法，但它們通?？蓺w為兩種截然不同的方法：功能測試和覆蓋測試。

功能測試(也稱為黑匣子測試)選擇可評估實(shí)現(xiàn)與需求規(guī)格符合程度的測試。覆蓋測試(也稱為白匣子測試)選擇可執(zhí)行代碼某些部分的測試?yán)獭?過后，將詳細(xì)討論這兩種方法。)

這兩種測試都是對嵌入式設(shè)計進(jìn)行嚴(yán)格測試所必需的。其中，覆蓋測試表示代碼的穩(wěn)定性，所以這種測試是用于已經(jīng)完成或?qū)⒔瓿傻漠a(chǎn)品的。另一方面，可在編寫要求文檔時，同時編寫功能測試。

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

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

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

2．找出每個功能的哪些部分沒被執(zhí)行。

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

4．運(yùn)行新增的額外測試。

5．重復(fù)以上步驟。

何時停止測試？

最通用的停止標(biāo)準(zhǔn)(按可靠性排序)如下：

1．老板命令停止測試

2．新的測試周期找到的新缺陷少于X個

3．在沒有發(fā)現(xiàn)任何新缺陷的情況下已經(jīng)滿足了某個覆蓋閥限

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

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

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