軟件工程的實驗測試策略

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

驗證：我們在正確地構(gòu)造產(chǎn)品嗎？

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