測試作業指導書

基礎篇...........................................................錯誤!未定義書簽。

001.什么是軟件缺陷(BUG).........................................................................錯誤!未定義書簽。

002.影響軟件質量的原因........................................錯誤!未定義書簽。

003.提高軟件質量11勺措施........................................錯誤!未定義書簽。

004.軟件測試的)目的I與定義.....................................錯誤!未定義書簽。

005.軟件測試中的原則..........................................錯誤!未定義書簽。

006.怎樣成為一種好的軟件測試員...............................錯誤!未定義書簽。

007.軟件測試時階段劃分........................................錯誤!未定義書簽。

008.測試用例的設計措施........................................錯誤!未定義書簽。

01.測試用例的特性：.........................................錯誤!未定義書簽。

02.測試用例的設計原則......................................錯誤!未定義書簽。

03.等價類劃分措施...........................................錯誤!未定義書簽。

04.邊界值分析措施...........................................錯誤!未定義書簽。

05.因果圖措施..............................................錯誤!未定義書簽。

06.鑒定表驅動分析措施......................................錯誤!未定義書簽。

07.功能圖分析措施...........................................錯誤!未定義書簽。

08.場景設計措施.............................................錯誤!未定義書簽。

09.測試用例設計綜合方略....................................錯誤!未定義書簽。

10.測試用例的設計環節......................................錯誤!未定義書簽。

009.軟件測試歐I基本方式........................................錯誤!未定義書簽。

01.黑盒測試................................................錯誤!未定義書簽。

02.白盒測試................................................錯誤!未定義書簽。

03.靜態測試................................................錯誤!未定義書簽。

04.動態測試................................................錯誤!未定義書簽。

010.軟件測試的基本措施........................................錯誤!未定義書簽。

01.過測試和失敗測試.........................................錯誤!未定義書簽。

02.等價類劃分..............................................錯誤!未定義書簽。

03.數據測試................................................錯誤!未定義書簽。

04.狀態測試................................................錯誤!未定義書簽。

05.其他黑盒測試措施.........................................錯誤!未定義書簽。

實踐篇...........................................................錯誤!未定義書簽。

001.測試流程圖...............................................錯誤!未定義書簽。

002.測試準備.................................................錯誤!未定義書簽。

003.怎樣做好式樣理解..........................................錯誤!未定義書簽。

004.有關測試用例口勺設計........................................錯誤!未定義書簽。

005.測試數據的準備............................................錯誤!未定義書簽。

006.測試時實行...............................................錯誤!未定義書簽。

007.測試過程中口勺變更管理.....................................錯誤!未定義書簽。

008.怎樣填寫QA票和BUG票....................................錯誤!未定義書簽。

009.文檔管理工具(CVS)的使用..................................錯誤!未定義書簽。

010.BUG管理工具(QAMS)的使用................................錯誤!未定義書簽。

基礎篇

001.什么是軟件缺陷（bug）

1.軟件未到達產品闡明書表明H勺功能

計算器日勺產品闡明書也許聲稱它可以精確無誤日勺進行加、減、乘、除運算。假如按下加號

（+）鍵，成果什么反應也沒有，根據該條規則，這就是個軟件缺陷。假如得到錯誤的答

案，根據規則，同樣是軟件缺陷

2.軟件出現了產品闡明書指明不會出現的錯誤

產品闡明書也許聲稱計算機永遠不會瓦解、鎖死或者停止反應。假如狂敲鍵盤會使計算器

停止接受輸入，根據本條規則，這是一種軟件缺陷

3.軟件功能超過產品闡明書指明范圍

假如我們發現除了加減乘除之外計算器還可以求品方根，而這一功能哪兒都沒提。干勁十

足的程序員加入這項功能也許由于覺得這是一項創舉，根據本條規則，這是軟件缺陷。

4.軟件未到達產品闡明書雖未指出但應到達的目H勺

這條規則也許讓人感覺有些矛盾和奇怪，不過這樣是為了抓住產品闡明書上遺漏之處。在

測試計算器時，會發現電池沒電會導致計算機不對"勺。沒有人會考慮應怎樣應付這種狀況,

使計算機反應正常，而盲目認為電池永遠充足了電。測試要持續進行到電池完全沒電，是

少要看到電力局限性的跡象。產品闡明書指出電力局限性無法對的計算，但未指出會怎樣,

根據本條規則，這是軟件缺陷。

5.軟件測試人員認為軟件難以理解、不易使用、運行速度緩慢，或者最終顧客認為不好。

本條規則是全面的。軟件測試人員是第1個真正使用軟件的人。假如發現某些地方不對勁,

無論什么原因，都要認定為軟件缺陷。對于計算器來說，也許覺得按鍵太小；也許等號（=）

鍵的位置放得不好按；也許顯示屏在亮光下很難以看清，根據本條規則，這些都是碳陷。

注意：每?種使用過某些軟件日勺人都會對怎樣改善有某些規定和意見。要編寫令所有顧客都

喜歡的軟件是不也許的。作為軟件測試人員，在運用第5條測試規則時應記住這一點。最佳

能全面地客觀評價，做到合情合理。

002.影響軟件質量的原因

影響軟件質量II勺原因諸多，詳細地說，重要有如下幾點：

1.顧客原因

需求不清；二義性

2.產品闡明書

沒有產品闡明書；闡明書不夠全面、常常更改

3.設計方案

與產品闡明書是同樣的，片面、易變

4.交流不夠、交流上有誤解或者主線不進行交流

在應用應當做什么或不應當做什么的細節（應用日勺需求）不清晰R勺狀況下進行開發

5.軟件復雜性

圖形顧客界面（GUI）,客戶/服務器構造，分布式應用，數據通信，超大型關系型數據庫

以及龐大H勺系統規模，使得軟件及系統的復雜性呈指數增長，沒有現代化開發經驗的人很

難理解它。

6.程序設計錯誤

跟所有日勺人同樣，程序員也會出錯

7.時間壓力

軟件項目的日程表很難做到精確，諸多時候需要估計和猜測。當最終期限迫近和關鍵時刻

到來之際，錯誤也就跟著來了。

8.自負

自負的人更喜歡說：“沒問題”；“這件事很輕易”；“幾種小時我就能拿出來”，太多不切

