單元測試標(biāo)準(zhǔn)

1、管理資源吧（），提供海量管理資料免費(fèi)下載！更多免費(fèi)下載，盡在管理資源吧（）單元測試標(biāo)準(zhǔn)s-10001rev-2作業(yè)標(biāo)準(zhǔn)s-10001總頁數(shù)8正文4附件4文件控制部門:項目管理部單元測試標(biāo)準(zhǔn) 批準(zhǔn)人劉巖審核人崔戈擬制人劉慧豐批準(zhǔn)日期1999.5.12生效日期1999.5.12關(guān)聯(lián)文件單元測試實施規(guī)程(r-10002)設(shè)計文檔標(biāo)準(zhǔn)（s-04001）沈陽東東系統(tǒng)集成有限公司沈陽東東系統(tǒng)集成有限公司s-10001rev-0單元測試標(biāo)準(zhǔn)更改記錄序號發(fā)行日更改對象更改內(nèi)容批準(zhǔn)審查擬制01999.5.12新發(fā)行劉巖崔戈劉慧豐沈陽東東系統(tǒng)集成有限公司p-4/4s-10001rev-0單元測試標(biāo)準(zhǔn)目 錄1.測試

2、的一般事項1.1 測試的目的與分類2/41.2 測試與調(diào)試的區(qū)分2/42.對測試過程的準(zhǔn)備2/43.單元測試作業(yè)的標(biāo)準(zhǔn)3.1 作業(yè)流程2/43.2 制作單元測試方案書2/43.3 測試結(jié)果的研討及調(diào)試3/43.4 程序的修正及再編譯4/43.5 單元測試結(jié)束報告書4/4附圖：附圖1、單元測試?yán)龝鴮懛椒?/4附圖2、單元測試?yán)龝鴮懤?/4附圖3、單元測試結(jié)束報告書式3/4附圖4、問題分析表4/41.測試的一般事項1.1測試的目的與分類測試是以發(fā)現(xiàn)錯誤為目的執(zhí)行程序的過程。也就是說，測試并不是為了驗證程序是正確的，而是為了找出程序中隱藏的錯誤。如果經(jīng)過測試沒有發(fā)現(xiàn)任何錯誤，在確認(rèn)該程序是正確無誤

3、的之前，應(yīng)該先確定測試過程本身的有效性。測試分為靜態(tài)測試和動態(tài)測試兩類。靜態(tài)測試也稱為桌面檢查，是指通過對程序代碼的分析找出程序中可能出現(xiàn)的問題。1.2測試與調(diào)試的區(qū)分在進(jìn)行測試之前一定要認(rèn)清測試和調(diào)試的區(qū)別。測試的目的是發(fā)現(xiàn)錯誤，而調(diào)試的目的是對錯誤進(jìn)行定位，分析錯誤的原因并加以改正。2.對測試過程的準(zhǔn)備以自底向上測試方法為基礎(chǔ)構(gòu)造測試過程。自底向上測試是從模塊樹的下一級別的程序模塊開始進(jìn)行測試的方式。這種測試不需做成支撐模塊，但需要驅(qū)動模塊。有許多種測試工具和系統(tǒng)特有的工具，可根據(jù)各程序的性質(zhì)充分地利用這些工具。3.單元測試作業(yè)標(biāo)準(zhǔn)3.1作業(yè)流程單元測試從編譯錯誤全部被修正時開始，到提交單

4、元測試結(jié)束報告書時結(jié)束。單元測試結(jié)束報告書（附圖3）是對是否進(jìn)行了全部測試的再確認(rèn)，同時也是通知該程序已經(jīng)測試結(jié)束的手續(xù)。測試人員對在單元測試過程中發(fā)現(xiàn)的問題，應(yīng)做記錄并進(jìn)行原因分析。分析和記錄的格式見（附圖4 問題分析表），并且要和單元測試成績書的各項相對應(yīng)。3.2制作單元測試方案書單元測試必須做成某種形式的測試方案書。這是因為不具有測試方案書的測試不具備判定測試結(jié)束的標(biāo)準(zhǔn)。標(biāo)準(zhǔn)的單元測試方案書的制作方法如下：(1)制作測試?yán)勒諟y試?yán)齺硗七M(jìn)測試。對于所有的測試?yán)?，都得到了預(yù)想的結(jié)果時，認(rèn)為對該程序的測試已經(jīng)結(jié)束。從這種角度上來說，測試?yán)脑O(shè)定就非常的重要。若在測試?yán)杏兄卮筮z漏時，就會使該

