軟件工程：第9章 軟件測試與維護(hù)

第9章軟件測試本章導(dǎo)讀隨著中國IT行業(yè)的發(fā)展，軟件產(chǎn)品的測試和質(zhì)量保證工作逐漸成為企業(yè)生存與發(fā)展的關(guān)鍵。每個IT企業(yè)的產(chǎn)品在發(fā)布前，都需要進(jìn)行大量的測試工作。本章首先論述軟件測試的理論基礎(chǔ)。接下來講解軟件測試流程和測試技術(shù)。最后介紹軟件測試文檔、軟件測試案例和測試員職業(yè)素質(zhì)培養(yǎng)。1

要求了解

(1)軟件測試的發(fā)展歷史

(2)目前國內(nèi)外軟件測試現(xiàn)狀

(3)軟件測試分類

(4)軟件測試工具

要求理解

(1)軟件測試的作用

(2)軟件質(zhì)量定義和相關(guān)測試標(biāo)準(zhǔn)

(3)軟件測試原則要求掌握

(1)軟件測試的定義

(2)軟件測試的目的和目標(biāo)

(3)軟件測試模型

(4)軟件測試文檔

29.1軟件測試概論

軟件測試的輸入是《測試計劃》、《用戶需求報告》/《需求規(guī)格說明書》，輸出是《測試報告》?；蛘哒f，軟件測試輸入的是測試用例（數(shù)據(jù)），輸出的是測試報告（或Bug報告）。根據(jù)“五個面向理論”，軟件測試的主要方法是“面向功能測試”。測試的目的是為了發(fā)現(xiàn)測試對象的問題，而不是證明測試對象沒有問題。軟件測試技術(shù)還不成熟，還大有搞頭！3測試對象的“問題”分為哪幾種？(1)缺陷。這是輕量級的問題，因?yàn)樗⒉挥绊懴到y(tǒng)的正常運(yùn)行，只是有點(diǎn)美中不足。例如：多了或少了某些次要的功能。有缺陷的產(chǎn)品可降級使用；

(2)錯誤。這是次重量級的問題，因?yàn)樗绊懴到y(tǒng)的正常運(yùn)行，使系統(tǒng)在運(yùn)行中出現(xiàn)錯誤，但這些錯誤還不是致命性的。有錯誤的產(chǎn)品不能使用；

(3)嚴(yán)重錯誤。這是最重量級的問題，因?yàn)樗坏绊懴到y(tǒng)的正常運(yùn)行，而且使系統(tǒng)在運(yùn)行中出現(xiàn)致命性的錯誤。例如造成系統(tǒng)的死鎖、生命危險或系統(tǒng)崩潰。有嚴(yán)重錯誤的產(chǎn)品絕對不能使用。4測試可以提高軟件的質(zhì)量嗎？

軟件公司一般都有自己的測試中心或測試部門，他們的職責(zé)和作用是什么呢？讀者可能會不加思索地回答：“測試可以提高軟件產(chǎn)品的質(zhì)量！”我們說：“回答錯了”，為什么？因?yàn)闇y試只能發(fā)現(xiàn)軟件產(chǎn)品的“不符合項(xiàng)”或錯誤(Bug)，不能改正軟件產(chǎn)品的錯誤，所以不能直接提高軟件產(chǎn)品的質(zhì)量。這個問題就是軟件測試的作用。優(yōu)秀的測試團(tuán)隊可在早期發(fā)現(xiàn)錯誤，使軟件維護(hù)的費(fèi)用降到最低點(diǎn)。5用戶需求(需求規(guī)格)是測試的基準(zhǔn)

軟件測試可分為系統(tǒng)軟件測試和應(yīng)用軟件測試：

(1)系統(tǒng)軟件測試主要是為了發(fā)現(xiàn)Bug，測試報告為“Bug測試報告”。

(2)應(yīng)用軟件測試主要是為了發(fā)現(xiàn)“不符合項(xiàng)”，測試報告為“軟件的需求規(guī)格測試報告”。不管是為客戶定制軟件項(xiàng)目還是開發(fā)通用軟件產(chǎn)品，都是為了滿足客戶的需求。若通過Beta測試滿足了功能、性能和接口的需求，就可以向客戶交付產(chǎn)品，客戶按合同付清全部款項(xiàng)。69.2軟件測試?yán)碚摶A(chǔ)

9.2.1什么是軟件測試

1.什么是測試測試的英文單詞為test，即檢驗(yàn)或考試之意。

【定義9-1】所謂測試，就是通過一定的方法或工具，對被測試對象進(jìn)行檢驗(yàn)或考試，以發(fā)現(xiàn)被測試對象具有某種屬性或者存在某些問題的過程。7什么是測試(續(xù))【例9-2】要初步測試一個人的智力是否存在嚴(yán)重障礙，可以出如下測試題目：1＋2＝？2＋2＝？如果他的回答全部正確，就可以初步斷定不是智力嚴(yán)重障礙，反之可能是智力嚴(yán)重障礙。上述參加測試的人就是被測試的對象；出算術(shù)題就是測試方法；“1＋2＝？”就是測試用例；請他們回答問題和參與測驗(yàn)的過程就是測試過程；將測試過程得出的結(jié)果和我們預(yù)期的結(jié)果相比較，就能得出測試結(jié)論；將測試結(jié)論進(jìn)行分析就可以產(chǎn)生測試報告。82.什么是軟件測試

軟件測試是測試中的特例，它的測試對象是人類的智力產(chǎn)品----軟件。

【定義9-2】軟件測試是發(fā)現(xiàn)軟件錯誤的過程.

為了深入理解軟件測試的定義，請從下面幾個角度來思考：

(1)從軟件測試的目的來理解。測試的目的是發(fā)現(xiàn)軟件中的錯誤，是為了證明軟件有錯，而不是證明軟件無錯，是在軟件投入運(yùn)行前，對軟件需求分析、設(shè)計和編碼各階段產(chǎn)品的最終檢查，是為了保證軟件開發(fā)產(chǎn)品的正確性、完全性和一致性。9請從下面幾個角度來思考：(2)從軟件測試的性質(zhì)來理解。在軟件開發(fā)過程中，分析、設(shè)計與編碼等工作都是“建設(shè)性的”，惟獨(dú)測試是帶有“破壞性的”。

(3)從軟件開發(fā)角度來理解。軟件測試以檢查軟件產(chǎn)品的內(nèi)容和功能特性為核心，是軟件質(zhì)量保證的關(guān)鍵步驟,也是成功實(shí)現(xiàn)軟件開發(fā)目標(biāo)的重要保障。

(4)從軟件工程角度來理解。軟件測試是軟件工程的一部分，是軟件工程過程中的重要階段。

(5)從軟件質(zhì)量保證角度來理解。軟件測試是軟件質(zhì)量保障的關(guān)鍵措施。109.2.2為什么要進(jìn)行軟件測試1.軟件質(zhì)量問題迫在眉睫軟件發(fā)展史上因?yàn)闇y試不充分，導(dǎo)致嚴(yán)重軟件問題：

1991年，美國愛國者導(dǎo)彈防御系統(tǒng)多次在防御戰(zhàn)爭中失利；

1994年，迪斯尼獅子王游戲在一些PC機(jī)上不能運(yùn)行；

1994年，Intel奔騰浮點(diǎn)除法錯誤事件；

1995年，千年蟲問題；

1999年，美國航天局火星車失蹤事件

……。歸根到底一句話：軟件質(zhì)量問題迫在眉睫。

軟件質(zhì)量問題，能否提前發(fā)現(xiàn)？能！方法就是測試。112.加強(qiáng)測試是提高質(zhì)量的有效辦法

客戶對投放市場的軟件產(chǎn)品質(zhì)量不滿意，從測試角度考慮原因有兩種可能：

(1)一是軟件開發(fā)商采用了非正規(guī)的測試方法和測試過程，對軟件進(jìn)行測試，或者根本就沒有按照正規(guī)要求進(jìn)行軟件測試。

(2)二是軟件開發(fā)商按照現(xiàn)有的正規(guī)做法，對軟件進(jìn)行了測試，但是，軟件質(zhì)量仍不能達(dá)到客戶的滿意度，這說明現(xiàn)有的軟件測試標(biāo)準(zhǔn)、方法和過程有待改進(jìn)。

(3)軟件的缺陷難以根除，但軟件的質(zhì)量是可以改進(jìn)的。加強(qiáng)軟件測試是控制和提高軟件質(zhì)量的一個行之有效的辦法。129.2.2軟件測試發(fā)展歷史

