研發(fā)流程中的產(chǎn)品測試_第1頁
研發(fā)流程中的產(chǎn)品測試_第2頁
研發(fā)流程中的產(chǎn)品測試_第3頁
研發(fā)流程中的產(chǎn)品測試_第4頁
研發(fā)流程中的產(chǎn)品測試_第5頁
已閱讀5頁,還剩60頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、研發(fā)流程中的產(chǎn)品測試本次交流的目的 我們許多技術(shù)人員往往將測試簡單的理解為對產(chǎn)品功能性能的驗證。 在產(chǎn)品測試中他們簡單的對產(chǎn)品需求規(guī)格說明書中所述的產(chǎn)品性能、功能進行分類,并按照其預(yù)想的用戶操作步驟通過黑盒測試的方法來測試產(chǎn)品是否實現(xiàn)設(shè)計指標(biāo)和功能。 這種方法會帶來嚴(yán)重的缺陷:本次交流的目的1、產(chǎn)品需求規(guī)格說明書只會對產(chǎn)品外在指標(biāo)和功能進行定義,而不會對產(chǎn)品組成的單元/單板、接口等指標(biāo)功能進行描述。這樣的測試可以肯定比較難以發(fā)現(xiàn)產(chǎn)品內(nèi)部的設(shè)計缺陷。2、產(chǎn)品需求規(guī)格說明書定義的指標(biāo)、功能可能列寫不充分。根據(jù)不充分的需求定義導(dǎo)出的測試用例不能夠覆蓋基本(正常)事件的測試,導(dǎo)致測試有效性的降低。本次

2、交流的目的3、產(chǎn)品需求規(guī)格說明書可能不會對備選事件和異常事件進行描述,即使是一一對應(yīng)需求規(guī)格而設(shè)計的測試用例也會造成對備選事件和異常事件的測試遺漏,進一步降低測試有效性。4、單元測試、集成測試、系統(tǒng)測試所用測試用例完全一樣,忽略了不同產(chǎn)品測試階段所要關(guān)注的工作重點,使得產(chǎn)品設(shè)計缺陷難以在研發(fā)階段暴露,后續(xù)影響量產(chǎn)產(chǎn)品的質(zhì)量。本次交流的目的就是增強技術(shù)人員對測試工作的理解和認識,便于后續(xù)公司測試工作流程的持續(xù)改進。提綱 測試的目的和原則 測試的分類和方法 測試實施測試的目的和原則測試的目的 為使最終用戶對產(chǎn)品滿意,就必須保證產(chǎn)品功能性能達到用戶需求。而驗證產(chǎn)品功能性能否達到用戶要求的唯一方法就是

3、持續(xù)有效的測試。 一點共識:測試的目的 從用戶的角度出發(fā),就是希望通過測試能充分暴露產(chǎn)品中存在的缺陷,以便決定是否買單。 從開發(fā)者的角度出發(fā),就是希望測試能表明產(chǎn)品不存缺陷,已經(jīng)完全正確地實現(xiàn)了用戶需求。 兩種角度:測試的目的 從情感角度來看,開發(fā)者是不愿意自己設(shè)計的產(chǎn)品被證明存在設(shè)計缺陷。 從應(yīng)用角度來看,開發(fā)者往往是認為用戶一定是按照自己設(shè)計好的操作模式來對產(chǎn)品進行操作的。 三個問題: 從實施角度來看,開發(fā)者總是對能夠驗證產(chǎn)品已經(jīng)實現(xiàn)了預(yù)期功能的測試項目更加感興趣。測試的目的 測試不僅僅是為了證明產(chǎn)品能夠?qū)崿F(xiàn)既定功能,還要盡可能多地發(fā)現(xiàn)產(chǎn)品中的錯誤和缺陷。 測試只能證明錯誤的存在,但不能證

