功能系統測試

測試對象的功能測試應側重於所有可直接追蹤到用例或業務功能和業務規則的測試需求。這種測試的目標是核實數據的接受、處理和檢索是否正確，以及業務規則的實施是否恰當。測試目標 確保測試的業務功能正常，其中包導航性質選單，數據輸入，處理和檢索等功能。

基本介紹

• 中文名：功能系統測試
• 外文名：function system test
• 組成：組裝測試和確認測試
• 目的：驗證系統是否滿足需求規格
• 功能：數據輸入，處理和檢索等
• 定義：具有較高的推廣價值

簡介

功能系統測試，根據產品特性、操作描述和用戶方案，測試一個產品的特性和可操作行為以確定它們滿足設計需求。本地化軟體的功能測試，用於驗證應用程式或網站對目標用戶能正確工作。使用適當的平台、瀏覽器和測試腳本，以保證目標用戶的體驗將足夠好，就像應用程式是專門為該市場開發的一樣。功能測試是為了確保程式以期望的方式運行而按功能要求對軟體進行的測試，通過對一個系統的所有的特性和功能都進行測試確保符合需求和規範。

計算機多媒體網路技術設計實現的認知功能系統測試，實驗系統充分考慮計算機多媒體技術的特點，為使其具有良好的網路運行特性。最後通過功能系統測試，驗證了整個系統的正確性。這種設計將傳統的測試系統多媒體化、網路化，可以方便地套用於其他功能系統測試，具有較高的推廣價值。

套用

套用電子技術方面的測試

印刷電路板，又稱印製電路板，印刷線路板，常使用英文縮寫PCB（Printed circuit board），是重要的電子部件，是電子元件的支撐體，是電子元器件線路連線的提供者。由於它是採用電子印刷技術製作的，故被稱為“印刷”電路板。

在印製電路板出現之前，電子元件之間的互連都是依靠電線直接連線而組成完整的線路。電路面包板只是作為有效的實驗工具而存在，而印刷電路板在電子工業中已經成了占據了絕對統治的地位。

PCBA功能系統測試

功能系統測試方法的原理是模擬設計輸入並檢測輸出來達到判定PCBA是否正常工作和PCBA上的電子元器件是否正確焊接的目的。面對電子產品的更新換代速度的提高，市場對電子產品的穩定性和可靠性的要求的增大，建立一個通用的可移植的PCBA功能系統測試平台搭是每個自動化測試工程師所要面臨的挑戰。實踐表明，選用合理的測試系統硬體平台和軟體平台能有效縮減PCBA功能系統測試的開發周期，提高生產效率。

基於NiosII軟核心技術的嵌入式系統具有豐富和可配置的外設接口，提高了PCBA功能系統測試硬體平台的通用性；由於LabVIEW開發環境對底層數據接口的良好封閉和其特有的簡捷直觀的開發方法，使得自動化測試工程師能夠專注於測試功能本身的實現，極大的提高了測試軟體的開發效率。

功能系統測試原理

FST是function system test的簡稱，功能系統測試可以測試一個PCBA的單板系統能否實現設計目標，它將線路板上的被測單元作為一個功能體，對其提供輸入信號，按照功能體的設計要求檢測輸出信號。

功能系統測試中的激勵信號源可以使用一些通用的儀器來實現，如任意波形發生器，任意函式發生器，邏輯信號發生器等，也可以使用自己設計的硬體系統來產生激勵信號，採用前者相對成本較高。

功能系統測試中的輸出信號的檢測可以使用一些通用的儀器來實現，如示波器，頻譜分析儀等，也可以使用定製的數據採集和分析模組來實現。輸出信號的分析和測試結果的保存往往要用計算機來實現，所以就引出了計算機和測試系統硬體的數據傳輸和控制的問題。

計算機和測試系統常用的通信方式有GPIB匯流排、PCI匯流排、RS232串口、USB等，通信方式的選擇需要根據測試系統的硬體選擇和測試對於數據傳輸的速度需求決定。

功能系統測試的特點

功能系統測試是從PCBA板卡的功能實現與否的角度來進行的測試，因此相對於其它測試手段顯得簡捷直觀，但由於功能系統測試是把待測PCBA當作一個類似於黑盒子的功能單元來進行測試，有時並不能準確定位出功能系統測試未能通過的PCBA所存在的問題之所在，不過採用。對比所列出的ICT、AOI、AXI等測試方法，採用功能系統測試的成本一般來說要小很多，對於一些小批量的PCBA板卡生產，採用功能系統測試可以有效的節約成本。此外，對於一些對穩定性和可靠性要求較高的產品，其測試系統往往是採用多種測試手段進行流水線作業，而功能系統測試是其中必不可少的步驟。

功能系統測試

元件測試和裝聯測試注重的是產品的加工質量，功能系統測試注重的是PCBA的電氣特性參數，並關注這些指標是否達到了相關的國家標準和設計規範的要求，功能系統測試是一類針對整件的綜合性測試，在以產品自行設計、加工為主的企業里套用最廣。

優點

⒈ 基本上不用人管著，如果程式停止運行了一般就是被測試程式crash了。

⒉ 設計完測試例之後，下來的工作就是好多了，當然更苦悶的是確定crash原因。

缺點

⒈ 結果取決於測試例的設計，測試例的設計部分來勢來源於經驗，OUSPG的東西很值得借鑑。

⒉ 沒有狀態轉換的概念，一些成功的例子基本上都是針對PDU來做的，還做不到針對被測試程式的狀態轉換來作。

⒊ 就沒有狀態概念的測試來說，尋找和確定造成程式crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨確認一遍。而就有狀態的測試來說，就更麻煩了，尤其不是一個單獨的testcase造成的問題。這些在堆的問題中表現的更為突出。