在中國的IT企業(yè)，20世紀(jì)90年代，軟件公司基本上沒有獨(dú)立的軟件測試人員，測試工作都由程序員自己完成。到了20世紀(jì)末、21世紀(jì)初，獨(dú)立的軟件測試部門才開始誕生。根據(jù)有關(guān)職位統(tǒng)計資料顯示，在國外大多數(shù)軟件公司，1個軟件開發(fā)工程師就需要輔有2個軟件測試工程師。而國內(nèi)目前的平均比例卻是8：1，在這種比例懸殊的情況下，很難通過測試提高軟件質(zhì)量。隨著我國軟件產(chǎn)業(yè)化的進(jìn)程，一些企業(yè)內(nèi)部的獨(dú)立測試部門，一些第三方測試機(jī)構(gòu)將逐漸發(fā)展壯大，軟件測試將成為比軟件編程更具挑戰(zhàn)性和創(chuàng)造性的職業(yè)。13軟件測試發(fā)展歷史(續(xù))

軟件測試人員分為測試執(zhí)行人員、測試設(shè)計人員、測試開發(fā)人員三種角色，我們可以統(tǒng)稱為軟件測試工程師：

(1)測試設(shè)計人員制定測試方案；

(2)測試執(zhí)行人員按照測試方案對產(chǎn)品進(jìn)行測試，并給出測試報告或者質(zhì)量評測結(jié)果；

(3)測試開發(fā)人員編寫測試工具，實(shí)現(xiàn)測試工作自動化。目前，在企業(yè)內(nèi)部，具有四年以上測試經(jīng)驗(yàn)的軟件測試工程師就可處于“雙高”地位，即地位高、待遇高，有的人月薪可高達(dá)8000元。149.2.3軟件測試目的和目標(biāo)

軟件測試的目的是什么？就是盡可能早的發(fā)現(xiàn)軟件問題。這里的問題，包括Bug和不符合項(xiàng)。那么，什么是軟件問題？符合下列五個規(guī)則中的一個，就是軟件問題：

(1)軟件未達(dá)到產(chǎn)品說明書（需求報告或需求說明書）標(biāo)明的功能；

(2)軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤；

(3)軟件未達(dá)到產(chǎn)品說明書未指明但應(yīng)達(dá)到的目標(biāo)；

(4)軟件功能超出產(chǎn)品說明書所指明范圍；

(5)軟件測試人員認(rèn)為軟件難以理解、不易使用、速度緩慢，或者最終客戶認(rèn)為不好。15軟件問題的生命周期

169.2.4軟件測試原則1.盡早開展測試工作2.完全測試不可能，把握最優(yōu)測試量3.嚴(yán)防寄生蟲現(xiàn)象4.嚴(yán)防殺蟲劑現(xiàn)象

5.并非所有的軟件缺陷都能修復(fù)6.難以說清的軟件缺陷7.產(chǎn)品說明書不斷變化8.軟件測試人員在產(chǎn)品小組中不受歡迎

171.盡早開展測試工作

需求分析時，就要按需求文檔來開展測試準(zhǔn)備工作。怎么準(zhǔn)備？

(1)首先要理解用戶需求，然后分析軟件需求定義是否具有可測性，最后把軟件開發(fā)需求轉(zhuǎn)換（分解）為軟件測試需求。

(2)針對測試需求，復(fù)用或者重新設(shè)計與編寫測試用例，定義測試策略。182.完全測試不可能，把握最優(yōu)測試量

由于時間、人員、設(shè)備和資金等條件的限制，導(dǎo)致完全測試不可能。因此，軟件產(chǎn)品的測試和發(fā)布工作是永遠(yuǎn)存在矛盾：

(1)時間有限：各個領(lǐng)域的軟件產(chǎn)品，都有多家開發(fā)商，面對這樣的買方市場，誰先發(fā)布產(chǎn)品誰就可能先搶占大部分市場，所以要提前發(fā)布。

(2)人員有限：更換或者新聘用人員時，無疑會增加軟件的開發(fā)成本，甚至火上加油。193.嚴(yán)防寄生蟲現(xiàn)象

軟件問題會像寄生蟲一樣過群居生活：

(1)在一個開發(fā)人員提交的代碼中發(fā)現(xiàn)了一個問題，提交故障單后，應(yīng)在該程序員提交的其他代碼中（如果此程序員負(fù)責(zé)幾個開發(fā)模塊的話），驗(yàn)證一下是否有類似的問題的寄生。

(2)寄生蟲與程序員的脾氣秉性和心情好壞成正比。作為測試人員都要洞察這些潛在的因素，保證盡可能多的發(fā)現(xiàn)寄生蟲群居現(xiàn)象。204.嚴(yán)防殺蟲劑現(xiàn)象

長時期使用一種藥物，病毒就會產(chǎn)生抗藥性，這就是殺蟲劑現(xiàn)象。在測試中的表現(xiàn)為：

(1)測試工作開展一段時間后，會出現(xiàn)找不到問題的現(xiàn)象，那么是真的沒有問題了嗎？不是，而是出了殺蟲劑現(xiàn)象。即：測試方法和思路需要更新了，因?yàn)橐环N思路下的大部分問題可能已經(jīng)被發(fā)現(xiàn)了。

(2)換一個測試執(zhí)行人員或者換一個測試設(shè)計人員，即：換一種殺蟲劑，問題就會再次出現(xiàn)。所以產(chǎn)品在進(jìn)行回歸測試的時候，最好要更換部分測試人員，避免殺蟲劑現(xiàn)象。215.并非所有的軟件缺陷都能修復(fù)

由于各種客觀條件的限制，軟件缺陷被發(fā)現(xiàn)后，不能都被修復(fù)，或者開發(fā)人員不認(rèn)同是軟件缺陷，認(rèn)為不值得修復(fù)。碰到這種情況怎么辦呢？這就需要分析：

(1)什么樣的缺陷客戶可以忍受？

(2)什么樣的缺陷可以延遲到發(fā)布之后去打補(bǔ)??？226.難以說清的軟件缺陷

軟件測試的復(fù)雜性，很大一部分原因是由于標(biāo)準(zhǔn)不明確和不統(tǒng)一，表現(xiàn)在：

(1)測試人員判斷一個缺陷，是以產(chǎn)品說明書（需求說明書）為標(biāo)準(zhǔn)，而產(chǎn)品說明書的需求是要分解成為測試需求后，才能作為測試工作判斷缺陷的標(biāo)準(zhǔn)的，這個轉(zhuǎn)化過程會有人為理解因素，需要經(jīng)過開發(fā)和測試人員確認(rèn)后，方可實(shí)行。

(2)最壞的情況是，測試工作開展后，產(chǎn)品說明書還沒有以書面形式定稿，那么測試工作的難度又加大了。237.產(chǎn)品說明書不斷變化

有了書面形式的產(chǎn)品說明書，測試工作可以正常開展，但是不要期望產(chǎn)品說明書是不變的，不變是軟件工程追求的目標(biāo)，但實(shí)際工作中都會有所變化，變動或大或小，這要看需求分析階段的工作質(zhì)量。為了應(yīng)對這種變化，測試計劃應(yīng)留有一定的應(yīng)變時間，這是測試經(jīng)理主要負(fù)責(zé)的工作，但是作為測試人員也要有心理準(zhǔn)備，即：測試工作中也要貫徹二八定律。248.軟件測試人員不受歡迎

挑毛病的人是不受歡迎的，怎么辦呢？

(1)測試人員要在工作中積累經(jīng)驗(yàn)，善于溝通，講究提缺陷的技巧。例如，盡早找出軟件缺陷，使改動和影響范圍更小，降低開發(fā)人員修復(fù)缺陷的工作量；控制情緒，不要帶有輕視、嘲笑的感情色彩報告軟件缺陷；

(2)不要總是報告壞消息，還要在溝通中對開發(fā)人員代碼質(zhì)量的提高給予肯定和夸獎，在報告壞消息前，先要報告好消息。259.2.5軟件測試模型

軟件測試最典型的測試模型是V模型，另外還有X模型、H模型、前置模型和測試驅(qū)動模型等等。模型是理論研究的成果，可以指導(dǎo)實(shí)際工作，但是不能完全照搬。

V模型左側(cè)是開發(fā)階段，右側(cè)是測試階段。開發(fā)階段先從定義軟件需求開始，然后要把這些需求不斷地轉(zhuǎn)換到概要設(shè)計和詳細(xì)設(shè)計中去，最后形成程序代碼。測試階段是在代碼編寫完成以后，先作單元測試開始，然后是集成測試、系統(tǒng)測試和驗(yàn)收測試。26軟件測試V模型2728X測試模型V模型的功勞是：提高了測試工作和測試人員的地位。因?yàn)閂模型也沒能體現(xiàn)出測試設(shè)計、測試回溯的過程，基于這種思想，出現(xiàn)了X測試模型。同學(xué)們也可提出其他測試模，例如O模型，它可以表達(dá)回歸測試的思想。2930X測試模型X模型的左邊描述的是針對單獨(dú)程序片段所進(jìn)行的相互分離的編碼和測試，此后將進(jìn)行頻繁的交接，通過集成最終合成為可執(zhí)行的程序。

X模型右上方還定位了已通過集成測試的成品可以進(jìn)行封版并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個部分發(fā)生。

