單元測試觀點的基礎知識

制作單體測試項目書的基礎知識1－目錄－2１．前言???????????????????????????????????3２．單體測試的重要性?????????????????????????5３．測試設計的心得

???????????????????????????9４．單體測試的目的???????????????????????????10４．１單體測試的目的???????????????????????10４．２單體測試的位置（測試什么）??????????????

11５．單體測試的進行方法?????????????????????????14５．１進行單體測試前??????????????????????

14５．２誰來做單體測試??????????????????????

25５．３單體測試的手法?????????????????????????27５．３．１動態(tài)測試?????????????????????????27５．３．２單體測試項目書的作成?????????????47６．單體測試項目書作成練習???????????????????61略１．前言3分析過去的失敗項目（沒有核算項目）或客戶的投訴，可以看出在顧客驗收測試或實際投入使用后，多發(fā)生單體不過關的現(xiàn)象。這并不僅僅是我們公司的問題。而是當今軟件質量普遍較低的社會問題。因此，本攻略會基于從新認識單體測試的重要性，解釋說明單體測試項目書的作成方法和基礎知識。略２．單體測試的重要性但是???在實際開發(fā)中，短期開發(fā)或是前工程的拖延都會測試工程帶來影響。然而，在測試工程中特別是輕視單體測試，簡化，或者省略的情況很多。單體測試在開發(fā)工程中非常必要這是普遍被認同的※NSD標準流程中用「單體測試工程」來定義4單體測試不合格在工程后期發(fā)現(xiàn)時，與單體測試時發(fā)生的修復成本相比，據(jù)說可達到幾倍甚至幾十倍。一旦成為發(fā)行后的故障時，加上對顧客經濟的沖擊也可能達到幾百倍的成本。況且不僅是成本，也可能失去顧客的信賴，對個人來說，也會導致身體上，精神上的損害。由此，該結果在工程后期易發(fā)生單體質量不合格！那么，為什么單體測試被輕視了呢？

測試環(huán)境中模擬器等的環(huán)境構建太麻煩

沒有留下單體測試記錄（也有殘留未測試項）

急于進行集成測試

基于「只要根據(jù)設計書來做項目錯誤應該很少」的觀念，所以「沒必要花那樣的時間」（做集成測試就夠了）

等等另一方面

在測試中，雖然在意識上并沒有想輕視單體測試，但由于對等價值分類或邊界值分析等的測試基礎知識的不了解，導致測試遺漏，工程后期出現(xiàn)諸多問題。最后也會以輕視單體測試來評判。單體測試テストテスト集成測試テストテストテスト5不符合原因分析←與單體測試時相比分解范圍更廣，需要更多時間來調查原因

也有急著徹夜調查原因的情況調查影響←委托本公司，其他公司關聯(lián)崗位進行調查～總結調查結果故障說明←原因分析～編輯說明資料～內部討論～給顧客的解釋

?說明資料：故障內容，影響范圍，對應措施，技術原因／設計的原因等程序修改／測試工作?準備工作?制作修改資料～討論

?修改資料：修改內容（修改前后流程／編碼）、

單體測試項目書、集成測試項目書

?修改程序／測試工作?登入源程序～程序修改～單體測試～集成測試～結束?結束工作?制作結果報告書～討論～結果報告發(fā)行作業(yè)?替換／制作撤回操作書～評價～顧客認可?替換試做（召集相關人員）?實施替換（召集相關人員）?其它?視情況而定????經營層，營業(yè)負責人出差到顧客方致歉?隨著公司外事故的影響被要求賠償????是嵌入式的話，則要回收商品，賠償造成損失的數(shù)十億甚至上百億給顧客???等等舉個例子說明發(fā)行后發(fā)生故障時必要的工作隨著工程的推進，出勤成本變多了6避免造成此類結果，有必要將致力于單體測試銘記于心。7３．測試設計的心得①在「更少的測試實施數(shù)」中、②進行「更多的發(fā)現(xiàn)故障的測試」、③「不遺漏測試對象」測試設計的3條心得不僅是對單體測試，而是對各個測試工程整體來說的！「踏實作業(yè)，有問題意識，堅持不懈」很重要！8４．單體測試的目的

４．１單體測試的目的一般來說發(fā)現(xiàn)構成軟件最小單位的模塊（類、函數(shù)等）的操作中，不符合的狀況（＝品質確認）通過這樣?各個程序是否滿足模塊單位的功能?驗證該程序構成是否按照內部設計運行等等9

