研發(fā)流程中的產(chǎn)品測試

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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