X模型右下方還定位了探索性測試。這是不進(jìn)行事先計劃的特殊類型的測試，這一方式往往能幫助有經(jīng)驗(yàn)的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件錯誤。31軟件測試模型(續(xù))

不管按照什么模型進(jìn)行軟件測試，根據(jù)“五個面向”的實(shí)施理論，在本質(zhì)上說，所有的測試都是面向功能的，即測試軟件產(chǎn)品是否滿足客戶的功能需求，這里的功能需求是廣義的，它包括功能、性能、接口和界面等需求。白盒測試如此，黑盒測試更如此。靜態(tài)測試如此，動態(tài)測試更如此。單元測試如此，集成測試更如此。系統(tǒng)測試如此，驗(yàn)收測試更如此！32-軟件工程講義--33-測試用例設(shè)計測試用例（testcase）設(shè)計的基本目的：是確定一組最有可能發(fā)現(xiàn)某個錯誤或某類錯誤的數(shù)據(jù)。無論是黑盒子，還是白盒子測試都不可能進(jìn)行窮舉測試。所以，測試用例的設(shè)計只能在周期和經(jīng)費(fèi)允許的條件下，使用最少數(shù)目的測試，發(fā)現(xiàn)最大數(shù)目可能的錯誤在實(shí)際工作中，一般都采用黑盒子與白盒子相結(jié)合的技術(shù)，可以選取并測試數(shù)量有限的重要邏輯路經(jīng)，對一些重要數(shù)據(jù)結(jié)構(gòu)的正確性進(jìn)行完全的檢查。這樣，不只證實(shí)軟件接口的正確性，同時在某種程度上保證軟件內(nèi)部工作也是正確的9.2.6軟件測試的分類1．靜態(tài)測試：不通過運(yùn)行程序來開展測試工作。這里并不局限于直接閱讀、檢測代碼，還包括閱讀和檢測文檔。

2．動態(tài)測試：通過運(yùn)行程序開展測試工作，即軟件測試人員通過使用軟件來找出問題，它包括白盒測試與黑盒測試。

3.白盒測試：基于程序執(zhí)行路徑的測試。

4．黑盒測試：又叫功能測試。盒子指的是被測試的軟件，“黑盒”就是只知道被測軟件的外部情況，被測軟件的內(nèi)部邏輯結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)，對測試人員是不可見的。這是基于規(guī)格說明書的測試。34黑盒測試

因?yàn)闇y試建立在模塊間的接口上，所以多采用黑盒測試，適當(dāng)輔以白盒測試，以便能對主要的控制路徑進(jìn)行測試。黑盒測試主要檢查以下錯誤：

(1)功能不正確或者被遺漏;(2)界面錯誤;(3)數(shù)據(jù)結(jié)構(gòu)或者外部數(shù)據(jù)庫訪問錯誤;(4)性能錯誤;(5)初始化或者終止錯誤.35幾種黑盒測試技術(shù)(1)等價分類法定義：把程序的輸入數(shù)據(jù)集合,按輸入條件劃分為若干個等價類，每一等價類的一個代表值在測試中的作用，等價于這一類的其他值的測試。優(yōu)點(diǎn)：減少測試工作量。36(1).等價分類法(續(xù))1).采用等價類劃分技術(shù)設(shè)計測試用例分兩步：1.劃分等價類2.確認(rèn)測試用例2）等價類的劃分方法：根據(jù)輸入條件，把輸入數(shù)據(jù)劃分為等價類，并定義有效等價類，無效等價類。

例1：如果輸入值的范圍是從1到999，則：1<=有效等價類<=999，兩個無效等價類為小于1和大于999。例2：如果一個輸入條件說明標(biāo)識符的第一個字符必須是字母，則可劃分一個有效等價類(第一字符是字母)，和一個無效等價類(第一字符不是字母)。37-軟件工程講義--38-2.確認(rèn)測試用例根據(jù)等價類設(shè)計測試用例。有三步：（1）給每個等價類規(guī)定一個唯一的編號（2）設(shè)計一個新的測試用例，使其盡可能多地覆蓋未被覆蓋過的合理等價類。此項(xiàng)工作重復(fù)進(jìn)行，直到所有的合理等價類都被覆蓋為止（3）設(shè)計一個新的測試用例，使其覆蓋一個、且僅一個未被覆蓋過的不合理等價類。此項(xiàng)工作同樣進(jìn)行到所有不合理等價類都被覆蓋為止第三點(diǎn)之所以要這樣做是因?yàn)槟承┏绦驅(qū)δ骋惠斎脲e誤的檢查會屏蔽檢查其它輸入錯誤-軟件工程講義--39-示例（1）三角形分類程序程序讀入三個整型數(shù)據(jù)值（A、B、C），表示三角形的三個邊。按照等邊、等腰、不等邊和非三角形的要求，把它們分類輸出-軟件工程講義--40-示例（2）：合理的用例輸入數(shù)據(jù)-軟件工程講義--41-示例（3）：不合理的用例輸入數(shù)據(jù)這里還應(yīng)該進(jìn)行極大值和極小值的測試(2).邊界值分析法邊界值分析方法是對等價類劃分方法的補(bǔ)充。經(jīng)驗(yàn)證明：使用正好等于、小于或大于邊界值的數(shù)據(jù)，對程序進(jìn)行測試，發(fā)現(xiàn)錯誤的概率比較大所以，在設(shè)計測試用例時，應(yīng)選擇一些邊界值，這就是邊界值分析的測試技術(shù)例：輸入三個正整數(shù)，表示三角形三個邊。其中任意兩個數(shù)之和應(yīng)大于第三個數(shù)。如果使用等價劃分，至少可以找出兩個等價類：一個滿足上述條件的合理等價類；一個兩數(shù)之和不大于第三個數(shù)的不合理的等價類

A=3,B=4,C=5；A=1,B=2,C=4但是，這里卻忽視了極易出現(xiàn)的錯誤：如把A+B>C錯誤地寫成A+B≥C，上述兩組測試數(shù)據(jù)均無法發(fā)現(xiàn)。從此例可見邊界值分析的必要性A=1,B=2,C=3這組數(shù)據(jù)可以發(fā)現(xiàn)上述錯誤42(2).邊界值分析法

1）.如果輸入條件規(guī)定了值的范圍,則應(yīng)取剛達(dá)到這個范圍的邊界的值,以及剛剛超越這個范圍邊界的值作為測試輸入數(shù)據(jù).2）.如果輸入條件規(guī)定了值的個數(shù),則用最大個數(shù),最小個數(shù),比最小個數(shù)少1,比最大個數(shù)多1的數(shù)作為測試數(shù)據(jù).3）.如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合,則應(yīng)選取集合的第一個元素和最后一個元素作為測試用例.4）.如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu),則應(yīng)當(dāng)選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試用例.5）.分析規(guī)格說明,找出其它可能的邊界條件.43(3).因果圖法借助因果圖，列出輸入數(shù)據(jù)的各種組合與程序?qū)?yīng)動作效果之間的階段聯(lián)系，構(gòu)造判定表，由此設(shè)計測試用例。它利用條件與對應(yīng)動作之間的邏輯關(guān)系，著重檢查各輸入條件的組合。例如：兩個輸入值的乘積超過了存儲的限制，程序發(fā)生錯誤。等價劃分和邊界值分析，都不能發(fā)現(xiàn)這類錯誤。因?yàn)樗鼈兙纯紤]輸入情況的各種組合因果圖的基本原理是通過畫因果圈圈圖把用自然語言描述的功能說明轉(zhuǎn)換為判定表最后為判定表的每一列設(shè)計一個測試用例44(3).因果圖法因果圖生成測試用例的步驟如下：

1).分析設(shè)計規(guī)格說明中的原因（輸入條件或者輸入條件等價類）、效果（輸出可能性），對每個原因效果進(jìn)行編號；

2).找出原因/效果之間的對應(yīng)關(guān)系，畫出因果圖；

3).將因果圖轉(zhuǎn)換為判定表；

4).對判定表中每一列生成測試用例。45-軟件工程講義--46-因果圖的符號表示-軟件工程講義--47-示例（1）:電費(fèi)帳單例：定義四種原因：“1”住宅電表“2”工業(yè)電表“3”峰值用電量≥1000kwh“4”非峰值用電量≥1000kwh根據(jù)不同原因組合，可排出下列效果：“101”按標(biāo)準(zhǔn)A收費(fèi)“102”按標(biāo)準(zhǔn)B收費(fèi)“103”按標(biāo)準(zhǔn)C收費(fèi)-軟件工程講義--48-示例（2）：電費(fèi)帳單因果圖(4).錯誤推測法

錯誤推測法基于經(jīng)驗(yàn)和直覺，推測程序中所有可能存在的各種錯誤,從而有針對性的設(shè)計測試用例。例如，如輸入數(shù)據(jù)為0，或輸出數(shù)據(jù)為0是容易發(fā)生錯誤的情形，因此可選擇輸入數(shù)據(jù)為0，或使輸出數(shù)據(jù)為0的例子作為測試用例。又如，輸入表格為空或輸入表格只有一行，也是容易發(fā)生錯誤的情況?？蛇x擇表示這種情況的例子作為測試用例。再如，若兩個模塊間有共享變量，則要設(shè)計測試用例檢查：當(dāng)讓一個模塊去修改這個共享變量的內(nèi)容后，另一個模塊的出錯情況等等