4、明錯誤不存在。 四條結(jié)論: 研發(fā)產(chǎn)品質(zhì)量保證的唯一方法就是盡量大覆蓋范圍下的有效測試。 測試的有效性是通過符合實際應(yīng)用條件下的測試用例的設(shè)計及實施來保證。測試實施原則 由于慣性思維的存在使得難以發(fā)現(xiàn)設(shè)計缺陷,因此盡量避免設(shè)計人員來測試自己設(shè)計的產(chǎn)品,但是單元測試除外。 確定預(yù)期輸出結(jié)果是測試用例必不可少的一部分。如果只有測試數(shù)據(jù)而無預(yù)期結(jié)果,那么就不容易判斷測試結(jié)果是否正確。 徹底檢查每個測試結(jié)果。如果不仔細檢查測試結(jié)果,有些已經(jīng)測試出來的錯誤也可能被遺漏掉。測試實施原則 對非法的和非預(yù)期的輸入也要像合法的和預(yù)期的輸入一樣編寫測試用例。 檢查產(chǎn)品是否做了應(yīng)做的事僅是成功的一半,另一半是看產(chǎn)品是

5、否做了不該做的事。 對測試錯誤結(jié)果一定要有一個確認的過程,一般有A測試出來的錯誤,一定要有一個B來確認,嚴(yán)重的錯誤可以召開評審會進行討論和分析。測試實施原則 測試后遺留的錯誤數(shù)目往往與已發(fā)現(xiàn)的錯誤數(shù)目成比例。因此當(dāng)A模塊找出錯誤比B模塊多得多時,很可能A模塊遺留的錯誤仍比B模塊遺留的錯誤多。 回歸測試的關(guān)聯(lián)性一定要引起充分的注意,修改一個錯誤而引起更多的錯誤出現(xiàn)的現(xiàn)象并不少見。 妥善保存一切測試過程文檔,測試的重現(xiàn)性往往要靠測試文檔。測試實施原則 制定嚴(yán)格的測試計劃,并把測試時間安排的盡量寬松,不要希望在極短的時間內(nèi)完成一個高水平的測試。 “盡早和不斷的測試”應(yīng)該成為一個合格的開發(fā)者的座右銘。

6、總結(jié)一下 對于測試重要性的理解我們都相差不多,唯一的區(qū)別在于對測試所關(guān)注問題的不同看法。 我們的核心問題是如何提高測試效率。 測試會占用開發(fā)周期,特別是測試覆蓋率要求越高周期就會越長,這與開發(fā)進度要求一定是矛盾的。 開發(fā)人員、測試人員較少測試經(jīng)驗,不具備良好的測試技能和測試工具,使得測試進度更加不可保證。廣義的測試 測試應(yīng)該貫穿產(chǎn)品開發(fā)周期,測試不僅僅是測試所實現(xiàn)的產(chǎn)品性能與功能,還要測試開發(fā)周期中各種設(shè)計文檔。 需求階段、總體(概要)設(shè)計階段、詳細設(shè)計階段所輸出的技術(shù)文檔,包括需求規(guī)格說明、總體(概要)設(shè)計、詳細設(shè)計、源程序(SCH、PCB)、用戶文檔等,都是測試的對象。測試的分類測試的分類

7、 按測試方法劃分,有靜態(tài)測試和動態(tài)測試。 動態(tài)測試:動態(tài)測試:使被測試產(chǎn)品或模塊有控制地運行,并從多種角度觀察運行時的行為,以發(fā)現(xiàn)其中的錯誤。 靜態(tài)測試:靜態(tài)測試:就是指人工評審設(shè)計文檔,借以發(fā)現(xiàn)其中的錯誤。作為研發(fā)質(zhì)量控制的重要手段,評審經(jīng)常作為具體實施前的檢查手段,其目的是保證設(shè)計的正確性、減小設(shè)計風(fēng)險、盡早發(fā)現(xiàn)設(shè)計缺陷。測試的分類 按測試功能劃分,有黑盒測試和白盒測試。 白盒測試:白盒測試:對模塊內(nèi)部是不透明的。從模塊/產(chǎn)品的設(shè)計、結(jié)構(gòu)上來進行測試,檢查模塊/產(chǎn)品中的錯誤。 黑盒測試:黑盒測試:對內(nèi)部透明,僅從使用上來檢查功能上是否有錯誤。黑盒與白盒 黑盒測試是從上到下、從宏觀到微觀的逐