實際的“沒問題”成果只能是引入錯誤。

9.代碼文檔貧乏

貧乏或者差勁H勺文檔使得代碼維護和修變化的異常艱苦，其成果是帶來許多錯誤。事實

上，在許多機構并不鼓勵其程序員為代碼編寫文檔，也不鼓勵程序員將代碼寫得清晰和

輕易理解，相反他們認為少寫文檔可以更快的J進行編碼，無法理解的代碼更易于工作的

保密（“寫H勺艱難必然讀的痛苦”）

10.軟件開發工具

可視化工具，類庫，編譯器，腳本工具，等等，他們常常會將自身的錯誤帶到應用軟件中。

就像我們所懂得的，沒有良好的工程化作為基礎，使用面向對象“勺技術只會使項目變得更

復雜。

003.提高軟件質量的措施

1.軟件工程化

2.CMM能力成熟度模型CapabilityMaturityModelforSoftware

3.軟件測試

004.軟件測試的目的與定義

軟件測試的目日勺決定了怎樣去組織測試，在項目的1不一樣階段，測試時目H勺也不相似。

1.在UT(Unitl^st)階段，測試日勺目H勺是為了盡量多地找出錯誤，那么UT階段測試就應當直

接針對軟件比較復雜的部分或是此前出錯比較多的位置。在此階段，可以引用GrcnfordJ.

Myers在《TheArtofSoftwareTesting》一書中的觀點:

>軟件測試是為了發現錯誤而執行程序的過程；

>測試是為了證明程序有錯，而不是證明程序無錯誤。

>好的測試方案是極也許發現迄今為止尚未發現日勺錯誤日勺測試方案；

>成功的測試是發現了至今為止尚未發現的錯誤的I測試。

這種觀點可以提醒人們測試要以杳找錯誤為中心，而不是為了演示軟件的對的功能。不過

僅憑字面意思理解這一觀點也許會產生誤導，認為發現錯誤是軟件測試H勺唯一目的，查找不

出錯誤的測試就是沒有價值的，事實并非如此。

首先，測試并不僅僅是為了要找出錯誤。通過度析錯誤產生的原因和錯誤的分布特性，

可以協助項目管理者發現目前所采用的軟件過程I內缺陷，以便改善。同步，這種分析也能協

助我們設計出有針對性地檢測措施，改善測試的有效性。

另一方面，沒有發現錯誤的測試也是有價值的，完整的測試是評估測試質量的一種措施。

詳細而嚴謹II勺可靠性增長模型可以證明這一點。

2.SI測試階段的目的是為了給最終顧客提供具有一定可信度的質量評價，那么測試就應當直

接針對在實際應用中會常常用到H勺商業假設。

在這一階段不僅要驗證UT測試的成果，檢測出軟件自身的缺陷，更重要的是要站在用

戶的角度找出我們在軟件開發過程中的不合理的地方，最終的FI的是讓顧客滿意。

對?于軟件產品小J不一樣角色來說，他們日勺測試目的也是不一樣的J。

顧客：通過測試來暴露錯誤

開發者：通過測試來證明自己開發H勺產品不存在錯誤

測試人員：找出軟件缺陷，盡量早某些，并保證其得以修復

測試從狹義上說，就是：憑借測試用例TestCase一運行程序一發現錯誤H勺過程。

005.軟件測試中的原則

1.完全測試程序是不也許的

在軟件測試H勺過程中，想要進行完全測試，找出所有軟件缺陷，并使軟件臻于完美，實際

上這是不也許日勺，雖然最簡樸的程序也不行，重要有如下4個原因：

?輸入量太大

?輸出成果太多

?軟件實現途徑太多

?軟件闡明書沒有客觀原則。從不一樣的角度看，軟件缺陷的原則不一樣。

2.軟件測試是有風險的行為

正由于完全測試程序是不也許的J,那么在測試的過程中必然會對某些你認為是反發的J

或者沒必要的或者為了節省時間，而將其提出，假如決定不去測試所有的狀況，這就是選

擇了風險。既然不也許做完全測試，那么這種風險就是無法防止的了。軟件測試員要學會

的一種重要原則就是怎樣把無邊無際的也許減少到可以控制的范圍，以及怎樣針對風險制

定做出明智抉擇，去粗存精。

3.測試無法顯示潛伏的軟件缺陷

軟件測試工作與防疫員的工作極為相似，可以匯報已發現的軟件缺陷，卻無法匯報潛

伏的軟件缺陷。你可以進行測試，查找并匯報軟件缺陷，不過不能保證軟件缺陷所有找到。

唯一的措施是繼續測試，也許還會找到某些。

4.找到的軟件缺陷越多，就闡明軟件缺陷越多

一般，軟件測試員在沒有找到軟件缺陷之前拼命地揣摩。找到一種之后，就會接二連

三地找到更多。其中的原因是：

?程序員怠倦。和我們大家同樣，程序員也要休假。編寫一天代碼還不錯，第二天就

會煩躁不安了。?種軟件缺陷很也許是泄露附近有更多軟件缺陷日勺信號。

?程序員往往犯同樣的J錯誤。每個人均有偏好。一種程序員總是反復犯下自己輕易犯

的錯誤。

?某些軟件缺陷實際上是大劫難的征兆。軟件的設計或者體系常常會出現基礎問題。

軟件測試員也許會發現某些軟件缺陷開始似乎弟無關聯的，不過最終才懂得它們是

由一種極其嚴重的原因導致的。

不過，假如無論怎樣也找不出軟件缺陷，那么乜有也許是軟件通過精心編制，確實

存在很少軟件缺陷

5.反更使用相似的J測試會使軟件具有抵御力

在測試過程中你會發現通過幾種回合的測試之后，該發現的軟件缺陷都被發現了，在測試

下去也不會有新的J發現了。這時，軟件測試員，需要采用其他新的措施，對程序的不一樣

部分進行測試，以找出更多軟件缺陷。

6.并非所有H勺軟件缺陷都能修復

這規定軟件測試員能過進行良好H勺判斷，弄清晰在什么狀況下不能追求完美。項目小組需

要對每一種軟件缺陷進行取舍，根據風險決定哪些需要修復，哪些不要。

