軟件工程的實(shí)驗(yàn)測(cè)試策略_第1頁
軟件工程的實(shí)驗(yàn)測(cè)試策略_第2頁
軟件工程的實(shí)驗(yàn)測(cè)試策略_第3頁
軟件工程的實(shí)驗(yàn)測(cè)試策略_第4頁
軟件工程的實(shí)驗(yàn)測(cè)試策略_第5頁
已閱讀5頁,還剩80頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

軟件工程的實(shí)驗(yàn)測(cè)試策略第12章軟件測(cè)試策略軟件工程的實(shí)驗(yàn)測(cè)試策略主要內(nèi)容軟件測(cè)試的策略性方法策略問題傳統(tǒng)軟件的測(cè)試策略面向?qū)ο筌浖臏y(cè)試策略確認(rèn)測(cè)試系統(tǒng)測(cè)試調(diào)試技巧小結(jié)軟件工程的實(shí)驗(yàn)測(cè)試策略軟件測(cè)試策略軟件測(cè)試的目的是為了發(fā)現(xiàn)軟件設(shè)計(jì)和實(shí)現(xiàn)過程中的疏忽所造成的錯(cuò)誤。但是,如何進(jìn)行測(cè)試?是否應(yīng)該制定正式的測(cè)試計(jì)劃?是應(yīng)該將整個(gè)程序作為一個(gè)整體來測(cè)試,還是應(yīng)該只測(cè)試其中的一部分?當(dāng)向一個(gè)大型系統(tǒng)加入新的構(gòu)件時(shí),是否需要重新測(cè)試已經(jīng)測(cè)過的部分?什么時(shí)候需要客戶介入測(cè)試工作?當(dāng)制定測(cè)試策略時(shí),就需要回答上述及其他一些問題。軟件工程的實(shí)驗(yàn)測(cè)試策略軟件測(cè)試策略測(cè)試所花費(fèi)的工作量經(jīng)常比其他任何軟件工程活動(dòng)都多。若測(cè)試是無計(jì)劃地進(jìn)行,既浪費(fèi)時(shí)間,又浪費(fèi)不必要的勞動(dòng)。甚至更糟的是,錯(cuò)誤會(huì)依然存在。因此,為測(cè)試軟件建立系統(tǒng)化的測(cè)試策略是合情合理的。軟件工程的實(shí)驗(yàn)測(cè)試策略軟件測(cè)試策略測(cè)試從“小規(guī)?!遍_始,進(jìn)展到“大規(guī)模”。這意味著,早期的測(cè)試關(guān)注單個(gè)構(gòu)件或相關(guān)的一小組構(gòu)件,利用測(cè)試發(fā)現(xiàn)構(gòu)件中的數(shù)據(jù)和處理邏輯錯(cuò)誤。當(dāng)單個(gè)的構(gòu)件被測(cè)試完后,需要將構(gòu)件集成直到建成整個(gè)系統(tǒng)。這時(shí),執(zhí)行一系列的高階測(cè)試以發(fā)現(xiàn)在滿足顧客需求方面的錯(cuò)誤。隨著錯(cuò)誤的發(fā)現(xiàn),必須利用調(diào)試過程進(jìn)行診斷和糾正。軟件工程的實(shí)驗(yàn)測(cè)試策略軟件測(cè)試策略測(cè)試規(guī)格說明是將軟件測(cè)試團(tuán)隊(duì)的測(cè)試具體作法文檔化。這主要包括制定描述整體策略的計(jì)劃、定義特定測(cè)試步驟的規(guī)程以及規(guī)定將要進(jìn)行的測(cè)試。通過在測(cè)試進(jìn)行之前評(píng)審測(cè)試規(guī)格說明,可以評(píng)估測(cè)試用例以及測(cè)試任務(wù)的完整性。有效的測(cè)試計(jì)劃和規(guī)程將導(dǎo)致軟件的有規(guī)則地構(gòu)造,并且能夠發(fā)現(xiàn)構(gòu)造過程中各個(gè)階段引入的錯(cuò)誤。軟件工程的實(shí)驗(yàn)測(cè)試策略軟件測(cè)試策略軟件測(cè)試策略將軟件測(cè)試用例的設(shè)計(jì)方法集成到一系列經(jīng)周密計(jì)劃的步驟中去,從而使軟件構(gòu)造成功地完成。測(cè)試策略提供以下方面的路徑圖:描述將要進(jìn)行的測(cè)試步驟,這些步驟計(jì)劃和執(zhí)行的時(shí)機(jī),需要多少工作量、時(shí)間和資源。因此,任何測(cè)試策略都必須包含測(cè)試計(jì)劃、測(cè)試用例設(shè)計(jì)、測(cè)試執(zhí)行以及測(cè)試結(jié)果數(shù)據(jù)的收集與評(píng)估。軟件工程的實(shí)驗(yàn)測(cè)試策略軟件測(cè)試的策略性方法測(cè)試是可以事先計(jì)劃并可以系統(tǒng)地進(jìn)行的一系列活動(dòng)。因此,應(yīng)該為軟件過程定義軟件測(cè)試模板,即將特定的測(cè)試用例設(shè)計(jì)技術(shù)和測(cè)試方法放在一系列的測(cè)試步驟中去。為完成有效的測(cè)試,軟件團(tuán)隊(duì)?wèi)?yīng)該進(jìn)行有效的、正式的技術(shù)評(píng)審。通過評(píng)審,許多錯(cuò)誤可以在測(cè)試開始之前排除。測(cè)試開始于構(gòu)件層,然后向外“延伸”到整個(gè)基于計(jì)算機(jī)系統(tǒng)的集成。軟件工程的實(shí)驗(yàn)測(cè)試策略軟件測(cè)試的策略性方法不同的測(cè)試技術(shù)適用于不同的時(shí)間點(diǎn)。測(cè)試由軟件開發(fā)人員和(對(duì)大型項(xiàng)目而言)獨(dú)立的測(cè)試組執(zhí)行。測(cè)試和調(diào)試是不同的活動(dòng),但任何測(cè)試策略中都必須包括調(diào)試。軟件測(cè)試策略必須提供用來驗(yàn)證小段源代碼是否正確實(shí)現(xiàn)的必要的低級(jí)測(cè)試,以及用來確認(rèn)系統(tǒng)的主要功能是否滿足用戶需求的高級(jí)測(cè)試。軟件測(cè)試策略必須為專業(yè)人員提供工作指南,同時(shí),為管理者提供一系列的里程碑。由于測(cè)試策略的步驟是在軟件完成的最后期限的壓力已逐步呈現(xiàn)的時(shí)候才開始進(jìn)行的,因此,測(cè)試的進(jìn)度必須是可測(cè)量的,應(yīng)該讓問題盡可能早地暴露。軟件工程的實(shí)驗(yàn)測(cè)試策略驗(yàn)證與確認(rèn)軟件測(cè)試是通常所講的更為廣泛的主題——驗(yàn)證與確認(rèn)的一部分。驗(yàn)證是指確保軟件正確地實(shí)現(xiàn)某一特定功能的一系列活動(dòng)。確認(rèn)則指的是確保開發(fā)的軟件可追溯到用戶需求的另外一系列活動(dòng)。[BOE81]用另一種方式說明了這兩者的區(qū)別:

驗(yàn)證:我們?cè)谡_地構(gòu)造產(chǎn)品嗎?

確認(rèn):我們?cè)跇?gòu)造正確的產(chǎn)品嗎?驗(yàn)證和確認(rèn)包含了廣泛的SQA活動(dòng),其中包括正式技術(shù)評(píng)審、質(zhì)量和配置審核、性能監(jiān)控、仿真、可行性研究、文檔評(píng)審、數(shù)據(jù)庫評(píng)審、算法分析、開發(fā)測(cè)試、易用性測(cè)試、合格性測(cè)試以及安裝測(cè)試。軟件工程的實(shí)驗(yàn)測(cè)試策略驗(yàn)證與確認(rèn)測(cè)試確實(shí)為軟件質(zhì)量的評(píng)估提供最后的防線。在軟件工程的整個(gè)過程中,質(zhì)量體現(xiàn)在軟件之中。在測(cè)試過程中,方法和工具的正確運(yùn)用、有效的正式技術(shù)評(píng)審、穩(wěn)固的管理與測(cè)量,都有助于得到讓人認(rèn)可的質(zhì)量。[MIL77]將軟件測(cè)試和質(zhì)量保證聯(lián)系在一起,他認(rèn)為:“無論是大規(guī)模系統(tǒng)還是小規(guī)模系統(tǒng),程序測(cè)試的根本動(dòng)機(jī)都是使用經(jīng)濟(jì)且能有效應(yīng)用的方法來認(rèn)可軟件質(zhì)量?!避浖こ痰膶?shí)驗(yàn)測(cè)試策略軟件測(cè)試的組織對(duì)每個(gè)軟件項(xiàng)目而言,在測(cè)試開始時(shí)總會(huì)在不同人員之間存在認(rèn)識(shí)上的差異。這時(shí)要求開發(fā)軟件的人員對(duì)該軟件進(jìn)行測(cè)試。從心理學(xué)的觀點(diǎn)來看,軟件分析和設(shè)計(jì)是建設(shè)性的任務(wù)。以開發(fā)者的觀點(diǎn)來看,測(cè)試可以認(rèn)為是破壞性的。因此,開發(fā)者精心地設(shè)計(jì)和執(zhí)行測(cè)試,試圖證明其程序的正確性,而不是注意發(fā)現(xiàn)錯(cuò)誤。遺憾的是,錯(cuò)誤是存在的,而且,如果軟件工程師沒有找到錯(cuò)誤,用戶也會(huì)發(fā)現(xiàn)。軟件工程的實(shí)驗(yàn)測(cè)試策略軟件測(cè)試的組織人們可能會(huì)產(chǎn)生誤解:(1)軟件開發(fā)人員根本不應(yīng)該做測(cè)試;(2)應(yīng)當(dāng)讓那些無情地愛挑毛病的陌生人做軟件測(cè)試;(3)測(cè)試人員僅在測(cè)試步驟即將開始時(shí)參與項(xiàng)目。這些想法都是不正確的。軟件開發(fā)人員總是要負(fù)責(zé)程序的個(gè)別單元的測(cè)試,確保每個(gè)單元完成其功能或顯示出被設(shè)計(jì)的行為。在多數(shù)情況下,開發(fā)者也進(jìn)行集成測(cè)試。集成測(cè)試是其中一個(gè)測(cè)試步驟,它將給出整個(gè)軟件體系結(jié)構(gòu)的構(gòu)造。只有在軟件體系結(jié)構(gòu)完成后,獨(dú)立的測(cè)試組才開始介入。軟件工程的實(shí)驗(yàn)測(cè)試策略軟件測(cè)試的組織獨(dú)立測(cè)試組ITG的作用是為了避免開發(fā)人員進(jìn)行測(cè)試所引發(fā)的固有問題。獨(dú)立測(cè)試可以消除可能存在的認(rèn)識(shí)差異。然而,軟件開發(fā)人員并不是將程序交給獨(dú)立測(cè)試組就可以一走了之。在整個(gè)軟件項(xiàng)目中,開發(fā)人員和測(cè)試組密切配合以確保測(cè)試嚴(yán)格地進(jìn)行。在測(cè)試進(jìn)行的過程中,必須隨時(shí)可以找到開發(fā)人員,以便及時(shí)修改發(fā)現(xiàn)的錯(cuò)誤。從分析與設(shè)計(jì)開始到計(jì)劃和制定測(cè)試規(guī)程,ITG參與整個(gè)項(xiàng)目過程。從這種意義上講,ITG是大型軟件開發(fā)項(xiàng)目組的一部分。然而,在多數(shù)情況下,ITG直接對(duì)軟件質(zhì)量保證組織負(fù)責(zé),由此獲得一定程度的獨(dú)立性。若ITG是軟件工程組織的一部分,則這種獨(dú)立性是不可能獲得的。軟件工程的實(shí)驗(yàn)測(cè)試策略傳統(tǒng)軟件體系結(jié)構(gòu)的測(cè)試策略軟件過程可以看作圖12-1所示的螺旋。開始時(shí)系統(tǒng)工程定義軟件的角色,從而引出軟件需求分析,在需求分析中建立軟件的信息域、功能、行為、性能、約束和確認(rèn)標(biāo)準(zhǔn)。沿著螺旋向內(nèi),經(jīng)過設(shè)計(jì)階段,最后到達(dá)編碼階段。為開發(fā)計(jì)算機(jī)軟件,沿著流線螺旋前進(jìn),每走一圈都會(huì)降低軟件的抽象層次。軟件工程的實(shí)驗(yàn)測(cè)試策略傳統(tǒng)軟件體系結(jié)構(gòu)的測(cè)試策略圖12-1測(cè)試策略軟件工程的實(shí)驗(yàn)測(cè)試策略傳統(tǒng)軟件體系結(jié)構(gòu)的測(cè)試策略軟件測(cè)試策略也可以放在螺旋模型中來考慮。單元測(cè)試起始于螺旋的旋渦中心,側(cè)重于以源代碼形式實(shí)現(xiàn)的每個(gè)單元(即構(gòu)件)。沿著螺旋向外,就是集成測(cè)試,這時(shí)的測(cè)試重點(diǎn)在于軟件體系結(jié)構(gòu)的設(shè)計(jì)和構(gòu)造。沿著螺旋向外再走一圈,就是確認(rèn)測(cè)試,在這個(gè)階段,依據(jù)已經(jīng)建立的軟件,對(duì)需求進(jìn)行確認(rèn)。最后到達(dá)系統(tǒng)測(cè)試階段,將軟件與系統(tǒng)的其他成分作為一個(gè)整體來測(cè)試。為了測(cè)試計(jì)算機(jī)軟件,沿著流線向螺旋前進(jìn),每轉(zhuǎn)一圈都拓寬了測(cè)試范圍。軟件工程的實(shí)驗(yàn)測(cè)試策略傳統(tǒng)軟件體系結(jié)構(gòu)的測(cè)試策略以過程的觀點(diǎn)考慮整個(gè)測(cè)試過程,軟件工程環(huán)境中的測(cè)試實(shí)際上就是按順序?qū)崿F(xiàn)四個(gè)步驟,如圖12-2所示。圖12-2軟件測(cè)試步驟軟件工程的實(shí)驗(yàn)測(cè)試策略傳統(tǒng)軟件體系結(jié)構(gòu)的測(cè)試策略最初,測(cè)試側(cè)重于單個(gè)構(gòu)件,確保它完全作為一個(gè)單元來起作用,因此稱之為單元測(cè)試。單元測(cè)試充分利用測(cè)試技術(shù),檢查構(gòu)件中每個(gè)控制結(jié)構(gòu)的特定路徑以確保完全覆蓋,并最大可能地發(fā)現(xiàn)錯(cuò)誤。接下來,組裝或集成各個(gè)構(gòu)件以形成完整的軟件包。集成測(cè)試處理并并驗(yàn)證與程序構(gòu)造相關(guān)的問題。在集成過程中,普遍使用關(guān)注輸入和輸出的測(cè)試用例設(shè)計(jì)技術(shù)。在軟件集成完成之后,要執(zhí)行一系列的高階測(cè)試,必須評(píng)估確認(rèn)準(zhǔn)則。確認(rèn)測(cè)試為軟件滿足所有的功能、行為和性能需求提供最后的保證。最后高階測(cè)試這一步已經(jīng)超出軟件工程的邊界,進(jìn)入更為廣泛的計(jì)算機(jī)系統(tǒng)工程的范圍。軟件一旦確認(rèn),就必須與其他系統(tǒng)成分結(jié)合在一起。系統(tǒng)測(cè)試驗(yàn)證所有的成分能合適地結(jié)合在一起,且能滿足整個(gè)系統(tǒng)的功能/性能需求。軟件工程的實(shí)驗(yàn)測(cè)試策略面向?qū)ο筌浖w系結(jié)構(gòu)的測(cè)試策略面向?qū)ο笙到y(tǒng)的測(cè)試為軟件工程師提出了不同的挑戰(zhàn)。測(cè)試的定義必須拓寬以包括運(yùn)用于分析和設(shè)計(jì)模型中的錯(cuò)誤發(fā)現(xiàn)技術(shù)。當(dāng)建立面向?qū)ο蟊硎緯r(shí),必須評(píng)估其完整性和一致性。單元測(cè)試已失去其部分意義,而且集成策略也發(fā)生了很大變化??偠灾?,測(cè)試策略和測(cè)試戰(zhàn)術(shù)都必須考慮面向?qū)ο筌浖奶赜刑卣?。軟件工程的?shí)驗(yàn)測(cè)試策略面向?qū)ο筌浖w系結(jié)構(gòu)的測(cè)試策略面向?qū)ο筌浖y(cè)試的總體策略在思想上與用于傳統(tǒng)體系結(jié)構(gòu)的策略是一致的,但測(cè)試方法是不同的。從“小型測(cè)試”開始,逐步走向“大型測(cè)試”。然而,當(dāng)進(jìn)行“小型測(cè)試”時(shí),重點(diǎn)由單個(gè)模塊測(cè)試變換為包含屬性和操作且隱含著通信與協(xié)作的類的測(cè)試。隨著將類集成為一個(gè)面向?qū)ο篌w系結(jié)構(gòu),運(yùn)行一系列的集成測(cè)試以發(fā)現(xiàn)由于類間的通信與協(xié)作產(chǎn)生的錯(cuò)誤以及新類的加入而引起的副作用。最后,作為一個(gè)整體來測(cè)試系統(tǒng),以確保發(fā)現(xiàn)需求中的錯(cuò)誤。軟件工程的實(shí)驗(yàn)測(cè)試策略測(cè)試完成的標(biāo)準(zhǔn)每當(dāng)討論軟件測(cè)試時(shí),就會(huì)引出一個(gè)標(biāo)準(zhǔn)問題:測(cè)試什么時(shí)候才算做完?怎么知道我們已做了足夠的測(cè)試?對(duì)上述問題的一個(gè)答復(fù)是:你永遠(yuǎn)也不能完成測(cè)試,這個(gè)擔(dān)子只會(huì)從你(軟件工程師)身上轉(zhuǎn)移到你的客戶身上??蛻?用戶每次運(yùn)行計(jì)算機(jī)程序時(shí),程序就在經(jīng)受測(cè)試。另一個(gè)答復(fù)是:當(dāng)你的時(shí)間或資金不夠時(shí),測(cè)試就完成了。軟件工程的實(shí)驗(yàn)測(cè)試策略測(cè)試完成的標(biāo)準(zhǔn)盡管少數(shù)實(shí)踐者會(huì)對(duì)這些答復(fù)產(chǎn)生異議,但是軟件工程師需要更嚴(yán)格的標(biāo)準(zhǔn)以確定什么時(shí)候已經(jīng)做完充足的測(cè)試。[MUS89]提出了一個(gè)基于統(tǒng)計(jì)標(biāo)準(zhǔn)的答復(fù):“不,我們不能絕對(duì)地認(rèn)為軟件從不失敗,但相對(duì)于一個(gè)理論上正確的、經(jīng)過實(shí)踐驗(yàn)證的統(tǒng)計(jì)模型而言,如果在按照概率方法定義的環(huán)境中,1000個(gè)CPU小時(shí)內(nèi)無故障運(yùn)行的概率大于,那么我們就有95%的信心說已經(jīng)進(jìn)行了足夠的測(cè)試“。利用統(tǒng)計(jì)建模和軟件可靠性理論,可以建立以執(zhí)行時(shí)間為函數(shù)的軟件故障模型。軟件工程的實(shí)驗(yàn)測(cè)試策略策略問題如果想實(shí)現(xiàn)一個(gè)成功的軟件測(cè)試策略,必須解決下述問題:早在開始測(cè)試之前,就要以量化的方式規(guī)定產(chǎn)品需求。盡管測(cè)試的主要目的是查找錯(cuò)誤,但是一個(gè)好的測(cè)試策略也能評(píng)估其他質(zhì)量特性,如可移植性、可維護(hù)性和易用性。這些都應(yīng)該以可測(cè)量的方式加以規(guī)定,從而保證測(cè)試結(jié)果的無歧義性。軟件工程的實(shí)驗(yàn)測(cè)試策略策略問題顯式地陳述測(cè)試目標(biāo):測(cè)試的特定目標(biāo)應(yīng)該用可測(cè)量的術(shù)語進(jìn)行陳述。例如,測(cè)試的有效性、測(cè)試的覆蓋率、故障出現(xiàn)的平均時(shí)間、發(fā)現(xiàn)和修正缺陷的成本、剩余缺陷的密度或出現(xiàn)頻率、每次回歸測(cè)試的工作時(shí)間,這些都應(yīng)當(dāng)在測(cè)試計(jì)劃中清晰地描述。了解軟件的用戶并為每類用戶建立用戶輪廓。為每類用戶描述交互場(chǎng)景的用例,側(cè)重于測(cè)試產(chǎn)品的實(shí)際使用,可以減少整個(gè)測(cè)試的工作量。建立強(qiáng)調(diào)”快速周期測(cè)試“的測(cè)試計(jì)劃。[GIL95]建議軟件工程團(tuán)隊(duì)“對(duì)客戶有用的功能增量和(或)質(zhì)量改進(jìn),學(xué)會(huì)以快速周期進(jìn)行測(cè)試?!?。從這些快速周期測(cè)試中得到的反饋可用于控制質(zhì)量的等級(jí)和相應(yīng)的測(cè)試策略。軟件工程的實(shí)驗(yàn)測(cè)試策略策略問題建立能夠測(cè)試自身的“健壯”軟件。軟件應(yīng)該利用防錯(cuò)技術(shù)進(jìn)行設(shè)計(jì)。也就是說,軟件應(yīng)該能夠診斷某類錯(cuò)誤。另外,軟件設(shè)計(jì)應(yīng)該包括自動(dòng)化測(cè)試和回歸測(cè)試。測(cè)試之前,利用有效的正式技術(shù)評(píng)審作為過濾器。在發(fā)現(xiàn)錯(cuò)誤方面,正式技術(shù)評(píng)審與測(cè)試一樣有效。因此評(píng)審可以減少生產(chǎn)高質(zhì)量軟件所需的測(cè)試工作量。軟件工程的實(shí)驗(yàn)測(cè)試策略策略問題實(shí)施正式技術(shù)評(píng)審以評(píng)估測(cè)試策略和測(cè)試用例本身。正式技術(shù)評(píng)審能夠發(fā)現(xiàn)測(cè)試方法中的不一致、遺漏和明顯的錯(cuò)誤。這節(jié)省了時(shí)間,也提高了產(chǎn)品質(zhì)量。為測(cè)試過程建立一種持續(xù)的改進(jìn)方法。測(cè)試策略應(yīng)該是可以測(cè)量的。測(cè)試過程中收集的度量數(shù)據(jù)應(yīng)當(dāng)作為軟件測(cè)試的統(tǒng)計(jì)過程控制方法的一部分。軟件工程的實(shí)驗(yàn)測(cè)試策略傳統(tǒng)軟件的測(cè)試策略許多策略可用于測(cè)試軟件。其中一個(gè)極端是,軟件團(tuán)隊(duì)等到系統(tǒng)完全建成后對(duì)整個(gè)系統(tǒng)執(zhí)行測(cè)試以期望發(fā)現(xiàn)錯(cuò)誤。這種方法盡管比較受歡迎,但效果不好;可能給出的是包含許多缺陷的軟件,致使客戶和最終用戶感到失望。另一個(gè)極端是,無論系統(tǒng)任何一部分何時(shí)建成,軟件工程師每天都在進(jìn)行測(cè)試。這種方法盡管不受多數(shù)人歡迎,但確實(shí)很有效。多數(shù)軟件團(tuán)隊(duì)選擇介于這兩者之間的測(cè)試策略。這種策略以漸進(jìn)的觀點(diǎn)對(duì)待測(cè)試,以個(gè)別程序單元的測(cè)試為起點(diǎn),逐步轉(zhuǎn)移到方便于單元集成的測(cè)試,最后以實(shí)施整個(gè)系統(tǒng)的測(cè)試而告終。軟件工程的實(shí)驗(yàn)測(cè)試策略單元測(cè)試單元測(cè)試側(cè)重于軟件設(shè)計(jì)的最小單元的驗(yàn)證工作。利用構(gòu)件級(jí)設(shè)計(jì)描述作為指南,測(cè)試重要的控制路徑以發(fā)現(xiàn)模塊內(nèi)的錯(cuò)誤。測(cè)試的相對(duì)復(fù)雜度和這類測(cè)試發(fā)現(xiàn)的錯(cuò)誤受到單元測(cè)試約束范圍的限制。單元測(cè)試側(cè)重于構(gòu)件中的內(nèi)部處理邏輯和數(shù)據(jù)結(jié)構(gòu)。這種類型的測(cè)試可以對(duì)多個(gè)構(gòu)件并行執(zhí)行。軟件工程的實(shí)驗(yàn)測(cè)試策略單元測(cè)試考慮作為單元測(cè)試一部分的測(cè)試如圖12-3所示。圖12-3單元測(cè)試軟件工程的實(shí)驗(yàn)測(cè)試策略單元測(cè)試考慮測(cè)試模塊的接口是為了保證被測(cè)程序單元的信息能夠正常地流入和流出;檢查局部數(shù)據(jù)結(jié)構(gòu)以確保臨時(shí)存儲(chǔ)的數(shù)據(jù)在算法的整個(gè)執(zhí)行過程中能維護(hù)其完整性;走遍控制結(jié)構(gòu)中的所有獨(dú)立路徑以確保模塊中的所有語句至少執(zhí)行一次;測(cè)試邊界條件以確保模塊在到達(dá)邊界值的極限或受限處理的情形下仍能正確執(zhí)行。最后,要對(duì)所有的錯(cuò)誤處理路徑進(jìn)行測(cè)試。對(duì)穿越模塊接口的數(shù)據(jù)流的測(cè)試要在任何其他測(cè)試開始之前進(jìn)行。若數(shù)據(jù)不能正確地輸入輸出,其他的測(cè)試都是沒有意義的。另外,應(yīng)當(dāng)測(cè)試局部數(shù)據(jù)結(jié)構(gòu),可能的話,在單元測(cè)試期間確定對(duì)全局?jǐn)?shù)據(jù)的局部影響。軟件工程的實(shí)驗(yàn)測(cè)試策略單元測(cè)試考慮在單元測(cè)試期間,選擇測(cè)試的執(zhí)行路徑是最基本的任務(wù)。測(cè)試用例的設(shè)計(jì)目的指在發(fā)現(xiàn)因錯(cuò)誤計(jì)算、不正確的比較或不適當(dāng)?shù)目刂屏鞫鸬腻e(cuò)誤。邊界測(cè)試是單元測(cè)試中一項(xiàng)最重要的任務(wù)。軟件通常在邊界處出錯(cuò),即錯(cuò)誤行為往往出現(xiàn)在處理n維數(shù)組的第n個(gè)元素,或者i次循環(huán)的第i次調(diào)用,或者遇到允許出現(xiàn)的最大、最小數(shù)值時(shí)。使用剛好小于、等于或大于最大值和最小值的數(shù)據(jù)結(jié)構(gòu)、控制流和數(shù)值作為測(cè)試用例就很有可能發(fā)現(xiàn)錯(cuò)誤。軟件工程的實(shí)驗(yàn)測(cè)試策略單元測(cè)試規(guī)程單元測(cè)試通常被認(rèn)為是編碼階段的附屬工作。單元測(cè)試的設(shè)計(jì)可以在編碼開始之前或源代碼生成之后完成。設(shè)計(jì)信息的評(píng)審可以指導(dǎo)建立發(fā)現(xiàn)前面所討論的各類錯(cuò)誤的測(cè)試用例,每個(gè)測(cè)試用例都應(yīng)與一組預(yù)期結(jié)果聯(lián)系在一起。由于構(gòu)件并不是獨(dú)立的程序,因此,必須為每個(gè)測(cè)試單元開發(fā)驅(qū)動(dòng)軟件和(或)樁軟件。單元測(cè)試環(huán)境如圖12-4所示。軟件工程的實(shí)驗(yàn)測(cè)試策略單元測(cè)試規(guī)程圖12-4單元測(cè)試環(huán)境軟件工程的實(shí)驗(yàn)測(cè)試策略單元測(cè)試規(guī)程在大多數(shù)應(yīng)用中,驅(qū)動(dòng)程序只是一個(gè)“主程序”,它接收測(cè)試用例數(shù)據(jù),將這些數(shù)據(jù)傳遞給構(gòu)件并打印相關(guān)結(jié)果。樁程序的作用是替換那些從屬于將要測(cè)試的構(gòu)件或被其調(diào)用的構(gòu)件。樁程序或“偽程序”使用從屬模塊的接口,可能做少量的數(shù)據(jù)操作,提供入口的驗(yàn)證,并將控制返回到被測(cè)模塊。軟件工程的實(shí)驗(yàn)測(cè)試策略單元測(cè)試規(guī)程驅(qū)動(dòng)程序和樁程序代表著額外的工作。即兩者都必須要寫但并不與最終的軟件產(chǎn)品一起交付的軟件。若驅(qū)動(dòng)程序和樁程序比較簡單,則實(shí)際的額外開銷就會(huì)相對(duì)比較低。當(dāng)構(gòu)件具有高內(nèi)聚性時(shí),可簡化單元測(cè)試。當(dāng)一個(gè)構(gòu)件只強(qiáng)調(diào)一個(gè)功能時(shí),測(cè)試用例數(shù)就會(huì)降低,且比較容易預(yù)見和發(fā)現(xiàn)錯(cuò)誤。軟件工程的實(shí)驗(yàn)測(cè)試策略集成測(cè)試集成測(cè)試是構(gòu)造軟件體系結(jié)構(gòu)的系統(tǒng)化技術(shù),同時(shí)也是進(jìn)行一些旨在發(fā)現(xiàn)與接口相關(guān)的錯(cuò)誤的測(cè)試。其目標(biāo)是利用已通過單元測(cè)試的構(gòu)件建立設(shè)計(jì)中描述的程序結(jié)構(gòu)。常常存在一種非增量集成的傾向,即利用“一步到位”的方式來構(gòu)造程序。所有的構(gòu)件都事先連接在一起,全部程序作為一個(gè)整體進(jìn)行測(cè)試,其結(jié)果往往是一片混亂!會(huì)出現(xiàn)一大堆錯(cuò)誤。由于在整個(gè)程序的廣闊區(qū)域中分離出錯(cuò)的原因非常復(fù)雜,因此,改正錯(cuò)誤比較困難。一旦改正了這些錯(cuò)誤,可能又會(huì)出現(xiàn)新的錯(cuò)誤。這個(gè)過程似乎會(huì)以一個(gè)無限循環(huán)的方式繼續(xù)下去。軟件工程的實(shí)驗(yàn)測(cè)試策略集成測(cè)試增量集成與“一步到位“的集成方法相反。程序以小增量的方式逐步進(jìn)行構(gòu)造和測(cè)試,這樣錯(cuò)誤易于分離和糾正,更易于對(duì)接口進(jìn)行徹底測(cè)試,而且可以運(yùn)用系統(tǒng)化的測(cè)試方法。軟件工程的實(shí)驗(yàn)測(cè)試策略自頂向下集成自頂向下集成測(cè)試是一種構(gòu)造軟件體系結(jié)構(gòu)的增量方法。模塊的集成順序從主控模塊開始,沿著控制層次結(jié)構(gòu)逐步向下,利用深度優(yōu)先或廣度優(yōu)先的方式將從屬于主控模塊的模塊集成到結(jié)構(gòu)中去。如圖12-5所示。軟件工程的實(shí)驗(yàn)測(cè)試策略自頂向下集成圖12-5自頂向下集成軟件工程的實(shí)驗(yàn)測(cè)試策略自頂向下集成集成過程可以通過5個(gè)步驟完成:1、主控模塊用作測(cè)試驅(qū)動(dòng)程序,所有的樁模塊替換為直接從屬于主控模塊的模塊;2、依靠所選擇的集成方法,用實(shí)際模塊一次一個(gè)地替換從屬樁模塊;3、每個(gè)模塊集成時(shí)都執(zhí)行測(cè)試;4、在完成每個(gè)測(cè)試集之后,用實(shí)際模塊替換另一個(gè)樁模塊;5、可以執(zhí)行回歸測(cè)試以確保沒有引入新的錯(cuò)誤。整個(gè)過程回到第2步繼續(xù)循環(huán)進(jìn)行,直到整個(gè)程序的構(gòu)造完成。軟件工程的實(shí)驗(yàn)測(cè)試策略自底向上集成自底向上集成測(cè)試,就是從原子模塊開始進(jìn)行構(gòu)造和測(cè)試。由于構(gòu)件是自底向上集成的,在處理時(shí)所需要的從屬于給定層次的模塊總是存在的。因此,沒有必要使用樁模塊。自底向上集成策略可以利用以下步驟來實(shí)現(xiàn):1、連接低層構(gòu)件以構(gòu)成完成特定子功能的簇;2、寫驅(qū)動(dòng)程序以協(xié)調(diào)測(cè)試用例的輸入和輸出;3、測(cè)試簇;4、去掉驅(qū)動(dòng)程序,沿著程序結(jié)構(gòu)向上逐步連接簇。遵循這種模式的集成如圖12-6所示。軟件工程的實(shí)驗(yàn)測(cè)試策略自底向上集成圖12-5自底向上集成軟件工程的實(shí)驗(yàn)測(cè)試策略回歸測(cè)試回歸測(cè)試是重新執(zhí)行已進(jìn)行測(cè)試的某個(gè)子集,以確保變更沒有傳播不期望的副作用。軟件工程的實(shí)驗(yàn)測(cè)試策略冒煙測(cè)試當(dāng)開發(fā)軟件產(chǎn)品時(shí),冒煙測(cè)試是一種常用的集成測(cè)試方法,是時(shí)間關(guān)鍵性項(xiàng)目的步進(jìn)機(jī)制,這讓軟件團(tuán)隊(duì)頻繁地對(duì)項(xiàng)目進(jìn)行評(píng)估。軟件工程的實(shí)驗(yàn)測(cè)試策略策略的選擇集成策略的選擇依賴于軟件的特征,有時(shí)也與項(xiàng)目的進(jìn)度安排有關(guān)。一般來講,組合方法,即用自頂向下方法測(cè)試程序結(jié)構(gòu)較高層,用自底向上方法測(cè)試其從屬層,這可能是最好的折衷。軟件工程的實(shí)驗(yàn)測(cè)試策略集成測(cè)試文檔軟件集成的總體計(jì)劃和特定的測(cè)試描述應(yīng)該在測(cè)試規(guī)格說明中文檔化。這個(gè)文檔包括測(cè)試計(jì)劃和測(cè)試規(guī)程,它是軟件過程的工作產(chǎn)品,也是軟件配置的一部分。軟件工程的實(shí)驗(yàn)測(cè)試策略面向?qū)ο筌浖臏y(cè)試策略測(cè)試目標(biāo)就是在現(xiàn)實(shí)的時(shí)間范圍內(nèi)利用可控的工作量盡可能多地找到錯(cuò)誤。對(duì)于面向?qū)ο筌浖?,盡管這個(gè)基本目標(biāo)是不變的,但面向?qū)ο筌浖谋举|(zhì)特征改變了測(cè)試策略和測(cè)試戰(zhàn)術(shù)。軟件工程的實(shí)驗(yàn)測(cè)試策略面向?qū)ο蟓h(huán)境的單元測(cè)試當(dāng)考慮面向?qū)ο筌浖r(shí),單元的概念發(fā)生了變化。封裝導(dǎo)出了類的定義。這意味著每個(gè)類和類的實(shí)例(對(duì)象)包裝有屬性(數(shù)據(jù))和處理這些數(shù)據(jù)的操作(函數(shù))。封裝的類常是單元測(cè)試的重點(diǎn),然而,類中包含的操作是最小的可測(cè)試單元。由于類中可以包含一些不同的操作,且特殊的操作可以作為不同類的一部分存在,因此,必須改變單元測(cè)試的戰(zhàn)術(shù)。軟件工程的實(shí)驗(yàn)測(cè)試策略面向?qū)ο蟓h(huán)境的單元測(cè)試不再孤立地對(duì)單個(gè)操作進(jìn)行測(cè)試(傳統(tǒng)的單元測(cè)試觀點(diǎn)),而是將其作為類的一部分。為便于說明,考慮一個(gè)類層次結(jié)構(gòu),在此結(jié)構(gòu)內(nèi)對(duì)超類定義某操作X,并且一些子類繼承了操作X。每個(gè)子類使用操作X,但它應(yīng)用于為每個(gè)子類定義的私有屬性和操作的環(huán)境內(nèi)。由于操作X應(yīng)用的環(huán)境有細(xì)微的差別,在每個(gè)子類的環(huán)境中測(cè)試操作X是必要的。這意味著在面向?qū)ο蟓h(huán)境中,以獨(dú)立的方式測(cè)試X往往是無效的。軟件工程的實(shí)驗(yàn)測(cè)試策略面向?qū)ο蟓h(huán)境的單元測(cè)試面向?qū)ο筌浖念悳y(cè)試等同于傳統(tǒng)軟件的單元測(cè)試。不同的是傳統(tǒng)軟件的單元測(cè)試側(cè)重于模塊的算法細(xì)節(jié)和穿過模塊接口的數(shù)據(jù),面向?qū)ο筌浖念悳y(cè)試是由封裝在該類中的操作和類的狀態(tài)行為驅(qū)動(dòng)的。軟件工程的實(shí)驗(yàn)測(cè)試策略面向?qū)ο蟓h(huán)境的集成測(cè)試由于面向?qū)ο筌浖]有明顯的層次控制結(jié)構(gòu),因此,傳統(tǒng)的自頂向下和自底向上集成策略已沒有太大意義。另外,由于類的成分間的直接或間接相互作用,每次將一個(gè)操作集成到類中往往是不可能的。軟件工程的實(shí)驗(yàn)測(cè)試策略面向?qū)ο蟓h(huán)境的集成測(cè)試面向?qū)ο笙到y(tǒng)的集成測(cè)試有兩種不同的策略。一是基于線程的測(cè)試,集成響應(yīng)系統(tǒng)的一個(gè)輸入或事件所需的一組類。每個(gè)線程單獨(dú)地集成和測(cè)試。應(yīng)用回歸測(cè)試以確保沒有副效應(yīng)產(chǎn)生。另一種方法是基于使用的測(cè)試,通過測(cè)試很少使用服務(wù)類(如果有的話)的那些類(稱之為獨(dú)立類)開始構(gòu)造系統(tǒng),獨(dú)立類測(cè)試完后,利用獨(dú)立類測(cè)試下一層次的類(稱之為依賴類)。繼續(xù)依賴類的測(cè)試直到完成整個(gè)系統(tǒng)。軟件工程的實(shí)驗(yàn)測(cè)試策略面向?qū)ο蟓h(huán)境的集成測(cè)試當(dāng)進(jìn)行面向?qū)ο笙到y(tǒng)的集成測(cè)試時(shí),驅(qū)動(dòng)程序和樁程序的使用也發(fā)生變化。驅(qū)動(dòng)程序可用于測(cè)試低層中的操作和整組類的測(cè)試。驅(qū)動(dòng)程序也可用于代替用戶界面以便在界面實(shí)現(xiàn)之前就可以進(jìn)行系統(tǒng)功能的測(cè)試。樁程序可用于在需要類間的協(xié)作但其中的一個(gè)或多個(gè)協(xié)作類仍未完全實(shí)現(xiàn)的情況下。軟件工程的實(shí)驗(yàn)測(cè)試策略面向?qū)ο蟓h(huán)境的集成測(cè)試簇測(cè)試是面向?qū)ο筌浖蓽y(cè)試中的一步。這里,利用試圖發(fā)現(xiàn)協(xié)作中的錯(cuò)誤的測(cè)試用例來測(cè)試(通過檢查CRC和對(duì)象-關(guān)系模型所確定的)協(xié)作的類簇。軟件工程的實(shí)驗(yàn)測(cè)試策略確認(rèn)測(cè)試確認(rèn)測(cè)試始于集成測(cè)試的結(jié)束,那時(shí)已測(cè)試完單個(gè)構(gòu)件,軟件已組裝成完整的軟件包,且接口錯(cuò)誤已被發(fā)現(xiàn)和改正。在確認(rèn)測(cè)試或系統(tǒng)級(jí)測(cè)試時(shí),傳統(tǒng)軟件與面向?qū)ο筌浖牟顒e已經(jīng)消失,測(cè)試便集中于用戶可見的動(dòng)作和用戶可識(shí)別的系統(tǒng)輸出。軟件工程的實(shí)驗(yàn)測(cè)試策略確認(rèn)測(cè)試確認(rèn)可用幾種方式進(jìn)行定義,但是,其中一個(gè)簡單(盡管粗糙)的定義是當(dāng)軟件可以按照用戶認(rèn)為的合理的預(yù)期方式工作時(shí),確認(rèn)就算成功。合理的預(yù)期在軟件需求規(guī)格說明中定義,軟件規(guī)格說明是描述軟件用戶可見屬性的文檔。該規(guī)格說明中包含了稱之為確認(rèn)準(zhǔn)則的部分,其中包含的信息形成了確認(rèn)測(cè)試方法的基礎(chǔ)。軟件工程的實(shí)驗(yàn)測(cè)試策略確認(rèn)測(cè)試準(zhǔn)則軟件確認(rèn)是通過一系列表明已符合軟件需求的測(cè)試而獲得的。測(cè)試計(jì)劃列出將要執(zhí)行的測(cè)試類,測(cè)試規(guī)程定義了測(cè)試用例。測(cè)試計(jì)劃和規(guī)程都是用于確保滿足所有的功能需求,具有所有的行為特征,達(dá)到所有的性能需求,文檔是正確的、可用的,且滿足其他需求。軟件工程的實(shí)驗(yàn)測(cè)試策略確認(rèn)測(cè)試準(zhǔn)則執(zhí)行每個(gè)確認(rèn)測(cè)試用例之后,存在下面兩種可能條件之一:(1)功能或性能特征符合需求規(guī)格說明,因而被接受;(2)發(fā)現(xiàn)了與規(guī)格說明的偏差,創(chuàng)建缺陷列表。在項(xiàng)目的這個(gè)階段發(fā)現(xiàn)的錯(cuò)誤或偏差很難在預(yù)定的交付期之前得到修復(fù)。此時(shí)往往必須與用戶進(jìn)行協(xié)商,確定解決這些缺陷的方法。軟件工程的實(shí)驗(yàn)測(cè)試策略配置評(píng)審確認(rèn)過程的一個(gè)重要成分是配置評(píng)審。評(píng)審的目的是確保所有的軟件配置元素已正確開發(fā)、編目,且具有支持軟件生命周期支持階段的必要細(xì)節(jié)。配置評(píng)審有時(shí)稱之為審核。軟件工程的實(shí)驗(yàn)測(cè)試策略α測(cè)試與β測(cè)試對(duì)軟件開發(fā)者而言,預(yù)見用戶如何實(shí)際使用一個(gè)程序幾乎是不可能的。軟件使用指南可能會(huì)被錯(cuò)誤理解;可能會(huì)經(jīng)常使用令用戶感到奇怪的數(shù)據(jù)連接;測(cè)試者看起來很明顯的輸出對(duì)于工作現(xiàn)場(chǎng)的用戶卻是難以理解的。軟件工程的實(shí)驗(yàn)測(cè)試策略α測(cè)試與β測(cè)試當(dāng)為用戶開發(fā)定制軟件時(shí),執(zhí)行一系列驗(yàn)收測(cè)試能使用戶確認(rèn)所有的需求。驗(yàn)收測(cè)試是由最終用戶而不是軟件工程師進(jìn)行的,它的范圍從非正式的“測(cè)試驅(qū)動(dòng)”直到有計(jì)劃地、系統(tǒng)地進(jìn)行一系列測(cè)試。實(shí)際上,驗(yàn)收測(cè)試的執(zhí)行可能超過幾個(gè)星期甚至幾個(gè)月,因此,可以發(fā)現(xiàn)長時(shí)間以來影響系統(tǒng)的累積錯(cuò)誤。軟件工程的實(shí)驗(yàn)測(cè)試策略α測(cè)試與β測(cè)試若軟件作為一個(gè)產(chǎn)品由多個(gè)用戶使用,讓每個(gè)用戶都進(jìn)行正式的驗(yàn)收測(cè)試是不切實(shí)際的。多數(shù)軟件開發(fā)者使用稱之為α測(cè)試與β測(cè)試的過程,以期查找到似乎只有終端用戶才能發(fā)現(xiàn)的錯(cuò)誤。軟件工程的實(shí)驗(yàn)測(cè)試策略α測(cè)試與β測(cè)試α測(cè)試是由最終用戶在開發(fā)者的場(chǎng)所進(jìn)行。軟件在自然的環(huán)境下使用,開發(fā)者站在典型用戶的后面觀看,并記錄錯(cuò)誤和使用問題。α測(cè)試在受控環(huán)境下進(jìn)行。β測(cè)試在最終用戶場(chǎng)所執(zhí)行。與α測(cè)試不同,開發(fā)者通常不在場(chǎng),因此,β測(cè)試是在不為開發(fā)者控制的環(huán)境下的“現(xiàn)場(chǎng)”應(yīng)用。最終用戶記錄測(cè)試過程中遇到的所有問題,并將其定期地報(bào)告給開發(fā)者。接到β測(cè)試的問題報(bào)告之后,軟件工程師進(jìn)行修改,然后準(zhǔn)備向最終用戶發(fā)布軟件產(chǎn)品。軟件工程的實(shí)驗(yàn)測(cè)試策略系統(tǒng)測(cè)試軟件只是基于計(jì)算機(jī)的大系統(tǒng)的一部分。最終,軟件要與其他系統(tǒng)成分相結(jié)合,并執(zhí)行一系列的集成測(cè)試和確認(rèn)測(cè)試。這些測(cè)試已超出軟件過程的范圍,而且不僅僅由軟件工程師執(zhí)行。然而,軟件設(shè)計(jì)和測(cè)試期間所采取的步驟可以大大提高在大系統(tǒng)中成功地集成軟件的可能性。軟件工程的實(shí)驗(yàn)測(cè)試策略系統(tǒng)測(cè)試一個(gè)傳統(tǒng)的系統(tǒng)測(cè)試問題是”相互指責(zé)”。這種情況出現(xiàn)在發(fā)現(xiàn)一個(gè)錯(cuò)誤時(shí),每個(gè)系統(tǒng)成分的開發(fā)人員都因?yàn)檫@個(gè)問題抱怨別人。軟件工程師應(yīng)該預(yù)見潛在的接口問題,以及:(1)設(shè)計(jì)出錯(cuò)處理路徑,用以測(cè)試來自系統(tǒng)其他成分的所有信息;(2)在軟件接口處執(zhí)行一系列模擬不良數(shù)據(jù)或其他潛在錯(cuò)誤的測(cè)試;(3)記錄測(cè)試結(jié)果,這些可作為”相互指責(zé)”出現(xiàn)時(shí)的”證據(jù)”;(4)參與系統(tǒng)測(cè)試的計(jì)劃和設(shè)計(jì),以保證軟件得到充分的測(cè)試。軟件工程的實(shí)驗(yàn)測(cè)試策略系統(tǒng)測(cè)試系統(tǒng)測(cè)試實(shí)際上是對(duì)整個(gè)基于計(jì)算機(jī)的系統(tǒng)進(jìn)行一系列不同考驗(yàn)的測(cè)試。雖然每個(gè)測(cè)試都有不同的目的,但所有測(cè)試都是為了驗(yàn)證系統(tǒng)成分已正確地集成在一起且完成了指派的功能。軟件工程的實(shí)驗(yàn)測(cè)試策略恢復(fù)測(cè)試多數(shù)基于計(jì)算機(jī)的系統(tǒng)必須從錯(cuò)誤中恢復(fù)并在一定的時(shí)間內(nèi)重新運(yùn)行。在有些情況下,系統(tǒng)必須是容錯(cuò)的,也就是說,處理錯(cuò)誤絕不能使整個(gè)系統(tǒng)功能都停止。而在有些情況下,系統(tǒng)的錯(cuò)誤必須在特定的時(shí)間內(nèi)或嚴(yán)重的經(jīng)濟(jì)危害發(fā)生之前得到改正。軟件工程的實(shí)驗(yàn)測(cè)試策略恢復(fù)測(cè)試恢復(fù)測(cè)試是通過各種方式強(qiáng)制地讓系統(tǒng)發(fā)生故障并驗(yàn)證其能適當(dāng)恢復(fù)的一種系統(tǒng)測(cè)試。若恢復(fù)是自動(dòng)的,則對(duì)重新初始化、檢查點(diǎn)機(jī)制、數(shù)據(jù)恢復(fù)和重新啟動(dòng)都要進(jìn)行正確性評(píng)估。若恢復(fù)需要人工干預(yù),則估算平均恢復(fù)時(shí)間以確定其是否在可接受的范圍之內(nèi)。軟件工程的實(shí)驗(yàn)測(cè)試策略安全測(cè)試安全測(cè)試驗(yàn)證建立在系統(tǒng)內(nèi)的保護(hù)機(jī)制是否能夠?qū)嶋H保護(hù)系統(tǒng)不受非法入侵。在安全測(cè)試過程中,測(cè)試者扮演試圖攻擊系統(tǒng)的角色。測(cè)試者可以試圖通過外部手段獲取密碼;可以通過瓦解任何防守的定制軟件來攻擊系統(tǒng);可以“制服”系統(tǒng)使其無法對(duì)別人提供服務(wù);可以有目的地引發(fā)系統(tǒng)錯(cuò)誤以期在其恢復(fù)過程中入侵系統(tǒng);可以通過瀏覽非保密數(shù)據(jù),從中找到進(jìn)入系統(tǒng)的鑰匙等。只要有足夠的時(shí)間和資源,好的安全測(cè)試最終將能夠入侵系統(tǒng)。系統(tǒng)設(shè)計(jì)人員的作用是使攻破系統(tǒng)所付出的代價(jià)大于攻破系統(tǒng)之后獲取信息的價(jià)值。軟件工程的實(shí)驗(yàn)測(cè)試策略壓力測(cè)試壓力測(cè)試的目的是使軟件面對(duì)非正常的情形。壓力測(cè)試是以一種要求反常數(shù)量、頻率或容量的方式執(zhí)行系統(tǒng)。例如:(1)當(dāng)平均每秒出現(xiàn)1~2次中斷的情形,可以設(shè)計(jì)每秒產(chǎn)生10次中斷的測(cè)試用例;(2)將輸入數(shù)據(jù)的量提高一個(gè)數(shù)量級(jí)以確定輸入功能將如何反應(yīng);(3)執(zhí)行需要最大內(nèi)存或其他資源的測(cè)試用例;(4)設(shè)計(jì)可能產(chǎn)生內(nèi)存管理問題的測(cè)試用例;(5)創(chuàng)建可能會(huì)過多查找磁盤駐留數(shù)據(jù)的測(cè)試用例。從本質(zhì)上說,壓力測(cè)試者是試圖破壞程序。軟件工程的實(shí)驗(yàn)測(cè)試策略壓力測(cè)試壓力測(cè)試的一個(gè)變體稱之為敏感性測(cè)試。在一些情況下,包含在有效數(shù)據(jù)界限之內(nèi)的一小部分?jǐn)?shù)據(jù)可能會(huì)引起極端處理情況,甚至是錯(cuò)誤處理或性能的急劇下降。敏感性測(cè)試試圖發(fā)現(xiàn)可能會(huì)引發(fā)系統(tǒng)不穩(wěn)定或者錯(cuò)誤處理的在有效輸入類中的數(shù)據(jù)組合。軟件工程的實(shí)驗(yàn)測(cè)試策略性能測(cè)試對(duì)于實(shí)時(shí)和嵌入式系統(tǒng),提供所需功能但不符合性能需求的軟件是不能接受的。性能測(cè)試用來測(cè)試軟件在集成環(huán)境中的運(yùn)行性能。性能測(cè)試可以發(fā)生在測(cè)試過程的所有步驟中。即使在單元測(cè)試中,也可以在執(zhí)行測(cè)試時(shí)評(píng)估單個(gè)模塊的性能。然而,只有當(dāng)整個(gè)系統(tǒng)的所有成分都集成在一起之后,才能搞清楚系統(tǒng)的真實(shí)性能。軟件工程的實(shí)驗(yàn)測(cè)試策略性能測(cè)試性能測(cè)試經(jīng)常與壓力測(cè)試一起進(jìn)行,且常需要硬件和軟件相配合。也就是說,在一種苛刻的環(huán)境中衡量資源的利用往往是必要的。外部的測(cè)試設(shè)備可以監(jiān)測(cè)執(zhí)行間歇,當(dāng)有事件發(fā)生或取樣機(jī)定時(shí)給出信息時(shí)記錄下來。通過檢測(cè)系統(tǒng),測(cè)試人員可以發(fā)現(xiàn)導(dǎo)致效率降低和系統(tǒng)故障的情形。軟件工程的實(shí)驗(yàn)測(cè)試策略調(diào)試技巧調(diào)試出現(xiàn)在成功的測(cè)試之后,即當(dāng)測(cè)試用例發(fā)現(xiàn)錯(cuò)誤時(shí),調(diào)試是致使錯(cuò)誤消除的行為。盡管調(diào)試可以是、也應(yīng)該是一個(gè)有序的過程,但它仍然需要很多的技巧。當(dāng)評(píng)估測(cè)試結(jié)果時(shí),軟件工程師經(jīng)常面對(duì)軟件問題表現(xiàn)的“癥狀”,

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論