8、步驗證過程,一般止步于單板/功能模塊外部功能的測試。 白盒測試是從下到上、從微觀到宏觀的逐步驗證過程,一般涉及單板/功能模塊內(nèi)部性能功能及單元間接口的測試。 一般采用白盒測試方法來檢查產(chǎn)品的基本功能單元內(nèi)部錯誤,而采用黑盒測試方法來驗證由各功能單元組裝而成的產(chǎn)品/系統(tǒng)的功能和性能。黑盒與白盒 黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試,它是在對產(chǎn)品應(yīng)具功能進行抽象的基礎(chǔ)上,將程序劃分成功能單元,然后對每個功能單元設(shè)計測試用例進行測試。 優(yōu)點:優(yōu)點:黑盒法測試用例是圍繞著產(chǎn)品操作方式和實際應(yīng)用環(huán)境來設(shè)計的,每一個測試用例表征著一種產(chǎn)品實際可能發(fā)生的應(yīng)用場景,測試結(jié)果非常直觀便于理解。 缺點:缺點:黑盒測

9、試用例的設(shè)計不可能做到完全覆蓋,因此難以完全觸發(fā)產(chǎn)品內(nèi)部所有執(zhí)行流程/路徑,也就難以完全發(fā)現(xiàn)深藏在產(chǎn)品內(nèi)部單元/模塊及接口的設(shè)計缺限,需要有白盒測試進行補充。黑盒與白盒 白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試,在知道產(chǎn)品內(nèi)部工作過程的前提下,按照產(chǎn)品內(nèi)部的結(jié)構(gòu),通過測試來檢測產(chǎn)品內(nèi)部動作是否符合詳細設(shè)計。 優(yōu)點:優(yōu)點:白盒法測試用例是圍繞著產(chǎn)品設(shè)計實現(xiàn)角度出發(fā),通過對其內(nèi)部信號特征、接口功能性能的覆蓋性檢查來保證設(shè)計的正確性。 缺點:缺點:以詳細設(shè)計為依據(jù),以覆蓋率為最終目標(biāo),因此缺乏宏觀把握的能力。不能查出詳細設(shè)計本身所存在的問題,即錯誤的產(chǎn)品設(shè)計。不可能查出被詳細設(shè)計所遺漏的功能、性能。灰盒測

10、試 灰盒測試介于黑盒與白盒之間,關(guān)注輸出對于輸入的正確性,同時也關(guān)注內(nèi)部表現(xiàn),但這種關(guān)注不象白盒那樣詳細、完整,只是通過一些表征性的現(xiàn)象、事件、標(biāo)志來判斷內(nèi)部的運行狀態(tài)。 灰盒法在用例設(shè)計中不關(guān)心模塊內(nèi)處理過程,只關(guān)心被測對象的輸入與輸出,這是典型的黑盒思維模式。 灰盒法在用例設(shè)計時基于對模塊內(nèi)部處理的了解,測試設(shè)計可以有針對性的進行,測試過程評估也是白盒法。模糊測試 模糊測試是黑盒法中的一種,其執(zhí)行過程為:向產(chǎn)品有意識地進行無效輸入以期望觸發(fā)錯誤條件或引起產(chǎn)品的故障。 模糊測試最為形象的說法是:測試過程要做的就是站在后面向目標(biāo)投擲石頭,等待玻璃被打破的聲音。就這個意義而言,模糊測試可被歸結(jié)為

