軟體測試的基本觀念

更多精彩请到 http://www.139ya.com

軟體測試的基本觀念 軟 體測試的議題，一般而言都可寫成專書來做論述，但在此節中，筆者僅就常見的以及本書所觸及的議題來做扼要的講述，並偏重於實作程式時的測試技術，所以沒有 對所有的議題做完整的論述；因此，想對軟體測試議題做通盤瞭解的讀者，則不妨上 amazon 網站鍵入 software testing 做搜尋，相信一定可以找到不少的專書著作。 Black Box Testing versus White Box Testing 在 說明正題之前，我們不妨來看個生活化的案例 ── Black Box Users versusWhite Box Users。什麼是black box users？大部分的人都是 black box users，也就是在購買家電或資訊產品時，只在乎它能完成什麼樣的功能以及如何使用，至於產品本身是如何完成該功能，使用者一點都不在乎；white box users 則是典型的好奇寶寶，這群使用者對於產品是如何完成各項功能，有著非常強烈的好奇心，而為了一窺箇中堂奧，凡是買回來的家電或資訊產品，幾乎都會遭到拆 解，以滿足其內心的好奇渴望。 看完 black box users 與white box users 的說明，相信在讀者的心中，對於什麼是 black box testing 與 white box testing，已經大致有譜了。所謂「Black Box Testing」，是指只知道受測元件的介面與功能等規格(例如它應當執行哪些功能，以及「什麼樣的 input 該得到什麼樣的 output」等等)，但完全不瞭解或是完全不在乎受測元件是如何完成這些功能；在這樣的環境與條件下所執行的測試，就是 black box testing。 就「Test Case Design」而言，因為 black box test case 完全不涉及受測元件的內部架構與實作的細節，所以它的可重複使用性很高，而且不需要等到受測元件完成之後才能設計 test case。 所 謂「White Box Testing」，是指根據受測元件的規格、以及其內部的架構、實作的細節與設計意圖(design intention)，而所執行的測試。white box testing 的優點是：除了可驗證實作細節的設計意圖之外，亦能操控受測元件的內部機制，使得測試者可以進一步地以更有效率的方式來測試受測元件；例如藉由操控內部的 某些機制，可以更方便地產生某些特殊的 input pattern，或是讓受測元件以更短的時間進入某種狀態等等。 就「Test Case Design」而言，white box test case 必須挑戰內部架構與實作細節的設計意圖，才能極大化其驗證的效果，所以設計 test case 的人最好不要找實作細節的執行者，以避免「當局者迷」所帶來的缺點與盲點；此外，由於 white box test case 與受測元件的內部架構與實作細節之相依程度很高，一旦受測元件改採不同的架構或實作方式，test case 就得重新設計，所以它的可重複使用性很低；最後，相較於 black box test case，white box test case 通常必須等到受測元件完成之後，才能開始設計，所以它在設計的時程上是受制於產品的研發進度。 Static Testing versus Dynamic Testing 所 謂「Static Testing」，顧名思義，就是在受測元件處於靜止的狀態下，對它所執行的測試；所謂「Dynamic Testing」，是指在受測元件處於活躍的狀態下，對它所執行的測試。以買車為例，到汽車展示場看車時，就是在執行 static testing，例如，打開車門進去坐坐，握握方向盤，用手觸摸內裝的質感，觀察其內裝的組裝品質與儀表版的配置，再走出車外用眼睛觀察烤漆的品質，用腳 踢踢輪胎，掀開引擎蓋看看引擎等等；跟汽車展商約定試車時間與地點，將車子駛上道路做試開，感受其馬力、扭力、引擎運轉的流暢性、避震的效果、隔音的靜謐 性以及轉彎的順暢度與離心力道等等，就是在執行 dynamic testing。 就軟體而言，只要程式碼還沒開始動工，就只能執行 static testing，例如 requirement validation、specification review、architecture review 等等，等到程式碼開始動工之後，才能依序展開各項的 dynamic testing，例如 unit test、integration test 與 systemtest 等等。 Validation versus Verification 簡 單地說，「Validation」是指「做對的事情 (do the right things)」，例如產品研發的大方向與目標對或不對、正確或不正確；而「Verification」則是指「把事情做對 (do the things right)」，例如專案的執行力好或不好，實作的技術能力精準或不精準。 以患病求診為例，針對醫生所開立的處方，檢視其 是否「對症下藥」，就是在做 validation；就病人而言，檢視其是否「按時服藥」，就是在做 verification。就軟體而言，validation 是在檢視產品所提供的功能，是否為使用者所期盼的功能，以及是否滿足了使用者的需求等等，而 verification 則是在檢視產品是否依照當初所規劃的規格來設計與實作，以及完工後的品質是否符合標準等等。