。49白盒測試技術(shù)

可以理解為基于代碼的或程序執(zhí)行路徑的測試。白盒測試還有多種叫法，如：玻璃盒測試（GlassBoxTesting）透明盒測試（ClearBoxTesting）開放盒測試（OpenBoxTesting）基于代碼的測試（Code-BasedTesting）邏輯驅(qū)動測試（Logic-DriverTesting）。測試人員進(jìn)行白盒測試之前，必須清楚軟件的內(nèi)部邏輯結(jié)構(gòu)和執(zhí)行路徑，然后根據(jù)它們展開測試的。50白盒測試技術(shù)(續(xù))

白盒測試原則：

a.保證模塊中每一個獨(dú)立的路徑至少執(zhí)行一次。

b.保證所有判斷的每一個分支至少執(zhí)行一次。

c.保證每一個循環(huán)都在邊界條件和一般條件下至少執(zhí)行一次。

d.驗(yàn)證所有內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性。白盒測試技術(shù)：

(1)邏輯覆蓋測試它以程序的內(nèi)部邏輯結(jié)構(gòu)為基礎(chǔ),設(shè)計如下測試用例：

a.語句覆蓋

b.判定(分支)覆蓋

c.條件覆蓋

d.判定---條件覆蓋

e.多重覆蓋等51語句覆蓋要實(shí)現(xiàn)DoWork函數(shù)的語句覆蓋，只需設(shè)計一個測試用例就可以覆蓋程序中的所有可執(zhí)行語句。測試用例輸入為：{x=4、y=5、z=5}程序執(zhí)行的路徑是：abd分析：語句覆蓋可以保證程序中的每個語句都得到執(zhí)行，但發(fā)現(xiàn)不了判定中邏輯運(yùn)算的錯誤，即它并不是一種充分的檢驗(yàn)方法。例如在第一個判定((x>3)&&(z<10))中把“&&”錯誤的寫成了“||”，這時仍使用該測試用例，則程序仍會按照流程圖上的路徑abd執(zhí)行?？梢哉f語句覆蓋是最弱的邏輯覆蓋準(zhǔn)則。判定(分支)覆蓋要實(shí)現(xiàn)DoWork函數(shù)的判定覆蓋，需要設(shè)計兩個測試用例。測試用例的輸入為：{x=4、y=5、z=5}；{x=2、y=5、z=5}程序執(zhí)行的路徑分別是：abd；ace分析：上述兩個測試用例不僅滿足了判定覆蓋，同時還做到語句覆蓋。從這點(diǎn)看似乎判定覆蓋比語句覆蓋更強(qiáng)一些，但仍然無法確定判定內(nèi)部條件的錯誤。例如把第二個判定中的條件y>5錯誤寫為y<5，使用上述測試用例，照樣能按原路徑執(zhí)行而不影響結(jié)果。因此，需要有更強(qiáng)的邏輯覆蓋準(zhǔn)則去檢驗(yàn)判定內(nèi)的條件。判定(分支)覆蓋（續(xù)）16352789410說明：以上僅考慮了兩出口的判斷，我們還應(yīng)把判定覆蓋準(zhǔn)則擴(kuò)充到多出口判斷（如Case語句）的情況。因此，判定覆蓋更為廣泛的含義應(yīng)該是使得每一個判定獲得每一種可能的結(jié)果至少一次。條件覆蓋在實(shí)際程序代碼中，一個判定中通常都包含若干條件。條件覆蓋的目的是設(shè)計若干測試用例，在執(zhí)行被測程序后，要使每個判定中每個條件的可能值至少滿足一次。對DoWork函數(shù)的各個判定的各種條件取值加以標(biāo)記。對于第一個判定((x>3)&&(z<10))： 條件x>3取真值記為T1，取假值記為-T1

條件z<10取真值記為T2，取假值記為-T2對于第二個判定((x==4)||(y>5))：條件x==4取真值記為T3，取假值記為-T3條件y>5取真值記為T4，取假值記為-T4條件覆蓋（續(xù)）根據(jù)條件覆蓋的基本思想，要使上述4個條件可能產(chǎn)生的8種情況至少滿足一次，設(shè)計測試用例如下：測試用例執(zhí)行路徑覆蓋條件覆蓋分支x=4、y=6、z=5abdT1、T2、T3、T4bdx=2、y=5、z=15ace-T1、-T2、-T3、-T4ce分析：上面這組測試用例不但覆蓋了4個條件的全部8種情況，而且將兩個判定的4個分支b、c、d、e也同時覆蓋了，即同時達(dá)到了條件覆蓋和判定覆蓋。條件覆蓋（續(xù)）說明：雖然前面的一組測試用例同時達(dá)到了條件覆蓋和判定覆蓋，但是，并不是說滿足條件覆蓋就一定能滿足判定覆蓋。如果設(shè)計了下表中的這組測試用例，則雖然滿足了條件覆蓋，但只是覆蓋了程序中第一個判定的取假分支c和第二個判定的取真分支d，不滿足判定覆蓋的要求。測試用例執(zhí)行路徑覆蓋條件覆蓋分支x=2、y=6、z=5acd-T1、T2、-T3、T4cdx=4、y=5、z=15acdT1、-T2、T3、-T4cd判定(分支)/條件覆蓋判定/條件覆蓋實(shí)際上是將判定覆蓋和條件覆蓋結(jié)合起來的一種方法，即：設(shè)計足夠的測試用例，使得判定中每個條件的所有可能取值至少滿足一次，同時每個判定的可能結(jié)果也至少出現(xiàn)一次。根據(jù)判定/條件覆蓋的基本思想，只需設(shè)計以下兩個測試用例便可以覆蓋4個條件的8種取值以及4個判定分支。測試用例執(zhí)行路徑覆蓋條件覆蓋分支x=4、y=6、z=5abdT1、T2、T3、T4bdx=2、y=5、z=15ace-T1、-T2、-T3、-T4ce判定(分支)/條件覆蓋（續(xù)）分析：從表面上看，判定/條件覆蓋測試了各個判定中的所有條件的取值，但實(shí)際上，編譯器在檢查含有多個條件的邏輯表達(dá)式時，某些情況下的某些條件將會被其它條件所掩蓋。因此，判定/條件覆蓋也不一定能夠完全檢查出邏輯表達(dá)式中的錯誤。例如：對于第一個判定(x>3)&&(z<10)來說，必須x>3和z<10這兩個條件同時滿足才能確定該判定為真。如果x>3為假，則編譯器將不再檢查z<10這個條件，那么即使這個條件有錯也無法被發(fā)現(xiàn)。對于第二個判定(x==4)||(y>5)來說，若條件x==4滿足，就認(rèn)為該判定為真，這時將不會再檢查y>5，那么同樣也無法發(fā)現(xiàn)這個條件中的錯誤。-軟件工程講義--60-邏輯覆蓋：示例例：Pascal程序：PROCEDURE（VARA，B，X：REAL）BEGIN IF（A>1）AND（B=O）

THENX:=X/A;IF（A=2）OR（X>1）

THENX:=X+1END.-軟件工程講義--61-1.語句覆蓋設(shè)計的用例能使程序中的每條語句至少執(zhí)行一次。如設(shè)計一條能通過路徑ace的測試用例：A=2，B=0，X=3-軟件工程講義--62-2.分支覆蓋使程序中每個分支至少有一次“真值”和一次“假值”，或每個分支都至少通過一次。如能通過路徑acd和abe；可選擇以下兩組數(shù)據(jù):A=3,B=0,X=1（acd）A=2,B=1,X=3（abe）-軟件工程講義--63-3.條件覆蓋（1）能使分支中的各個條件的所有可能的情況都至少執(zhí)行一次四個條件：

A>1,B=0,A=2,X>1測試用例：a點(diǎn)

A>1,A≤1,B=0,B≠0b點(diǎn)

A=2,A≠2,X>1,X≤1可選擇以下兩組數(shù)據(jù)：

A=2,B=0,X=4（ace）

A=1,B=1,X=1（abd）-軟件工程講義--64-條件覆蓋（2）條件覆蓋的問題：當(dāng)測試語句為：IF（AANDB）THENS時，一般可設(shè)計兩種測試用例：A為“真”，B為“假”；A為“假”，B為“真”；但這兩組測試用例，都不能使IF語句中的子句THENS執(zhí)行。有時候選擇的兩組數(shù)據(jù)，在滿足條件覆蓋的同時，也滿足了分支覆蓋。然而，這只是一種巧合-軟件工程講義--65-4.分支/條件覆蓋（1）為解決上述問題，提出了分支/條件覆蓋這種覆蓋所要求的測試用例，是使分支中的每個條件的所有結(jié)果至少出現(xiàn)一次，同時使各分支本身的所有可能結(jié)果也至少出現(xiàn)一次在條件覆蓋中選擇的兩組數(shù)據(jù)：