11、黑盒測試。 若我們對產(chǎn)品內(nèi)部有所了解,就可以讓石頭每次的飛行路線更直接并且更真實。因此,模糊測試也可以應(yīng)用在灰盒測試中。測試方法的選擇 有一種觀點認為: 在單元測試階段采用白盒法; 在集成測試階段采用灰盒法; 在系統(tǒng)測試階段采用黑盒法。測試的分類 按測試步驟劃分,有單元測試、集成測試、系統(tǒng)測試。 單元測試:單元測試:也稱模塊測試。測試的對象是設(shè)計的最小單位功能模塊。單元測試的依據(jù)是詳細設(shè)計描述,對模塊內(nèi)所有表達功能/性能的節(jié)點設(shè)計測試用例,以便發(fā)現(xiàn)模塊內(nèi)部的錯誤。單元測試主要發(fā)現(xiàn)詳細設(shè)計階段產(chǎn)生的錯誤。測試的分類 集成測試:集成測試:又稱聯(lián)合測試也稱組裝測試,它是對由各模塊組裝而成的產(chǎn)品進行測

12、試,主要檢查模塊間的接口和通信。 系統(tǒng)測試:系統(tǒng)測試:是把軟、硬件和環(huán)境連在一起全面的測試,檢查系統(tǒng)的功能、性能及其他特征是否與用戶的需求一致,它是以需求規(guī)格說明書作為依據(jù)的測試。系統(tǒng)測試又可細分為功能測試、容量測試、壓力測試、使用性測試、安全性測試、性能測試、可靠性測試、恢復(fù)測試、強度測試、文檔測試以及工序測試。測試的分類 劃分測試的種類并不重要,重要的是,一定要把測試看成是產(chǎn)品設(shè)計全生命周期持續(xù)不斷而不是階段性的工作。測試覆蓋范圍 正確性測試:正確性測試:測試用例中的測試點應(yīng)首先保證要至少覆蓋需求規(guī)格說明書中的各項功能。 健壯性測試:健壯性測試:正確信息輸入將產(chǎn)生預(yù)期輸出, 非法信息輸入將

13、導(dǎo)致相應(yīng)提示或錯誤處理,而不至于系統(tǒng)/模塊崩潰。 容錯性測試:容錯性測試:測試系統(tǒng)/產(chǎn)品的功能單元、接口間出現(xiàn)異常的情況下系統(tǒng)的保護性處理,以及異常結(jié)束后系統(tǒng)功能性能的恢復(fù)處理。測試覆蓋范圍 可靠性測試:可靠性測試:測試系統(tǒng)/產(chǎn)品在實際應(yīng)用環(huán)境下可保證性能功能有效性的能力。 壓力測試:壓力測試:測試在大信息量處理情況下的系統(tǒng)/產(chǎn)品正常工作的能力。 回歸測試:回歸測試:測試上一輪測試所發(fā)現(xiàn)缺陷的解決及對系統(tǒng)的潛在影響。軟件測試與硬件測試 軟件測試:軟件測試:軟件不涉及制造加工,因此軟件測試的目的僅僅是驗證設(shè)計的正確性。 硬件測試:硬件測試:除了驗證設(shè)計正確性以外,還要包括制造的準(zhǔn)確性,或者一致性

14、測試。軟件測試與硬件測試 當(dāng)我們只考慮驗證設(shè)計正確性的話: 軟件測試:軟件測試:發(fā)現(xiàn)軟件代碼語法錯誤和邏輯錯誤,衡量軟件設(shè)計正確性的標(biāo)準(zhǔn)是:軟件在某種輸入條件下是否按正確時序完成對硬件的操作(如寫入/讀出寄存器數(shù)據(jù))。 硬件測試:硬件測試:發(fā)現(xiàn)硬件設(shè)計的錯誤,衡量硬件設(shè)計正確性的標(biāo)準(zhǔn)是:硬件系統(tǒng)在某種激勵條件下能否保證線路上的信號完整性,即“在需要的時間內(nèi)信號達到所需要的形狀”。測試的實施測試實施 制定測試策略。 測試用例設(shè)計。 實施測試工作的過程為: 執(zhí)行測試用例。 缺陷修復(fù)過程。 回歸測試。測試策略定義 資源需求的詳細說明。 進度約束下的人力資源角色和職責(zé)。 依據(jù)測試項目的特定環(huán)境約束而規(guī)