不需要修復軟件缺陷的重要原因有：

?沒有足夠的時間。在任何一種項目中，一般是軟件功能較多，而代碼編寫人員和軟件

測試人員較少，并且在項目進度中沒有為編制和則試留出足夠的空間。常常會在不可

更改日勺交付期限內，必須準時完畢軟件。

?不算真正的軟件缺陷。在某些特殊場所，錯誤理解、測試錯誤或者闡明書變更會把軟

件缺陷當作附加功能來看待。

?修復的風險太大。修復一種軟件缺陷也許導致其他軟件缺陷出現；在緊迫的產品公布

進度壓力之外，修改軟件將冒很大的風險。不去理會未知軟件缺陷，以防止出現未知

新缺陷的做法也許是安全之道。

?不值得修復。不常出現的軟件缺陷和在不常用功能中出現的軟件缺陷可以放過；可以

躲過和顧客有措施防止或防止的軟件缺陷一般不用修復。這些都要歸結為商業風險決

策。

7.要盡早、不停地進行測試

測試是無窮近日勺，而測試W、J時間又是有限的，因此我們要盡早地開始測試，盡快地找出軟

件缺陷，以便減少修復成木。在幾種【口I合的測試后來，沒有再檢測出BIG,不能說程序沒

有錯誤，只能說還沒有找到錯誤，沒有人可以找出程序中所有的錯誤，沒有任何軟件產品

是完美無錯H勺，我們能做H勺只是不停地進行測試.

8.測試用例可以協助我們有效地進行測試

“好H勺測試用例是極也許發現迄今為止尚未發現H勺錯誤的測試用例”，可見測試用例對在

軟件測試中占有很重要的地位，它可以彌補軟件測試員在測試時的遺漏、偏差以及經驗上

的局限性，給我們的測試提供根據。同步測試用例也是作為向顧客提供的質量保證的重要

根據之一。

9.程序員應防止測試自己的程序

“自負”是影響程序質量的原因之一，程序員測試的目口勺是證明程序的無錯，基于這種心

理，程序員是很難測試自己程序中價JBUG的。另首先，程序員在理解式樣的時候難免會有

偏差，假如測試自己的程序是很難找出這些偏差H勺。

10.對附和錯誤U勺測試

軟件測試員測試的目的是要找出軟件潛在的錯誤和缺陷，這里的錯誤和缺陷不僅指軟件

自身的錯誤，還要檢測軟件對錯誤的處理能力，因此我們在測試的時候既要準備對的的

數據也要準備錯誤的數據，一般來說測試錯誤口勺CASE比對曰勺口勺CASE要多諸多。

11.群集現象

在測試口勺過程中，會發現某些畫面BUG尤其多，某些功能會出現BUG群集的現象，因此

要重視這些群集現象，并且及時H勺采用對策。

12.杜絕隨意性

軟件測試時一定要有測試根據Fl勺，測試人員不能按照自己的想法憑空想象來評判對錯。

軟件測試員是客戶H勺眼睛，是第一次看到軟件口勺人，代表客戶說話，應力爭完美。但力

爭完美的同步，最佳能全面地客觀評價，做到合情合理。

006.怎樣成為一種好日勺軟件測試員

目前，大多數企業把軟件測試視為技術T.程專業工作。他們意識到在項目組中培訓軟件測試

員，并在開發過程中初期投入工作可以制造出質量更優的軟件。

下面是大多數軟件測試員應具有U勺素質：

?溝通能力。--名理想的測試者必須可以同測試波及到的所有人進行溝通，具有與技

術（開發者）和非技術人員（客戶，管理人員）的交流能力。既要可以和顧客談得

來，又能同開發人員說得上話，不幸日勺是這兩類人沒有共同語言。和顧客談話H勺重

點必須放在系統可以對的地處理什么和不可以處理什么上。而和開發者談相似的信

息時，就必須將這些活重新組織以另一種方式體現出來，測試小組的組員必須可以

同等地同顧客和開發者溝通。

?技術能力。就總體言，開發人員對那些不懂技術的人持一種輕視的態度。一旦測試

小組日勺某個組員作出了一種錯誤0日勺斷定，那么他們日勺可信度就會立即被傳揚了出

去。一種測試者必須既明白被測軟件系統的概念又要會使用工程中的那些工具。要

做到這一點需要有幾年以上的編程經驗，前期時開發經驗可以協助對?軟件開發過程

有較深入時理解，從開發人員口勺角度對口勺啊評價測試者，簡化自動測試工具編程時

學習曲線。

?自信心。開發者指責測試者出了錯是常有的事，測試者必須對自己的觀點有后夠時

自信心。假如容許他人對自己指東指西，就不能完畢什么更多的事情了。由于開發

和測試的立場不一樣，面對問題的時候測試人員要有自信堅持自己的觀點，而不能

輕信開發人員的說法。

?外交能力。當你告訴某人他出了錯時，就必須使用某些外交措施。機智老練和外交

手法有助于維護與開發人員的協作關系，測試者在告訴開發者他口勺軟件有錯誤時，

也同樣需要一定的外交手腕。假如采用日勺措施過于強硬，對測試者來說，在后來和

開發部門口勺合作方面就相稱于“贏了戰爭卻輸了戰役”。

?風趣感。在碰到狡辯的狀況下，一種風趣的批評將是很有協助H勺。

?很強的記憶力。一種理想的測試者應當有能力將此前曾經碰到過的類似的錯誤從記

憶深處挖掘出來，這一能力在測試過程中的價值是無法衡量的。由于許多新“現時

問題和我們已經發現的問題相差無幾。

?耐心。某些質量俁證工作需要難以置信的耐心。有時你需要花費驚人的時間去分離、

識別和分派一種錯誤。這個工作是那些坐不住的人無法完畢日勺。

?懷疑精神。可以預料，開發者會盡他們最大的努力將所有口勺錯誤解釋過去。測式者

必須聽每個人的闡明，但他必須保持懷疑直到他自己看過后來.

?自我督促。干測試工作很輕易使你變得懶散。只有那些具有自我督促能力的人才可

以使自己每天正常地工作。

?洞察力。一種好的測試工程師具有“測試是為了破壞”口勺觀點，捕捉顧客觀點的能