5、程序不能被全部測試到。(2)測試?yán)拇_認(rèn)確認(rèn)測試?yán)采w的程序范圍。由于程序的復(fù)雜性，對每個模塊都進(jìn)行單元測試要花費(fèi)大量的時間制作相應(yīng)測試的支撐模塊或驅(qū)動模塊，同時因為與實際環(huán)境不同，造成測試結(jié)果與實際運(yùn)行結(jié)果之間存在一定的差異。因此單元測試時，可只對基本的模塊進(jìn)行測試，其它測試可在組合測試時進(jìn)行。(3)制作測試數(shù)據(jù)可在決定測試?yán)耐瑫r制作測試數(shù)據(jù)，也可分開來作。對于單元測試，測試數(shù)據(jù)的制作者主要是實際測試者。(4)測試的準(zhǔn)備單元測試方案書原則上由程序設(shè)計者來制作。測試數(shù)據(jù)由測試者(通常是程序制作者)制作。測試者應(yīng)對測試程序的每個測試?yán)绾卧跈C(jī)器上運(yùn)行及數(shù)據(jù)設(shè)定的方法等進(jìn)行研討。 在實際測試中只

6、能找出那些可以同輸出結(jié)果進(jìn)行對照的錯誤。也就是說，大體上可以覆蓋與程序的本來功能有關(guān)的錯誤，對于由其它程序的輸入/輸出不合格而造成的錯誤(排它、資源的釋放等)就很難找出來。這充分說明了動態(tài)測試的局限性，從而體現(xiàn)了桌面檢查（對程序流程，設(shè)計文檔等的檢查）的重要性。 單元測試方案書的記述方法對于將測試?yán)脑O(shè)計與測試數(shù)據(jù)的設(shè)計分開進(jìn)行時，主要由程序設(shè)計者進(jìn)行測試?yán)脑O(shè)計，而由測試執(zhí)行者負(fù)責(zé)測試數(shù)據(jù)的制作。但是，如果根據(jù)測試?yán)荒軟Q定測試數(shù)據(jù)，也寫不出預(yù)定的結(jié)果時（多見于以計算為主的程序中），由程序設(shè)計者負(fù)責(zé)測試數(shù)據(jù)的制作。(1)測試?yán)挠浭鲫P(guān)于測試?yán)脑O(shè)計，沒有必要進(jìn)行程序代碼級的檢查，(所謂的桌面

7、檢查是在測試數(shù)據(jù)的制作階段應(yīng)該進(jìn)行的作業(yè)。)但有必要進(jìn)行覆蓋率的確認(rèn)。測試?yán)挠浭龇椒ㄈ绺綀D1所示、測試?yán)挠浭龇独绺綀D2所示。(2)測試數(shù)據(jù)的記述原則上是由測試者制作測試數(shù)據(jù)。但是，測試數(shù)據(jù)列表不只限定為后記的格式。也可以采用與測試程序相適合的形式。3.3測試結(jié)果的研討及調(diào)試 對測試中發(fā)現(xiàn)的錯誤進(jìn)行調(diào)試，必須以桌面調(diào)試為主。機(jī)器調(diào)試作為一種補(bǔ)助手段。 調(diào)試時通常會采取如下的順序進(jìn)行：(1) 是否正確地設(shè)定了測試數(shù)據(jù)？由于意外，測試數(shù)據(jù)沒有被正確地設(shè)定或沒有全部設(shè)定，這樣屬于測試本身的錯誤的情況也很多。因此，將參照數(shù)據(jù)做成列表，進(jìn)行確認(rèn)是很有意義的。(2)有無編碼錯誤？語句被誤寫成了注釋，符

8、號出錯(i：1、o：0等)，因為沒有說明而成為缺省說明，這樣的錯誤會成為意外和盲點。(3)測試?yán)诔绦蛟O(shè)計上已經(jīng)被假定了嗎？這是一個根本性的問題，但是如果不注意的話，就會將程序向錯誤的方向修正。(4)條件判定是正確的嗎？在縮小“bug”的范圍的基礎(chǔ)上，應(yīng)確認(rèn)程序是否通過了所定的路徑。(5)os宏/函數(shù)/模塊等(系統(tǒng)調(diào)用)的使用方法、輸入/輸出方法是正確的嗎？錯誤地使用各種宏及子程序也很常見。通常返回到原點進(jìn)行確認(rèn)，是早期發(fā)現(xiàn)“bug”的一個方法。(6)縮小錯誤的范圍從得到的結(jié)果和條件來縮小錯誤的范圍，根據(jù)錯誤的種類有多種不同的方法，但其基本是對得到的數(shù)據(jù)進(jìn)行詳細(xì)的研討從而找出矛盾。若以上的項目

9、全部都被檢查確認(rèn)過了，大多情況是若正確檢查了要檢查的項目，應(yīng)該能夠發(fā)現(xiàn)絕大部分的“bug”。以下為在調(diào)試時必須注意的其它事項：1)不可漏掉錯誤發(fā)生了錯誤，而且沒有再現(xiàn)性時，就無視該錯誤而想通過，這是常情。但是，該錯誤在今后的某個時候肯定會再次發(fā)生的。因此，測試者一定要重視。2)要考慮種種的可能性出現(xiàn)了錯誤，在一般的情況下直接就可以想到錯誤的位置。但是有時當(dāng)不能在該地點發(fā)現(xiàn)“bug”時，因為先入為主的觀念，就會發(fā)生不再考慮別的地點而在該地點浪費(fèi)時間的現(xiàn)象。在怎么也找不到“bug”時，有必要到別的地點去找找原因，或是將想法全部重新整理一下。3)對于一個錯誤要考慮存在多個“bug”在發(fā)現(xiàn)了一個“bu