15、定的測試原則、方式、方法的集合,用以描述在測試活動各階段所采用的測試方法和測試目標(biāo)。內(nèi)容主要包括: 某測試階段所使用的測試方法和工具。 某測試階段所需要執(zhí)行的測試類型。 測試完成和測試成功所采用的評價標(biāo)準(zhǔn)。測試策略意義 測試策略的制定還可以使得測試過程中的溝通交流變得更為容易和有效,而它會影響到整個項目組。 測試策略明確了所有測試階段、測試技術(shù)和項目所使用的測試工具和測試目標(biāo),用以指導(dǎo)后續(xù)測試工作得有效實施。測試用例定義 測試用例(Test Case)是為某個特殊目標(biāo)而編制的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果,以便測試某個功能單元/模塊、系統(tǒng)/產(chǎn)品是否滿足某些特定需求。 測試用例指對特定的功能

16、單元/模塊、系統(tǒng)/產(chǎn)品進行測試任務(wù)的描述,體現(xiàn)測試方案、方法、技術(shù)和策略。內(nèi)容包括測試目標(biāo)、測試環(huán)境、測試輸入、測試步驟、預(yù)期結(jié)果等,并以文檔的形式予以表達。測試用例要素 用例編號:用例編號:便于測試用例的管理及測試過程的跟蹤。 用例標(biāo)題:用例標(biāo)題:清楚表達測試用例的用途。 重要級別:重要級別:定義測試用例的優(yōu)先級別。高:確保系統(tǒng)基本功能及主要功能的測試用例中:確保系統(tǒng)功能的完善方面的測試用例低:較少使用或輔助功能的測試用例,如提示信息 測試輸入:測試輸入:定義用例實施中的各種輸入條件。測試用例要素 操作步驟:操作步驟:對于復(fù)雜測試用例,操作時需要分幾個步驟完成,這部分內(nèi)容在操作步驟中詳細列出

17、。 預(yù)期結(jié)果:預(yù)期結(jié)果:提供測試執(zhí)行的預(yù)期結(jié)果,預(yù)期結(jié)果應(yīng)該根據(jù)產(chǎn)品需求中的輸出得出。 基本事件:基本事件:描述該測試用例的基本操作流程,指每個流程都“正常”運作時所發(fā)生的事情。基本事件用以測試在正確環(huán)境及操作下產(chǎn)品所能實現(xiàn)的性能、功能。測試用例要素 備選事件:備選事件:表示這種行為或流程是可選的或備選的,并不是總要執(zhí)行。 異常事件:異常事件:表示在發(fā)生某些非正常的事件后產(chǎn)品所要執(zhí)行的響應(yīng)。 正面測試:正面測試:用于驗證被測單元能夠執(zhí)行應(yīng)該完成的工作。 負面測試:負面測試:用于驗證軟件不執(zhí)行其不應(yīng)該完成的工作。測試用例設(shè)計白盒法 白盒測試是窮舉類測試,主要強調(diào)的是覆蓋率,即測試用例要覆蓋單元內(nèi)

18、部所有處理流程。 對軟件來講就是代碼路徑的覆蓋率,對于硬件測試來講則是檢查所有電路節(jié)點的響應(yīng)信號。 受到進度和資源的約束,不可能達到完全覆蓋率,折衷辦法就是選取關(guān)鍵重要的部分進行測試用例的設(shè)計。測試用例設(shè)計白盒法 語句覆蓋語句覆蓋:檢查到模塊中每個語句執(zhí)行情況。 判定覆蓋判定覆蓋:檢查到模塊中每個分支/信號流執(zhí)行情況。 條件覆蓋條件覆蓋:使判定中的每個條件獲得各種可能的結(jié)果。 判定判定/條件覆蓋條件覆蓋:選擇足夠的測試用例,使得判定中每個條件取到各種可能的值,并且每個判定取到各種可能的結(jié)果。 條件組合覆蓋條件組合覆蓋:執(zhí)行足夠的測試用例,使得每個判定中條件的各種可能組合都至少出現(xiàn)一次。覆蓋率由