力,強烈FI勺質量追求，對細節FI勺關注能力。應月的高風險區的判斷能力以便將有限

的測試針對重點環節。

?不懈努力。軟件測試員總是不停嘗試。他們也許會碰到瞬間即逝或者難以重建口勺軟

件缺陷。他們不會心存僥幸，而是盡一切也許去尋找。

?發明性。測試顯而易見口勺事實，那不是軟件測試員。他們口勺工作是相處富有創意甚

至超常H勺手段來尋找軟件缺陷。

?追求完美.他們力爭完美，不過懂得某些無法企及時，不去苛求，而是竭力靠近目

的。

?判斷精確。軟件測試員要決定測試內容、測試時間，以及看到的問題與否算作真正

的缺陷。

?說服力。軟件測試員找出的軟件缺陷有是被人認為不重要，不用修復。測試員要善

于體現觀點，表明軟件缺陷為何須須修愛，并通過實際演示力陳觀點。

軟件測試員的一種基本素質是打破砂鍋問究竟。他們喜歡找出那些深藏不露日勺系統沖突。

他們樂于處理最復雜口勺問題。他們外表上熱衷于來回奔忙，追求盡善盡美。

軟件測試員的任務是檢查和批評同事的工作，挑毛病，公布發現的問題。這樣難免與項

目組中的其他人員會產生摩擦，下面是保持小組組員和睦的提議:

?早點找出軟件缺陷。這是軟件測試員口勺當然任務，不過不輕易做到。在三個月之前

而不是在產品即將公布前夕找出嚴重H勺軟件缺陷，會產生更小的影響，更輕易讓人

接受。

?控制情緒。誠然，軟件測試員真心愛慕自己的工作，當發現嚴重的軟件缺陷時樂不

自勝。不過，假如興沖沖地闖入程序員同事口勺房間告訴他程序中存在不可救藥口勺軟

件缺陷，他不會快樂的。

不要總是匯報壞消息。假如意外發現某些代碼沒有軟件缺陷，就大聲宣揚。花某些時間找程

序員聊聊天。假如總是匯報壞消息，他人就會惟恐避之不及。

007.軟件測試的階段劃分

1.單體測試

單元測試的對象是軟件設干的最小單位一一模塊。單元測試的根據是詳細設描述，單元測試

應對模塊內所有重要的I控制途徑設計測試用例，以便發現模塊內部的錯誤。單元測試時，系統

內多種模塊可以并行地進行測試。在這個測試階段所發現日勺往往是編碼和詳細設計的J錯誤。

2.結合測試

也可以稱作“集成測試”，是組裝軟件的系統測試技術，按設計規定把通過單元測試的各個

模塊組裝在一起之后，進行綜合測試以便發現與接口有關的多種錯誤。

3.系統測試

系統測試應當由若干個不一樣測試構成，目的是充足運行系統，驗證系統各部件與否都能正

常工作并完畢所賦予的任務。

系統測試重要有如下的幾種類型：

?恢復測試：重要檢查系統的容錯能力。

?安全測試：檢查系統對非法侵入的防備能力。

?強度測試：檢查程序對異常狀況的抵御能力。

?性能測試：檢查測試數據在超負荷環境中運行，程序與否可以承擔。

4.回歸測試

確定軟件修改和變更后仍然滿足所有軟件規定。回歸測試是有選擇地反復已經有確實認測試,

而不開發新日勺測試。回歸測試需要針對修改或者變更日勺程序進行驗證，并且對該程序修正或

者變更有關口勺功能點進行驗證。I可歸測試不是一種獨立的測試階段，是貫穿在所有測試階段

中反復進行的過程.

008.測試用例的設計措施

測試用例是為特定的目的而設計的一組測試輸入、執行條件和預期日勺成果。簡樸日勺說，測試

用例就是設計一種場景，使軟件程序在這種場景下，必須可以正常運行并且到達程序所波及

H勺執行成果。

測試用例的設計措施與測試H勺基本措施有類似之處，測試用例是對軟件測試的設計，然后基

于測試用例來進行軟件測試的實行。

01.測試用例H勺特性:

1.最有也許抓住錯誤的

2.不是反復H勺、多出的

3.一組相似測試用例中最有效的

4.既不是太簡樸，也不是太復雜

02.測試用例日勺設計原則

1.測試用例H勺代表性：可以代表并覆蓋多種合理的和不合理的、合法的和非法口勺、邊界口勺和

越界口勺以及極限的輸入數據、操作和環境等。

2.測試成果的可判斷性：即測試執行成果的對的性是可鑒定的，每一種測試用例都應有對應

的期望成果。

3.測試成果的可再現性：即對同樣的測試用例，系統的執行成果應當是相似的。

03.等價類劃分措施

1.定義

是把所有也許H勺輸入數據,即程序的輸入域劃提成若干部分（子集），然后從每一種子集中選

用少數具有代表性的數據作為測試用例。該措施是一種重要H勺，常用H勺黑盒測試用例設計措

施。

2.劃分等價類：

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭發程序中的錯誤都是等

效的，并合理地假定：測試某等價類H勺代表值就等于對這一類其他值的測試，因此，可以把所

有輸入數據合理劃分為若干等價類，在每一種等價類中取一種數據作為測試的輸入條件就可

以用少許代表性的測試數據獲得很好H勺測試成果。等價類劃分可有兩種不一樣的狀況：有效

等價類和無效等價類。

1）有效等價類

是指對于程序日勺規格闡明來說是合理日勺、故意義的輸入數據構成的集合。運用有效等

價類可檢查程序與否實現了規格闡明中所規定的功能和性能。

2）無效等價類

與有效等價類的I定義碰巧相反。無效等價類指對程序的規格闡明是不合理的或無意義

H勺輸入數據所構成H勺集合。對于詳細H勺問題，無效等價類至少應有一種，也也許有多種。

設計測試用例時，要同步考慮這兩種等價類。由于軟件不僅要能接受合理的數據，也要能經

受意外的考驗，這樣的測試才能保證軟件具有更高的可靠性。

3.劃分等價類的原則：

1）完備測試、防止冗余；

2）劃分等價類重要的是：集合H勺劃分，劃分為互不相交H勺一組子集，而子集時并是整個

