一篇畢業(yè)設(shè)計(jì)論文 | 面向?qū)ο蟮能浖y(cè)試

【文章摘要】

面向?qū)ο蟮能浖y(cè)試摘 要: 如今,面向?qū)ο箝_發(fā)技術(shù)正大力地的推動(dòng)著軟件產(chǎn)業(yè)的快速發(fā)展。在保證軟件產(chǎn)品質(zhì)量的手段中,最有效、最重要的技術(shù)要數(shù)軟件測(cè)試技術(shù)。然而,傳統(tǒng)的測(cè)試技術(shù)和方法,對(duì)面向?qū)ο蠹夹g(shù)開發(fā)的的軟件多少顯得有些力不從心。鑒于此,提出了面向?qū)ο蟮臏y(cè)試技術(shù)!在此,本文通過(guò)翻閱大量的文獻(xiàn),總結(jié)出著實(shí)有效的面向?qū)ο蟮能浖y(cè)試技術(shù)。首先,闡明面向?qū)ο筌浖y(cè)試的基本概念;然后,分別討論分析和設(shè)計(jì)……

【文章正文】

面向?qū)ο蟮能浖y(cè)試

摘 要: 如今,面向?qū)ο箝_發(fā)技術(shù)正大力地的推動(dòng)著軟件產(chǎn)業(yè)的快速發(fā)展。在保證軟件產(chǎn)品質(zhì)量的手段中,最有效、最重要的技術(shù)要數(shù)軟件測(cè)試技術(shù)。然而,傳統(tǒng)的測(cè)試技術(shù)和方法,對(duì)面向?qū)ο蠹夹g(shù)開發(fā)的的軟件多少顯得有些力不從心。鑒于此,提出了面向?qū)ο蟮臏y(cè)試技術(shù)!

在此,本文通過(guò)翻閱大量的文獻(xiàn),總結(jié)出著實(shí)有效的面向?qū)ο蟮能浖y(cè)試技術(shù)。首先,闡明面向?qū)ο筌浖y(cè)試的基本概念;然后,分別討論分析和設(shè)計(jì)模型測(cè)試技術(shù)、類測(cè)試技術(shù)、對(duì)象交互測(cè)試技術(shù)、類層次結(jié)構(gòu)測(cè)試技術(shù)、面向?qū)ο笙到y(tǒng)測(cè)試技術(shù);最后,對(duì)面向?qū)ο筌浖y(cè)試的實(shí)施進(jìn)行小結(jié)。

關(guān)鍵詞:面向?qū)ο螅卉浖y(cè)試;類測(cè)試;對(duì)象交互;測(cè)試用例

Object-Oriented Software Test

Abstract:Now, Object-Oriented development technique is strongly pushing the fast development of the software industry.In the means of the assurance software product quality, most valid,the most important technique wants the few software test technique.However, the traditional test technique and method, the opposite develops toward the object technique of software how much seem to be some to lack the ability to do.Owing to this, put forward to the Object-Oriented test technology!

Here, this text passes to browse a great deal of cultural heritage, tallying up to really effectively Object-Oriented software test technique。First, clarify the basic concept of Object-Oriented software test;then, discuss respectively the Class test technique;a test technique,object hands over to with each other test the technique,a layer structure test technique, the distribute type object test technique and face to the object system test technique; finally,the implement that tests toward the object software in front carries on the sub-footing.

Key Words:Object-Oriented ;Software test;Class test;Object interact;Test case

引 言

軟件測(cè)試的發(fā)展歷程 軟件測(cè)試是伴隨著計(jì)算機(jī)軟件的產(chǎn)生而產(chǎn)生的。在早期軟件開發(fā)的過(guò)程中,軟件就是由程序員寫的簡(jiǎn)單計(jì)算機(jī)程序代碼。因而,軟件測(cè)試的含義比較狹窄 ---- 測(cè)試等同于 “調(diào)試”。軟件測(cè)試的目的就是為尋找和糾正軟件中的故障,這部分的工作常常由開發(fā)人員自己完成。

直到上世紀(jì) 80 年代早期,“質(zhì)量” 的號(hào)角才開始吹響。軟件測(cè)試定義發(fā)生了改變,測(cè)試不單純是一個(gè)發(fā)現(xiàn)錯(cuò)誤的過(guò)程,而且包含軟件質(zhì)量評(píng)價(jià)的內(nèi)容。軟件開發(fā)人員和測(cè)試人員開始坐在一起探討軟件工程和測(cè)試問(wèn)題。制定了各類標(biāo)準(zhǔn),包括 IEEE(Institute of Electrical and Electronic Engineers)標(biāo)準(zhǔn)、美國(guó) ANSI(American national Standard Institute)標(biāo)準(zhǔn)以及 ISO(International Standard Organization)國(guó)際標(biāo)準(zhǔn)。1983 年,Bill Wetzel 在《軟件測(cè)試完全指南》(Complete Guide of Software Testing)一書中指出:“測(cè)試是以評(píng)價(jià)一個(gè)程序或者系統(tǒng)屬性為目標(biāo)的任何一種活動(dòng)。測(cè)試是對(duì)軟件質(zhì)量的度。”Myers 和 Wetzel 的定義至今仍被引用。

到了 2002 年,Rick 和 Stefan 在《系統(tǒng)的軟件測(cè)試》(Systematic Software Testing)中對(duì)軟件測(cè)試做了進(jìn)一步定義:“測(cè)試是為了度量和提高被測(cè)軟件的質(zhì)量,對(duì)測(cè)試件進(jìn)行工程設(shè)計(jì)、實(shí)施和維護(hù)的整個(gè)生命周期過(guò)程。” 這些經(jīng)典論著對(duì)軟件測(cè)試研究的理論化和體系化產(chǎn)生了巨大的影響。

近 20 年來(lái),隨著計(jì)算機(jī)和軟件技術(shù)的飛速發(fā)展,軟件測(cè)試技術(shù)研究也取得了很大的突破。測(cè)試專家總結(jié)了很好的測(cè)試模型,比如著名的 V 模型、W 模型等,在測(cè)試過(guò)程改進(jìn)方面提出了 TMM(Testing Maturity Model)的概念,在單元測(cè)試、自動(dòng)化測(cè)試、負(fù)載壓力測(cè)試以及測(cè)試管理等方面涌現(xiàn)了大量?jī)?yōu)秀的軟件測(cè)試工具。

雖然軟件測(cè)試技術(shù)的發(fā)展很快,但是其發(fā)展速度仍落后于軟件開發(fā)技術(shù)的發(fā)展速度,使得軟件測(cè)試在今天面臨著很大的挑戰(zhàn)。軟件規(guī)模越來(lái)越大,功能越來(lái)越復(fù)雜,如何進(jìn)行充分而有效的測(cè)試成為難題。尤其是面向?qū)ο蟮拈_發(fā)技術(shù)越來(lái)越普及,但是面向?qū)ο蟮臏y(cè)試技術(shù)卻剛剛起步。

