單元測試觀點(diǎn)的基礎(chǔ)知識(shí)

制作單體測試項(xiàng)目書的基礎(chǔ)知識(shí)1－目錄－2１．前言???????????????????????????????????3２．單體測試的重要性?????????????????????????5３．測試設(shè)計(jì)的心得

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

11５．單體測試的進(jìn)行方法?????????????????????????14５．１進(jìn)行單體測試前??????????????????????

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

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

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

沒有留下單體測試記錄（也有殘留未測試項(xiàng)）

急于進(jìn)行集成測試

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

等等另一方面

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

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

?說明資料：故障內(nèi)容，影響范圍，對(duì)應(yīng)措施，技術(shù)原因／設(shè)計(jì)的原因等程序修改／測試工作?準(zhǔn)備工作?制作修改資料～討論

?修改資料：修改內(nèi)容（修改前后流程／編碼）、

單體測試項(xiàng)目書、集成測試項(xiàng)目書

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

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

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

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

上表全是一般性的定義。

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

５．１進(jìn)行單體測試前◆NSD標(biāo)準(zhǔn)流程的工程定義（制造和單體測試工程）單體測試制造（編碼）?編碼?源代碼審核（內(nèi)部?外部）?單體測試項(xiàng)目書

作成?審核?機(jī)上調(diào)試?機(jī)器調(diào)試?測試結(jié)果審核

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

必要條件，確定設(shè)計(jì)書和編碼結(jié)果都有一慣性，沒有矛盾

※機(jī)上調(diào)試

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

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

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

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

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

◆確認(rèn)外觀的測試

?

黑盒測試

◆確認(rèn)內(nèi)部的測試

?

白盒測試

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

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

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

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

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

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

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

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

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

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

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

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

?審核人員的自身技術(shù)也會(huì)影響源代碼審核的品質(zhì)

?即使審核人員的自身技術(shù)充分，也會(huì)因?yàn)橄热霝橹鞯挠^念等可能看漏缺陷。?因?yàn)樾枰獣r(shí)間，源代碼全部檢測是有困難的這個(gè)可能有一部分的機(jī)械性的輔助?靜態(tài)解析工具靜態(tài)解析工具（代碼解析工具），構(gòu)造性的解析源程序或類文件檢測一般性的問題在編碼中是否存在的工具。這里所說的一般性問題，就是潛在的故障，違反編碼規(guī)約，或擴(kuò)張性，保守性低的代碼，和成為性能惡化的原因的代碼等。20靜態(tài)解析工具中所能做的（例：Jtest）?編碼規(guī)約解析（可定制獨(dú)自規(guī)約）?代碼基準(zhǔn)的計(jì)量

?方法數(shù)，對(duì)象的結(jié)合度、サイクロマティック難易度等基準(zhǔn)的報(bào)表

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

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

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

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

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

工具的選擇。

運(yùn)用規(guī)則的確認(rèn)。

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

?解析結(jié)果的利用者是誰、怎樣靈活運(yùn)用？等

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

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

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

審核觀點(diǎn)被大幅集中。

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

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

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

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

５．３單體測試手法

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

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

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

制御パス?テスト著眼于測試對(duì)象的構(gòu)造，知錯(cuò)測試用例的方法。從設(shè)計(jì)或?qū)嵮b的內(nèi)容中網(wǎng)羅內(nèi)部構(gòu)造（處理線路）來制作測試用例。并且、制作評(píng)價(jià)完成的測試用例網(wǎng)羅了多少處理線路是很重要的。將這個(gè)處理線路的網(wǎng)羅程度的基準(zhǔn)稱作網(wǎng)羅率、在白盒測試中，為了滿足作為目標(biāo)的網(wǎng)羅率設(shè)計(jì)高效的測試用例。

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

②－１同値分割法【例】用年齡判定費(fèi)用。

?式樣?

１）12歲以上是普通費(fèi)用

２）6歲以上12歲以下是兒童費(fèi)用

３）6歲以下免費(fèi)

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

※0以下或150以上時(shí)作為錯(cuò)誤40條件0歳未満判定式x＜0入力領(lǐng)域に含まれる値???-5,-4,-3,-2,-1期待される結(jié)果エラー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測試以上進(jìn)行全數(shù)測試時(shí)41同値クラス條件0歳未満判定式x＜0入力領(lǐng)域に含まれる値???-5,-4,-3,-2,-1代表値-5Ａ期待される結(jié)果エラーＢＣＤＥ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個(gè)例子就ok！適用于同值分割法的思考方法視為同值4243其他同值分割的例子【例】輸入平臺(tái)：フリガナ?全角カナ、半角カナ都OK?除了上面以外的NG有効な値アイウ?????ワヲンガギグ?????ブベボパピプペポ??????????????????????????????????????代表値「ソ」代表値「??」あいう?????阿胃迂?????１２３４５??????。！纾ィ?????ＡＢＣＤＥ?????ａｂcｄｅ?????ひらがな漢字記號(hào)全角數(shù)字全角英字1

2

3

4

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

B

C

D

E?????a

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

②－２境界値分析【例】

?式樣?

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

２）上文記述之外的為錯(cuò)誤

邊界值分析中、有2個(gè)思考方法44

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

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

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

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

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

?式樣?

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

弄錯(cuò)為

ａ==７

來編碼時(shí)

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

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

?畫面（項(xiàng)目長／明細(xì)行などのコントロールブレイク）

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

等等47

５．３．２單體測試項(xiàng)目書的作成

NSD標(biāo)準(zhǔn)模板◆字模形式48工程

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

システム名

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

サブシステム名

作成日

業(yè)務(wù)名

作成者

機(jī)能名

管理者

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

項(xiàng)目CL-001CL-002CL-003CL-004CL-005CL-006CL-007CL-008CL-009CL-010CL-011CL-012CL-013CL-014CL-015

確認(rèn)內(nèi)容

區(qū)分正/異/境

???/機(jī)上

確認(rèn)結(jié)果日付

擔(dān)當(dāng)者

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

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

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

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