４．２單體測試的位置（測試什么）保證按詳細設計書來做成源代碼（以模塊單位Input/Output（輸入/輸出）為中心來進行確認（臨界值、邊界值、錯誤處理））保證按照概要設計來做成模塊（以模塊間的接口為主進行確認）保證按照需求定義來做成模塊V模型品質保證流程需求定義系統(tǒng)測試概要設計集成測試詳細設計單體測試編碼驗證源代碼審核1011位測試名測試內容

單體測試邏輯確認測試法全部按照邏輯處理線路執(zhí)行，確認處理結果條件分支確認測試法確認是否全部按照條件分支來進行測試等價分類測試法確認具代表性條件輸入的操作邊界值測試法確認邊界值的處理（最小值、最大值以及附近值）高位接口確認測試確認使用驅動程序的接口低位接口確認測試確認使用導體的接口

上表全是一般性的定義。

因為測試名或執(zhí)行測試的步驟以及是否實施測試都根據(jù)程序而不同，所以請根據(jù)該程序的設計書，各種測試案例進行。12參考略13５．單體測試的推進方法

５．１進行單體測試前◆NSD標準流程的工程定義（制造和單體測試工程）單體測試制造（編碼）?編碼?源代碼審核（內部?外部）?單體測試項目書

作成?審核?機上調試?機器調試?測試結果審核

（內部?外部）実行系作業(yè)（抜粋）工程※源代碼審核

必要條件，確定設計書和編碼結果都有一慣性，沒有矛盾

※機上調試

根據(jù)單體測用測試列表來實施（例）機器上無法進行的異常確認等14總之作為『測試』實施『靜態(tài)測試』實施『動態(tài)測試』制造工程（編碼）單體測試工程15清除機上調試◆靜態(tài)測試和動態(tài)測試■靜態(tài)測試???

程序或系統(tǒng)等“不動的”測試

◆人為靜態(tài)測試?源代碼審核◆機械的靜態(tài)測試?

靜態(tài)解析工具■動態(tài)測試???

程序或系統(tǒng)等“動的”測試

◆確認外觀的測試

?

黑盒測試

◆確認內部的測試

?

白盒測試

161.避免不必要的string方法調用2.避免值為常量的表達式3.避免零做除數(shù)4.避免nullpointerException異常

靜態(tài)測試和動態(tài)測試是否有都進行的必要？?回答?有必要?理由?由于在單體測試（動態(tài)測試）中有無法檢出的不良情況，靜態(tài)測試有必要進行17◆靜的テスト

源代碼審核和靜態(tài)解析工具

這里所謂的源代碼審核，是以包含第三者，式樣或編碼規(guī)約的形式檢測，和對程序整體的審核為前提。

根據(jù)項目的不同，

通過審核觀點表來進行自檢等的「審核方法」也不同。所謂的源代碼審核，由人來進行編碼作業(yè)時，對于源程序，在程序整體中用眼睛來檢查式樣或程序是否有誤再進行修改的作業(yè)。即使沒有對操作必要的外部模型和也可以進行審核。?目的和效果?

通過測試發(fā)現(xiàn)源程序的錯誤之前，通過人的測試來發(fā)現(xiàn)故障時直接的目的。此外，也期待一些重要的效果的出現(xiàn)，比如通過第三方的眼睛來修改源程序，從而發(fā)現(xiàn)編碼中的錯誤，故障等。18在源代碼審核中????在單體測試中能檢出的缺陷全部檢出。?檢測出無法執(zhí)行的注釋的缺陷

（←單體測試中無法檢出）?能檢出在執(zhí)行中難以確認的冗長代碼（←單體測試中無法檢出）?能檢出時機的缺陷（←單體測試中無法檢出）?能檢出違反編碼規(guī)約的編碼的缺陷

（←單體測試中無法檢出）?能提高可讀性和保守性

（←單體測試中無法檢出）?能檢出影響性能惡化的因素

（←大體是在結合測試中檢出，可能變成大的返工）?鄰域尺寸的缺陷（←單體測試中無法檢出）?Java、VB、C#因為發(fā)生異常有檢出可能性?能檢出內存泄露或多線程模式的缺陷（←單體測試中無法檢出）?Java基本上不會發(fā)生內存泄露，但是慎重來說有發(fā)生的可能性。?「無意識的對象保持」單體測試不能替代源代碼測試19冗長代碼、被實行的程序與輸出沒有任何影響的代碼內存泄漏