A=2，B=0，X=4 A=1，B=1，X=1是滿足分支/條件覆蓋要求的分支/條件覆蓋好像是測試了所有條件的所有結(jié)果，實(shí)際上并非如此。因?yàn)榇蠖鄶?shù)計算機(jī)不能用一條指令對多個條件進(jìn)行判定，而必須把源程序中的多個條件的判定分解為幾個簡單的判定。所以徹底的分支/條件測試覆蓋，應(yīng)使每一個簡單判定的所有可能結(jié)果都至少真正出現(xiàn)一次-軟件工程講義--66-分支/條件覆蓋（2）上例流程圖經(jīng)編譯產(chǎn)生的目標(biāo)程序流程圖-軟件工程講義--67-分支/條件覆蓋（3）分支/條件覆蓋中的兩組測試數(shù)據(jù)均不可能使目標(biāo)程序中的簡單判定得到所有可能的結(jié)果分支覆蓋測試數(shù)據(jù)：

A=3,B=0,X=1 A=2,B=1,X=3它們不能使判定h為“假”，也不能使判定k為“真”條件覆蓋測試數(shù)據(jù)：

A=2,B=0,X=4 A=1,B=1,X=1不能使判定i為“假”，也不能使判定k為“真”。這是因?yàn)樵凇芭c”或“或”的邏輯表達(dá)式中，某些條件掩蓋了其它條件。如在“與”的邏輯表達(dá)式中，若某一條件為“假”，則這個表達(dá)式中隨后的幾個條件就不再進(jìn)行檢查了-軟件工程講義--68-5.多重覆蓋（1）這是鑒于分支/條件覆蓋存在的問題提出的，是使各判定中條件的所有可能組合都至少出現(xiàn)一次只要滿足了多重覆蓋，就一定滿足分支、條件和分支/條件覆蓋要滿足多重覆蓋，設(shè)計的測試用例就必須滿足以下八種組合： （1）A>1,B=0； （5）A=2,X>1； （2）A>1,B≠0； （6）A=2,X≤1； （3）A≤1,B=0； （7）A≠2,X>1； （4）A≤1,B≠0； （8）A≠2,X≤1。注意：第二個IF語句的四種組合（（5）-（8）），其中X值在該IF語句之前已經(jīng)過計算，所以必須算出入口處相應(yīng)的輸入值X-軟件工程講義--69-多重覆蓋（2）要測試上述八種組合結(jié)果可采用以下四組數(shù)據(jù)：

A=2，B=0，X=4覆蓋（1）、（5）；

A=2，B=1，X=1覆蓋（2）、（6）；

A=1，B=0，X=2覆蓋（3）、（7）；

A=1，B=1，X=1覆蓋（4）、（8）。上例程序中，有四條路徑，這里有四組測試用例，這僅僅是巧合。實(shí)際上，這四組測試數(shù)據(jù)并沒有覆蓋每一條路徑。如acd就未能走過白盒測試技術(shù)(續(xù))循環(huán)測試注重循環(huán)結(jié)構(gòu)的有效性。存在三種循環(huán)測試

a.簡單循環(huán)測試。

b.嵌套循環(huán)測試。

c.串接循環(huán)測試?；韭窂綔y試基本思想是：以軟件過程性描述為基礎(chǔ)，通過分析它的控制流程計算復(fù)雜度，導(dǎo)出基本路徑集合，并設(shè)計一組測試用例，確保程序中的每個語句至少執(zhí)行一次，每條路徑都通過一次。70-軟件工程講義--71-循環(huán)覆蓋主要用來檢查循環(huán)構(gòu)造們的有效性?？煞炙念悾?軟件工程講義--72-簡單循環(huán)簡單循環(huán)（simpleloops）可用下面測試集：（1）跳過整個循環(huán)（2）只通過循環(huán)一次（3）通過循環(huán)兩次（4）通過循環(huán)m次，其中m<n（5）通過循環(huán)n-1、n、n+1次-軟件工程講義--73-嵌套（串接）循環(huán)如果把單循環(huán)的測試方法擴(kuò)展到嵌套循環(huán)（nestedloops），那么可能的測試次數(shù)會隨著嵌套層次數(shù)的遞增而呈幾何級數(shù)增長，這是一個不實(shí)際的測試次數(shù)Beizer提出了一種有利于減少次數(shù)的方法：（1）從最內(nèi)層的循環(huán)開始，將其它循環(huán)設(shè)為最小值。（2）保持外層循環(huán)處于它的最小重復(fù)參數(shù)（循環(huán)計數(shù)器）值，對最內(nèi)層進(jìn)行單循環(huán)測試增加其它范圍以外或排斥（excluded）值的測試。（3）從里向外進(jìn)行下一層的循環(huán)測試，但仍要保持所有外層循環(huán)處于最小值，而其它嵌套循環(huán)處于一般值。（4）照此進(jìn)行，直到所有循環(huán)測試完畢-軟件工程講義--74-串聯(lián)循環(huán)如果串聯(lián)循環(huán)（concatenatedloops）的每個循環(huán)相互獨(dú)立，則可用單循環(huán)方法測試。如果，兩個循環(huán)串聯(lián)，而且循環(huán)1的循環(huán)計數(shù)器是循環(huán)2的初始值，則它們是非獨(dú)立的。當(dāng)循環(huán)不是獨(dú)立時，可采用嵌套循環(huán)的測試方法來進(jìn)行非結(jié)構(gòu)化循環(huán)，如果可能，這類循環(huán)應(yīng)采用結(jié)構(gòu)化的構(gòu)造來重新設(shè)計【例9-3】假設(shè)一個程序需要3個整數(shù)型的輸入數(shù)據(jù)，計算機(jī)的字長為16位，則每個整數(shù)可能取值的個數(shù)有216。3個輸入數(shù)據(jù)的排列組合數(shù)為216×216×216個，216×216×216≈3×1014

這就是說，這個程序執(zhí)行的次數(shù)達(dá)到了3×1014

，才能做到有窮測試。如果程序每執(zhí)行1次需要1毫秒，那么也需要運(yùn)行10000年時間。若將無效的和錯誤的數(shù)據(jù)輸入也計算在內(nèi)，則程序的運(yùn)行時間還要長。一萬年太久，誰受得了這種測試！那么，對于這種程序，到底該怎么測試呢？比較好的辦法是以靜態(tài)代碼測試為主，即用“順序、選擇(if-then-else)、循環(huán)(do-while或do-until)”3種基本結(jié)構(gòu)，一行一行地分析測試其源程序，因?yàn)殪o態(tài)代碼測試能發(fā)現(xiàn)約60%的錯誤。與此同時，以白盒子測試為輔，選擇幾條典型的程序路徑進(jìn)行測試。75白盒測試技術(shù)(續(xù))白盒測試的優(yōu)點(diǎn)是：迫使測試人員去仔細(xì)思考軟件的實(shí)現(xiàn)。可以檢測代碼中的每條分支和路徑。揭示隱藏在代碼中的錯誤。對代碼的測試比較徹底。白盒測試的缺點(diǎn)是：無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤。不驗(yàn)證規(guī)格的正確性。76灰盒測試

在白盒測試中交叉使用黑盒測試的方法；在黑盒測試中交叉使用白盒測試的方法?；液袦y試就是這類介于白盒測試和黑盒測試之間的測試。宏觀上用黑盒子測試，微觀上用白盒子測試，測試員用黑盒子測試，程序員用白盒子測試，這就是常用的測試方法。