面向?qū)ο筌浖_發(fā)過(guò)程及其特點(diǎn) 面向?qū)ο蟮拈_發(fā)方法(簡(jiǎn)稱 OO)的基本思想認(rèn)為,客觀世界是由各種各樣的對(duì)象組成的,每種對(duì)象都有各自的內(nèi)部狀態(tài)和運(yùn)動(dòng)規(guī)律,不同的對(duì)象之間的相互作用和聯(lián)系就構(gòu)成了各種不同的系統(tǒng)。故面向?qū)ο筌浖_發(fā)的工作過(guò)程為:

1. 調(diào)查、分析系統(tǒng)需求,建立一個(gè)全面、合理、統(tǒng)一的模型。

2. 在繁雜的問(wèn)題域中抽象地識(shí)別出對(duì)象以及其行為、結(jié)構(gòu)、屬性、方法

3. 對(duì)象設(shè)計(jì)——即對(duì)分析的結(jié)果作進(jìn)一步地抽象、歸類、整理,并最終以范式的形式將它們確定下來(lái)。

4. 程序?qū)崿F(xiàn)——即用面向?qū)ο蟮某绦蛟O(shè)計(jì)語(yǔ)言將上一步整理的范式直接映射(直接用程序語(yǔ)言來(lái)取代)為應(yīng)用程序軟件。

面向?qū)ο箝_發(fā)的特點(diǎn)是遵循一下三項(xiàng)原則:

1. 抽象原則(abstraction)——指為了某一分析目的而集中精力研究對(duì)象的某一性質(zhì),它可以忽略其它與此目的無(wú)關(guān)的部分

2. 封裝原則(encapsulation)即信息隱藏——指在確定系統(tǒng)的某一部分內(nèi)容時(shí),應(yīng)考慮到其它部分的信息及聯(lián)系都在這一部分的內(nèi)部進(jìn)行, 外部各部分之間的信息聯(lián)系應(yīng)盡可能的少。

3. 繼承原則(inheritance)——指能直接獲得已有的性質(zhì)和特征而不必重復(fù)定義它們

1. 面向?qū)ο蟮能浖y(cè)試的基本概念

面向軟件測(cè)試技術(shù)是新興的軟件測(cè)試技術(shù),是專門針對(duì)使用面向?qū)ο蠹夹g(shù)開發(fā)的軟件而提出的一種測(cè)試技術(shù)。其目的是為了解決傳統(tǒng)的軟件測(cè)試技術(shù),面對(duì)面向?qū)ο蠹夹g(shù)開發(fā)的軟件多少顯得有些力不從心的現(xiàn)象。面向?qū)ο箝_發(fā)技術(shù)和傳統(tǒng)的開發(fā)技術(shù)相比,新增了多態(tài)、繼承、封裝等特點(diǎn)。這些新特點(diǎn)使得開發(fā)出來(lái)的程序,具有更好的結(jié)構(gòu)更規(guī)范的編程風(fēng)格, 極大地優(yōu)化了數(shù)據(jù)使用的安全性, 提高了代碼的重用率。由此可見,它們是面向?qū)ο箝_發(fā)技術(shù)產(chǎn)生巨大吸引力的重要因素。然而,另一方面也影響了軟件測(cè)試的方法和內(nèi)容;增加了軟件測(cè)試的難度;帶來(lái)了傳統(tǒng)軟件設(shè)計(jì)技術(shù)所不存在的錯(cuò)誤;或者使得傳統(tǒng)軟件測(cè)試中的重點(diǎn)不再顯得突出;或者使原來(lái)測(cè)試經(jīng)驗(yàn)認(rèn)為和實(shí)踐證明的次要方面成為了主要問(wèn)題。

面向?qū)ο筌浖y(cè)試是根據(jù)面向?qū)ο蟮能浖_發(fā)過(guò)程結(jié)合面向?qū)ο蟮奶攸c(diǎn)提出的。它包括分析與設(shè)計(jì)模型測(cè)試技術(shù)、類測(cè)試技術(shù)、對(duì)象交互測(cè)試技術(shù)、類層次結(jié)構(gòu)測(cè)試技術(shù)、面向?qū)ο笙到y(tǒng)測(cè)試技術(shù)五大部分。下面分別圍繞這五部分展開討論。

2. 分析和設(shè)計(jì)模型測(cè)試技術(shù)

面向?qū)ο筌浖_發(fā)的起始步驟是開發(fā)分析和設(shè)計(jì)模型。UML(統(tǒng)一建模語(yǔ)言)能在面向?qū)ο蠹夹g(shù)開發(fā)中廣泛應(yīng)用,也是因?yàn)闃?gòu)建模型能幫助開發(fā)者理解正在解決的問(wèn)題;構(gòu)建模型能幫助管理正在開發(fā)的系統(tǒng)的復(fù)雜性;分析和設(shè)計(jì)階段建構(gòu)的模型最后將對(duì)具體地實(shí)現(xiàn)起指導(dǎo)作用。如果模型的質(zhì)量很高對(duì)項(xiàng)目來(lái)說(shuō)就很有價(jià)值;但是如果模型有錯(cuò)誤,那么它對(duì)項(xiàng)目的危害就無(wú)可估量。

2.1. 分析和設(shè)計(jì)模型測(cè)試的內(nèi)容

分析和設(shè)計(jì)模型測(cè)試的重點(diǎn)是測(cè)試模型的完整性和一致性, 其主要內(nèi)容有:

1. 對(duì)確定的對(duì)象的測(cè)試;

2. 對(duì)確定的結(jié)構(gòu)的測(cè)試;

3. 對(duì)確定的主題的測(cè)試;

4. 對(duì)定義的屬性和實(shí)例關(guān)聯(lián)的測(cè)試;

5. 對(duì)定義的服務(wù)和消息關(guān)聯(lián)的測(cè)試。

2.2. 分析和設(shè)計(jì)模型測(cè)試的方法

分析與設(shè)計(jì)模型的測(cè)試主要是對(duì)分析與設(shè)計(jì)模型進(jìn)行測(cè)試,找出模型中的錯(cuò)誤,其采用的方法是指導(dǎo)性審查 (guided inspection)。指導(dǎo)性審查技術(shù)通過(guò)使用明確的測(cè)試用例為查找工作成果中的缺陷提供了客觀的、系統(tǒng)的方法。是一種增強(qiáng)了的專為檢驗(yàn)?zāi)P偷臋z測(cè)技巧,也可用來(lái)驗(yàn)證模型是否能符合項(xiàng)目的需求。其基本步驟如下:

1. 定義測(cè)試位置。

2. 使用特定的策略從測(cè)試位置選擇測(cè)試值。

3. 將測(cè)試值應(yīng)用到被測(cè)試的產(chǎn)品中。