【memoryleak】是指電腦在運作中，能夠使用的內存容量在逐漸減少的現(xiàn)象。為了處理操作系統(tǒng)和應用軟件所占有的內存、沒有理由釋放導致的。源代碼審核的缺點?人是用眼睛來做，所以可能看漏一些缺陷，缺乏安定性和信賴性。

?審核人員的自身技術也會影響源代碼審核的品質

?即使審核人員的自身技術充分，也會因為先入為主的觀念等可能看漏缺陷。?因為需要時間，源代碼全部檢測是有困難的這個可能有一部分的機械性的輔助?靜態(tài)解析工具靜態(tài)解析工具（代碼解析工具），構造性的解析源程序或類文件檢測一般性的問題在編碼中是否存在的工具。這里所說的一般性問題，就是潛在的故障，違反編碼規(guī)約，或擴張性，保守性低的代碼，和成為性能惡化的原因的代碼等。20靜態(tài)解析工具中所能做的（例：Jtest）?編碼規(guī)約解析（可定制獨自規(guī)約）?代碼基準的計量

?方法數(shù)，對象的結合度、サイクロマティック難易度等基準的報表

超過基準指定的容許范圍時，作為違反輸出。?源代碼安全驗證?SQL注入、預防クロスサイトスクリプティング的脆弱性

等?被定型的故障模式的驗證?驗證循環(huán)次數(shù)、性能惡化模式等?參考?NSD持有Jtest（對應Java）但是、一些版本只有JtestSecurity。現(xiàn)在只有一個許可證。關于Jtest的詳細，請詢問開發(fā)技術部。其他的版本?JtestProfessionalEdition?JtestArchitrctEdition?JtestServerEdition21代碼基準、是指為了能夠理解開發(fā)者所寫的代碼、軟件設計而使用的一系列基準。開發(fā)者、利用代碼基準、直接作成、能夠把握必要的實行更加徹底的測試和方法主要的靜態(tài)解析工具22ツール名（製品名）會社名対応言語その他C++testテクマトリックスC/C++JtestJavadotTEST．NETQAC東陽テクニカCQAC++C++DevPartnerStudioProfessionalEdition日本コンピュウェア．NETFindBugsフリーソフトJavaPMDフリーソフトJava23

執(zhí)行靜態(tài)解析，是在開發(fā)作業(yè)中編碼階段或為了缺陷修改的代碼變更后早期執(zhí)行?開發(fā)終端首次執(zhí)行靜態(tài)解析的話、發(fā)現(xiàn)的缺陷的大多數(shù)被殘留。

在工數(shù)中無法對應不能修改、或是為了修改缺陷而不得不變更項目的日程。

靜態(tài)解析工具所擁有的規(guī)則查詢并不完全適用?工具可以發(fā)現(xiàn)各種的錯誤，但是當所發(fā)現(xiàn)的缺陷過多時，給與開發(fā)者的負擔會變得過大，最后會陷入無法引用工具的解析結果的狀況。靜態(tài)解析工具使用上的注意略24如何靈活運用從工具中得到的結果、從如下所示的觀點來進行。（隨意利用靜態(tài)解析工具無法達到效果。）用途（確認是否遵守編碼規(guī)約、是否驗證循環(huán)？等）的確認。

工具的選擇。

運用規(guī)則的確認。

?在開發(fā)進程的哪個階段、哪個位的頻度來利用？

?解析結果的利用者是誰、怎樣靈活運用？等

利用解析結果變更源代碼時のワークロード需要多少位？

靜態(tài)解析工具是有效的但無法檢出全部缺陷。

?因此，有必要進行源代碼審核。但是、在使用靜態(tài)解析工具時、

審核觀點被大幅集中。

靜態(tài)解析工具中無法檢出的缺陷例?共通函數(shù)的使用／不使用?機能（處理）的充足性（機能泄露或錯誤（例：利息計算的公式））?注釋的錯誤靜態(tài)解析工具使用上的注意（接續(xù)）略

５．２誰來做單體測試一般性的單體測試、

考慮作業(yè)效率、由源代碼開發(fā)者來執(zhí)行。拋棄「自己寫的代碼時正確的」這樣的先入為主的觀念、客觀的來進行單體測試是很重要的！但是25不要遺留單體的故障！為什么？設計，制造組來進行測試時、比起想要發(fā)現(xiàn)故障、更多是確認動作是否按照式樣執(zhí)行。、容易變成這種情況。另一方面、測試組不僅停留在確認動作是否按照式樣執(zhí)行、還有很強的發(fā)現(xiàn)未被找出的故障的欲望。換句話說，測試組是以發(fā)現(xiàn)故障為工作。因為不了解軟件的構成、可以用于設計者不同的觀點來進行測試、所以可能可以發(fā)現(xiàn)更多的故障。結合測試之后、