集合；

3）并是整個集合：完備性；

4）子集互不相交：保證一種形式的無冗余性;

5）同一類中標識（選擇）一種測試用例，同一等價類中，往往處理相似，相似處理映射

到”相似的執行途徑”。

4.劃分等價類II勺措施

6）在輸入條件規定了取值范圍或值日勺個數的I狀況卜，則可以確立一種有效等價類和兩個

無效等價類。如：輸入值是學生成績，范圍是0?100；

0100

無效等價類—<________懿等價類________..正效等俗賽

成績VOUW娟W1U0成績>100

7）在輸入條件規定了輸入值的集合或者規定了“必須怎樣”的條件的狀況下，可確立一種

有效等價類和一種無效等價類；

8）在輸入條件是一種布爾量U勺狀況下,可確定一種有效等價類和一種無效等價類。

9）在規定了輸入數據的一組值（假定n個），并且程序要對每一種輸入值分別處理的狀

況下,可確立n個有效等價類和一種無效等價類。

例：輸入條件闡明學歷可為:專科、本科、碩士、博士四種之一，則分別取這四種這四個

值作為四個有效等價類，此外把四種學歷之外的任何學歷作為無效等價類。

10）在規定了輸入數據必須遵守的規則的狀況下，可確正一種有效等價類（符合規則）和

若干個無效等價類（從不一樣角度違反規則）；

11）在確知已劃分的等價類中各元素在程序處理中的方式不一樣的狀況下，則應再將該等

價類深入H勺劃分為更小Fl勺等價類。

5.設計測試用例

在確立了等價類后，可建立等價類表，列出所有劃分出時等價類輸入條件：有效等價類、無

效等價類，然后從劃分出的等價類中按如下三個原則設計測試用例：

1）為每一種等價類規定一種唯一的編號；

2）設計一種新的）測試用例，使其盡量多地覆蓋尚未被覆蓋地有效等價類,反復這?步，直到

所有的有效等價類都被覆蓋為止；

3）設計一種新的測試用例，使其僅覆蓋一種尚未被覆蓋日勺無效等價類,反復這一步，直到所

有的無效等價類都被覆蓋為止。

04.邊界值分析措施

邊界值分析法就是對輸入或輸出的邊界值進行測試口勺一種黑盒測試措施。一般邊界值分析法

是作為對等價類劃分法的補充，這種狀況下，其測試用例來自等價類口勺邊界。

1.與等價劃分打勺區別

D邊界值分析不是從某等價類中隨便挑一種作為代表，而是使這個等價類的每個邊界都要

作為測試條件。

2）邊界值分析不僅考慮輸入條件，還要考慮輸出空間產生的測試狀況。

2.邊界值分析措施的考慮：

長期歐I測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生

在輸入輸出范圍H勺內部。因此針對多種邊界狀況設計測試用例，可以查出更多的錯誤。

使用邊界值分析措施設計測試用例，首先應確定邊界狀況。一般輸入和輸出等價類的邊界，

就是應著重測試的邊界狀況。應當選用恰好等于，剛剛不小于或剛剛不不小于邊界時值作為

測試數據，而不是選用等價類中的經典值或任意值作為測試數據。

3.常見的邊界值

1）對16-bit的整數而言32767和-32768是邊界

2）屏幕上光標在最左上、最右下位置

3）報表的第一行和最終一行

4）數組元素的第一種和最終一種

5）循環的第0次、第1次和倒數第2次、最終一次

4.邊界值分析

1）邊界值分析使用與等價類劃分法相似II勺劃分，只是邊界值分析假定錯誤更多地存在于劃分

的邊界上，因此在等價類的邊界上以及兩側的狀況設計測試用例。

2）等價類劃分：

I.可以考慮作出如下劃分：

a、輸入（i）＜0和（ii）＞=0

b、輸出（a）＞=0和⑹Error

II.測試用例有兩個:

a、輸入4,輸出2。對應于（ii）和（a）。

c、輸入TO,輸出0和錯誤提醒。對應于（i）和（b）。

3）邊界值分析：

劃分（ii）的邊界為0和最大正實數；劃分（i）的邊界為最小負實數和0。由此得到如

下測試用例：

a、輸入｛最小負實數》

b、輸入｛絕對值很小的負數｝

c、輸入0

d、輸入｛絕對值很小的正數｝

e、輸入｛最大正實數｝

4）一般狀況下，軟件測試所包括的邊界檢查有幾種類型：數字、字符、位置、重量、大小、

速度、方位、尺寸、空間等。

5）對應地，以上類型的邊界值應當在：最大/最小、首位/末位、上/下、最快/最慢、最忘

/最低、最短/最長、空/滿等狀況下。

6）運用邊界值作為測試數據

項邊界值測試用例的設計思緒

起始T個字假設一種文本輸入區域容許輸入1個到255個字符，輸入1

字符符/結束+1個個和255個字符作為有效等價類；輸入。個和256個字符作

字符為無效等價類，這幾種數值都屬于邊界條件值。

最小值7/最假設某軟件的數據輸入域規定輸入5位口勺數據值，可以使用

數值

大信+110000作為最小值、99999作為最大值；然后使用剛好不不

小于5位和不小于5位的數值來作為邊界條件。

不不小于空

余空間一點/例如在用U盤存儲數據時，使用比剩余磁盤空間大一點（兒

空間

不小于滿空KB）的文獻作為邊界條件。

間一點

7）內部邊界值分析:

在多數狀況下，邊界值條件是基于應用程序口勺功能設計而需要考慮的原因，可以從軟件口勺規

格闡明或常識中得到，也是最終顧客可以很輕易發現問題的。然而，在測試用例設計過程中，

某些邊界值條件是不需要展現給顧客的），或者說顧客是很難注意到日勺，但同步確實屬于檢查

范圍內的J邊界條件?，稱為內部邊界值條件或子邊界值條件。

內部邊界值條件重要有下面幾種：

a）數值的邊界值檢查：計算機是基于二進制進行工作的，因此，軟件的J任何數值運算均有一

定H勺范圍限制。

項范圍或值

位(bit)0或1

字節(byte)0~255

字(word)0~65535（單字）或0~（雙字）