4. 對(duì)測(cè)試結(jié)果以及對(duì)模型的測(cè)試覆蓋率(基于某中標(biāo)準(zhǔn))進(jìn)行評(píng)估。

這些步驟經(jīng)過(guò)具體化后形成下列詳細(xì)步驟:

1. 制訂檢查的范圍和深度:范圍將通過(guò)描述材料的實(shí)體或一系列詳細(xì)的用例來(lái)定義。對(duì)小的項(xiàng)目來(lái)說(shuō),范圍可以是整個(gè)模型。深度將通過(guò)指定須要測(cè)試的模型(MUT)的某種 UML 圖的集合層次中的級(jí)別來(lái)定義。

2. 確定 MUT 產(chǎn)生的基礎(chǔ):除原始模型之外,所有的 UMT 的基礎(chǔ)是前一開發(fā)階段創(chuàng)建的一系列模型:比如,應(yīng)用分析模型就是以域分析模型和用例模型為基礎(chǔ)。起初模型則是基于所選擇的一組人頭腦里的知識(shí)。

3. 為每一個(gè)評(píng)價(jià)標(biāo)準(zhǔn)開發(fā)測(cè)試用例,標(biāo)準(zhǔn)在應(yīng)用時(shí)使用基本模型的內(nèi)容作為輸入。這種從用戶用例模型出發(fā)的方式對(duì)許多模型的測(cè)試用例來(lái)說(shuō)是一個(gè)很好的出發(fā)點(diǎn)。

4. 為測(cè)量測(cè)試的覆蓋率建立標(biāo)準(zhǔn)。比如對(duì)一個(gè)類圖來(lái)說(shuō),如果圖中每一個(gè)類都被測(cè)試到了,那么覆蓋率就算不錯(cuò)了。

5. 使用合適的檢查列表進(jìn)行靜態(tài)分析。將 MUT 與基本的模型相比較可以確定 2 個(gè)圖型之間的連貫性。

6. “執(zhí)行” 測(cè)試用例。

7. 使用測(cè)試用例覆蓋率衡量法對(duì)測(cè)試的效率進(jìn)行評(píng)價(jià),計(jì)算覆率率百分比。比如,測(cè)試用例 “涉及” 到了包含 18 個(gè)類的類圖中的 12 個(gè)類,那么測(cè)試的覆蓋率就是 75%。鑒于分析和設(shè)計(jì)模型的測(cè)試如此高級(jí),以至于要達(dá)到好的結(jié)果,必須有 100% 的覆蓋率。

8. 如果覆蓋率不充分,就要對(duì)測(cè)試進(jìn)行擴(kuò)充并應(yīng)用額外的測(cè)試用例。否則終止正在進(jìn)行的測(cè)試。通常無(wú)法在檢查片斷的過(guò)程中寫下附加的測(cè)試用例。測(cè)試者確定哪些地方?jīng)]有覆蓋到并與開發(fā)者一起確定將觸及未覆蓋的模型組件的潛在的測(cè)試用例。然后,測(cè)試者創(chuàng)建整個(gè)的測(cè)試用例并且進(jìn)行另一次檢查。

采用指導(dǎo)性審查技術(shù)對(duì)分析和設(shè)計(jì)產(chǎn)生的文本進(jìn)行正確性驗(yàn)證, 是軟件開發(fā)前期的關(guān)鍵性測(cè)試。

3. 類測(cè)試技術(shù)

面向?qū)ο筌浖a(chǎn)品的基本組成單位是類,從宏觀上來(lái)看,面向?qū)ο筌浖歉鱾€(gè)類之間的相互作用。在面向?qū)ο笙到y(tǒng)中, 系統(tǒng)的基本構(gòu)造模塊是封裝了的數(shù)據(jù)和方法的類和對(duì)象, 而不再是一個(gè)個(gè)能完成特定功能的功能模塊。每個(gè)對(duì)象有自己的生存周期, 有自己的狀態(tài)。消息是對(duì)象之間相互請(qǐng)求或協(xié)作的途徑, 是外界使用對(duì)象方法及獲取對(duì)象狀態(tài)的惟一方式。對(duì)象的功能是在消息的觸發(fā)下, 由對(duì)象所屬類中定義的方法與相關(guān)對(duì)象的合作共同完成。且在不同狀態(tài)下對(duì)消息的響應(yīng)可能完全不同。工作過(guò)程中對(duì)象的狀態(tài)可能被改變, 產(chǎn)生新的狀態(tài)。對(duì)象中的數(shù)據(jù)和方法是一個(gè)有機(jī)的整體, 測(cè)試過(guò)程中不能僅僅檢查輸入數(shù)據(jù)產(chǎn)生的輸出結(jié)果是否與預(yù)期的吻合, 還要考慮對(duì)象的狀態(tài),且在不同狀態(tài)下對(duì)消息的響應(yīng)可能完全不同。工作過(guò)程中對(duì)象的狀態(tài)可能被改變, 產(chǎn)生新的狀態(tài)。對(duì)象中的數(shù)據(jù)和方法是一個(gè)有機(jī)的整體, 測(cè)試過(guò)程中不能僅僅檢查輸入數(shù)據(jù)產(chǎn)生的輸出結(jié)果是否與預(yù)期的吻合, 還要考慮對(duì)象的狀態(tài)。

類測(cè)試是由那些與驗(yàn)證類的實(shí)現(xiàn)是否和該類的說(shuō)明完全一致的相關(guān)聯(lián)的活動(dòng)組成的。該類測(cè)試的對(duì)象主要是指能獨(dú)立完成一定功能的原始類。如果類的實(shí)現(xiàn)正確,那么類的每一個(gè)實(shí)例的行為也應(yīng)該是正確的。

3.1. 類測(cè)試的內(nèi)容

類測(cè)試的目的主要是確保一個(gè)類的代碼能夠完全滿足類的說(shuō)明所描述的要求.對(duì)一個(gè)類進(jìn)行測(cè)試以確保他只做規(guī)定的事情,對(duì)此給與關(guān)注的多少,取決于提供額外的行為的類相關(guān)聯(lián)的風(fēng)險(xiǎn).在運(yùn)行了各種類的測(cè)試后,如果代碼的覆蓋率不完整,這可能意味著該類包含了額外的文檔支持的行為.需要增加更多的測(cè)試用例來(lái)進(jìn)行測(cè)試。

3.2. 類測(cè)試的時(shí)間

類測(cè)試的開始時(shí)間一般在完全說(shuō)明這個(gè)類,并且準(zhǔn)備對(duì)其編碼后不久,就開發(fā)一個(gè)測(cè)試計(jì)劃——至少是確定測(cè)試用例的某種形式。如果開發(fā)人員還負(fù)責(zé)該類的測(cè)試,那么尤其應(yīng)該如此。因?yàn)榇_定早期測(cè)試用例有利于開發(fā)人員理解類說(shuō)明,也有助于獲得獨(dú)立代碼檢查的反饋。