第三方（測試組）來執(zhí)行。是較為理想的。附26

５．３單體測試手法

５．３．１動態(tài)測試

（１）測試技巧27分類技法説明白盒測試路徑覆蓋測試著眼于程序的處理流、執(zhí)行所有的處理路徑確認動作。代碼檢查法著眼于數(shù)據(jù)流、執(zhí)行所有的路徑確認動作和代碼的正確性。黑盒測試劃分等價類（同値分割）輸入有連續(xù)范圍時、輸入條件分為適當?shù)挠行Х秶?、有効値を同値とみなして、１ケースをテストする。邊界值分析法（境界値分析）如果有連續(xù)輸入的范圍，適用輸入條件的有效范圍和無效范圍，測試有效范圍的邊界。異常值，無效值測試測試輸入范圍外的條件。配對構成測試（All-Pair法）根據(jù)2因子組合包含的所有算法測試。ペア構成テスト（直交表）利用叫做直角表的特殊矩陣、進行2組以上的網羅率是100%的測試。狀態(tài)遷移測試次々に変化していく狀態(tài)遷移の遷移すべての狀態(tài)を１回経由するような狀態(tài)遷移を見出しテストする。ドメイン分析テスト被認為是相互作用的多個組合的時候，以組合條件來進行測試?？辞宥x域的邊界、多個邊界值相組合、用邊界外、邊界內、邊界上的值來進行測試。ユースケーステスト明確從利用者和程序相互作用的程序的利用，作成測試腳本。（不適用與單體測試。統(tǒng)合測試以后）動的テストの代表的なテスト技法28

（２）白盒測試和黑盒測試白盒測試參照程序內部構造、確認其邏輯的測試黑盒測試不參照程序內部構造、確認輸入和輸出值得測試?參考：現(xiàn)場適用基準??白盒→路徑覆蓋區(qū)域的確保為主要目標?黑盒→用戶視角的測試29白盒測試是對于源代碼的測試、不可能確認式樣．從式樣引出源代碼是即使發(fā)生錯誤、也不用在意．因此、只做白盒測試認為「路徑覆蓋率100%ok！」就結束單體測試是非常危險的．30①白盒測試

制御パス?テスト著眼于測試對象的構造，知錯測試用例的方法。從設計或實裝的內容中網羅內部構造（處理線路）來制作測試用例。并且、制作評價完成的測試用例網羅了多少處理線路是很重要的。將這個處理線路的網羅程度的基準稱作網羅率、在白盒測試中，為了滿足作為目標的網羅率設計高效的測試用例。