77通過測試簡單說就是驗(yàn)證軟件至少能做什么，而不會考驗(yàn)其能力有多強(qiáng)。把握這個思想，設(shè)計通過測試的測試案例時，就是設(shè)計最通常的數(shù)據(jù)，能證明其正確實(shí)現(xiàn)了某個功能就可以，不用挖空心思給出破壞性數(shù)據(jù)。失敗測試純粹是為了驗(yàn)證軟件在某一條件下，是否會出現(xiàn)異常、停止工作等現(xiàn)象而進(jìn)行的測試。所以做失敗測試時，設(shè)計的測試用例叫做失敗測試用例，執(zhí)行失敗測試用例的過程，叫做失敗測試或者叫做迫使出錯測試。進(jìn)行失敗測試的指導(dǎo)思想，是找出軟件薄弱環(huán)節(jié)，蓄意攻擊（病毒程序就是比較好的失敗測試用例?。?8負(fù)載/壓力測試一方面，可以通過減少軟件需要的資源（內(nèi)存、磁盤空間、網(wǎng)絡(luò)資源等），來測試出軟件運(yùn)行的最低配置或最低資源需求；另一方面，可以正常提供軟件需要的資源，但是通過不斷加重軟件要處理的任務(wù)，來測試軟件在正常配置下能夠具有的能力指標(biāo)。在軟件測試V模型中，按照測試過程又可以分出單元測試、集成測試、系統(tǒng)測試和驗(yàn)收測試四種測試類型。79易用性測試易用性涉及的范圍也比較廣，例如安裝易用性、功能易用性、界面易用性，甚至是針對聽力、視覺、運(yùn)動和認(rèn)知有缺陷的客戶，軟件體現(xiàn)出的易用性等等。邊界值測試專門針對軟件需要從外界（客戶、接口程序）獲取數(shù)據(jù)的地方，提供數(shù)據(jù)的邊界值，驗(yàn)證程序是否對邊界值進(jìn)行正確或合理的處理。80兼容性測試可以測試軟件與軟件之間的兼容性。例如軟件與操作系統(tǒng)、數(shù)據(jù)庫、中間件、瀏覽器和其他支撐軟件的兼容性，同一軟件不同版本之間的兼容性，同一類軟件對不同數(shù)據(jù)格式的兼容性等等。還可以測試軟件與硬件之間的兼容性。例如軟件與CPU、主版、顯卡、聲卡等硬件的兼容性。進(jìn)行兼容性測試時，需要對軟硬件環(huán)境有一個規(guī)劃，是購買軟硬件建立測試實(shí)驗(yàn)室，還是臨時租用。如果選擇成立專門測試實(shí)驗(yàn)室，那么對實(shí)驗(yàn)環(huán)境的規(guī)劃、維護(hù)、分配和管理也很重要。81回歸測試在軟件發(fā)生修改之后，重新執(zhí)行原有已經(jīng)執(zhí)行過的測試用例，以保證修改的正確性，為此目的開展的測試工作稱為回歸測試。理論上，任何時候更改軟件后，都可以進(jìn)行回歸測試，驗(yàn)證以前發(fā)現(xiàn)和修復(fù)的錯誤是否在新軟件版本上再現(xiàn)，但是實(shí)際測試過程中，只有軟件版本相對穩(wěn)定后，執(zhí)行回歸測試的可行性和效率才最高。82Alpha測試有開發(fā)人員或者測試人員在場，客戶在開發(fā)環(huán)境下使用軟件，也稱為受控測試。實(shí)際工作中，客戶也可以由公司內(nèi)部的員工充當(dāng)，但不能由程序員或者測試人員。進(jìn)行Alpha測試，主要是保證軟件發(fā)布之前，從客戶（非軟件專業(yè)人員）的角度再試圖發(fā)現(xiàn)一些潛在的bug。Beta測試所謂Beta測試，就是將軟件的Beta版本交給大量典型客戶，由他們從客戶的角度出發(fā)，在實(shí)際環(huán)境中使用軟件（沒有開發(fā)人員和測試人員做指導(dǎo)）。軟件開發(fā)商搜集客戶的反饋信息后，對Beta版本進(jìn)行改進(jìn)，改進(jìn)后再由測試部門進(jìn)行回歸測試，通過后對外發(fā)布正式版本。83-軟件工程講義--84-9.2.7軟件測試的過程和步驟（一）軟件測試過程-軟件工程講義--85-（二）軟件測試步驟-軟件工程講義--86-（三）單元測試單元測試（unittesting）檢查軟件設(shè)計的最小單元（模塊），是以詳細(xì)過程設(shè)計為依據(jù)，對重要的控制路徑進(jìn)行測試，用以發(fā)現(xiàn)邏輯結(jié)構(gòu)中的錯誤。單元測試主要使用白盒子測試、多個模塊可以同時平行測試。單元測試是針對模塊的，它不是一個獨(dú)立的程序。因此，模塊自己不能運(yùn)行，要靠其它部分來調(diào)用或驅(qū)動。這樣就要為每個單元測試模塊設(shè)計兩個軟件：驅(qū)動（driver）程序和連接（stub）程序-軟件工程講義--87-（四）組裝測試組裝測試（integrationtesting）它是以結(jié)構(gòu)設(shè)計文檔為依據(jù)，把巳通過單元測試的模塊裝配在一起時進(jìn)行測試，主要用以發(fā)現(xiàn)與接口相關(guān)的錯誤組裝測試是用于軟件裝配的一種系統(tǒng)化的技術(shù)。它有自頂向下結(jié)合和自底向上結(jié)合兩種測試方法。自頂向下的結(jié)合又可分為先深度后寬度的方法和先寬度后深度的方法。自頂向下和自底向上兩種方法相比較，一種方法的優(yōu)點(diǎn)是另一種方法的缺點(diǎn)-軟件工程講義--88-示例：自頂向下和自底向上集成測試

集成測試是組裝軟件的系統(tǒng)測試技術(shù)，按設(shè)計要求,把通過單元測試的各個模塊組裝在一起之后,進(jìn)行綜合測試,以便發(fā)現(xiàn)與模塊接口有關(guān)的各種錯誤。集成測試的方法可以分為：

A.非增量式系統(tǒng)集成。