類測(cè)試可以在開發(fā)過(guò)程中的不同位置進(jìn)行。在遞增的反復(fù)開發(fā)過(guò)程中,一個(gè)類的說(shuō)明和實(shí)現(xiàn)在一個(gè)工程的進(jìn)程中可能會(huì)發(fā)生變化,所以因該在軟件的其它部分使用該類之前執(zhí)行類的測(cè)試。每當(dāng)一個(gè)類的實(shí)現(xiàn)發(fā)生變化時(shí),就應(yīng)該執(zhí)行回歸測(cè)試。如果變化是因發(fā)現(xiàn)代碼中的缺陷(bug)而引起的,那么就必須執(zhí)行測(cè)試計(jì)劃的檢查,而且必須增加或改變測(cè)試用例以測(cè)試在未來(lái)的測(cè)試期間可能出現(xiàn)的那些缺陷。

3.3. 類測(cè)試的測(cè)試人員

類測(cè)試通常由他的開發(fā)人員測(cè)試,讓開發(fā)人員起到測(cè)試人員的作用,就可使得必須理解類說(shuō)明的人員數(shù)量減至最少。而且方便使用基于執(zhí)行的測(cè)試方法,因?yàn)樗麄儗?duì)代碼極其的熟悉。由同一個(gè)開發(fā)者來(lái)測(cè)試,也有一定的缺點(diǎn):開發(fā)人員對(duì)類說(shuō)明的任何錯(cuò)誤理解,都會(huì)影響到測(cè)試。因此,最好要求另一個(gè)類的開發(fā)人員編寫測(cè)試計(jì)劃,并且允許對(duì)代碼進(jìn)行對(duì)立檢查。這樣就可以避免這些潛在的問(wèn)題了。

3.4. 類測(cè)試的方法

類測(cè)試的方法有代碼檢查和執(zhí)行測(cè)試用例。在某些情況下,用代碼檢查代替基于執(zhí)行的測(cè)試方法是可行的,但是,和基于執(zhí)行的測(cè)試相比,代碼檢查有以下兩個(gè)不利之處:

1. 代碼檢查易受人為因素影響。

2. 代碼檢查在回歸測(cè)試方面明顯需要更多的工作量,常常和原始測(cè)試差不多。

盡管基于執(zhí)行的測(cè)試方法克服了以上的缺點(diǎn),但是確定測(cè)試用例和開發(fā)測(cè)試驅(qū)動(dòng)程序也需要很大的工作量。在某些情況下,構(gòu)造一個(gè)測(cè)試驅(qū)動(dòng)程序的工作量比開發(fā)這個(gè)類的還多,此時(shí)就應(yīng)該評(píng)估在使用了這個(gè)類的系統(tǒng)之外測(cè)試測(cè)試這個(gè)類所花的代價(jià)和帶來(lái)的收益。

一旦確定了一個(gè)類的可執(zhí)行測(cè)試用例,就必須執(zhí)行測(cè)試驅(qū)動(dòng)程序來(lái)運(yùn)行每一個(gè)測(cè)試用例,并給出每一個(gè)測(cè)試用例的結(jié)果。

3.5. 測(cè)試程度

可以根據(jù)已經(jīng)測(cè)試了多少類實(shí)現(xiàn)和多少類說(shuō)明來(lái)衡量測(cè)試的充分性。對(duì)于類的測(cè)試,通常需要將這兩者都考慮到,希望測(cè)試到操作和狀態(tài)轉(zhuǎn)換的各種組合情況。一個(gè)對(duì)象能維持自己的狀態(tài),而狀態(tài)一般來(lái)說(shuō)也會(huì)影響操作的含義。但要窮舉所有組合式不可能的,而且是沒必要的 。因此,就因該結(jié)合風(fēng)險(xiǎn)分析進(jìn)行選擇配對(duì)系列的組合,以致達(dá)到使用最重要的測(cè)試用例并抽取部分不太重要的測(cè)試用例。

3.6. 構(gòu)建類測(cè)試用例

要對(duì)類進(jìn)行測(cè)試,就必須先確定和構(gòu)建類的測(cè)試用例。類的描述方法有 OCL, 自然語(yǔ)言,和狀態(tài)圖等方法,可以根據(jù)類說(shuō)明的描述方法構(gòu)件類的測(cè)試用例。因而,構(gòu)建類的測(cè)試用例的方法有:根據(jù)類說(shuō)明(用 OCL 表示)確定測(cè)試用例和根據(jù)類的狀態(tài)轉(zhuǎn)換圖來(lái)構(gòu)建類的測(cè)試用例。

根據(jù)類的說(shuō)明確定測(cè)試用例 用 OCL 表示的類的說(shuō)明中描述了類的每一個(gè)限定條件條件。在 OCL 條件下分析每個(gè)邏輯關(guān)系,從而得到由這個(gè)條件的結(jié)構(gòu)所對(duì)應(yīng)的測(cè)試用例。這種確定類的測(cè)試用例的方法叫做根據(jù)前置條件和后置條件構(gòu)建測(cè)試用例。其總體思想是:為所有可能出現(xiàn)的組合情況確定測(cè)試用例需求。在這些可能出現(xiàn)的組合情況下,可滿足前置條件,也能夠到達(dá)后置條件。根據(jù)這些需求,創(chuàng)建測(cè)試用例;創(chuàng)建擁有特定輸入值(常見值和特殊值)的測(cè)試用例;確定它們的正確輸出——預(yù)期輸出值。

根據(jù)前置條件和后置條件創(chuàng)建測(cè)試用例的基本步驟如下:

1. 確定在表 1 中與前置條件形成相匹配的各個(gè)項(xiàng)目所指定的一系列前置條件的影響。

2. 確定在表 2 中與后置條件形成相匹配的各個(gè)項(xiàng)目所指定的一系列前置條件的影響。

3. 根據(jù)影響到列表中各個(gè)項(xiàng)目的所有可能的組合情況從而構(gòu)造測(cè)試用例需求。一種簡(jiǎn)單的方法就是:用第一個(gè)列表中的每一個(gè)輸入約束來(lái)代替第二個(gè)列表中每一個(gè)前置條件。

4. 排除表中生成的所有無(wú)意義的條件。

表 1 前置條件對(duì)測(cè)試系列的影響

前置條件影 響

True(true 、post)

A(A、post)

(not A、exception) *

Not A(not A、post)

(A、exception) *

A and B(A and B、post)

(not A and B、exception) *

(A and not B、exception) *

(not A and not B、exception) *

A or B(A、post)

(B、post)

(A and B、post)

(not A and not B、post)

A xor B(not A and B、post)

(A and not B、post)

(A and B、exception) *

(not A and not B、exception) *