カバレッジの種類名稱內容C０カバレッジ命令網羅（率）ステートメントカバレッジ著眼于編碼內的語句是否執(zhí)行C１カバレッジ分岐網羅（率）ブランチカバレッジ著眼于編碼內的判定條換的結果C２カバレッジ條件網羅（率）コンディションカバレッジ著眼于編碼內的條件語句的結果3132條件①參數(shù)為null或者參數(shù)的長度不到2個文字參數(shù)的第一個文字是「a」參數(shù)的第二個文字是「b」、并且最后一個文字是「z」條件②條件③例外スローresult[0]=trueresult[1]=truereturnresult入力（引數(shù)）結果（配列）result[0]result[1]falsetruefalsefalsetruetrue初期値として「false」が設定されているものとする33條件①條件②條件③例外スローresult[0]=trueresult[1]=truereturnresult入力（引數(shù)）結果（配列）result[0]result[1]falsetruefalsefalsetruetrueケースNo入力引數(shù)の値判定條件①の結果判定條件②の結果判定條件③の結果戻り値（結果）TC1nulltrue--例外TC2abzfalsetruetrue配列（true/true）ケースNo入力引數(shù)の値判定條件①の結果判定條件②の結果判定條件③の結果戻り値（結果）TC1nulltrue--例外TC2abzfalsetruetrue配列（true/true）TC3cccfalsefalsefalse配列（false/false）TC3TC2TC1C0:命令網羅C1:分岐網羅（注）C0カバレッジを包含34C2:條件網羅ケースNo入力引數(shù)の値判定條件①判定條件②判定條件③戻り値（結果）條件①-1の結果條件①-2の結果條件②の結果條件③-1の結果條件③-2の結果TC11nulltruefalse---例外TC12afalsetrue---例外TC2abzfalsefalsetruetruetrue配列（true/true)TC31cccfalsefalsefalsefalsefalse配列（false/false）TC32cbcfalsefalsefalsetruefalse配列（false/false）如果對于每個條件「true」の場合和「false」場合の兩方都能實行的話、那就被網羅了！如果對C2組合的條件有意見。這種時候、符合條件③的話就必須追加false,true。多數(shù)的語言zai條件③-1が就alse了、不能通過這個路徑、所以這種情況C2里不包含。35不能為100%時用正當理由向領導說明并得到承認、并且如果下一工程能覆蓋的話作為可。36ツール名（製品名）會社名対応言語その他DevPartnerJavaマイクロフォーカス JavaC++test9.2テクマトリックスC/C++Jtest9.1 JavadotTEST9.0．NETIBMRational?ApplicationDeveloper 日本アイ?ビー?エム JavaEclipseTPTPフリーソフトJavaEclipseプラグイン LDRAtoolsuite LDRA社（英）C、C++、Ada83、Ada95、Java國內代理店：富士設備工業(yè)(株)主要覆蓋范圍測量工具②黑盒測試基于測試對象的「式樣」的測試用例的制作方法。吧測試對象作為「里面的看不見的箱子（黑盒）」捕捉制作測試用例。具體來說、對與測試對象而言進行輸入時，著眼于輸出怎樣的東西（或狀態(tài)是否改變）來制作測試用例。這時、不在意測試對象中怎樣實裝，怎樣執(zhí)行處理。37因此、確認「選擇組合品」中沒有故障的技術變得重要．軟件由程序庫提供、幾乎是只有API宣布的例子。．從而、對于那些有隱藏源代碼的軟件組成的商品不使用白盒測試手法。所以、用黑盒來進行結合測試的方法變得越來越重要。時代的推進制作時代選擇即存的軟件進行組合的時代軟件軟件38黑盒測試中經常使用的方法是「同值分割法」と「邊界值分析」、一般是兩個方法結合起來使用?！苯槐?、域分析等方法雖然也使用、但「同値分割法」、「境界値分析」的知識是必要的。同值分割法將輸入－輸出關系的集合分為幾個同值類、在各類中選擇代表值作為測試數(shù)據(jù)（測試用例）的測試方法邊界值分析明確通過同值分割得到的同值類中成為端的值（和其前后的值）、將其作為測試數(shù)據(jù)的方法39

②－１同値分割法【例】用年齡判定費用。

?式樣?

１）12歲以上是普通費用

２）6歲以上12歲以下是兒童費用

３）6歲以下免費

４）承認注入的數(shù)值是0以上150以下的整數(shù)

※0以下或150以上時作為錯誤40條件0歳未満判定式x＜0入力領域に含まれる値???-5,-4,-3,-2,-1期待される結果エラー0歳以上6歳未満6歳以上12歳未満12歳以上150歳未満150歳以上0≦x＜66≦x＜1212≦x＜150150≦x0,1,2,3,4,56,7,8,9,10,1112,13,14,???148,149150,151,152,153???無料子供料金通常料金エラー在150測試以上進行全數(shù)測試時41同値クラス條件0歳未満判定式x＜0入力領域に含まれる値???-5,-4,-3,-2,-1代表値-5Ａ期待される結果エラーＢＣＤＥ0歳以上6歳未満6歳以上12歳未満12歳以上150歳未満150歳以上0≦x＜66≦x＜1212≦x＜150150≦x0,1,2,3,4,56,7,8,9,10,1112,13,14,???148,149150,151,152,153???3968153無料子供料金通常料金エラー測試5個例子就ok！適用于同值分割法的思考方法視為同值4243其他同值分割的例子【例】輸入平臺：フリガナ?全角カナ、半角カナ都OK?除了上面以外的NG有効な値アイウ?????ワヲンガギグ?????ブベボパピプペポ??????????????????????????????????????代表値「ソ」代表値「??」あいう?????阿胃迂?????１２３４５??????。！纾ィ?????ＡＢＣＤＥ?????ａｂcｄｅ?????ひらがな漢字記號全角數(shù)字全角英字1

2

3

4

5?????半角數(shù)字A

B

