數據庫測試

前天剛被Oracle電話ＢＳ一頓，今天又迅速的被ＢＳ了，多是手機的問題，一直聽不清對方的話，不少問題我都讓她重複了幾遍，估計她也要抓狂了。 先說下今天電話面試的大致內容吧： １）先了解下我大概去實習的具體時間； ２）對個人實習經歷很感興趣，讓我說下實習所作的具體工做，這也是我悲劇的地方，由於沒聽清她所問的問題，也就本身揣磨了她的意思，而後本身一我的balalbala的提及來了，說到中途時，她打斷我了，而後直接換了個方式問我，又是一串的balabala。。。在這裏要說下，若是沒懂對方的意思，必定要果斷再問，直到問清！不要怕問！（我就是以爲問得太多了，很差意思。。。） 3）研發和測試的見解。。（這個感受本身答的還過得去）； 4）問我有沒有什麼問題問她，想了片刻，以爲如今若是直接問待遇的話不是很好，因此就問了下公司如今的項目，用什麼語言，而後進一步探討了下python和perl哪一個更有前景。（木有養分的問題）最後，要我等最後的通知。（若是要掛，我以爲就是本身沒聽清問題，本身就開始balabala的說，有點搶風頭的感受！！！） 在此，順便把前天的面試的狀況也大體說下： １）面試之初，先下我作個英文的自我介紹，準備了一個下午啊，英語雖渣，但一個下午的準備仍是沒什麼問題的； ２）就我我的項目問題進行了深刻的瞭解； ３）Linux的經常使用命令； ４）ＴＣＰ／ＩＰ最經典的問題：三次握手； ５）實習的經歷； 在此愈加以爲實習經歷必定要徹底熟悉記得，因此把實習相關的重要知識點在此作個總結： 1、墨盒測試： 黑盒測試是以用戶的角度，從輸入數據與輸出數據的對應關係出發進行測試的。很明顯，若是外部特性自己設計有問題或規格說明的規定有誤，用黑盒測試方法是發現不了的。 編輯本段做用 黑盒測試法注重於測試軟件的功能需求，主要試圖發現下列幾類錯誤。 功能不正確或遺漏； 界面錯誤； 輸入和輸出錯誤； 數據庫訪問錯誤； 性能錯誤； 初始化和終止錯誤等。 編輯本段測試方法 概述 從理論上講，黑盒測試只有採用窮舉輸入測試，把全部可能的輸入都做爲測試狀況考慮，才能查出程序中全部的錯誤。實際上測試狀況有無窮多個，人們不只要測試全部合法的輸入，並且還要對那些不合法但可能的輸入進行測試。這樣看來，徹底測試是不可能的，因此咱們要進行有針對性的測試，經過制定測試案例指導測試的實施，保證軟件測試有組織、按步驟，以及有計劃地進行。黑盒測試行爲必須可以加以量化，才能真正保證軟件質量，而測試用例就是將測試行爲具體量化的方法之一。具體的黑盒測試用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、斷定表驅動法、正交試驗設計法、功能圖法、場景法等。 等價類劃分的辦法是把程序的輸入域劃分紅若干部分（子集），而後從每一個部分中選取少數表明性數據做爲測試用例。每一類的表明性數據在測試中的做用等價於這一類中的其餘值。該方法是一種重要的，經常使用的黑盒測試用例設計方法。 劃分等價類 1) 劃分等價類： 等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等效的，併合理地假定：測試某等價類的表明值就等於對這一類其它值的測試.所以，能夠把所有輸入數據合理劃分爲若干等價類，在每個等價類中取一個數據做爲測試的輸入條件，就能夠用少許表明性的測試數據.取得較好的測試結果.等價類劃分可有兩種不一樣的狀況：有效等價類和無效等價類. 有效等價類：是指對於程序的規格說明來講是合理的，有意義的輸入數據構成的集合.利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能. 無效等價類：與有效等價類的定義恰巧相反. 設計測試用例時，要同時考慮這兩種等價類.由於，軟件不只要能接收合理的數據，也要能經受意外的考驗.這樣的測試才能確保軟件具備更高的可靠性. 劃分等價類準則 2）劃分等價類的方法：下面給出六條肯定等價類的原則. ①在輸入條件規定了取值範圍或值的個數的狀況下，則能夠確立一個有效等價類和兩個無效等價類. ②在輸入條件規定了輸入值的集合或者規定了「必須如何」的條件的狀況下，可確立一個有效等價類和一個無效等價類. ③在輸入條件是一個布爾量的狀況下，可肯定一個有效等價類和一個無效等價類. ④在規定了輸入數據的一組值（假定n個），而且程序要對每個輸入值分別處理的狀況下，可確立n個有效等價類和一個無效等價類. ⑤在規定了輸入數據必須遵照的規則的狀況下，可確立一個有效等價類（符合規則）和若干個無效等價類（從不一樣角度違反規則）. ⑥在確知已劃分的等價類中各元素在程序處理中的方式不一樣的狀況下，則應再將該等價類進一步的劃分爲更小的等價類. 3）設計測試用例：在確立了等價類後，可創建等價類表，列出全部劃分出的等價類： 輸入條件 輸入條件 有效等價類 無效等價類 而後從劃分出的等價類中按如下三個原則設計測試用例： ①爲每個等價類規定一個惟一的編號. ②設計一個新的測試用例，使其儘量多地覆蓋還沒有被覆蓋地有效等價類，重複這一步.直到全部的有效等價類都被覆蓋爲止. ③設計一個新的測試用例，使其僅覆蓋一個還沒有被覆蓋的無效等價類，重複這一步.直到全部的無效等價類都被覆蓋爲止。 邊界值分析 邊界值分析是經過選擇等價類邊界的測試用例。邊界值分析法不只重視輸入條件邊界，並且也必須考慮輸出域邊界。它是對等價類劃分方法的補充. （1）邊界值分析方法的考慮： 長期的測試工做經驗告訴咱們，大量的錯誤是發生在輸入或輸出範圍的邊界上，而不是發生在輸入輸出範圍的內部.所以針對各類邊界狀況設計測試用例，能夠查出更多的錯誤. 使用邊界值分析方法設計測試用例，首先應肯定邊界狀況.一般輸入和輸出等價類的邊界，就是應着重測試的邊界狀況.應當選取正好等於，剛剛大於或剛剛小於邊界的值做爲測試數據，而不是選取等價類中的典型值或任意值做爲測試數據. （2）基於邊界值分析方法選擇測試用例的原則： 1）若是輸入條件規定了值的範圍，則應取剛達到這個範圍的邊界的值，以及剛剛超越這個範圍邊界的值做爲測試輸入數據. 2）若是輸入條件規定了值的個數，則用最大個數,最小個數，比最小個數少一，比最大個數多一的數做爲測試數據. 3）根據規格說明的每一個輸出條件，使用前面的原則1）. 4）根據規格說明的每一個輸出條件，應用前面的原則2）. 5）若是程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最後一個元素做爲測試用例. 6）若是程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界上的值做爲測試用例. 7）分析規格說明，找出其它可能的邊界條件. 錯誤推測法 錯誤推測法是基於經驗和直覺推測程序中全部可能存在的各類錯誤，從而有針對性的設計測試用例的方法. 錯誤推測方法的基本思想： 列舉出程序中全部可能有的錯誤和容易發生錯誤的特殊狀況，根據他們選擇測試用例. 例如，在單元測試時曾列出的許多在模塊中常見的錯誤. 之前產品測試中曾經發現的錯誤等，這些就是經驗的總結. 還有，輸入數據和輸出數據爲0的狀況. 輸入表格爲空格或輸入表格只有一行. 這些都是容易發生錯誤的狀況. 可選擇這些狀況下的例子做爲測試用例. 因果圖法 前面介紹的等價類劃分方法和邊界值分析方法，都是着重考慮輸入條件，但未考慮輸入條件之間的聯繫，相互組合等. 考慮輸入條件之間的相互組合，可能會產生一些新的狀況. 但要檢查輸入條件的組合不是一件容易的事情，即便把全部輸入條件劃分紅等價類，他們之間的組合狀況也至關多. 所以必須考慮採用一種適合於描述對於多種條件的組合，相應產生多個動做的形式來考慮設計測試用例. 這就須要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是斷定表. 它適合於檢查程序輸入條件的各類組合狀況. 因果圖生成測試用例 （1) 分析軟件規格說明描述中，哪些是緣由（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），並給每一個緣由和結果賦予一個標識符. (2) 分析軟件規格說明描述中的語義.找出緣由與結果之間，緣由與緣由之間對應的關係. 根據這些關係，畫出因果圖. (3) 因爲語法或環境限制，有些緣由與緣由之間，緣由與結果之間的組合狀況不可能出現. 爲代表這些特殊狀況，在因果圖上用一些記號標明約束或限制條件. (4) 把因果圖轉換爲斷定表. (5) 把斷定表的每一列拿出來做爲依據，設計測試用例. 從因果圖生成的測試用例（局部，組合關係下的）包括了全部輸入數據的取TRUE與取FALSE的狀況，構成的測試用例數目達到最少，且測試用例數目隨輸入數據數目的增長而線性地增長. 前面因果圖方法中已經用到了斷定表.斷定表（Decision Table）是分析和表達多邏輯條件下執行不一樣操做的狀況下的工具.在程序設計發展的初期,斷定表就已被看成編寫程序的輔助工具了.因爲它能夠把複雜的邏輯關係和多種條件組合的狀況表達得既具體又明確. 斷定表組成 條件樁（Condition Stub）：列出了問題得全部條件.一般認爲列出得條件的次序可有可無. 動做樁（Action Stub）：列出了問題規定可能採起的操做.這些操做的排列順序沒有約束. 條件項（Condition Entry）：列出針對它左列條件的取值.在全部可能狀況下的真假值. 動做項（Action Entry）：列出在條件項的各類取值狀況下應該採起的動做. 規則：任何一個條件組合的特定取值及其相應要執行的操做.在斷定表中貫穿條件項和動做項的一列就是一條規則.顯然，斷定表中列出多少組條件取值，也就有多少條規則，既條件項和動做項有多少列. 斷定表的創建步驟 ①肯定規則的個數.假若有n個條件.每一個條件有兩個取值（0,1），故有2n種規則. ②列出全部的條件樁和動做樁. ③填入條件項. ④填入動做項.等到初始斷定表. ⑤簡化.合併類似規則（相同動做）. B. Beizer 指出了適合使用斷定表設計測試用例的條件： ①規格說明以斷定表形式給出，或很容易轉換成斷定表. ②條件的排列順序不會也不影響執行哪些操做. ③規則的排列順序不會也不影響執行哪些操做. ④每當某一規則的條件已經知足，並肯定要執行的操做後，沒必要檢驗別的規則. ⑤若是某一規則獲得知足要執行多個操做，這些操做的執行順序可有可無. 參考資料：http://baike.baidu.com/view/51274.htm 2、白盒測試； 白盒測試（white-box testing）又稱透明盒測試（glass box testing）、結構測試（structural testing）等，軟件測試的主要方法之一，也稱結構測試、邏輯驅動測試或基於程序自己的測試。測試應用程序的內部結構或運做，而不是測試應用程序的功能（即黑盒測試）。在白盒測試時，以編程語言的角度來設計測試案例。測試者輸入數據驗證數據流在程序中的流動路徑，並肯定適當的輸出，相似測試電路中的節點。測試者瞭解待測試程序的內部結構、算法等信息，這是從程序設計者的角度對程序進行的測試。 白盒測試能夠應用於單元測試（unit testing）、集成測試（integration testing）和系統的軟件測試流程，可測試在集成過程當中每一單元之間的路徑，或者主系統跟子系統中的測試。儘管這種測試的方法能夠發現許多的錯誤或問題，它可能沒法檢測未使用部分的規範。 參考資料：http://zh.wikipedia.org/wiki/%E7%99%BD%E7%9B%92%E6%B5%8B%E8%AF%95 3、單元測試； 單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，通常來講，要根據實際狀況去斷定其具體含義，如C語言中單元指一個函數，Java裏單元指一個類，圖形化的軟件中能夠指一個窗口或一個菜單等。總的來講，單元就是人爲規定的最小的被測功能模塊。單元測試是在軟件開發過程當中要進行的最低級別的測試活動，軟件的獨立單元將在與程序的其餘部分相隔離的狀況下進行測試。 簡介 在一種傳統的結構化編程語言中，好比C，要進行測試的單元通常是函數或子過程。在像C++這樣的面向對象的語言中， 要進行測試的基本單元是類。對Ada語言來講，開發人員能夠選擇是在獨立的過程和函數，仍是在Ada包的級別上進行單元測試。單元測試的原則一樣被擴展到第四代語言（4GL)的開發中，在這裏基本單元被典型地劃分爲一個菜單或顯示界面。 常常與單元測試聯繫起來的另一些開發活動包括代碼走讀（Code review)，靜態分析（Static analysis)和動態分析（Dynamic analysis)。靜態分析就是對軟件的源代碼進行研讀，查找錯誤或收集一些度量數據，並不須要對代碼進行編譯和執行。動態分析就是經過觀察軟件運行時的動做，來提供執行跟蹤，時間分析，以及測試覆蓋度方面的信息。 編輯本段詳解 cppunit進行單元測試   cppunit進行單元測試 單元測試（模塊測試）是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。一般而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數的行爲。例如，你可能把一個很大的值放入一個有序list 中去，而後確認該值出如今list 的尾部。或者，你可能會從字符串中刪除匹配某種模式的字符，而後確認字符串確實再也不包含這些字符了。 單元測試是由程序員本身來完成，最終受益的也是程序員本身。能夠這麼說，程序員有責任編寫功能代碼，同時也就有責任爲本身的代碼編寫單元測試。執行單元測試，就是爲了證實這段代碼的行爲和咱們指望的一致。 工廠在組裝一臺電視機以前，會對每一個元件都進行測試，這，就是單元測試。 其實咱們天天都在作單元測試。你寫了一個函數，除了極簡單的外，老是要執行一下，看看功能是否正常，有時還要想辦法輸出些數據，如彈出信息窗口什麼的，這，也是單元測試，把這種單元測試稱爲臨時單元測試。只進行了臨時單元測試的軟件，針對代碼的測試很不完整，代碼覆蓋率要超過70%都很困難，未覆蓋的代碼可能遺留大量的細小的錯誤，這些錯誤還會互相影響，當BUG暴露出來的時候難於調試，大幅度提升後期測試和維護成本，也下降了開發商的競爭力。能夠說，進行充分的單元測試，是提升軟件質量，下降開發成本的必由之路。 對於程序員來講，若是養成了對本身寫的代碼進行單元測試的習慣，不但能夠寫出高質量的代碼，並且還能提升編程水平。 要進行充分的單元測試，應專門編寫測試代碼，並與產品代碼隔離。我認爲，比較簡單的辦法是爲產品工程創建對應的測試工程，爲每一個類創建對應的測試類，爲每一個函數（很簡單的除外）創建測試函數。首先就幾個概念談談個人見解。 通常認爲，在結構化程序時代，單元測試所說的單元是指函數，在當今的面向對象時代，單元測試所說的單元是指類。以個人實踐來看，以類做爲測試單位，複雜度高，可操做性較差，所以仍然主張以函數做爲單元測試的測試單位，但能夠用一個測試類來組織某個類的全部測試函數。單元測試不該過度強調面向對象，由於局部代碼依然是結構化的。單元測試的工做量較大，簡單實用高效纔是硬道理。 有一種見解是，只測試類的接口（公有函數），不測試其餘函數，從面向對象角度來看，確實有其道理，可是，測試的目的是找錯並最終排錯，所以，只要是包含錯誤的可能性較大的函數都要測試，跟函數是否私有沒有關係。對於C++來講，能夠用一種簡單的方法區隔需測試的函數：簡單的函數如數據讀寫函數的實如今頭文件中編寫（inline函數），全部在源文件編寫實現的函數都要進行測試（構造函數和析構函數除外）。 編輯本段使用效果 咱們編寫代碼時，必定會反覆調試保證它可以編譯經過。若是是編譯沒有經過的代碼，沒有任何人會願意交付給本身的老闆。但代碼經過編譯，只是說明了它的語法正確；咱們卻沒法保證它的語義也必定正確，沒有任何人能夠輕易承諾這段代碼的行爲必定是正確的。 幸運的是，單元測試會爲咱們的承諾作保證。編寫單元測試就是用來驗證這段代碼的行爲是否與咱們指望的一致。有了單元測試，咱們能夠自信的交付本身的代碼，而沒有任何的後顧之憂。 何時測試？單元測試越早越好，早到什麼程度？XP開發理論講究TDD，即測試驅動開發，先編寫測試代碼，再進行開發。在實際的工做中，能夠沒必要過度強調先什麼後什麼，重要的是高效和感受溫馨。從老納的經驗來看，先編寫產品函數的框架，而後編寫測試函數，針對產品函數的功能編寫測試用例，而後編寫產品函數的代碼，每寫一個功能點都運行測試，隨時補充測試用例。所謂先編寫產品函數的框架，是指先編寫函數空的實現，有返回值的隨便返回一個值，編譯經過後再編寫測試代碼，這時，函數名、參數表、返回類型都應該肯定下來了，所編寫的測試代碼之後需修改的可能性比較小。 由誰測試？單元測試與其餘測試不一樣，單元測試可看做是編碼工做的一部分，應該由程序員完成，也就是說，通過了單元測試的代碼纔是已完成的代碼，提交產品代碼時也要同時提交測試代碼。測試部門能夠做必定程度的審覈。 關於樁代碼，老納認爲，單元測試應避免編寫樁代碼。樁代碼就是用來代替某些代碼的代碼，例如，產品函數或測試函數調用了一個未編寫的函數，能夠編寫樁函數來代替該被調用的函數，樁代碼也用於實現測試隔離。採用由底向上的方式進行開發，底層的代碼先開發並先測試，能夠避免編寫樁代碼，這樣作的好處有：減小了工做量；測試上層函數時，也是對下層函數的間接測試；當下層函數修改時，經過迴歸測試能夠確認修改是否致使上層函數產生錯誤。 在一種傳統的結構化編程語言中，好比C，要進行測試的單元通常是函數或子過程。在象C++這樣的面向對象的語言中， 要進行測試的基本單元是類。對Ada語言來講，開發人員能夠選擇是在獨立的過程和函數，仍是在Ada包的級別上進行單元測試。單元測試的原則一樣被擴展到第四代語言（4GL)的開發中，在這裏基本單元被典型地劃分爲一個菜單或顯示界面。 一些流行的誤解 在明確了什麼是單元測試之後，咱們能夠進行"反調論證"了。在下面的章節裏，咱們列出了一些反對單元測試的廣泛的論點。而後用充分的理由來證實這些論點是不足取的。 它浪費了太多的時間 一旦編碼完成，開發人員老是會迫切但願進行軟件的集成工做，這樣他們就可以看到實際的系統開始啓動工做了。這在外表上看來是一項明顯的進步，而象單元測試這樣的活動也許會被看做是通往這個階段點的道路上的障礙， 推遲了對整個系統進行聯調這種真正有意思的工做啓動的時間。 在這種開發步驟中，真實意義上的進步被外表上的進步取代了。系統可以正常工做的可能性是很小的，更多的狀況是充滿了各式各樣的Bug。在實踐中，這樣一種開發步驟經常會致使這樣的結果：軟件甚至沒法運行。更進一步的結果是大量的時間將被花費在跟蹤那些包含在獨立單元裏的簡單的Bug上面，在個別狀況下，這些Bug也許是瑣碎和微不足道的，可是總的來講，他們會致使在軟件集成爲一個系統時增長額外的工期， 並且當這個系統投入使用時也沒法確保它可以可靠運行。 在實踐工做中，進行了完整計劃的單元測試和編寫實際的代碼所花費的精力大體上是相同的。一旦完成了這些單元測試工做，不少Bug將被糾正，在確信他們手頭擁有穩定可靠的部件的狀況下，開發人員可以進行更高效的系統集成工做。這纔是真實意義上的進步，因此說完整計劃下的單元測試是對時間的更高效的利用。而調試人員的不受控和散漫的工做方式只會花費更多的時間而取得不多的好處。 使用AdaTEST和Cantata這樣的支持工具可使單元測試更加簡單和有效。但這不是必須的，單元測試即便是在沒有工具支持的狀況下也是一項很是有意義的活動。 它僅僅是證實這些代碼作了什麼 這是那些沒有首先爲每一個單元編寫一個詳細的規格說明而直接跳到編碼階段的開發人員提出的一條廣泛的抱怨， 當編碼完成之後而且面臨代碼測試任務的時候，他們就閱讀這些代碼並找出它實際上作了什麼，把他們的測試工做基於已經寫好的代碼的基礎上。固然，他們沒法證實任何事情。全部的這些測試工做可以代表的事情就是編譯器工做正常。是的，他們也許可以抓住（但願可以）罕見的編譯器Bug，可是他們可以作的僅僅是這些。 若是他們首先寫好一個詳細的規格說明，測試可以以規格說明爲基礎。代碼就可以針對它的規格說明，而不是針對自身進行測試。這樣的測試仍然可以抓住編譯器的Bug，同時也能找到更多的編碼錯誤，甚至是一些規格說明中的錯誤。好的規格說明可使測試的質量更高，因此最後的結論是高質量的測試須要高質量的規格說明。 在實踐中會出現這樣的狀況：一個開發人員要面對測試一個單元時只給出單元的代碼而沒有規格說明這樣吃力不討好的任務。你怎樣作纔會有更多的收穫，而不只僅是發現編譯器的Bug？第一步是理解這個單元本來要作什麼， --- 不是它實際上作了什麼。比較有效的方法是倒推出一個概要的規格說明。這個過程的主要輸入條件是要閱讀那些程序代碼和註釋， 主要針對這個單元， 及調用它和被它調用的相關代碼。畫出流程圖是很是有幫助的，你能夠用手工或使用某種工具。能夠組織對這個概要規格說明的走讀（Review)，以確保對這個單元的說明沒有基本的錯誤， 有了這種最小程度的代碼深層說明，就能夠用它來設計單元測試了。 我是個很棒的程序員， 我是否是能夠不進行單元測試？ 在每一個開發組織中都至少有一個這樣的開發人員，他很是擅長於編程，他們開發的軟件老是在第一時間就能夠正常運行，所以不須要進行測試。你是否常常聽到這樣的藉口？ 在真實世界裏，每一個人都會犯錯誤。即便某個開發人員能夠抱着這種態度在不多的一些簡單的程序中應付過去。但真正的軟件系統是很是複雜的。真正的軟件系統不能夠寄但願於沒有進行普遍的測試和Bug修改過程就能夠正常工做。 編碼不是一個能夠一次性經過的過程。在真實世界中，軟件產品必須進行維護以對操做需求的改變做出反應， 而且要對最初的開發工做遺留下來的Bug進行修改。你但願依靠那些原始做者進行修改嗎？ 這些製造出這些未經測試的原始代碼的資深專家們還會繼續在其餘地方製造這樣的代碼。在開發人員作出修改後進行可重複的單元測試能夠避免產生那些使人不快的負做用。 無論怎樣， 集成測試將會抓住全部的Bug 咱們已經在前面的討論中從一個側面對這個問題進行了部分的闡述。這個論點不成立的緣由在於規模越大的代碼集成意味着複雜性就越高。若是軟件的單元沒有事先進行測試，開發人員極可能會花費大量的時間僅僅是爲了使軟件可以運行，而任何實際的測試方案都沒法執行。 一旦軟件能夠運行了，開發人員又要面對這樣的問題：在考慮軟件全局複雜性的前提下對每一個單元進行全面的測試。這是一件很是困難的事情，甚至在創造一種單元調用的測試條件的時候，要全面的考慮單元的被調用時的各類入口參數。在軟件集成階段，對單元功能全面測試的複雜程度遠遠的超過獨立進行的單元測試過程。 最後的結果是測試將沒法達到它所應該有的全面性。一些缺陷將被遺漏，而且不少Bug將被忽略過去。 讓咱們類比一下，假設咱們要清洗一臺已經徹底裝配好的食物加工機器！不管你噴了多少水和清潔劑，一些食物的小碎片仍是會粘在機器的死角位置，只有任其腐爛並等待之後再想辦法。但咱們換個角度想一想，若是這臺機器是拆開的， 這些死角也許就不存在或者更容易接觸到了，而且每一部分均可以絕不費力的進行清洗。 成本效率不高 一個特定的開發組織或軟件應用系統的測試水平取決於對那些未發現的Bug的潛在後果的重視程度。這種後果的嚴重程度能夠從一個Bug引發的小小的不便到發生屢次的死機的狀況。這種後果可能經常會被軟件的開發人員所忽視（可是用戶可不會這樣），這種狀況會長期的損害這些向用戶提交帶有Bug的軟件的開發組織的信譽，而且會致使對將來的市場產生負面的影響。相反地，一個可靠的軟件系統的良好的聲譽將有助於一個開發組織獲取將來的市場。 不少研究成果代表，不管何時做出修改都要進行完整的迴歸測試，在生命週期中儘早地對軟件產品進行測試將使效率和質量獲得最好的保證。Bug發現的越晚，修改它所需的費用就越高，所以從經濟角度來看， 應該儘量早的查找和修改Bug。在修改費用變的太高以前，單元測試是一個在早期抓住Bug的機會。 相比後階段的測試，單元測試的建立更簡單，維護更容易，而且能夠更方便的進行重複。從全程的費用來考慮， 相比起那些複雜且曠日持久的集成測試，或是不穩定的軟件系統來講，單元測試所需的費用是很低的。 參考資料：http://baike.baidu.com/view/106237.htm 4、功能測試： 定義 Functional testing（功能測試），也稱爲behavioral testing（行爲測試），根據產品特性、操做描述和用戶方案，測試一個產品的特性和可操做行爲以肯定它們知足設計需求。本地化軟件的功能測試，用於驗證應用程序或網站對目標用戶能正確工做。使用適當的平臺、瀏覽器和測試腳本，以保證目標用戶的體驗將足夠好，就像應用程序是專門爲該市場開發的同樣。功能測試是爲了確保程序以指望的方式運行而按功能要求對軟件進行的測試，經過對一個系統的全部的特性和功能都進行測試確保符合需求和規範。 功能測試也叫黑盒子測試或數據驅動測試，只需考慮各個功能，不須要考慮整個軟件的內部結構及代碼.通常從軟件產品的界面、架構出發，按照需求編寫出來的測試用例，輸入數據在預期結果和實際結果之間進行評測，進而提出更加使產品達到用戶使用的要求。 應用 以上是屬於程序軟件類的測試，下面介紹應用電子技術方面的測試 印刷電路板，又稱印製電路板，印刷線路板，常使用英文縮寫PCB（Printed circuit board），是重要的電子部件，是電子元件的支撐體，是電子元器件線路鏈接的提供者。因爲它是採用電子印刷技術製做的，故被稱爲「印刷」電路板。 在印製電路板出現以前，電子元件之間的互連都是依靠電線直接鏈接而組成完整的線路。如今，電路面包板只是做爲有效的實驗工具而存在，而印刷電路板在電子工業中已經成了佔據了絕對統治的地位。 20世紀初，人們爲了簡化電子機器的製做，減小電子零件間的配線，下降製做成本等優勢，因而開始鑽研以印刷的方式取代配線的方法。三十年間，不斷有工程師提出在絕緣的基板上加以金屬導體做配線。而最成功的是1925年，美國的Charles Ducas 在絕緣的基板上印刷出線路圖案，再以電鍍的方式，成功創建導體做配線。[1] 直至1936年，奧地利人保羅·愛斯勒（Paul Eisler）在英國發表了箔膜技術[1]，他在一個收音機裝置內採用了印刷電路板；而在日本，宮本喜之助以噴附配線法「メタリコン法吹着配線方法（特許119384號）」成功申請專利。[2]而二者中Paul Eisler 的方法與現今的印刷電路板最爲類似，這類作法稱爲減去法，是把不須要的金屬除去；而Charles Ducas、宮本喜之助的作法是隻加上所需的配線，稱爲加成法。雖然如此，但由於當時的電子零件發熱量大，二者的基板也難以配合使用[1]，以至未有正式的實用做，不過也使印刷電路技術更進一步。