B.增量式系統(tǒng)集成。即一個個模塊逐步接入系統(tǒng)并進(jìn)行測試，也就是模塊一邊接入系統(tǒng)一邊測試，使系統(tǒng)逐步擴(kuò)大最后得到一個完整的系統(tǒng)。可以采用AB兩種方法的結(jié)合。89-軟件工程講義--90-（五）確認(rèn)測試確認(rèn)測試（validationtesting）它是以軟件需求規(guī)格說明文檔為依據(jù)，用以檢查軟件功能與用戶需求是否一致確認(rèn)測試另一項(xiàng)重要工作就是對軟件配置進(jìn)行評審，其目的在于保證軟件配置的所有程序和文檔正確、完整，而且兩者要一致-軟件工程講義--91-（六）驗(yàn)收測試驗(yàn)收測試（acceptancetests）不是由系統(tǒng)開發(fā)者，而是由最終用戶實(shí)施，用以保證所有需求有效α測試是一個用戶以開發(fā)者的身份來實(shí)施。在通常設(shè)置的情況下使用軟件，開發(fā)者通過用戶來觀察所開發(fā)的軟件，記錄下發(fā)生的錯誤和使用問題。α測試是在一個受控環(huán)境下進(jìn)行的β測試是軟件的最終用戶，以一個或多個用戶的身份進(jìn)行。與α測試不同的是開發(fā)者一般不在現(xiàn)場。因此，β測試是軟件不在開發(fā)巖者控制的環(huán)境下“活的”應(yīng)用。用戶記錄下存在β測試過程中遇到的所有問題，并在規(guī)定時間間隔內(nèi)，把這些問題通知開發(fā)者。開發(fā)者根據(jù)β測試中發(fā)現(xiàn)的問題，必須做出相應(yīng)的修改，然后才能給用戶準(zhǔn)備發(fā)布的軟件產(chǎn)品-軟件工程講義--92-（七）系統(tǒng)測試（1）系統(tǒng)測試（systemtesting）軟件只是計算機(jī)系統(tǒng)的一個元素，軟件最終要與其它系統(tǒng)元素相結(jié)合，進(jìn)行各種集成（integration）測試（主要發(fā)現(xiàn)各元素間的接口問題）和確認(rèn)測試（主要發(fā)現(xiàn)系統(tǒng)功能問題）這些軟件工程過程工作范圍以外的測試不是由軟件開發(fā)者來實(shí)施的，但是軟件開發(fā)者在軟件設(shè)計和測試過程中所采取的步驟，會極大的改善軟件在系統(tǒng)中（特別是大型系統(tǒng)）集成功能的可能性-軟件工程講義--93-系統(tǒng)測試（2）系統(tǒng)測試中出現(xiàn)的典型問題：是相互指責(zé)。為了避免這種無意義的“扯皮”，軟件工程人員名應(yīng)該預(yù)見到這些可能的“接口”問題。為了找出問題所在可采取以下措施:（1）設(shè)計錯誤-處理路徑，測試可能來自系統(tǒng)其它元素的所有信息。（2）進(jìn)行一組測試，模擬錯誤數(shù)據(jù)或在軟件接口處其它可能的錯誤（3）如果指責(zé)出現(xiàn)，可以記錄下測試的結(jié)果作為“證據(jù)”。（4）參與系統(tǒng)測試計劃的制定和設(shè)計，以保證軟件能得到充分的測試系統(tǒng)測試實(shí)際上是一系列不同的測試。其主要目的是：充分的運(yùn)行基于計算機(jī)的系統(tǒng)。雖然，每種測試都有自己的目的，但所有工作都應(yīng)該用來驗(yàn)證所有系統(tǒng)元素己經(jīng)恰當(dāng)?shù)乇患?，而且完成了所分配的功?軟件工程講義--94-系統(tǒng)測試類型（1）1.恢復(fù)測試（recoverytesting）許多基于計算機(jī)的系統(tǒng)，如果發(fā)生故障，系統(tǒng)必須能從故障中恢復(fù)過來，并在預(yù)定的時間間隔內(nèi)重新開始工作在某些情況下，一個系統(tǒng)必須能容忍故障，即處理故障必須不會導(dǎo)致整個系絕功能的終止。在另外一些情況下，一個系統(tǒng)的故障必須能自己在巳確定的時間間隔內(nèi)，或在嚴(yán)重的經(jīng)濟(jì)損失發(fā)生前被改正恢復(fù)測試是一種系統(tǒng)測試。它以不同的方式強(qiáng)使軟件出現(xiàn)故障，用來驗(yàn)證軟件能否恰當(dāng)?shù)赝瓿苫謴?fù)。如果，恢復(fù)是自動的（由系統(tǒng)自身完成），則重新初始化、檢測點(diǎn)設(shè)置、數(shù)據(jù)恢復(fù)，以及重新啟動等都是對其正確性的評價。如果恢復(fù)需要人員干預(yù)，則要估算出修復(fù)的平均時間，以便確定它是否能在可接受的限制范圍以內(nèi)-軟件工程講義--95-系統(tǒng)測試類型（2）2.安全性測試（securitytesting）任何管理敏感信息或產(chǎn)生能夠?qū)е禄谟嬎銠C(jī)系統(tǒng)非正常傷害活動，都是一種非正?；蚍欠ǖ那秩肽繕?biāo)。侵入可以包括很寬的活動范圍：可以看似游戲，實(shí)則企圖侵入系統(tǒng)的竊賊；也可以是為報復(fù)而侵入的不滿意雇員；還可以是為個人非法牟利而侵入的不誠實(shí)小人安全性測試就是試圖去驗(yàn)證建立在系統(tǒng)內(nèi)的預(yù)防機(jī)制，以防止來自非正常的侵入。也即不僅必須保證對來自正面的襲擊不受傷害，而且必須保證對來自側(cè)面或背面的襲擊也不受傷害在安全性測試過程中，測試者應(yīng)扮演期望侵入系統(tǒng)的個人角色，可充當(dāng)任何角色?？梢酝ㄟ^外部書寫的方式得到口令；可以用用戶設(shè)計的軟件去破壞巳構(gòu)造好的任何防御的襲擊系紇；可以破壞系統(tǒng)使其不能為他人服務(wù)；可以跳過侵入的恢復(fù)過程，而故意使系統(tǒng)出錯；也可以跳過找出系絕的入口鑰匙，而放過看到的不安全數(shù)據(jù)，等等。因此，為了安全測試能侵入系紇，必須給出足夠的時間和資源。系統(tǒng)設(shè)計者的角色為了能侵入系統(tǒng)所需的開銷，可能要比所得到的信息的價值-軟件工程講義--96-系統(tǒng)測試類型（3）3.強(qiáng)度測試（stresstesting）在先前的測試步驟中，正常的程序功能和性能都已得到充分的評價。強(qiáng)度測試則是對付那些非正常情況下的程序測試，看一看程序允許在什么樣的極端情況下仍不會出現(xiàn)錯誤！強(qiáng)度測試是在要求一個非正常數(shù)量、頻率或容量資源方式下運(yùn)行一個系統(tǒng)。如：（1）當(dāng)平均每秒出現(xiàn)1個或2個中斷的情況下，用每秒出現(xiàn)10個中斷對程序進(jìn)行測試。（2）把輸入數(shù)據(jù)的數(shù)量提高一個數(shù)量級來測試輸入功能會如何響應(yīng)。（3）運(yùn)行需要最大內(nèi)存或其它資源的測試用例。（4）在虛擬操作系統(tǒng)中，可以設(shè)計產(chǎn)生多次反復(fù)的測試用例。（5）對磁盤駐留數(shù)據(jù)設(shè)計產(chǎn)生過渡搜索的測試用例?？傊?，測試者應(yīng)想辦法破壞程序。-軟件工程講義--97-系統(tǒng)測試類型（4）4.性能測試（performancetesting）對于實(shí)時和嵌入式系統(tǒng)，其軟件雖然能提供所需功能，但卻不符合性能要求，這是不能接受的。性能測試就是測試軟件在被組裝進(jìn)系統(tǒng)的環(huán)境下運(yùn)行時的性能性能測試應(yīng)覆蓋測試過程的每一步。即使在單元層，單個模塊的性能也可以通過白盒子測試來評價，而不是等到所有系統(tǒng)元素完全組裝后，再確定系統(tǒng)的實(shí)際性能性能測試有時是與強(qiáng)度測試聯(lián)系在一起的，常常需要硬件和軟件的測試設(shè)備。也即通常需要在嚴(yán)格的方式下不變量資源的利用率（如處理器的周期）外部測試設(shè)備可以監(jiān)控運(yùn)行時間間隔，記錄它們發(fā)生的事件（如中斷），以及存在有規(guī)律的樣機(jī)的狀態(tài)。通過測試設(shè)備系統(tǒng)，測試者可以發(fā)現(xiàn)導(dǎo)致降級和系統(tǒng)可能故障的情況-軟件工程講義--98-測試與開發(fā)的關(guān)系9.2.8軟件質(zhì)量定義與軟件測試標(biāo)準(zhǔn)

國標(biāo)GB/T6583-ISO8404文件在《質(zhì)量管理與質(zhì)量保證術(shù)語》中對質(zhì)量的定義是“反映實(shí)體滿足明確的和隱含的需要的能力的特性的總和”。國標(biāo)GB/T18905-ISO14598文件在《軟件工程產(chǎn)品評價》中，質(zhì)量定義為“實(shí)體特性的總和，滿足明確或者隱含要求的能力”。通俗的講，軟件質(zhì)量的好壞，就是看軟件產(chǎn)品和需求說明書（關(guān)于產(chǎn)品功能、性能和接口的明確描述以及隱含要求）的符合程度。完全符合是最好的，少了也不好，多了也不好。99軟件測試相關(guān)的標(biāo)準(zhǔn)

標(biāo)準(zhǔn)名稱標(biāo)準(zhǔn)的主要內(nèi)容GB/T18905.1-2002（ISO/IEC14598-1：1999）軟件工程產(chǎn)品評價GB/T16260－1996（ISO/IEC9126：1991）信息技術(shù)軟件產(chǎn)品評價質(zhì)量特性及其使用指南GB/T17544－1998（ISO/IEC12119：1994）信息技術(shù)軟件包質(zhì)量要求和測試GB/T9388－88計算機(jī)軟件測試文件編制規(guī)范GB/T15532－1995計算機(jī)軟件單元測試1009.2.9軟件測試工具

目前，自動化軟件測試工具本身已經(jīng)初步形成了軟件領(lǐng)域的一個產(chǎn)業(yè)。只有單元測試的自動化測試工具，在IT企業(yè)比較常用。

IT企業(yè)的測試部門，不要對商業(yè)測試工具抱太大期望，還要設(shè)計與開發(fā)自己的測試工具。1019.2.10軟件測試文檔

軟件測試文檔包括兩部分：被測試文檔和測試文檔。提供給客戶的所有文檔都要經(jīng)過測試，從這個角度考慮，被測試的文檔還可能包括聯(lián)機(jī)幫助文檔、樣例、模板、常見問題解答、市場宣傳材料、授權(quán)/注冊登記表、客戶許可協(xié)議，以及包裝文字、圖片、標(biāo)簽、不干膠條等等。文檔測試工作看似簡單，但是容易被忽略。仔細(xì)分析起來，很多軟件問題都是由于文檔描述不清楚或有歧意造成的。文檔和代碼同樣重要！好的文檔可以復(fù)現(xiàn)代碼！提供各種文檔模板是提高文檔質(zhì)量的有效方法。102-軟件工程講義--103-9.2.11OO軟件測試*OO軟件測試的主要目標(biāo)與傳統(tǒng)軟件測試一樣，用最小的投入發(fā)現(xiàn)最大限度存在的錯誤。但由于OO軟件的特殊性質(zhì)，所以O(shè)O測試的內(nèi)容、策略和方法卻不完全相同:（1）OOA和OOD的評審與傳統(tǒng)軟件SA、SD相同，應(yīng)給出相應(yīng)的評審檢查表（2）OOP后單元和組裝測試策略必須作相應(yīng)的改變（3）測試用例設(shè)計必須能夠說明OO軟件特有的性質(zhì)-軟件工程講義--104-一、評審（OOA、OOD）因?yàn)镺OA、OOD階段所建立的OOA、OOD模型不能執(zhí)行，所以每次迭代之后一定要進(jìn)行評審：1.正確性（correctness）OO開發(fā)模式為演化（重復(fù)迭代）性質(zhì)，即系統(tǒng)的初期為非形式表示，以后發(fā)展為類的細(xì)節(jié)模型、類的連接和關(guān)聯(lián)、系統(tǒng)設(shè)計和配置，以及對類的設(shè)計（通過消息組成對象連接模型）。每一階段都要進(jìn)行評審正確性主要在分析和設(shè)計模型表示所使用的符號、語法是否正確？語義是否正確（即模型與真實(shí)世界領(lǐng)域是否一致）？以及類的關(guān)聯(lián)（實(shí)例間的聯(lián)系）是否正確的反映了真實(shí)世界對象間的關(guān)聯(lián)？2.一致性（consistency）由于演化性質(zhì)，OOA、OOD模型（包括分析設(shè)計和編碼層次（類、屬性、操作、消息））不僅要正確，而且要一致-軟件工程講義--105-二、測試：1.單元測試（1）與傳統(tǒng)軟件單元（模塊）不同，OO中的單元是類。每個類都封裝了屬性（數(shù)據(jù)）和管理這些數(shù)據(jù)的操作（也被叫為方法或服務(wù)）。一個類可以包含許多不同的操作，一個特殊的操作可以出現(xiàn)在許多不同的類中傳統(tǒng)的單元測試只能測試一個操作（功能）而OO單元測試中，一個操作功能只能作為一個類的一部分，類中有多個操作（功能）。因此，就要進(jìn)行多個操作的測試另外，父類中定義的某個操作被許多子類繼承。但在實(shí)際應(yīng)用中，不同子類中某個操作在使用時，又有一些細(xì)小的不同。所以還必須對每個子類中某個操作進(jìn)行測試。-軟件工程講義--106-單元測試（2）傳統(tǒng)軟件的單元測試主要關(guān)注模塊的算法細(xì)節(jié)和模塊接口間流動的數(shù)據(jù)；OO軟件的類測試是由封裝在類中的操作和類的狀態(tài)行為驅(qū)動的類的測試使用多種方法：基于故障的測試、隨機(jī)測試和分割測試等。每一種方法都要檢查封裝在類中的操作，即設(shè)計的測試序例（用例）要保證相關(guān)的操作被檢查到。因?yàn)椋惖膶傩灾当硎绢惖臓顟B(tài)，由此來確定被檢查的錯誤是否存在1075.5單元測試舉例1、如何使用VC6進(jìn)行單元測試產(chǎn)品類：