千(K)1024

兆(M)1048576

吉(G)

b）字符的邊界值檢查：在計算機軟件中，字符也是很重要口勺表達元素，其中ASCII和Unicode

是常見的編碼方式。下表中列出了某些常用字符而應的ASCII碼值。

字符ASCII碼值字符ASCII碼值

空(null)0A65

空格（space）32a97

斜杠（/）47Z90

048z122

冒號（：）58單引號（'）96

@64

c）其他邊界值檢查

5.基于邊界值分析措施選擇測試用例H勺原則

1）假如輸入條件規定了值H勺范圍，則應取剛到達這個范圍口勺邊界的值，以及剛剛超越這個范

圍邊界的I值作為測試輸入數據。

例如，假如程序日勺規格闡明中規定：”重量在10公斤至50公斤范圍內的郵件，其郵費計算

公式為……\作為測試用例,我們應取10及50,還應取】（）.01,49.99,9.99及50.（）1等。

2）假如輸入條件規定了值H勺個數，則用最大個數，最小個數，比最小個數少一，比最大個數多

—U勺數作為測試數據。

例如，一種輸入文獻應包括:255個記錄，則測試用例可取1和255,還應取0及256等。

3）將規則1）和2）應用于輸出條件，即設計測試用例使輸出值到達邊界值及其左右的值。

例如，某程序的規格闡明規定計算出〃每月保險金扣除額為0至1165.25元"，其測試用例可

取O00及1165.24、還可取一0.01及1165.26等。

再如一程序屬于情報檢索系統，規定每次〃至少顯示1務、最多顯示4條情報摘要”，這時我

們應考慮的測試用例包括1和4,還應包括0和5等。

4）假如程序I為規格闡明給出口勺輸入域或輸出域是有序集合，則應選用集合H勺第一種元素和最

終一種元素作為測試用例。

5）假如程序中使用了一種內部數據構造，則應當選擇這個內部數據構造I內邊界上時值作為測

試用例。

6）分析規格闡明，找出其他也許日勺邊界條件。

?錯誤推測法

基于經驗和直覺推測程序中所有也許存在的多種錯誤，從而有針對性口勺設計測試用例口勺措

施。

1.錯誤推測措施的基本思想：

列舉出程序中所有也許有的J錯誤和輕易發生錯誤的特殊狀況,根據他們選擇測試用例。

1）例如，輸入數據和輸出數據為0『、J狀況；輸入表格為空格或輸入表格只有一行。這些都

是輕易發生錯誤的狀況。可選擇這些狀況下日勺例子作為測試用例。

2）例如，前面例子中成績匯報的程序，采用錯誤推測法還可補充設計某些測試用例：

1.程序與否把空格作為回答

II.在回答記錄中混有原則答案記錄

III.除了標題記錄外，尚有某些U勺記錄最終一種字符即不是2也不是3

IV.有兩個學生的學號相似

V.試題數是負數,

3）再如，測試一種對線性表（例如數組）進行排序H勺程序，可推測列出如下幾項需要尤

其測試的狀況：

I.輸入的線性表為空表；

II.表中只具有一種元素；

III.輸入表中所有元素已排好序；

IV.輸入表已按逆序排好；

V.輸入表中部分或所有元素相似

05.因果圖措施

是一種運用圖解法分析輸入的多種組合狀況，從而設計測試用例U勺措施，它適合于檢查程序

輸入條件的多種組合狀況。

1.因果圖法產生的背景：

等價類劃分法和邊界值分析措施都是著重考慮輸入條件，但沒有考慮輸入條件口勺多種組合、

輸入條件之間的互相制約關系。這樣雖然多種輸入條件也許出錯H勺狀況已經測試到了：但多

種輸入條件組合起來也許出錯的狀況卻被忽視了。

假如在測試時必須考慮輸入條件的多種組合，則也許的組合數目將是天文數字，因此必須考

慮采用一種適合于描述多種條件的組合、對應產生多種動作U勺形式來進行測試用例的設計，

這就需要運用因果圖（邏輯模型）。

2.因果圖簡介

1）4種符號分別表達了規格闡明中向4種因果關系。

2）因果圖中使用了簡樸的邏輯符號，以直線聯接左右結點。左結點表達輸入狀態（或稱原

因），右結點表達輸出狀態（或稱成果）。

3）Ci表達原因，一般置于圖口勺左部；ei表達成果，一般在圖H勺右部。Ci和ei均可取值0

或1,0表達某狀態不出現，1表達某狀態出現。

3.因果圖概念

1）關系

①恒等：若ci是1,則ei也是1；否則ei為0。

②非：若ci是1,則ei是0：否則ei是1。

③或：若cl或c2或c3是1,則ei是1；否則ei為0,“或”可有任意個輸入。

④與：若cl和c2都是1,則ei為1；否則ei為仇“與”也可有任意個輸入。

2）約束

輸入狀態互相之間還也許存在某些依賴關系，稱為約束。例如，某些輸入條件自身不也許同

步出現。輸出狀態之間也往往存在約束。在因果圖中，用特定的符號標明這些約束。

0Q-

E<--0

唯‘、?

異

0Q\

/IM

Rl.一/.：

強制?守

要求

A.輸入條件時約束有如下4類：

①E約束（異）：a和b中至多有一種也許為1,即a和b不能同步為1°

②I約束（或）：a、b和c中至少有一種必須是1,即a、b和c不能同步為0。

③0約束（唯一）；a和b必須有一種，且僅有1個為1。

④R約束（規定）：a是1時，b必須是1,即不也許a是1時b是0。

B.輸出條件約束類型

輸出條件的約束只有M約束（強制）：若成果a是1,則成果b強制為0。

4.采用因果圖法設計測試用例的環節:

1）分析軟件規格闡明描述中，那些是原因（即輸入條件或輸入條件的等價類），那些是成果

（即輸出條件），并給每個原因和成果賦予一種標識符。

2）分析軟件規格闡明描述中的語義，找出原因與成果之間，原因與原因之間對應的關系，根

據這些關系，畫出因果圖。

3）由于語法或環境限制，有些原因與原因之間，原因與成果之間的組合狀況不也許出現，為

表明這些特殊狀況，在因果圖上用某些記號表明約束或限制條件。