A implies B (not A、post)

(B、post)

(not A and B、post)

(A and not B、exception) *

if A then B

else C endif(A and B、post)

(not A and C、post)

(A and not B、exception) *

(not A and not C、exception) *

注:①.A、B、C 代表用 OCL 表示的組件。

②.假如類說(shuō)明中的保護(hù)性設(shè)計(jì)方法是隱式的,那么也必須對(duì)那些標(biāo)記有 * 的測(cè)試用例進(jìn)行闡述。如果保護(hù)性設(shè)計(jì)方法在類的說(shuō)明中是顯式出現(xiàn)的,那么測(cè)試用例也就確定了。

表 2 后置條件對(duì)測(cè)試系列的影響

后置條件影 響

A(pre ;A)

A and B(pre ;A and B)

A or B(pre ;A)

(pre ;B)

(pre ;A or B)

A xor B(pre ;not A or B)

(pre ;A or not B)

A implies B(pre ;not A or B)

if A then B

else C endif(pre and * ;B)

(pre and not * ;C)

注:①.A、B、C 代表用 OCL 表示的組件。

②.對(duì)于 “if A then B else C endif” 這個(gè)后置條件,假如測(cè)試用例不會(huì)對(duì)表達(dá)式 A 產(chǎn)生影響那么在用這個(gè)后置條件時(shí),* = A else * 就是使得 A 為真的一個(gè)條件

根據(jù)狀態(tài)轉(zhuǎn)換圖構(gòu)建測(cè)試用例 狀態(tài)轉(zhuǎn)換圖以圖例的形式說(shuō)明了與一個(gè)類的實(shí)例相關(guān)聯(lián)的行為。狀態(tài)轉(zhuǎn)換圖可用來(lái)補(bǔ)充編寫的類說(shuō)明或者構(gòu)成完整的類說(shuō)明。狀態(tài)圖中的每一個(gè)轉(zhuǎn)換都描述了一個(gè)或多個(gè)測(cè)試用例需求。因而,可以用過(guò)在轉(zhuǎn)換的每一端選擇有代表性的值和邊界來(lái)滿足這些需求。如果轉(zhuǎn)換是受保護(hù)的,那么也應(yīng)該為這些保護(hù)條件選擇邊界。狀態(tài)的邊界值取決于狀態(tài)相關(guān)屬性值的范圍,可以根據(jù)屬性值來(lái)定義每一個(gè)狀態(tài)。

由此可見,和根據(jù)前置條件和后置條件創(chuàng)建類的測(cè)試用例相比,根據(jù)狀態(tài)轉(zhuǎn)換圖創(chuàng)建類的測(cè)試用例有非常大的優(yōu)勢(shì)。在類的狀態(tài)圖中,類相關(guān)聯(lián)的行為非常的明顯和直觀,測(cè)試用例的需求直接來(lái)自于狀態(tài)轉(zhuǎn)換,因而很容易確定測(cè)試用例的需求。不過(guò)基于狀態(tài)圖的方法也有其不利的方面。如要完全理解怎樣根據(jù)屬性值來(lái)定義狀態(tài);事件是如何在一個(gè)給定的狀態(tài)內(nèi)影響特定值等。這都很難僅從簡(jiǎn)單的狀態(tài)圖中確定。因此,在使用基于狀態(tài)轉(zhuǎn)換圖進(jìn)行測(cè)試時(shí),務(wù)必在生成的測(cè)試用例時(shí)檢查每個(gè)狀態(tài)轉(zhuǎn)換的邊界值和預(yù)期值。

4. 類層次結(jié)構(gòu)測(cè)試技術(shù)

繼承作為代碼復(fù)用的一種機(jī)制,可能是面向?qū)ο筌浖_發(fā)產(chǎn)生巨大吸引力的一個(gè)重要因素。繼承由擴(kuò)展、覆蓋和特例化三種基本機(jī)制實(shí)現(xiàn)的。其中,擴(kuò)展是子類自動(dòng)包含父類的特征;覆蓋是子類中的方法與父類中的方法有相同的名字和消息參數(shù)以及相同的接口,但方法的實(shí)現(xiàn)不同;特例化是子類中特有的方法和實(shí)例變量。好的面向?qū)ο蟪绦蛟O(shè)計(jì)要求通過(guò)非常規(guī)范的方式使用繼承——即代碼替代原則。在這種規(guī)則下,為一個(gè)類確定的測(cè)試用例集對(duì)該類的子類也是有效的。因此,額外的測(cè)試用例通常應(yīng)用于子類。通過(guò)仔細(xì)分析根據(jù)父類定義的子類的增量變化,有時(shí)候,子類中的某些部分可以不做執(zhí)行測(cè)試。因?yàn)閼?yīng)用于父類中的測(cè)試用例所測(cè)試的代碼被子類原封不動(dòng)的繼承,是同樣的代碼。

類的層次結(jié)構(gòu)測(cè)試就是用來(lái)測(cè)試類的繼承關(guān)系的技術(shù),主要是用來(lái)測(cè)試層次關(guān)系的一系列類(包括父類和子類)。其測(cè)試的方法有用于測(cè)試子類的分層增量測(cè)試和用于測(cè)試父類的抽象類測(cè)試。

4.1. 分層、增量測(cè)試

C

D

Void op1 ( );

Void op2 ( );

Void op2 ( );

Void open ( );

Newvar type;

說(shuō) 明

子類 D 添加了一個(gè)新的實(shí)例變量(NewVar)和一個(gè)新的操作(newop())。D 重載了 C 中定義的方法 op2(),因?yàn)樵摬僮髟?D 中有新的規(guī)范或操作的實(shí)現(xiàn)

圖 1 類的派生及增量變化

分層增量測(cè)試(hierarchical incremental testing(HIT))指通過(guò)分析來(lái)確定子類的哪些測(cè)試用例需要添加,哪些繼承的測(cè)試用例需要運(yùn)行,以及哪些繼承的測(cè)試用例不需要運(yùn)行的測(cè)試方法。如圖一,展示了 C 類和它的派生類 D 類,以及它們之間的增量變化。C 類和它的派生類 D 類間的增量變化能夠用來(lái)幫助確定需要在 D 中測(cè)試什么。

由于 D 類是 C 類的子類,則所有用于 C 類的基于規(guī)范的測(cè)試用例也都適用于 D 類。那么,哪些繼承的測(cè)試用例(用于子類的測(cè)試用例)適用于子類的測(cè)試,哪些又不必在子類中執(zhí)行呢?要解決以上問(wèn)題,可通過(guò)對(duì)子類的增量分析。可能情況如下:

1. D 的接口中添加一個(gè)或多個(gè)新的操作,并且有可能 D 中的一個(gè)新方法實(shí)現(xiàn)一個(gè)新操作。新的操作引入了新的功能和新的代碼,這些都需要測(cè)試。如果操作不是抽象的并且有具體的實(shí)現(xiàn),那么為了合乎測(cè)試計(jì)劃中的覆蓋標(biāo)準(zhǔn),需要添加基于規(guī)范和基于交互的測(cè)試用例。

