定義
Functional testing（功能測試），也稱為behavioral testing（行為測試），根據産品特性、操作描述和用戶方案，測試一個産品的特性和可操作行為以确定它們滿足設計需求。本地化軟件的功能測試，用于驗證應用程序或網站對目标用戶能正确工作。使用适當的平台、浏覽器和測試腳本，以保證目标用戶的體驗将足夠好，就像應用程序是專門為該市場開發的一樣。功能測試是為了确保程序以期望的方式運行而按功能要求對軟件進行的測試，通過對一個系統的所有的特性和功能都進行測試确保符合需求和規範。
應用
以上是屬于程序軟件類的測試，下面介紹應用電子技術方面的測試
印刷電路闆，又稱印制電路闆，印刷線路闆，常使用英文縮寫PCB（Printed circuit board），是重要的電子部件，是電子元件的支撐體，是電子元器件線路連接的提供者。由于它是采用電子印刷技術制作的，故被稱為“印刷”電路闆。
在印制電路闆出現之前，電子元件之間的互連都是依靠電線直接連接而組成完整的線路。電路面包闆隻是作為有效的實驗工具而存在，而印刷電路闆在電子工業中已經成了占據了絕對統治的地位。
20世紀初，人們為了簡化電子機器的制作，減少電子零件間的配線，降低制作成本等優點，于是開始鑽研以印刷的方式取代配線的方法。三十年間，不斷有工程師提出在絕緣的基闆上加以金屬導體作配線。而最成功的是1925年，美國的Charles Ducas 在絕緣的基闆上印刷出線路圖案，再以電鍍的方式，成功建立導體作配線。
直至1936年，奧地利人保羅·愛斯勒（Paul Eisler）在英國發表了箔膜技術，他在一個收音機裝置内采用了印刷電路闆；而在日本，宮本喜之助以噴附配線法“メタリコン法吹着配線方法（特許119384号）”成功申請專利。而兩者中Paul Eisler 的方法與現今的印刷電路闆最為相似，這類做法稱為減去法，是把不需要的金屬除去；而Charles Ducas、宮本喜之助的做法是隻加上所需的配線，稱為加成法。雖然如此，但因為當時的電子零件發熱量大，兩者的基闆也難以配合使用，以緻未有正式的實用作，不過也使印刷電路技術更進一步。
發展
1941年，美國在滑石上漆上銅膏作配線，以制作近接信管。
1943年，美國人将該技術大量使用于軍用收音機内。
1947年，環氧樹脂開始用作制造基闆。同時NBS開始研究以印刷電路技術形成線圈、電容器、電阻器等制造技術。
1948年，美國正式認可這個發明用于商業用途。
自20世紀50年代起，發熱量較低的晶體管大量取代了真空管的地位，印刷電路版技術才開始被廣泛采用。而當時以蝕刻箔膜技術為主流。
1950年，日本使用玻璃基闆上以銀漆作配線；和以酚醛樹脂制的紙質酚醛基闆（CCL）上以銅箔作配線。
1951年，聚酰亞胺的出現，便樹脂的耐熱性再進一步，也制造了聚亞酰胺基闆。
1953年，Motorola開發出電鍍貫穿孔法的雙面闆。這方法也應用到後期的多層電路闆上。
印刷電路闆廣泛被使用10年後的60年代，其技術也日益成熟。而自從Motorola的雙面闆面世，多層印刷電路闆開始出現，使配線與基闆面積之比更為提高。
1960年，V. Dahlgreen以印有電路的金屬箔膜貼在熱可塑性的塑膠中，造出軟性印刷電路闆。
1961年，美國的Hazeltine Corporation參考了電鍍貫穿孔法，制作出多層闆。
1967年，發表了增層法之一的“Plated-up technology”。
1969年，FD-R以聚酰亞胺制造了軟性印刷電路闆。
1979年，Pactel發表了增層法之一的“Pactel法”。
1984年，NTT開發了薄膜回路的“Copper Polyimide法”。
1988年，西門子公司開發了Microwiring Substrate的增層印刷電路闆。
1990年，IBM開發了“表面增層線路”（Surface Laminar Circuit，SLC）的增層印刷電路闆。
1995年，松下電器開發了ALⅣH的增層印刷電路闆。
1996年，東芝開發了B2it的增層印刷電路闆。
就在衆多的增層印刷電路闆方案被提出的1990年代末期，增層印刷電路闆也正式大量地被實用化。
為大型、高密度的印刷電路闆裝配（PCBA,printed circuit board assembly）發展一個穩健的測試策略是重要的，以保證與設計的符合與功能。除了這些複雜裝配的建立與測試之外，單單投入在電子零件中的金錢可能是很高的，當一個單元到最後測試時可能達到25,000美元。由于這樣的高成本，查找與修理裝配的問題是重要的步驟。今天更複雜的裝配大約18平方英寸，18層；在頂面和底面有2900多個元件；含有6000個電路節點；有超過20000個焊接點需要測試。
在朗訊加速的制造工廠（N. Andover,MA），制造和測試藝術級的PCBA和完整的傳送系統。超過5000節點數的裝配對我們是一個關注，因為它們已經接近我們現有的在線測試（ICT,in circuit test）設備的資源極限（圖一）。我們制造大約800種不同的PCBA或“節點”。在這800種節點中，大約20種在5000~6000個節點範圍。可是，這個數迅速增長。
新的開發項目要求更加複雜、要有更大的PCBA和更緊密的包裝。這些要求挑戰我們建造和測試這些單元的能力。更進一步，具有更小元件和更高節點數的更大電路闆可能将會繼續。例如，正在畫電路闆圖的一個設計，有大約116000個節點、超過5100個元件和超過37800個要求測試或确認的焊接點。這個單元還有BGA在頂面與底面，BGA是緊接着的。使用傳統的針床測試這個尺寸和複雜性的闆，ICT一種方法是不可能的。
在制造工藝，特别是在測試中，不斷增加的PCBA複雜性和密度不是一個新的問題。意識到的增加ICT測試夾具内的測試針數量不是要走的方向，我們開始觀察可代替的電路确認方法。看到每百萬探針不接觸的數量，我們發現在5000個節點時，許多發現的錯誤（少于31）可能是由于探針接觸問題而不是實際制造的缺陷（表一）。因此，我們着手将測試針的數量減少，而不是上升。盡管如此，我們制造工藝的品質還是評估到整個PCBA。我們決定使用傳統的ICT與X射線分層法相結合是一個可行的解決方案。
黑盒
概述
黑盒測試（Black-box Testing，又稱為功能測試或數據驅動測試）是把測試對象看作一個黑盒子。利用黑盒測試法進行動态測試時，需要測試軟件産品的功能，不需測試軟件産品的内部結構和處理過程。
比如黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。
黑盒測試注重于測試軟件的功能性需求，也即黑盒測試使軟件工程師派生出執行程序所有功能需求的輸入條件。黑盒測試并不是白盒測試的替代品，而是用于輔助白盒測試發現其他類型的錯誤。
黑盒測試試圖發現以下類型的錯誤：
（1）功能錯誤或遺漏
（2）界面錯誤
（3）數據結構或外部數據庫訪問錯誤
（4）性能錯誤
（5）初始化和終止錯誤
用例設計
（1）等價類劃分方法
（2）邊界值分析方法
（3）錯誤推測方法
（4）因果圖方法
（5）判定表驅動分析方法
（6）正交實驗設計方法
（7）功能圖分析方法
等價類劃分
是把所有可能的輸入數據，即程序的輸入域劃分成若幹部分（子集），然後從每一個子集中選取少數具有代表性的數據作為測試用例.該方法是一種重要的，常用的黑盒測試用例設計方法。
劃分等價類
等價類是指某個輸入域的子集合.在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的.并合理地假定：測試某等價類的代表值就等于對這一類其它值的測試.因此，可以把全部輸入數據合理劃分為若幹等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況：有效等價類和無效等價類。
有效等價類：是指對于程序的規格說明來說是合理的，有意義的輸入數據構成的集合.利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能。
無效等價類：與有效等價類的定義恰巧相反。
設計測試用例時，要同時考慮這兩種等價類.因為，軟件不僅要能接收合理的數據，也要能經受意外的考驗.這樣的測試才能确保軟件具有更高的可靠性。
方法
下面給出六條确定等價類的原則。
①在輸入條件規定了取值範圍或值的個數的情況下，則可以确立一個有效等價類和兩個無效等價類。
②在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可确立一個有效等價類和一個無效等價類。
③在輸入條件是一個布爾量的情況下，可确定一個有效等價類和一個無效等價類。
④在規定了輸入數據的一組值（假定n個），并且程序要對每一個輸入值分别處理的情況下，可确立n個有效等價類和一個無效等價類。
⑤在規定了輸入數據必須遵守的規則的情況下，可确立一個有效等價類（符合規則）和若幹個無效等價類（從不同角度違反規則）。
⑥在确知已劃分的等價類中各元素在程序處理中的方式不同的情況下，則應再将該等價類進一步的劃分為更小的等價類。
設計用例
在确立了等價類後，可建立等價類表，列出所有劃分出的等價類：
輸入條件有效等價類無效等價類
.........
.........
然後從劃分出的等價類中按以下三個原則設計測試用例：
①為每一個等價類規定一個唯一的編号
②設計一個新的測試用例，使其盡可能多地複蓋尚未被複蓋地有效等價類，重複這一步.直到所有的有效等價類都被複蓋為止
③設計一個新的測試用例，使其僅複蓋一個尚未被複蓋的無效等價類，重複這一步.直到所有的無效等價類都被複蓋為止
邊界值分析法
邊界值分析方法是對等價類劃分方法的補充
⑴邊界值分析方法的考慮：
長期的測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出範圍的邊界上，而不是發生在輸入輸出範圍的内部.因此針對各種邊界情況設計測試用例，可以查出更多的錯誤
使用邊界值分析方法設計測試用例，首先應确定邊界情況.通常輸入和輸出等價類的邊界，就是應着重測試的邊界情況.應當選取正好等于，剛剛大于或剛剛小于邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據
⑵基于邊界值分析方法選擇測試用例的原則：
1）如果輸入條件規定了值的範圍,則應取剛達到這個範圍的邊界的值，以及剛剛超越這個範圍邊界的值作為測試輸入數據
2）如果輸入條件規定了值的個數，則用最大個數，最小個數，比最小個數少一，比最大個數多一的數作為測試數據
3）根據規格說明的每個輸出條件，使用前面的原則1）
4）根據規格說明的每個輸出條件，應用前面的原則2）
5）如果程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最後一個元素作為測試用例
6）如果程序中使用了一個内部數據結構，則應當選擇這個内部數據結構的邊界上的值作為測試用例
7）分析規格說明，找出其它可能的邊界條件
錯誤推測法
錯誤推測法：基于經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例。例如，在單元測試時曾列出的許多在模塊中常見的錯誤。以前産品測試中曾經發現的錯誤等，這些就是經驗的總結。還有，輸入數據和輸出數據為0的情況。輸入表格為空格或輸入表格隻有一行。這些都是容易發生錯誤的情況。可選擇這些情況下的例子作為測試用例。
因果圖方法
前面介紹的等價類劃分方法和邊界值分析方法，都是着重考慮輸入條件，但未考慮輸入條件之間的聯系，相互組合等。考慮輸入條件之間的相互組合，可能會産生一些新的情況。但要檢查輸入條件的組合不是一件容易的事情，即使把所有輸入條件劃分成等價類，他們之間的組合情況也相當多。因此必須考慮采用一種适合于描述對于多種條件的組合，相應産生多個動作的形式來考慮設計測試用例。這就需要利用因果圖（邏輯模型）。
因果圖方法最終生成的就是判定表。它适合于檢查程序輸入條件的各種組合情況。
利用因果圖生成測試用例的基本步驟：
⑴分析軟件規格說明描述中，那些是原因（即輸入條件或輸入條件的等價類），那些是結果（即輸出條件），并給每個原因和結果賦予一個标識符。
⑵分析軟件規格說明描述中的語義.找出原因與結果之間，原因與原因之間對應的關系。根據這些關系，畫出因果圖。
⑶由于語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不不可能出現。為表明這些特殊情況，在因果圖上用一些記号表明約束或限制條件。
⑷把因果圖轉換為判定表。
⑸把判定表的每一列拿出來作為依據，設計測試用例。
從因果圖生成的測試用例（局部,組合關系下的）包括了所有輸入數據的取TRUE與取FALSE的情況，構成的測試用例數目達到最少，且測試用例數目随輸入數據數目的增加而線性地增加。
前面因果圖方法中已經用到了判定表。判定表（Decision Table）是分析和表達多邏輯條件下執行不同操作的情況下的工具.在程序設計發展的初期，判定表就已被當作編寫程序的輔助工具了。由于它可以把複雜的邏輯關系和多種條件組合的情況表達得既具體又明确。
判定表
通常由四個部分組成
條件樁（Condition Stub）：列出了問題得所有條件.通常認為列出得條件的次序無關緊要.
動作樁（Action Stub）：列出了問題規定可能采取的操作.這些操作的排列順序沒有約束.
條件項（Condition Entry）：列出針對它左列條件的取值.在所有可能情況下的真假值.
動作項（Action Entry）：列出在條件項的各種取值情況下應該采取的動作.
規則：任何一個條件組合的特定取值及其相應要執行的操作.在判定表中貫穿條件項和動作項的一列就是一條規則。顯然，判定表中列出多少組條件取值，也就有多少條規則，既條件項和動作項有多少列.
建立步驟
（根據軟件規格說明）
①确定規則的個數.假如有n個條件.每個條件有兩個取值（0,1），故有5種規則：
②列出所有的條件樁和動作樁。
③填入條件項。
④填入動作項.等到初始判定表。
⑤簡化.合并相似規則（相同動作）。
B. Beizer指出了适合使用判定表設計測試用例的條件：
①規格說明以判定表形式給出，或很容易轉換成判定表。
②條件的排列順序不會也不影響執行哪些操作。
③規則的排列順序不會也不影響執行哪些操作。
④每當某一規則的條件已經滿足，并确定要執行的操作後，不必檢驗别的規則。
⑤如果某一規則得到滿足要執行多個操作，這些操作的執行順序無關緊要。
優點
⒈基本上不用人管着，如果程序停止運行了一般就是被測試程序crash了
⒉設計完測試例之後，下來的工作就是爽了，當然更苦悶的是确定crash原因
缺點
⒈結果取決于測試例的設計，測試例的設計部分來勢來源于經驗，OUSPG的東西很值得借鑒
⒉沒有狀态轉換的概念，一些成功的例子基本上都是針對PDU來做的，還做不到針對被測試程序的狀态轉換來作
⒊就沒有狀态概念的測試來說，尋找和确定造成程序crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨确認一遍。而就有狀态的測試來說，就更麻煩了，尤其不是一個單獨的testcase造成的問題。這些在堆的問題中表現的更為突出。
工具選擇
那麼，如何高效地完成功能測試？選擇一款合适的功能測試工具并培訓一支高素質的工具使用隊伍無疑是至關重要的。盡管現階段存在少數不采用任何功能測試工具，從事功能測試外包項目的軟件服務企業。短期來看，這類企業盈利狀況尚可，但長久來看，它們極有可能被自動化程度較高的軟件服務企業取代。
用于功能測試的工具軟件有很多，針對不同架構軟件的工具也不斷推陳出新。這裡重點介紹的是其中一個較為典型自動化測試工具，即Mercury公司的WinRunner。
WinRunner是一種用于檢驗應用程序能否如期運行的企業級軟件功能測試工具。通過自動捕獲、檢測和模拟用戶交互操作，WinRunner能識别出絕大多數軟件功能缺陷，從而确保那些跨越了多個功能點和數據庫的應用程序在發布時盡量不出現功能性故障。
WinRunner的特點在于：與傳統的手工測試相比，它能快速、批量地完成功能點測試；能針對相同測試腳本，執行相同的動作，從而消除人工測試所帶來的理解上的誤差；此外，它還能重複執行相同動作，測試工作中最枯燥的部分可交由機器完成；它支持程序風格的測試腳本，一個高素質的測試工程師能借助它完成流程極為複雜的測試，通過使用通配符、宏、條件語句、循環語句等，還能較好地完成測試腳本的重用；它針對于大多數編程語言和Windows技術，提供了較好的集成、支持環境，這對基于Windows平台的應用程序實施功能測試而言帶來了極大的便利。
