功能測試
定義
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平台的應用程式實施功能測試而言帶來了極大的便利。