classCMyClass

{

public:

intAdd(inti,intj);

CMyClass();

virtual~CMyClass();

private:

intmAge;//年齡

CStringmPhase;//年齡階段，如"少年"，"青年"

};108建立對應(yīng)的測試類CMyClassTester，為了節(jié)約編幅，只列出源文件的代碼：

voidCMyClassTester::CaseBegin()

{

//pObj是CMyClassTester類的成員變量，是被測試類的對象的指針，

//為求簡單，所有的測試類都可以用pObj命名被測試對象的指針。

pObj=newCMyClass();

}

voidCMyClassTester::CaseEnd()

{

deletepObj;

}

測試類的函數(shù)CaseBegin()和CaseEnd()建立和銷毀被測試對象，每個測試用例的開頭都要調(diào)用CaseBegin()，結(jié)尾都要調(diào)用CaseEnd()。109接下來，我們建立示例的產(chǎn)品函數(shù)：

intCMyClass::Add(inti,intj)

{

returni+j;

}

和對應(yīng)的測試函數(shù)：

voidCMyClassTester::Add_int_int()

{

}

把參數(shù)表作為函數(shù)名的一部分，這樣當(dāng)出現(xiàn)重載的被測試函數(shù)時，測試函數(shù)不會產(chǎn)生命名沖突。110添加測試用例：

voidCMyClassTester::Add_int_int()

{

//第一個測試用例

CaseBegin();{//1

inti=0;//2

intj=0;//3

intret=pObj->Add(i,j);//4

ASSERT(ret==0);//5

}CaseEnd();//6

}

第1和第6行建立和銷毀被測試對象，所加的{}是為了讓每個測試用例的代碼有一個獨(dú)立的域，以便多個測試用例使用相同的變量名。

第2和第3行是定義輸入數(shù)據(jù)，第4行是調(diào)用被測試函數(shù)，這些容易理解，不作進(jìn)一步解釋。第5行是預(yù)期輸出，它的特點(diǎn)是當(dāng)實(shí)際輸出與預(yù)期輸出不同時自動報錯，ASSERT是VC的斷言宏，也可以使用其他類似功能的宏，使用測試工具進(jìn)行單元測試時，可以使用該工具定義的斷言宏。111示例中的格式顯得很不簡潔，2、3、4、5行可以合寫為一行：ASSERT(pObj->Add(0,0)==0);但這種不簡潔的格式卻是我們推薦的，因?yàn)樗荒苛巳?，易于建立多個測試用例，并且具有很好的適應(yīng)性，同時，也是極佳的代碼文檔，總之，我們建議：輸入數(shù)據(jù)和預(yù)期輸出要自成一塊。

建立了第一個測試用例后，應(yīng)編譯并運(yùn)行測試，以排除語法錯誤，然后，使用拷貝/修改的辦法建立其他測試用例。由于各個測試用例之間的差別往往很小，通常只需修改一兩個數(shù)據(jù)，拷貝/修改是建立多個測試用例的最快捷辦法。1122、Junit由ErichGamma和KentBeck編寫的一個回歸測試框架（regressiontestingframework），是Java語言事實(shí)上的標(biāo)準(zhǔn)單元測試庫。Junit測試是程序員測試，即所謂白盒測試，因?yàn)槌绦騿T知道被測試的軟件如何（How）完成功能和完成什么樣（What）的功能。Junit是一套框架，繼承TestCase類，就可以用Junit進(jìn)行自動測試了。/單元測試配置：使用eclipse＋myEclopse的簡單配置；右鍵點(diǎn)擊項(xiàng)目選擇“屬性”，在彈出窗口中到環(huán)境變量中添加junit.jar包，下一步就可以進(jìn)行單元測試了；113114使用eclipse快速開發(fā)testCase：如下圖：右鍵選擇你要測試的類，在新建中點(diǎn)擊“JUnit測試用例”，115出對話框，配置測試名稱和根目錄，添加注釋等，再點(diǎn)擊“下一步”到下圖116選擇你要測試類中的方法，點(diǎn)擊完成！便生成測試類的基本框架，如下代碼，我們以對一個DAO類測試為例：

/*

*

Copyright

reserved

2005

by

XXXXCo.

Ltd.

*

Author：Fu

wei

Date：2006-9-4

*/

import

junit.framework.TestCase;

/**

*

@author

Fu

wei

*/

public

class

OrgTypeDAOTest

extends

TestCase

{

/**

*

@param

arg0

*/

public

OrgTypeDAOTest(String

arg0)

{

super(arg0);

}

/*

*

@see

junit.framework.TestCase#setUp()

*/

protected

void

setUp()

throws

Exception

{

super.setUp();

}

/*

*

@see

junit.framework.TestCase#tearDown()

*/

protected

void

tearDown()

throws

Exception

{

super.tearDown();

}117/**主函數(shù)

*

@param

args

*/

public

static

void

main(String[]

args){

TestRunner.run(OrgTypeDAOTest

.class);

}

/**

*

{@link

OrgTypeDAO#getOrgTypeList()}

的測試方法。

*/

public

final

void

testGetOrgTypeList()

{

fail("尚未實(shí)現(xiàn)");

//

TODO

}

/**

*

{@link

OrgTypeDAO#insertOrgTypeInfo(com.zhjy.mltx.vo.OrgTypeVO)}

的測試方法。

*/

public

final

void

testInsertOrgTypeInfo()

{

fail("尚未實(shí)現(xiàn)");

//

TODO

}

/**

*

{@link

OrgTypeDAO#deleteOrgTypeInfo(java.lang.String)}

的測試方法。

*/

public

final

void

testDeleteOrgTypeInfo()

{

fail("尚未實(shí)現(xiàn)");

//

TODO

}

/**

*

{@link

OrgTypeDAO#updateOrgTypeInfo(com.zhjy.mltx.vo.OrgTypeVO)}

的測試方法。

*/

public

final

void

testUpdateOrgTypeInfo()

{

fail("尚未實(shí)現(xiàn)");

//

TODO

}

/**

*

{@link

OrgTypeDAO#getOrgTypeInfoById(java.lang.String)}

的測試方法。

*/

public

final

void

testGetOrgTypeInfoById()

{

fail("尚未實(shí)現(xiàn)");

//

TODO

}

/**

*

{@link

OrgTypeDAO#isRepeatOrgTypeInfo(java.lang.String)}

的測試方法。

*/

public

final

void

testIsRepeatOrgTypeInfoString()

{

fail("尚未實(shí)現(xiàn)");

//

TODO

}

/**

*

{@link

OrgTypeDAO#isRepeatOrgTypeInfo(com.zhjy.mltx.vo.OrgTypeVO)}

的測試方法。

*/

public

final

void

testIsRepeatOrgTypeInfoOrgTypeVO()

{

fail("尚未實(shí)現(xiàn)");

//

TODO

}

/**

*

{@link

OrgTypeDAO#getFlatOrgIdByName(java.lang.String)}

的測試方法。

*/

public

final

void

testGetFlatOrgIdByName()

{

fail("尚未實(shí)現(xiàn)");

//

TODO