2. 通過(guò)兩種方式改變由 C 申明的操作的規(guī)范和實(shí)現(xiàn):一. 在 D 中改變那些在 D 中申明的操作規(guī)范。二. 在 D 中覆蓋那些在 C 中實(shí)現(xiàn)了某個(gè)操作并且被 D 繼承了的方法。

3. 在 D 中添加一個(gè)或多個(gè)實(shí)例變量來(lái)實(shí)現(xiàn)更多的狀態(tài)和屬性。新添的變量最有可能與新的操作和重載方法中代碼有關(guān),而且對(duì)測(cè)試的處理也與他們有關(guān)。如果新的變量沒有在任何地方使用,那么就不必做任何的變化。

4. 在 D 中改變類常量。類常量組成每個(gè)側(cè)使用例的附加的后置條件,并且,“類常量句柄” 在每個(gè)測(cè)試用例輸出中是顯示的。因此,如果類常量變化了,就需要重新運(yùn)行所有繼承的測(cè)試用例以驗(yàn)證常量句柄。

從基類派生出派生類時(shí),不必為那些未經(jīng)變化的操作添加基于規(guī)范的測(cè)試用例,測(cè)試用例能夠不加修改的復(fù)用。如果測(cè)試的操作沒有以任何方式加以修改,就不必運(yùn)行這些測(cè)試用例中的任何一個(gè)。但是,如果一個(gè)操作的方法被間接的修改了,不但需要重新運(yùn)行那些操作的任何一個(gè)測(cè)試用例,還需要運(yùn)行附加的機(jī)遇實(shí)現(xiàn)的測(cè)試用例。

4.2 抽象類測(cè)試

對(duì)類基于執(zhí)行的測(cè)試時(shí),需要建構(gòu)一個(gè)類的實(shí)例。然而,一個(gè)繼承體系的根類通常是抽象的,許多編程語(yǔ)言在語(yǔ)義上不允許建構(gòu)抽象類的實(shí)例。這位抽象類的測(cè)試帶來(lái)了很大的困難。在此,提出三種測(cè)試抽象類的方法:

1. 需要測(cè)試的抽象類單獨(dú)定義一個(gè)具體的子類。通過(guò)對(duì)具體子類創(chuàng)建的實(shí)例測(cè)試,來(lái)完成對(duì)抽象類的測(cè)試。這種方法的缺點(diǎn)是,如果不是用多層繼承,抽象類的方法的實(shí)現(xiàn)就不能輕易的傳遞給抽象子類。但是大部分面向?qū)ο蟮木幊陶Z(yǔ)言都不支持多重繼承,而且不提倡將多重繼承用在這些方面。

2. 將抽象類作為測(cè)試第一個(gè)具體子孫的一部分進(jìn)行測(cè)試。這種方法不需要開發(fā)額外的用于測(cè)試的目的類,但需要考慮到為每一個(gè)祖先提供恰當(dāng)?shù)摹⒄_的測(cè)試用例和測(cè)試腳本方法,而增加了測(cè)試具體類的復(fù)雜性。

3. 以對(duì)用于測(cè)試目的的抽象類的具體版本作直接實(shí)現(xiàn),嘗試找到一種為類編寫源代碼的方法,從而使得該類可以做為一個(gè)抽象或具體類而很容易編譯。然而,不管是基于編輯遺產(chǎn)方案還是基于條件編譯的方案都沒有產(chǎn)生好的結(jié)果。應(yīng)為合成代碼都很復(fù)雜,而且難以閱讀,很容易出錯(cuò)。

5.對(duì)象交互測(cè)試技術(shù)

面向?qū)ο蟮能浖怯扇舾蓪?duì)象組成的,通過(guò)這些對(duì)象的相續(xù)協(xié)作來(lái)解決某些問(wèn)題。對(duì)象的交互和寫作方式?jīng)Q定了程序能作什么,從而決定了這個(gè)程序執(zhí)行的正確性。也許可信任的原始類的實(shí)例可能不包含任何錯(cuò)誤,但是如果那個(gè)實(shí)例的服務(wù)部被其他程序組件正確的使用的話,那么這個(gè)程序也就包含了錯(cuò)誤。因此,程序中對(duì)象的正確協(xié)作——即交互——對(duì)于程序的正確性是非常關(guān)鍵的。

對(duì)象的交互測(cè)試的重點(diǎn)是確保對(duì)象(這些對(duì)象的類已經(jīng)被單獨(dú)測(cè)試過(guò))的消息傳送能夠正確進(jìn)行。交互測(cè)試的執(zhí)行可以使用嵌入到應(yīng)用程序中的交互對(duì)象,或者在獨(dú)立的測(cè)試工具(例如一個(gè) Tester 類)提供環(huán)境中,交互測(cè)試通過(guò)使得該環(huán)境中的對(duì)象相互交互而執(zhí)行。

根據(jù)類的類型可以將對(duì)向交互測(cè)試分為匯集類測(cè)試和協(xié)作類測(cè)試。

5.1.匯集類測(cè)試

匯集類指的是這樣的一種類,這些類在他們的說(shuō)明中使用對(duì)象,但是實(shí)際上從不和這些對(duì)象中的任何一個(gè)進(jìn)行協(xié)作——即他們從不請(qǐng)求這些對(duì)象的服務(wù)。相反,他們會(huì)表現(xiàn)出以下的一個(gè)或多個(gè)行為:

1. 存放這些對(duì)象的引用(或指針),通常表現(xiàn)程序中的對(duì)象之間一對(duì)多的關(guān)系。

2. 創(chuàng)建這些對(duì)象的實(shí)例。

3. 刪除這些對(duì)象的實(shí)例。

可以使用測(cè)試原始類的方法來(lái)測(cè)試匯集類,測(cè)試驅(qū)動(dòng)程序要?jiǎng)?chuàng)建一些實(shí)例,作為消息中的參數(shù)被傳送給一個(gè)正在測(cè)試的集合。測(cè)試用例的中心目的主要是保證那些實(shí)例被正確加入集合和被正確的從集合中移出,以及測(cè)試用例說(shuō)明的集合對(duì)其容量有所限制。因此,每個(gè)對(duì)象的準(zhǔn)確的類(這些對(duì)象是用在匯集類的測(cè)試中)在確定匯集類的正確操作是不重要的,因?yàn)樵谝粋€(gè)集合實(shí)例和集合中的對(duì)象之間沒有交互。假如在實(shí)際應(yīng)用中可能要加入 40 到 50 條信息,那么生成的測(cè)試用例至少要增加 50 條信息。如果無(wú)法估計(jì)出一個(gè)有代表性的上限,就必須使用集合中大量的對(duì)象進(jìn)行測(cè)試。

