新聞中心

        EEPW首頁 > 嵌入式系統 > 設計應用 > 嵌入式軟件測試基礎知識

        嵌入式軟件測試基礎知識

        作者: 時間:2012-12-12 來源:網絡 收藏


        選擇測試案例

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

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

        顯然,理想的狀況是無法實現的,因此你必須采用接近這種理想狀況的標準。如你所見,功能測試與覆蓋測試相結合可以提供合理的次優選擇方案。基本方法是選擇最有可能發現錯誤的測試(一部分功能測試,一部分覆蓋測試)。

        1.功能測試

        功能測試一般稱為黑匣子測試,因為在編寫功能測試的測試例程時并沒有涉及實際的代碼。換句話說,沒有觸及到“匣子內”。系統有輸入和輸出,并在輸入和輸出之間執行某些算法。黑匣子測試是根據對哪些輸入應該是可接受的以及這些輸入應與輸出有何種關系的了解來進行的。黑匣子測試完全不了解輸入與輸出之間的算法是如何實現的。黑匣子測試的示例包括:

        壓力測試:有意使輸入通道、內存緩沖器、磁盤控制器、存儲器管理系統等過載的測試

        邊界值測試:表示特定范圍內的“邊界”的輸入(例如,對于整數輸入而言,是最大和最小整數以及-1、0、+1);以及應使輸出在輸出范圍的類似邊界出現跨變的輸入值。

        異常測試:能觸發故障模式或異常模式的測試。

        錯誤推測:根據以前的經驗或者從測試類似程序獲得的經驗進行的測試。

        隨機測試:通常,這是效率最低的一種測試方法,但卻仍然廣泛用于評估用戶界面代碼的魯棒性。

        性能測試:由于性能預期是產品要求的一部分,因此性能分析屬于功能測試的范疇。

        由于黑匣子測試僅取決于程序要求及其I/O行為,因此一旦完成功能要求的編寫,即可開發這類測試。這使得黑匣子測試例程的開發可以與余下的系統設計同步進行。

        與所有測試一樣,功能測試應被設計得具有破壞性,也即,要試圖證明程序無法工作。這包括使輸入通道過載、隨意地敲打鍵盤,以及故意地做程序員認為會破壞其程序的所有事情。

        作為研發產品經理,這是我的主要測試方法之一。如果產品在經過40個小時的極限測試(abuse testing)后,并沒發現任何嚴重或者致命的缺陷,那么就可以發布這個產品了。如果找到了一個重大的缺陷,那么修正這個缺陷后,還必須重復前面的測試步驟。

        2.覆蓋測試

        功能測試的缺點是其很少執行全部代碼。覆蓋測試則試圖規避這個缺點,它采用的方法是(理想地)確保每一條代碼語句、判定點或者判定路徑都至少被測試一次。覆蓋測試還可以顯示已經訪問的數據空間大小。

        覆蓋測試也稱為白匣子測試或玻璃匣子測試,這類測試的設計需要全面了解軟件的實現方式,也就是說,它要“看到匣子里面”。白匣子測試利用了源代碼所能提供的方便。

        白匣子測試充分借力了程序員對程序API、內部控制結構的知識,分享了程序員的異常處理能力。由于白匣子測試取決于具體的實現決策,因此要到應用代碼完成后,才能動手設計這類測試。

        系統的角度來看,覆蓋測試是最重要的測試,這是因為只要你把握已在多大程度上對代碼進行了測試,你就可很好地預警出現未發現缺陷的風險。白匣子測試的示例包括:

        語句覆蓋:選擇的測試案例可以至少將程序中的每一條語句執行一次。

        判定或分支覆蓋:選擇的測試例程可以使每一個分支(條件為真和假的路徑)至少執行一次。

        條件覆蓋:選擇的測試例程可以強制判定中的每一個條件(項)都包含所有可能的邏輯值。

        理論上,白匣子測試可以利用或控制所需的任何對象來執行其測試。因此,白匣子測試可能使用JTAG接口強制設定特定的存儲器值作為測試的一部分。實踐上,白匣子測試可以分析邏輯分析儀報告的執行路徑。

        3.灰匣子測試

        由于白匣子測試可以深入代碼內部,因此與黑匣子測試相比,這類測試的維護成本更高。只要要求和I/O關系保持穩定,黑匣子測試就會一直有效;但每次修改代碼后,可能都需要重新進行白匣子測試。因此成本效益最高的白匣子測試一般是那些在不深入編程細節的情況下利用實現知識進行的測試。

        較少涉及代碼細節的測試有時也稱為灰匣子測試。當與“錯誤推測”配合使用時,灰匣子測試非常有效。如果你知道(或者至少猜到)代碼中的弱點在哪里,那么你就可以設計出對這些弱點“施壓”的測試案例。

        因為這些測試覆蓋了代碼的特定部分,因此這些測試是灰匣子測試;因為這些測試是根據可能會出現哪些錯誤的猜測而選擇的,因此這些測試是錯誤推測測試。

        在整合新功能與穩定的舊代碼庫時,這種測試策略非常有用。由于代碼庫已經過全面的測試,因此將測試重點集中在新、舊代碼交集處可以起到事半功倍的效果。

        本文引用地址:http://www.104case.com/article/148196.htm
        linux操作系統文章專題:linux操作系統詳解(linux不再難懂)

        上一頁 1 2 下一頁

        評論


        相關推薦

        技術專區

        關閉
        主站蜘蛛池模板: 松桃| 英超| 海淀区| 谢通门县| 洛阳市| 扎赉特旗| 栾川县| 临沂市| 万宁市| 年辖:市辖区| 浦江县| 邹城市| 新巴尔虎左旗| 霍州市| 云浮市| 邳州市| 越西县| 浮梁县| 房山区| 石台县| 铜山县| 大冶市| 古蔺县| 读书| 万全县| 嘉鱼县| 改则县| 涿州市| 牙克石市| 曲靖市| 天津市| 班玛县| 榆中县| 盐源县| 资兴市| 萝北县| 达孜县| 余干县| 如皋市| 白玉县| 玉环县|