19、低到高覆蓋率由低到高 路徑覆蓋路徑覆蓋:執(zhí)行足夠的測試用例,使得每條路徑至少被執(zhí)行一次。測試用例設(shè)計白盒法 白盒法實施深度: 白盒法(包括設(shè)計文檔評審、軟件代碼檢查)工作量應(yīng)占到測試總工作量的50。 對測試缺陷進行統(tǒng)計分析,白盒法發(fā)現(xiàn)的缺陷要達到總?cè)毕輸?shù)的50以上。測試用例設(shè)計黑盒法 黑盒法是測試者完全不考慮功能模塊內(nèi)部結(jié)構(gòu)和處理過程,而只是根據(jù)功能說明來設(shè)計測試用例,檢查模塊功能是否符合規(guī)格說明的要求。 等價分類法 邊緣值分析法 因果圖法 錯誤推測法測試用例設(shè)計黑盒法 等價分類法等價分類法:在輸入數(shù)據(jù)中選擇一組子集,每個子集選擇一個具有“代表性”的測試用例,使這個測試用例可以代表一大類的有同

20、樣共性的其他測試用例,這就形成了一個等價類。這樣就可使用少數(shù)的等價類測試用例能發(fā)現(xiàn)較多的錯誤。 等價分類法分為二步:根據(jù)功能說明中的輸入條件劃分等價類;按等價類來選擇測試用例。測試用例設(shè)計黑盒法 邊緣值分析法邊緣值分析法:與等價分類法的差別主要在于邊緣值分析法是著重檢查等價類邊界上的情況。 若某個輸入條件說明了值的范圍,則可選擇恰好取到邊界值的用例;另外再編寫一些代表不合理輸入數(shù)據(jù)的用例,它們的值恰好超過邊界。 如果一個輸入條件指出了輸入數(shù)據(jù)的個數(shù),則為最小個數(shù),最大個數(shù),比最小個數(shù)少1,比最大個數(shù)多1,分別設(shè)計用例。測試用例設(shè)計黑盒法 因果圖法因果圖法:因果圖法則著重檢查輸入條件的各種組合情

21、況,消除等價分類法和邊緣值分析法沒有檢查各種輸入條件的組合的缺點。 從用自然語言書寫的功能說明中找出因(輸入條件)和果(輸出或程序狀態(tài)的修改); 通過畫因果圖將功能說明轉(zhuǎn)換成判定表,然后為判定表的第一列設(shè)計測試用例。 因果圖法是設(shè)計測試用例的一個系統(tǒng)的方法。測試用例設(shè)計黑盒法 錯誤推測法錯誤推測法:通過經(jīng)驗或直覺推測程序中可能存在的各種錯誤,從而有針對性的編寫測試用例,這就是錯誤推測法。 錯誤推測法沒有確定的步驟,很大程度上是憑經(jīng)驗進行的。 前述概念是隨著軟件測試的發(fā)展而提出并逐漸完善。測試用例設(shè)計 相對而言,硬件測試并未能夠形成一種完善的理論和實施流程,其主要原因在于硬件的多樣性以及硬件系統(tǒng)

22、難以獨立于軟件而單獨實現(xiàn)。 對于軟件測試用例的設(shè)計有許多參考文獻,這里不再描述。后續(xù)僅對硬件測試談?wù)勔恍├斫夂腕w會。 測試目的:驗證設(shè)計的正確性、制造準(zhǔn)確性,以及查找、排除現(xiàn)場故障;硬件測試 測試對象:可測量信號的時域頻域形狀、指標(biāo)偏差、容限、極限參數(shù)。 測試項目:指標(biāo)、功能、可靠性、一致性。 測試方法:白盒測試、黑盒測試。 測試階段:單元測試、集成測試、系統(tǒng)測試。硬件單元測試 單元測試主要是指單板測試,一般采用白盒及黑盒測試相結(jié)合的方法,主要進行性能指標(biāo)測試。 白盒測試的目的是保證板上各級信號的完整性。 黑盒測試的目的是驗證板上及板間接口信號是否符合設(shè)計要求。硬件單元測試白盒測試 根據(jù)詳細設(shè)