如果匯集類不能為增加的新元素分配內(nèi)存,就應(yīng)該測(cè)試這個(gè)匯集類的行為,或者是可變數(shù)組這一結(jié)構(gòu),往往一次就為若干條信息分配空間。在測(cè)試用例的執(zhí)行期間,可以使用異常機(jī)制,幫助測(cè)試人員限制在測(cè)試用例執(zhí)行期間可得到的內(nèi)存容量的分配情況。如果已經(jīng)使用了保護(hù)設(shè)計(jì)方法,那么,測(cè)試系列還應(yīng)該包括否定系列。即當(dāng)某些即和已擁有有限的制定容量,并且有實(shí)際的限制,則應(yīng)該用超過(guò)指定的容量限制的測(cè)試用例進(jìn)行測(cè)試。

5.2.協(xié)作類的測(cè)試

凡不是匯集類的非原始類(原始累即一些簡(jiǎn)單的,獨(dú)立的類,這些類可以用類測(cè)試方法進(jìn)行測(cè)試)就是協(xié)作類。這種類在它們的一個(gè)或多個(gè)操作中使用其它的對(duì)象并將其作為他們的實(shí)現(xiàn)中不可缺少的一部分。當(dāng)接口中的一個(gè)操作的某個(gè)后置條件引用了一個(gè)協(xié)作類的對(duì)象的實(shí)例狀態(tài),則說(shuō)明那個(gè)對(duì)象的屬性別使用或修改了。由此可見,寫作類的測(cè)試的復(fù)雜性遠(yuǎn)遠(yuǎn)高于匯集類或者原始類測(cè)試的復(fù)雜性。鑒于協(xié)助類的測(cè)試需要根據(jù)具體的情況來(lái)定,而具體情況復(fù)雜多變,在此,就方便不論述了。

6.面向?qū)ο笙到y(tǒng)測(cè)試技術(shù)

通過(guò)類測(cè)試、對(duì)象交互測(cè)試、類層次結(jié)構(gòu)測(cè)試,僅能保證軟件開發(fā)的功能得以實(shí)現(xiàn)。但不能確認(rèn)在實(shí)際運(yùn)行時(shí),它是否滿足用戶的需要,是否大量存在實(shí)際使用條件下會(huì)被誘發(fā)產(chǎn)生錯(cuò)誤的隱患。為此,對(duì)完成開發(fā)的軟件必須經(jīng)過(guò)規(guī)范的系統(tǒng)測(cè)試。換個(gè)角度說(shuō),開發(fā)完成的軟件僅僅是實(shí)際投入使用系統(tǒng)的一個(gè)組成部分,需要測(cè)試它與系統(tǒng)其他部分配套運(yùn)行的表現(xiàn),以保證在系統(tǒng)各部分協(xié)調(diào)工作的環(huán)境下也能正常工作。

系統(tǒng)測(cè)試應(yīng)該盡量搭建與用戶實(shí)際使用環(huán)境相同的測(cè)試平臺(tái),應(yīng)該保證被測(cè)系統(tǒng)的完整性,對(duì)臨時(shí)沒有的系統(tǒng)設(shè)備部件,也應(yīng)有相應(yīng)的模擬手段。系統(tǒng)測(cè)試時(shí),應(yīng)該參考 OOA 分析的結(jié)果,對(duì)應(yīng)描述的對(duì)象、屬性和各種服務(wù),檢測(cè)軟件是否能夠完全 "再現(xiàn)" 問(wèn)題空間。系統(tǒng)測(cè)試不僅是檢測(cè)軟件的整體行為表現(xiàn),從另一個(gè)側(cè)面看,也是對(duì)軟件開發(fā)設(shè)計(jì)的再確認(rèn)。

這里說(shuō)的系統(tǒng)測(cè)試是對(duì)測(cè)試步驟的抽象描述。它體現(xiàn)的具體測(cè)試內(nèi)容包括:

1. 功能測(cè)試:測(cè)試是否滿足開發(fā)要求,是否能夠提供設(shè)計(jì)所描述的功能,是否用戶的需求都得到滿足。功能測(cè)試是系統(tǒng)測(cè)試最常用和必須的測(cè)試,通常還會(huì)以正式的軟件說(shuō)明書為測(cè)試標(biāo)準(zhǔn)。

2. 強(qiáng)度測(cè)試:測(cè)試系統(tǒng)的能力最高實(shí)際限度,即軟件在一些超負(fù)荷的情況,功能實(shí)現(xiàn)情況。如要求軟件某一行為的大量重復(fù)、輸入大量的數(shù)據(jù)或大數(shù)值數(shù)據(jù)、對(duì)數(shù)據(jù)庫(kù)大量復(fù)雜的查詢等。

3. 性能測(cè)試:測(cè)試軟件的運(yùn)行性能。這種測(cè)試常常與強(qiáng)度測(cè)試結(jié)合進(jìn)行,需要事先對(duì)被測(cè)軟件提出性能指標(biāo),如傳輸連接的最長(zhǎng)時(shí)限、傳輸?shù)腻e(cuò)誤率、計(jì)算的精度、記錄的精度、響應(yīng)的時(shí)限和恢復(fù)時(shí)限等。

4. 安全測(cè)試:驗(yàn)證安裝在系統(tǒng)內(nèi)的保護(hù)機(jī)構(gòu)確實(shí)能夠?qū)ο到y(tǒng)進(jìn)行保護(hù),使之不受各種非常的干擾。安全測(cè)試時(shí)需要設(shè)計(jì)一些測(cè)試用例試圖突破系統(tǒng)的安全保密措施,檢驗(yàn)系統(tǒng)是否有安全保密的漏洞。

5. 恢復(fù)測(cè)試:采用人工的干擾使軟件出錯(cuò),中斷使用,檢測(cè)系統(tǒng)的恢復(fù)能力,特別是通訊系統(tǒng)。恢復(fù)測(cè)試時(shí),應(yīng)該參考性能測(cè)試的相關(guān)測(cè)試指標(biāo)。

6. 可用性測(cè)試:測(cè)試用戶是否能夠滿意使用。具體體現(xiàn)為操作是否方便,用戶界面是否友好等。

7. 安裝 / 卸載測(cè)試(install/uninstall test)等等。

系統(tǒng)測(cè)試需要對(duì)被測(cè)的軟件結(jié)合需求分析做仔細(xì)的測(cè)試分析,建立測(cè)試用例。

總 結(jié)