C

D

E?????a

bcde?????半角英字無効な値代表値「か」代表値代表値「a」中間值或經常使用的值作為代表值

②－２境界値分析【例】

?式樣?

１）年齡ａ0歲以上（０≦ａ）7歲以下（ａ≦７）

２）上文記述之外的為錯誤

邊界值分析中、有2個思考方法44

：、著眼于邊界所指定的點數(shù)，其前后的工6個作為測試用例的方法７８有效值類（正常）無效值類（錯誤）６１０－１無效值類（錯誤）邊界值分析的思考方法

：邊界的前后的4個值作為測試用例的方法７８有效值類（正常）無效值類（錯誤）６１０－１無效值類（錯誤）

在實際測試中、有必要結合前文記述的「同值分割法」。

加上前文記述的４點的邊界值、作成『代表值』的測試用例。

上文所記、作為代表值的中間的「４」作為測試用例。AB45與代表值結合的理由【例】

?式樣?

１）７以下以式樣書為基礎制作邊界值的測試用例的話會變成下列模式。條件７期待される結果正常８錯誤如果、將ａ≦７

弄錯為

ａ==７

來編碼時

用上述所說來作成的邊界值的測試用例中不能檢出錯誤。因此、同值分割（代表値）的測試用例成為必要。條件４期待される結果正常７正常８錯誤７８有効同値クラス（正常）無効同値クラス（エラー）46①同値分割＋境界値分析（Ａ）?○②同値分割＋境界値分析（Ｂ）?◎③境界値分析（Ｂ）?△

↑使用以上哪一個根據(jù)項目討論決定?！荒軆H僅邊界值分析（Ａ）（危險）?邊界值分析的適用案例?內部變量日期?時刻入力數(shù)據(jù)長接口參數(shù)輸出結果

?畫面（項目長／明細行などのコントロールブレイク）

?賬票（項目長／１頁に出力する行などのコントロールブレイク）?DB?文件（項目長）

等等47

５．３．２單體測試項目書的作成

NSD標準模板◆字模形式48工程

??????名（???名）

システム名

??????ID（???ID）

サブシステム名

作成日

業(yè)務名

作成者

機能名

管理者

テスト項目數(shù)15正常系15異常系0境界?限界0チェック條件ケースNo．

項目CL-001CL-002CL-003CL-004CL-005CL-006CL-007CL-008CL-009CL-010CL-011CL-012CL-013CL-014CL-015

確認內容

區(qū)分正/異/境

???/機上

確認結果日付

擔當者

49◆一覧形式（１）案例調查詳細設計書單體測試項目書源代碼單體測試項目書×◎×寫在詳細設計書里但測試項目中遺漏、不很好的寫單體測試項目書就進行測試的情況詳細設計書＞単體テスト項目書詳細設計書＝単體テスト項目書詳細設計書＜単體テスト項目書良好。被認為詳細設計書中遺漏的通過單體測試來覆蓋的案例、有必要注意。不認真制作設計書就進行編程時，也適用于這個。「在測試中覆蓋設計書的不完整」這樣的思考方法、擁有什么來判斷是否正常的基準變得很曖昧、成為故障多發(fā)的原因。50如果這樣的話、將詳細設計書作為單體測試式樣書來挪用的話既沒有遺漏、也能減少式樣書作成的工數(shù)！這樣的想法。將詳細設計書作為單體測試式樣書時候的問題點

難以記述測試用例／測試數(shù)據(jù)

修改詳細設計書時、很難維護??????不要將原則，詳細設計書作為測試項目書來使用！如果、代替使用時、明確能擔保網羅性的制作方法。また、処理漏れ等で詳細設計書に修正が発生した場合のチェックリストへの対処法?運用法を明確にしたうえで代用することが肝要。5152測試情況的比例舉例情況舉例正常異常有限度·邊界其他（接口等）A項目７０％以下１０％以上２０％以上－B項目４０％３０％２０％１０％C項目６０％以下１５％以上１５％以上１０％以上根據(jù)項目不同，所占比例就不同！所以需要確認單體測試手冊（或重點手冊）！53

異常情況的思考方式為什么項目不同，異常情況的思考方式（定義）就會不同？異常的種類概要業(yè)務性異常指輸入了內部設計中沒有預想到的數(shù)據(jù)等情況下的異常。例如，該系統(tǒng)雖預想到了金額等的0以上的整數(shù)，卻輸入了負值的情況等就是業(yè)務性異常。