4）把因果圖轉換為鑒定表。

5）把鑒定表的每一列拿出來作為根據，設計測試用例。

06.鑒定表驅動分析措施

鑒定表是分析和體現多邏輯條件下執行不一樣操作的I狀況日勺工具。

1.鑒定表的長處

可以將復雜的問題按照多種也許的狀況所有列舉出來，簡要并防止遺漏。因此，運用鑒定表

可以設計出完整H勺測試用例集合。

在某些數據處理問題當中，某些操作的實行依賴于多種邏輯條件口勺組合，即：針對不一樣邏

輯條件的組合值，分別執行不一樣的操作。鑒定表很適合于處理此類問題。

2.“閱讀指南”鑒定表

12345678

覺得疲憊？YYYYNNNX

問

感愛好嗎？YYNNYYN\

題

糊涂嗎？YNYNYNYN

重讀V

提繼續

議跳下一章

休息7VVV

3.鑒定表一般由四個部分構成如下圖所示。

條件樁條件項

動作項

動作樁規

則

1)條件樁(ConditionStub)：列出了問題得所有條件,一般認為列出的I條件的次序無關緊

要。

2)動作樁(ActionStub)：列出了問題規定也許采用的操作。這些操作的排列次序沒有約束。

3)條件項(ConditionEntry)：列出針對它左列條件的取值。在所有也許狀況下的真假值。

4)動作項(ActionEntry)：列出在條件項的多種取值狀況下應當采用的動作。

4.規則及規則合并

1)規則：任何一種條件組合口勺特定取值及其對應要執行的操作稱為規則。在鑒定表中貫穿條

件項和動作項的一列就是一條規則。顯然,鑒定表中列出多少組條件取值，也就有多少條規則,

既條件項和動作項有多少列。

2）化簡：就是規則合并有兩條或多條規則具有相似的動作，并且其條件項之間存在著極為相

似H勺關系。

5.規則及規則合并舉例

1）如下圖左端，兩規則動作項同樣，條件項類似，在1、2條件項分別取Y、N時，無論條件

3取何值，都執行同一操作。即要執行的動作與條件3無關。于是可合并。“一”表達與取

值無關。

YY

NN

YNC=>

，XX

2）與上類似，下圖中，無關條件項“一”可包括其他條件項取值，具有相似動作H勺規則可合

并。□

M

0M

E

3）化簡后的讀書指南鑒定表

1234

你覺得疲憊嗎？——YN

問

你對內容感愛好嗎？YYNN

題

書中內容使你胡涂嗎？YN一—

請回到本章開頭重讀X

建繼續讀下去X

議

跳到下一章去讀X

停止閱讀，請休息X

6.鑒定表的建立環節：（根據軟件規格闡明）

D確定規則的個數.假如有n個條件。每個條件有兩個取值（0,1），故有2n種規則。

2）列出所有的條件樁和動作樁。

3）填入條件項。

4）填入動作項。等到初始鑒定表。

5）簡化.合并相似規則（相似動作）。

07.功能圖分析措施

一種程序的功能闡明一般由動態闡明和靜態闡明構成.動態闡明描述了輸入數據的次序或轉

移U勺次序.靜態闡明描述了輸入條件與輸出條件之間的對應關系.對于較復雜"勺程序，由于存

在大量的組合狀況,因此，僅用靜態闡明構成的規格闡明對于測試來說往往是不夠的.必須用

動態闡明來補充功能闡嘰功能圖措施是用功能圖FD形式化地表達程序H勺功能闡明，并機械

地生成功能圖的測試用例.功能圖模型由狀態遷移圖和邏輯功能模型構成.狀態遷移圖用于

表達輸入數據序列以及對應的輸出數據.在狀態遷移圖中，由輸入數據和目前狀態決定輸出

數據和后續狀態.邏輯功能模型用于表達在狀態中輸入條件和輸出條件之間H勺對應關系.邏

輯功能模型只適合于描達靜態闡明，輸出數據僅由輸入數據決定.測試用例則是由測試中通

過的一系列狀態和在每個狀態中必須依托輸入/輸出數據滿足的一對條件構成.功能圖措施

其實是是一種黑盒白盒混合用例設計措施。

（功能圖措施中，要用到邏輯覆蓋和途徑測試H勺概念和措施，其屬白盒測試措施中代I內容.

邏輯覆蓋是以程序內部的邏輯構造為基礎口勺測試用例設計措施.該措施規定測試人員對程序

H勺邏輯構造有清晰H勺理解.由于覆蓋測試日勺目H勺不一樣,邏輯覆蓋可分為:語句覆蓋，鑒定覆

蓋，鑒定-條件覆蓋，條件組合覆蓋及途徑覆蓋.下面我們指的邏輯覆蓋和途徑是功能或系統

水平上的，以區別與白盒測試中的程序內部的.）

1.功能圖

功能圖由狀態遷移圖和布爾函數構成.狀態遷移圖用狀態和遷移來描述.一種狀態指出數據

輸入日勺位置（或時間），而遷移則指明狀態的變化.同步要依托鑒定表或因果圖表達小J邏輯功

能.

2.測試用例生成措施

將節點替代狀態,用弧線替代遷移，則狀態遷移圖就可轉化成一種程序的控制流程圖形式.問

題就轉化為程序的途徑測試問題（如白盒測試）問題了.

3.測試用例生成規則

為了把狀態遷移（測試途徑）口勺測試用例與邏輯模型（局部測試用例）日勺測試用例組合起來,

從功能圖生成實用日勺測試用例，須定義下面的規則.在一種構造化日勺狀態遷移（SST）中,定義

三種形式的循環:次序,選擇和反復.但辨別一種狀態遷移中的所有循環是有困難的.

4.從功能圖生成測試用例的過程

D生成局部測試用例：在每個狀態中，從因果圖生成局部測試用例.局部測試用例由原因值

（輸入數據）組合與對應R勺成果值（輸出數據或狀態）構成。

2）測試途徑生成:運用上面的規則（三種）生成從初始狀態到最終狀態的測試途徑。

3）測試用例合成：合成測試途徑與功能圖中每個狀態中H勺局部測試用例.成果是初始狀態