面向?qū)ο筌浖y(cè)試仍處于發(fā)展階段。本論文根據(jù)面向?qū)ο箝_發(fā)方法過(guò)程和特點(diǎn)討論了面向?qū)ο蟮能浖y(cè)試,提出了一系列實(shí)用的面向軟件測(cè)試技術(shù)。如,分析和設(shè)計(jì)模型測(cè)試技術(shù)、類測(cè)試技術(shù)、對(duì)象交互測(cè)試技術(shù)、類層次結(jié)構(gòu)測(cè)試技術(shù)、面向?qū)ο笙到y(tǒng)測(cè)試技術(shù)等。,盡管上面說(shuō)得很輕松,軟件測(cè)試是一項(xiàng)非常麻煩的工作因此。有一些常用的小技巧留給大家討論:

1. 盡早的開始測(cè)試工作

2. 從測(cè)試第一個(gè)模型開始應(yīng)用指導(dǎo)性檢查,直到模型不再更新。

3. 創(chuàng)建測(cè)試用例時(shí)使用 SYN-PATH 分析以確保覆蓋所有可能的故障。

4. 當(dāng)需要運(yùn)行的測(cè)試多于現(xiàn)有資源所能運(yùn)行的測(cè)試用例的測(cè)試時(shí),一定要考慮分層增量測(cè)試。

由于面向?qū)ο筌浖膹?fù)雜性,本文還有許多的面向?qū)ο筌浖y(cè)試的問(wèn)題還沒有討論到。比如,分布式系統(tǒng)的測(cè)試、對(duì)象的多態(tài)性和動(dòng)態(tài)綁定的測(cè)試等等。因此有待于進(jìn)一步研究

參 考 文 獻(xiàn)

[1] McGregor.J.D. 等著;楊文宏等譯.《面向?qū)ο蟮能浖y(cè)試》[M].機(jī)械工業(yè)出版社,2002.8.

[2] BinderRobertV.等著;華慶一,陳莉等譯.《面向?qū)ο笙到y(tǒng)的測(cè)試》[M].北京: 人民郵電出版社,2001

[3] 趙元聰,朱三元.面向?qū)ο筌浖y(cè)試的認(rèn)識(shí) [J].計(jì)算機(jī)應(yīng)用與軟件,1996,17(3):1~4

[4] 郭菏清主編.《現(xiàn)代軟件工程——原理,方法,與管理》[M].廣州:華南理工大學(xué)出版社,2004.2(2005.1)

[5] 齊治昌等編著.《軟件工程》[M].北京:高等教育出版社,2001.8(2002 重印)

[6] 鄭人杰等編著.《基于軟件能力成熟度模型(CMM)的軟件過(guò)程改進(jìn)——方法實(shí)施》[M]. 北京:清華大學(xué)出版社,2003

[7] 周夢(mèng)醒.面向?qū)ο筌浖臏y(cè)試 [OL].http://www.m1570.com/Article/article_view.asp?id=159,2006.2

[8] 姬瑩,羅鈞日,鐘聯(lián)炯.面向?qū)ο筌浖y(cè)試主要問(wèn)題的探討 [J].西安工業(yè)學(xué)院學(xué)報(bào),2001,21(1):31237

[9] 楊小平,王勝開.面向?qū)ο筌浖y(cè)試探討 [J].計(jì)算機(jī)工程與應(yīng)用,2000,36(1):44246.

[10] Ma Yu-Seung,Kwon Yong-Rae,Jeff Offutt.Inter-class mutation operators for Java [A].Thirteenth International Symposium on Software Reliability Engineering,Annapolis,MD,2002.

[11] Perry.D.E,Kaiser.G.E .《Adequate Testing and Object-oriented Programming》[M].Journal of Object-oriented Programming.1998, 2

[12] DUSTINE,RASHKAJ,PAULJ.Automated Software Testin[M].Addison2Wesley,1999.

[13] 作者不詳.使用面向?qū)ο蟮乃枷脒M(jìn)行測(cè)試(游戲測(cè)試相關(guān))[OL].http://www.iceshi.com/html/2006-3/200634044842188.htm,2006-3-4

[14] 張海藩.軟件工程導(dǎo)論 [M].北京:清華大學(xué)出版社,1998.

[15] 張毅坤.面向?qū)ο筌浖y(cè)試的特點(diǎn)及方法 [J].西安理工大學(xué)學(xué)報(bào),2002,18(4):361 365.



作者:西邊人

頭條號(hào)、公眾號(hào)請(qǐng)搜索(軟件測(cè)試資源站)

關(guān)注后私信回復(fù) 【入群】,加入自學(xué)微信社群聯(lián)盟。

QQ群:3303744

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,698評(píng)論 6 539
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異,居然都是意外死亡,警方通過(guò)查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 99,202評(píng)論 3 426
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái),“玉大人,你說(shuō)我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 177,742評(píng)論 0 382
  • 文/不壞的土叔 我叫張陵,是天一觀的道長(zhǎng)。 經(jīng)常有香客問(wèn)我,道長(zhǎng),這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,580評(píng)論 1 316
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 72,297評(píng)論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,688評(píng)論 1 327
  • 那天,我揣著相機(jī)與錄音,去河邊找鬼。 笑死,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,693評(píng)論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來(lái)了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,875評(píng)論 0 289
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 49,438評(píng)論 1 335
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 41,183評(píng)論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 43,384評(píng)論 1 372
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,931評(píng)論 5 363
  • 正文 年R本政府宣布,位于F島的核電站,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,612評(píng)論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,022評(píng)論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,297評(píng)論 1 292
  • 我被黑心中介騙來(lái)泰國(guó)打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 52,093評(píng)論 3 397
  • 正文 我出身青樓,卻偏偏與公主長(zhǎng)得像,于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 48,330評(píng)論 2 377

推薦閱讀更多精彩內(nèi)容

  • 1.測(cè)試與軟件模型 軟件開發(fā)生命周期模型指的是軟件開發(fā)全過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)性框架。軟件項(xiàng)目的開發(fā)包括:需求、設(shè)...
    Mr希靈閱讀 21,980評(píng)論 7 278
  • 1.測(cè)試與軟件模型 軟件開發(fā)生命周期模型指的是軟件開發(fā)全過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)性框架。軟件項(xiàng)目的開發(fā)包括:需求、設(shè)...
    宇文臭臭閱讀 6,743評(píng)論 5 100
  • 文章來(lái)自:http://blog.csdn.net/mj813/article/details/52451355 ...
    好大一只鵬閱讀 9,212評(píng)論 2 126
  • 黑盒測(cè)試案例設(shè)計(jì)技術(shù)篇 1 概述 本章介紹黑盒測(cè)試的概念和進(jìn)行黑盒測(cè)試的目的與意義,及關(guān)于等價(jià)類劃分、邊界值分析、...
    西邊人閱讀 17,011評(píng)論 0 41
  • 黑眼圈:一早起來(lái),發(fā)現(xiàn)眼睛四周暗沈、眼圈發(fā)黑?小心了!這可能是血液中沈積太多廢物的緣故。下眼瞼皮膚比其他部位薄,最...
    小蘇女閱讀 215評(píng)論 0 1