23、計選取關(guān)鍵/重要信號設(shè)計測試用例,注意用例必須包括對測試結(jié)果的預(yù)期。 通過測試驗證板上關(guān)鍵/重要信號的完整性,使信號在傳輸過程中忠實的再現(xiàn)原始波形,從而保證功能的實現(xiàn)。 單板的EMC性能在很大程度上可以通過信號完整性來保證。硬件單元測試白盒測試 狹義的信號完整性,是指因數(shù)字信號的模擬特性而產(chǎn)生的任何影響信號傳輸?shù)默F(xiàn)象,嚴(yán)重時信號傳輸發(fā)生紊亂,整個系統(tǒng)不能正常工作。 廣義方面信號完整性可理解為:在需要的時間內(nèi)信號達到所需要的形狀。 板內(nèi)信號完整性測試: 電源:電壓值、紋波、負載能力硬件單元測試白盒測試 時鐘:電平、占空比、抖動、上升/下降沿、準(zhǔn)確度、穩(wěn)定度; 數(shù)字信號:電平、上升/下降沿、過沖;

24、 模擬信號:輸出電平范圍,變化率、諧波、失真; 。 黑盒測試的重點是是各功能實體接口的性能指標(biāo)。具體來說除了板級接口性能以外,單板內(nèi)部各功能實體接口性能也需要進行測試。測試的過程: 一是驗證單板/功能模塊的輸入信號在需求定義的變化范圍內(nèi),輸出信號是否達到設(shè)計要求。硬件單元測試黑盒測試 二是驗證單板/功能模塊的輸出信號在符合設(shè)計要求的情況下輸入信號的最大允許變化范圍。 輸入信號不僅僅理解為接口輸入信號,應(yīng)用環(huán)境的變化對單板的影響也應(yīng)視為一種輸入條件,如溫濕度、震動、電磁干擾等。硬件單元測試黑盒測試 同樣輸出信號也不應(yīng)僅僅理解為接口輸出信號,單板/功能模塊工作中對外界應(yīng)用環(huán)境造成的影響也應(yīng)考慮在內(nèi)

25、,如EMI。 多數(shù)情況下,EMC性能會在集成/系統(tǒng)測試階段進行,但是前期的信號完整性測試可以基本反映系統(tǒng)的EMC性能。硬件單元測試 在硬件不獨立的情況下,為了避免軟件問題帶來的測試誤差,可以針對不同功能運行特定的測試軟件來驗證硬件各部分的性能指標(biāo),如串口測試、中斷信號的產(chǎn)生及捕獲等。 集成測試的依據(jù)為產(chǎn)品概要設(shè)計,是對由各模塊組裝而成的產(chǎn)品進行測試,主要檢查模塊間的接口和通信。硬件集成測試 不完善的總體/概要設(shè)計,會導(dǎo)致的各功能模塊接口的功能、指標(biāo)定義有問題,使得模塊間通信不正常。這樣的問題在單元測試中是無法檢驗的。 產(chǎn)品結(jié)構(gòu)限制各功能模塊在空間上不能完全隔離,使得組裝后的產(chǎn)品各功能模塊間可能產(chǎn)生相互干擾,導(dǎo)致產(chǎn)品性能的下降,嚴(yán)重的會導(dǎo)致產(chǎn)品無法工作。 單元測試有效性不可能達到100,導(dǎo)致部分指標(biāo)沒有被測試到或者測試結(jié)果的不正確。 集成測試

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論