到最終狀態的一種狀態序列，以及每個狀態中輸入數據與對應輸出數據的組合。

08.場景設計措施

目前口勺軟件兒乎都是用事件觸發來控制流程H勺，事件觸發時H勺情景便形成了場景，而同一事

件不一樣的觸發次序和處理成果就形成事件流。這種在軟件設計方面的思想也可以引入到軟

件測試中，可以比較生動地描繪出事件觸發時H勺情景，有助于測試設計者設計測試用例，同

步使測試用例更輕易理解和執行。

基本流和備選流：如下圖所示，圖中通過用例的每條途徑都用基本流和備選流來表達，直黑

線表達基本流，是通過用例日勺最簡樸的途徑。備選流用不一樣日勺色彩表達，一種備選流也許

從基本流開始，在某個特定條件下執行，然后重新加入基本流中（如備選流1和3）；也也

許來源于另一種備選流（如備選流2）,或者終止用例而不再重新加入到某個流（如備選流2

和4）。

開始用例

基本流

備選流

備選流1

備選流4

結束用例

結束用例

09.測試用例設計綜合方略

1）在任何狀況下都必須使用邊界值分析措施，經驗表明用這種措施設計出測試用例發現程序

錯誤的能力最強。

2）必要時用等價類劃分措施補充某些測試用例。

3）用錯誤推測法再追加某些測試用例。

4）對照程序邏輯，檢查已設計出口勺測試用例的邏輯覆蓋程度，假如沒有到達規定的覆蓋原則,

應當再補充足夠口勺測試用例。

5）假如程序的功能闡明中具有輸入條件H勺組合狀況，則一開始就可選用因果圖法。

10.測試用例的設計環節

I）構造根據設計書得出的基本功能測試用例；

2）邊界值測試用例；

3）狀態轉換測試用例；

4）錯誤猜測測試用例：

5）異常測試用例；

009.軟件測試的基本方式

01.黑盒測試

只需要懂得軟件要做什么即可一一而無法看到盒子中是怎樣運作的。只要進行某些輸入，就

能得到某種輸出成果。不用懂得軟件怎樣運行，為何會這樣，只要懂得程序做什么。

02.白盒測試

用訪問程序員日勺代碼，并通過檢查代碼來協助測試一一可以看到盒子里面。測試員根據代碼

檢查成果判斷多大的數字乜許出錯，并據此調整測試程序。要注意的是，進行白盒測試要冒

某些風險。由于要調整測試程序以適應代碼操作，因此很輕易形成偏見而無法進行客觀測試.

03.靜態測試

是指測試不運行U勺部分一一只是檢查和審閱。

04.動態測試

是指?般意義上日勺測試一一運行和使用軟件。

010.軟件測試的基本措施

01.通過測試和失敗測試

軟件測試有兩個基本措施，通過測試和失敗測試。我們一般的測試用例的內容也就是門通過

測試和失敗測試兩部分構成的I。通過測試就是我們所說的正常的CASE,確認軟件至少能做什

么，而不會考驗其能力。軟件測試員不把軟件當回事，只運用最簡樸最直觀的測試用例。在

設計和執行測試案例時，總是首先進行通過測試。在做破壞性試驗之前首先要保證軟件基本

功能與否已經實現了。失敗測試就是所謂H勺異常CASE,在確信軟件在一般狀況下對口勺運行之

后，就可以采用多種手段通過搞垮軟件來找出缺陷。設計和執行破壞軟件的測試用例。常見

的測試用例就是設法迫使軟件出現錯誤提醒信息。雖然與通過測試看起來差不多，不過它是

蓄意襲擊軟件口勺微弱環節。

02.等價類劃分

選擇測試按例是軟件測試員最重要H勺任務。選擇測試案例H勺措施是等價分派，有時稱為等價

劃分。等價分派是指分環節地把過多（無限）的測試用例減小到同樣有效的小范圍的過程。

尋找等價區間時，想措施把軟件的相似輸入、輸出、操作提成組。這些組就是等價區間。等

價分派日勺目日勺是把也許的測試用例組合縮減到仍然足以測試軟件日勺控制范圍。由于選擇了不

完全測試，就要冒一定的風險，因此必須仔細選擇分類。

03.數據測試

軟件由數據（包括鍵盤輸入、鼠標單擊、磁盤文獻、打印輸出等等）和程序（可執行的流程、

轉換、邏輯和運算）兩個最基本的要素構成。對軟件進行數據測試，就是在檢查顧客輸入的

信息、返回成果以及中間計算成果與否對的。重要根據下列原則來進行等價分派，以合理減

少測試案例：邊界條件、空值和無效數據。

?邊界條件測試

邊界條件是指軟件計劃的操作界線所在的邊緣條件。程序在處理大量中間數值時都是對日勺，

不過也許在邊界處出現錯誤。數據類型：數值、字符、位置、數晟、速度、地址、尺寸等，

都會包括確定口勺邊界。

應考慮H勺特性：第一種/最終一種、開始/完畢、空/滿、最慢/最快、相鄰/最遠、最小值/最

大值、超過/在內、最短/最長、最早/最遲、最高/最低。

這些都是也許出現的邊界條件。根據邊界來選擇等價分派中包括口勺數據。然而，僅僅測試邊

界線上口勺數據點往往不夠充足。提出邊界條件時，一定要測試臨近邊界的合法數據，即測試

最終一種也許合法日勺數據，以及剛超過邊界的非法數據。

?默認值測試（默認、空白、空值、零值和無）

好的軟件會處理這種狀況，常用的J措施：一是將輸入內容默認為合法邊界內的最小值，或者

合法區間內某個合理值；二是返回錯誤提醒信息。這些值在軟件中一般需要進行特殊處理。

因此應當建立單獨H勺等價區間。在這種默認下，假如顧客輸入。或一1作為非法值，就可以執

行不一樣的軟件處埋過程。

?破壞測試（非法、錯誤、不對H勺和垃圾數據）

數據測試的這一類型是失敗測試的對象。此類測試沒有實際規則，只是設法破壞軟件。不按

軟件的規定行事，發揮發明力吧！

04.狀態測試

狀態測試是通過不一樣的狀態驗證程序的邏輯流程。軟件測試員必須測試軟件的狀態及