10、g”時，在此處還有“bug”的概率就變得很高。因此，在已發(fā)現(xiàn)的“bug”不能完全地對錯誤進(jìn)行說明時，必須要想到此處還可能存在“bug”。 4)不要抱住錯誤常常有為了微不足道的“bug”而浪費(fèi)了很多時間的情況。很多即使對于他人是一目了然的“bug”，而擔(dān)當(dāng)者卻很難發(fā)現(xiàn)。因此，對于無論做了怎樣的調(diào)查仍不明白的錯誤，應(yīng)該同上級或設(shè)計者商量。常有在進(jìn)行說明的同時發(fā)現(xiàn)“bug”的情況。3.4程序的修正及再編譯若能在調(diào)試時明白錯誤的原因，接下來就要考慮程序的修正、編輯、再編譯。這種工作看上去好象是當(dāng)然的，而實際上是極其重要的工作。這是因為，對程序的修正，有可能使到此為止合格的測試全都化為烏有。而且，草率的

11、更改進(jìn)一步產(chǎn)生更改，接下去就有可能破壞了程序的結(jié)構(gòu)，而成為不易收拾的狀態(tài)。因此，關(guān)于程序的修正、再編譯必須遵守以下的事項：1)一定要先確認(rèn)程序的修正對于程序的其它部分沒有影響。在無論如何要產(chǎn)生影響時，要重新測試。2)程序的修正一定要先在清單上清楚地寫上以后再進(jìn)行。千萬不可進(jìn)行只在頭腦中考慮的修正。3)一定要認(rèn)真并且整潔地填寫清單。不可進(jìn)行別人看不懂的修正。4)一定要保留程序的更改經(jīng)歷。在測試中經(jīng)常有前一次的修正對下一次的測試造成影響的情況。一定要保留更改履歷。5)若程序修正并不是編碼上的錯誤，而是程序設(shè)計上的錯誤的話，就一定要先進(jìn)行程序規(guī)范書的修正。3.5單元測試結(jié)束報告書若是對所有的測試?yán)?/p>

12、得到了正確的結(jié)果，根據(jù)單元測試結(jié)束報告，進(jìn)行再確認(rèn)，制作單元測試結(jié)束報告書，單元測試結(jié)束報告樣式見附圖3。p-2/4(附)s-10001rev-0單元測試標(biāo)準(zhǔn)附圖1 單元測試?yán)龝鴮懛椒╟pu 程序名（模塊名）測試項目測試方法預(yù)想結(jié)果判定良否日期判定者問題及備注測試?yán)男蛱柤皽y試?yán)饕愿鳒y試?yán)囊韵赂鼽c為中心記述：1目的本測試的含義(在不易理解時記述)2內(nèi)容進(jìn)行什么樣的測試3條件在什么樣的條件下進(jìn)行測試。*條件復(fù)雜時，也可在附頁上做成各條件的組合表，取得與各測試?yán)龑?yīng)。記述各測試?yán)模?.預(yù)想結(jié)果(無錯誤時的結(jié)果)2.記述以外的應(yīng)進(jìn)行檢查的項。對于錯誤而進(jìn)行程序的修正，而修正涉及到程序規(guī)范書

13、的修正時記述。(參考)在同實際的運(yùn)行狀態(tài)不同的條件下進(jìn)行測試時，記述其內(nèi)容。(例如stub的利用等) 或者記述單元測試很困難，即使做了也沒有什么意義而省略了的測試以及在組合測試時應(yīng)該確認(rèn)的事項。 附圖2單元測試?yán)龝鴮懤餐?ssgetmod 模塊讀出宏 測試項目測試方法預(yù)想結(jié)果判定良否日期判定者問題及備注1.正常讀出 1(online on時)確認(rèn)在cpu online狀態(tài)時，對邊界mode序號的讀出是正常的。1.讀出mode單一2.讀出mode多個回車情況=0讀出數(shù)據(jù)=被set為mmmodtbl的值讀出數(shù)據(jù)沒有破壞的領(lǐng)域以外良6/10中西2.正常讀出 2(online off時)1 cpu

14、offline狀態(tài)時的連續(xù)讀出 scc1 online scc2 offline 確認(rèn)對讀出在此中間的mode狀態(tài)的scc2的mode中，全部選擇了offmode 。 回車情報=0讀出數(shù)據(jù) mmmodtbl的 scc1 內(nèi)容 scc2 mode grant=0 (僅是與online有關(guān)的mode)良6/11中西3參數(shù)異常測試1 確認(rèn)在讀出范圍外的mode no.時為錯誤(超越下限時)2 同上(超越上限時)3 在連續(xù)讀出mode中，在指定了超越最大mode序號的讀出個數(shù)時的參數(shù)異?；剀嚮剀嚽閳?2參數(shù)異常message的輸出良6/11中西因為在連續(xù)讀出中，沒有超越范圍時的參數(shù)檢查，而修正了程序。 (參考)online狀態(tài)時將check module作為stub module進(jìn)行測試