一、選擇題(每題只有一個選項，將你認為合理的選項填在題前括號內，每小題2分，共16分)(D)1、較實用的軟件測試停止標準是()。A、測試超產過了預定時間，則停止測試。B、根據單位時間內查出故障的數量決定是否停止測試。C、執行了所有的測試用例，但并沒有發現故障，則停止測試。D、用圖表示出某個測試階段中單位時間檢查出的故障數量，通過對圖中曲線的分析，確定應繼續測試還是停止測試。(C)2、軟件測試的目的是：A、表明軟件是正確的 B、評價軟件質量C、盡可能發現軟件中的錯誤 D、判定軟件是否合格(A)3、()不是常見的覆蓋率標準。A、函數覆蓋 B、數據流覆蓋 C、邏輯覆蓋 D、功能覆蓋(B)4、將基于功能的和基于實現的測試方法結合在一起的動態測試類型，我們稱這種測試為（）。A、白盒測試 B、灰盒測試 C、黑盒測試 D、基于故障的測試(B)5、下列不隸屬于白盒測試方法的是()：A、控制流測試 B、健壯性測試 C、數據流測試 D、變異測試(A)6、項目管理三要素不包括()。 A、Programming B、Process C、Problem D、Process(D)7、下列選項中，不是Mercury公司測試工具的是()。A、LoadRunner B、WinRunner C、TestDirector D、Rebot(A)8、下面（）方法能夠有效地檢測輸入條件的各種組合可能引起的錯誤。A、因果圖 B、等價類劃分 C、邊界值分析 D、錯誤推測(D)1、通常，()是在編碼階段進行的測試，它是整個測試工作的基礎。A、系統測試 B、確認測試 C、集成測試 D、單元測試(A)2、據權威部門統計，軟件錯誤產生的原因分布圖表中，如下()選項是導致軟件錯誤的主要原因：A、軟件需求規格說明錯誤B、設計錯誤C、編碼錯誤D、測試錯誤(C)3、軟件測試充分性理論是由()最先提出的。A、Deutsch和Willis B、McCalletal.C、Goodenough和Gerhart D、Evansh和Marciniak(C)4、軟件測試風險管理包含（）和風險控制兩方面內容。A、 風險排序 B、風險識別 C、風險評估 D、風險分析(D)5、下列不屬于黑盒測試方法的是()。A、等價類劃分 B、狀態測試 C、邊界值分析 D、變異測試(A)6、常見的覆蓋率標準不包括()。A、函數覆蓋 B、邏輯覆蓋 C、數據流覆蓋 D、功能覆蓋(B)7、因果圖是（）公司最先發明并實施的。A、SUN B、IBM C、Microsoft D、ORACLE(D)8、針對下面一個程序段：if ((A>1)&&(B==0))S1;If ((A==2)||(X>1))S2;其中，S1、S2均為語句塊。現在選取測試用例：A=2B=0X=3，該測試用例滿足了（）。A、路徑覆蓋 B、條件組合覆蓋C、判定覆蓋 D、語句覆蓋(A)1、下列各測試工具中隸屬于Mercury公司產品的是（）A、WinRunner B、JUnit C、Purify D、WebStress(D)2、下面關于軟件測試的說法，其中正確的是()經過測試沒有發現錯誤，說明程序正確 成功的測試是沒有發現錯誤的測試測試的目標是為了證明程序沒有錯誤 D、成功的測試是發現了迄今尚未發現的錯誤的測試(B)3、在某種類型會議上，由小組成員閱讀程序，以發現程序錯誤，同時測試員利用測試數據人工運行程序并得出輸出結果，然后由參加者對結果進行審查,以達到測試的目的。這種測試方法是（）。A、軟件審查 B、代碼走查 C、技術評審 D、代碼審查(C)4、測試充分性準則內容不包括()。A、空集不充分性 B、單調性 C、可靠性 D、復雜性(A)5、控制流覆蓋準則約束最弱的是()。A、點覆蓋 B、邊覆蓋 C、條件覆蓋 D、路徑覆蓋(C)6、設計測試用例時候，（）是用得最多的一種黑盒測試方法。A、因果圖 B、等價類劃分 C、邊界值分析 D、錯誤推測(B)7、軟件測試風險管理包含（）和風險控制兩方面內容。A、風險識別 B、風險評估 C、風險排序 D、風險分析(A)8、對下面的計算個人所得稅程序中if(income<800) taxrate=0;elseif(income<=1500) taxrate=0.05;elseif(income<2000) taxrate=0.08;elsetaxrate=0.1;滿足判定覆蓋的測試用例是()。A、income=(799,1500,1999,2000) B、income=(799,1501,2000,2001)C、income=(800,1500,2000,2001) D、income=(800,1499,2000,2001)二、判斷題(判斷下列題目是否正確，如果正確請打“√”，錯誤請打“×”每小題2分，共8分)(√)1、技術評審即是一種技術手段，也是一種質量管理手段。(×)2、設計－實現－測試，軟件測試是開發后期的一個階段。(×)3、單元測試僅僅證明了被測程序單元做了什么。(×)4、由于函數覆蓋率是基于代碼的，所以也可以把函數覆蓋歸入黑盒測試的范疇。(√)1、在軟件測試中,測試預言是一種檢驗待測系統在特定執行下是否正確運行的方法。(×)2、在白盒測試中，如果覆蓋率達到100%，就基本可以保證把所有的隱藏程序缺陷都已經揭露出來了。(×)3、軟件測試的目的在于發現錯誤、改正錯誤。(√)4、由于函數覆蓋率是基于代碼的，所以也可以把函數覆蓋歸入白盒測試的范疇。(×)1、軟件測試等于程序測試。(×)2、我是個很棒的程序員，我無需進行單元測試。(√)3、在白盒測試中，即使覆蓋率達到100%，也無法保證所有的隱藏程序缺陷都已經被揭露出來。(×)4、由于函數覆蓋率是基于代碼的，所以也可以把函數覆蓋歸入黑盒測試的范疇。(×)1、軟件故障是導致軟件失效的必要和充分要素。(√)2、同行評審的主要目標在于檢測錯誤、核對與標準的偏離。(√)3、在任何軟件機構中，定期、不定期的培訓、再培訓都是必須而且是必要的。(√)4、在整個機構中使用基礎設施防護與改進部件的主要目標是在機構積累的SQA經驗基礎上消除或至少降低出錯率。(×)5、所有SQA活動和項目里程碑的完成或項目里程碑的檢驗是同時發生的。(×)6、DanielGalin等提在20世紀50年代建立的經典質量費用模型，提供了一種以經濟學觀點把與產品質量保證相關的費用非類的方法學。(√)7、一旦更改過的SCI替換了前面的SCI，就認為完成了軟件的一個新版本。(√)8、軟件質量成本是一個投資問題，而不是成本問題!(×)9、SEICMM評估標準,ISO9001和ISO9000-3標準是典型的項目過程標準。(√)10、軟件質量保證的獨特性是由軟件產品不同于其他制造產品的本質決定的。(√)1、在專業的軟件開發、維護中，SQA環境是建立、執行SQA方法時必須首要考慮的問題。(×)2、如何看待軟件產品內部的缺陷，開發者和用戶的立場是一致的。(√)3、專家觀點通過引進補充的外部能力到機構內部開發過程中來而支持質量評估工作。(×)4、質量管理標準是專業標準，它們向開發組提供方法學指南。(√)5、軟件生命周期模型強調的是直接開發活動，而沒有指示出開發過程的顧客參與。(×)6、規程具有機構范圍的適用性，它的執行和具體執行的人或組織背景有著密切關系。(×)7、CAPA的目的在于檢測、處理、改正軟件缺陷。(×)8、項目進展控制SQA工具有Gatt圖、日歷、數據流圖和活動網絡圖。(√)9、IEEE、ISO、DOD、ANSI、EIA都是著名的SQA標準開發機構。(√)10、在科學和工程中，如果沒有度量，對一切都沒有一個定量的了解，那么這種科學和工程既不是有效的，也不是實際的。(×)1、在軟件產品制定生產計劃階段,不必進行重大的SQA活動。(√)2、軟件故障是導致軟件失效的必要，而非充分要素。(×)3、只有客戶才會有興趣透徹定義它的需求以確保他約定的軟件產品的質量。(√)4、軟件質量系統之間各不相同，說明機構SQA系統構建存在固有靈活性。(√)5、質量管理標準指導軟件開發、維護和基礎設施的管理。它的重點是需要什么，但沒有指明如何達到標準要求的努力細節。(×)6、通常，檢查表的使用的是強制性的。(×)7、CAPA的執行從根本上依賴于正確的指導和經常的培訓。(√)8、軟件質量度量面臨的特有困難根植于包含于軟件質量度量的測量（參數）中。(√)9、一旦更改過的SCI替換了前面的SCI，就認為完成了軟件的一個新版本。(×)10、SQA項目過程標準如CMM、ISO9000-3標準。三、填空題(每空1分，共14分；請把答案書寫在相應橫線上。)1、軟件測試過程包含的測試活動有測試計劃，測試設計，測試實施，測試執行，缺陷跟蹤和測試評估2、軟件測試策略的確定過程通常經歷確定測試需求、評估風險、確定測試策略三個階段組成。3、變異測試的理論基礎是程序員能力假設和組合效應假設。4、軟件缺陷打開/關閉圖表、根本原因圖表、軟件缺陷關閉周期表是常用的軟件缺陷跟蹤圖表。5、軟件測試規范可以分為行業規范和操作規范。1、通常，由人工進行的靜態測試方法包括桌面檢查、代碼審查、代碼走查和技術評審。2、典型的測試設計活動包括測試用例設計、測試過程設計、設計驅動程序和穩定的樁。3、按照測試的層次和策略,軟件測試可以分為單元測試、集成測試、確認測試和系統測試。4、為了考察測試用例的重要性，我們可以從有效性、可重用性、易組織性、可評估性、可管理性五方面理解。5、面向對象集成測試常見方法包括抽樣測試、正交矩陣（陣列）測試。1、面向對象測試充分性三個常用標準是基于狀態的覆蓋率、基于約束的覆蓋率和基于代碼的覆蓋率。2、常見的程序分析視角有句法視角，功能視角、文本視角和計算流視角3、按照測試用例的設計方法，軟件測試可以分為白盒測試、黑盒測試和灰盒測試。4、我們可以按照編寫過程、執行過程和組織過程三個緯度對測試用例屬性進行歸類。5、單元測試內容包含如下方面：模塊接口測試、邊界條件測試、錯誤處理測試、局部數據結構測試和重要路徑測試。1、軟件質量工程包括軟件質量保證、軟件質量規劃和軟件質量控制三大方面。2、McCall模型產品修改緯度的質量因素有可維護性、可測試性、靈活性。3、面向對象模型不同于其他模型的主要特征是組件的密集重用。4、有兩種同行評審方法學：審查和走查。5、RMA可以劃分成三組類別內部風險管理措施、分包風險管理措施和顧客風險管理措施。6、支持性質量手段有模板和檢查表。7、依據軟件系統的生命周期和其他階段，軟件質量度量劃分為軟件過程度量和軟件產品度量。8、軟件配置發布的版本有基線版本、中間版本、修訂版本。9、SQA標準被劃分成軟件質量管理標準和軟件項目過程標準兩類。10、軟件缺陷的固有特征有軟件缺陷的固有性、軟件缺陷的敏感性、軟件缺陷的感染性。1、McCall模型劃分了軟件運行、軟件轉移、軟件修改三個緯度的11個軟件質量因素。2、螺旋模型任何一次迭代都可劃分為制定計劃、風險分析和化解、工程和顧客評估四個項限。3、依據合同評審的目標對合同評審主題進行分類為建議草案評審主題和合同草案評審主題兩種類型。4、典型的版本方針包括嚴格-單一活動版本方針、多版本方針。5、軟件對屬于各種質量因素的需求的符合性是由軟件質量度量來測量的。6、CAPA過程的成功運行包含如下活動：信息收集、信息分析、解決方案和改進方法的建立、改進方法的執行、跟蹤。7、常見的軟件配置演化模型有線性演化模型和樹演化模型。8、軟件更改的質量保證工作需要每個更改的SCI的質量保證和整個新軟件系統版本的質量保證兩個級別的活動。9、從內容和重點上我們可以把質量管理標準劃分成認證標準和評估標準兩種類型。10、測試人員、SQA單位是SQA專職人員。1、CMM內容包含初始級、可重復級、已定義級、已管理級和可優化級五個等級。2、軟件質量保證的目標包括面向產品的軟件開發和面向過程的軟件維護兩大方面。3、開發生命周期階段SQA部件可以劃分成三類：評審、專家觀點、軟件測試、軟件維護SQA部件和由第三方/分包商使用的SQA部件。4、版本方針和更改方針是維護方針的主要組成。5、外部參與方可被分類為分包商、COTS軟件和重用軟件模塊的供貨商和顧客自身三組。6、在任何機構中，CAPA要正確發揮作用需要CAPA記錄流的跟蹤、CAPA執行的跟蹤和CAPA執行結果的跟蹤三個要的跟蹤任務。7、軟件更改的質量保證工作需要每個更改的SCI的質量保證和整個新軟件系統版本的質量保證兩個級別的活動。8、軟件過程度量可以進一步劃分為軟件過程質量度量、軟件過程進度度量和軟件過程生產率度量。9、從內容和重點上我們可以把質量管理標準劃分成認證標準和評估標準兩種類型。10、通常，軟件質量的管理部件有項目進展控制、軟件質量度量、軟件質量費用和可用于控制軟件維護的工具SQA管理工具。四、名詞解釋(每小題3分，共18分)1、軟件測試風險軟件測試風險是指軟件測試過程出現的或潛在的問題2、動態測試技術通過在抽樣測試數據上運行程序來檢驗程序的動態行為和運行結果以發現缺陷。3、確認測試確認測試是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。對軟件的從功能、性能、可靠性、易用性等方面作全面的質量檢測，幫助軟件企業找出產品存在的問題，出具相應的產品質量報告。4、條件組合覆蓋條件組合覆蓋是邏輯覆蓋標準的一種，它要求選取足夠多的測試數據，使得每個判定表達式中條件的各種可能組合都至少出現一次。5、L10N軟件本地化6、（軟件產品的）FURPSFURPS即軟件系統的功能、可使用性、可靠性、性能和支持等特性。1、L10N&&I18N軟件本地化和國際化2、軟件測試項目管理軟件測試項目管理就是以測試項目為管理對象，通過一個臨時性的專門的測試組織，運用專門的軟件測試知識、技能、工具和方法，對測試項目進行計劃、組織、執行和控制，并在時間成本、軟件測試質量等方面進行分析和管理活動。3、軟件測試文檔測試文檔是對要執行的軟件測試及測試的結果進行描述、定義、規定和報告的任何書面或圖示信息。4、測試用例測試用例是為了特定目的而設計的測試數據及相關測試規程的一個特定集合，即為有效發現軟件缺陷的最小測試執行單元。5、白盒測試白盒測試是指測試人員根據程序的內部結構特性和與程序路徑相關的數據特性，設計測試數據組成測試用例執行程序的一種動態測試。6、無效等價類無效等價類是指對于程序的規格說明來說，不合理的，沒有意義的輸入數據的集合。軟件測試軟件測試是為了發現錯誤而執行程序的過程。或軟件測試是根據軟件開發各階段的規格說明和程序的內部結構而精心設計的一批測試用例（即輸入數據及其預期的輸出結果），并利用這些測試用例運行程序，以及發現錯誤的過程。2、測試用例的有效性軟件測試用例是測試人員測試過程中的重要參考依據；不同測試人員根據相同測試用例所得到的輸出應該是一致的。3、軟件測試規范軟件測試規范是對軟件測試流程的過程化，并對每一個過程元素進行明確界定，而形成的完整的規范體系。4、條件覆蓋條件覆蓋隸屬控制流覆蓋標準的范疇，它不僅要求每個語句至少執行一次，而且要求使得判定表達式中每個條件都取得各種可能的結果5、TDD測試驅動開發（TestDrivenDevelopment）6、α測試α測試是由用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試。這是在受控制的環境下進行的測試。Crosby軟件質量的定義系統、部件或過程滿足規定需求的程度。2、軟件可靠性（IEEE）軟件可靠性是指一個系統或組件在某個特定時期、特定條件下完成所需完成的功能的能力。3、規程規程是完成某件事情或行動的特定方式，即規程是為了完成一個任務，根據給定方法所執行的詳細活動或過程。4、開發風險軟件開發風險是軟件開發任務或環境的一種狀態或性質，如果忽略它，將增加軟件項目失敗的可能。5、（軟件工程領域）模板在軟件工程領域，模板指的是小組或機構創建的，用于編輯報告以及其他形式文檔的格式。6、軟件配置管理一個負責應用(計算機化的或非計算機化的)技術工具和管理規程、使之能夠完成為維護SCI和軟件配置版本所需任務的SQA部1、DanielGalin軟件質量保證的擴展定義軟件質量保證是一個有系統的、有計劃的行動集合，它是提供軟件產品開發、維護過程符合其已建立的技術需求以及跟上計劃安排和在預算限制之內進行管理上的需求充分信任所必需的。2、合同評審合同評審是一個指導評審建議草案和合同文檔的SQA部件。3、規程規程是完成某件事情或行動的特定方式，即規程是為了完成一個任務，根據給定方法所執行的詳細活動或過4、4W1HW1H即WHAT,WHEN,WHERE,WHO和HOW。他們具體含義如下：WHAT--Whatactivitieshavetobeperformed?WHEN--WhenShouldtheactivitybeperformed?WHERE--Whereshouldtheactivitybeperformed?WHO--Whoshouldperformtheactivity?HOW--Howshouldeachactivitybeperformed?5、受控文檔受控文檔是那些目前就對軟件系統的開發、維護以及與目前和將來顧客關系的管理重要或可能變得重要的，并且處于控制狀態下的文檔。6、軟件質量度量一個項目具有給定質量屬性的程度定量測度；或一個函數，其輸入為軟件數據、輸出為單一的數值，該值可以被理解為軟件具有給定質量屬性的程度Pressman軟件質量的定義軟件質量是符合明確陳述的功能性能需求、明確文檔化了的開發標準和所有專業開發預期的隱含特性。2、軟件開發風險軟件開發風險是軟件開發任務或環境的一種狀態或性質，如果忽略它，將增加軟件項目失敗的可能。3、合同評審合同評審是一個指導評審建議草案和合同文檔的SQA部件。4、質量記錄質量記錄是一種特殊類型的受控文檔。它是面向顧客的文檔，用于證實同顧客需求的全面符合性以及貫穿于開發和維護全過程的軟件質量保證系統的有效運行5、軟件可靠性管理軟件可靠性管理指通過一個程序使軟件的可靠性得到最優化的過程。此程序著重于軟件防錯（softwareerrorprevention），發現并清除fault；此程序著重于采用一定措施并根據諸如資源，進度表及性能的約束條件使可靠性最大化。6、軟件配置版本軟件配置版本是指在給定時間點上組成軟件系統的、已批準而且文檔化的SCI版本的集合。五、問答題(每小題4分，共20分)談談你對變異測試原理的理解。（1）使用變異算子對被測程序做微小的合乎語法的變動，每個新程序稱為一個變異體；（2）根據已有的測試數據運行變異體；（3）比較變異體和原程序的運行結果：如果兩者不同就稱該測試數據將該變異體殺死了；否則稱該變異體是活的。2、請闡述軟件測試的原則。（1）盡早的和不斷的測試應作為軟件開發人員的座右銘。（2）測試用例應當由測試數據和與之對應的預期結果組成。（3）測試用例應包括合理的輸入條件和不合理的輸入條件。（4）嚴格執行測試計劃，排除測試的隨意性。（5）充分注意測試當中的群體現象。（6）要對每一個測試結果作全面的檢查。（7）保存測試計劃、測試用例、出錯統計和最終分析報告，為維護工作提供充分的資料。3、測試用例設計的考慮因素有哪些？（1）測試用例必須具有代表性、典型性；[1分]（2）測試用例要濃縮系統設計；[1分]（3）測試用例既要考慮正確的輸入，也需要考慮錯誤或異常的輸入，以及促使這些錯誤、異常發生的條件；[1分]（4）用戶測試用例設計需要考慮用戶實際使用場景。[1分]4、集成測試策略中，漸增式與非漸增式集成策略各有何優、缺點？為什么通常采用漸增式？非漸增式集成策略是將所有的模塊一次連接起來，簡單、易行，節省機時，但測試過程中難于查錯，發現錯誤也很難定位，測試效率低。[1分]漸增式集成策略是將模塊一個一個地連入系統，每連入一個模塊，都要對新系統進行測試。這種組裝測試方案比較非漸增式，容易查出錯誤及進行錯誤定位，有利于查出模塊接口部分的錯誤，因此測試效率高。但漸增式較費機時。[2分]比較兩種集成策略，顯然漸增式有利于實現測試的目標，故通常采用漸增式進行組裝測試。[1分]5、請評價白盒測試？（1）[2分]優點迫使測試人員去仔細思考軟件的實現;可以檢測代碼中的每條分支和路徑;揭示隱藏在代碼中的錯誤;對代碼的測試比較徹底;最優化。（2）[2分]缺點昂貴;無法檢測代碼中遺漏的路徑和數據敏感性錯誤;白盒測試不驗證規格的正確性。黑盒測試的特點有哪些？（1）不考慮程序內部結構和內部特性；[1分]（2）測試人員只需知道該程序輸入和輸出之間的關系或功能；[1分]（3）設計測試用例的依據是需求規格說明書或用戶手冊；[1分]（4）尤其適合于一些第三方軟件測試，由于無法得到源程序，無法用其它方法進行測試。[1分]等價類劃分的步驟如何？（1）根據輸入條件把數目極多的輸入數據劃分成若干有效等價類和若干無效等價類；[2分]（2）設計一個測試用例，使其覆蓋盡可能多的尚未被覆蓋的有效等價類，重復該步驟，直至所有有效等價類均被覆蓋；[1分]（3）設計一個測試用例，使其覆蓋一個的尚未被覆蓋的無效等價類，重復該步驟，直至所有無效等價類均被覆蓋。[1分]3、談談你對“持續的軟件測試”的理解。持續的軟件測試有兩方面的含義：（1）完整的軟件測試工作應該貫穿整個軟件生存周期存周期[2分]（2）軟件開發不同階段都有軟件測試工作，即軟件測試工作的各個步驟分布在整個軟件生存周期中。[2分]4、一般的軟件項目管理與軟件測試項目管理之間的區別由那些？（1）對于一般的軟件項目管理，成本和進度控制是最重要的；[2分]（2）而在軟件測試項目管理中，質量第一是基本點，所有測試項目管理工作都要圍繞提高產品質量展開，最終保證在合理的成本、進度下滿足用戶需求或期望。[2分]5、與桌面檢查相比，代碼審查與代碼走查有哪些優點？（1）桌面檢查即程序員自己檢查自己的程序。通常，由于程序員思維定勢、心理因素的限制，使得桌面檢查效率不高。[2分]（2）代碼走查、代碼審查采用成組方式進行，一旦發現錯誤就知道了錯誤的位置和性質，從而大大降低了調試費用和成本；另外代碼走查、代碼審查可以一次發現一批錯誤，錯誤發現效率較高。[2分]1、請比較白盒測試與黑盒測試方法？（1）白盒測試只考慮測試軟件產品,它不保證完整的需求規格是否被滿足。而黑盒測試只考慮測試需求規格,它不保證實現的所有部分是否被測試到。[1分]（2）黑盒測試會發現遺漏的缺陷,指出規格的哪些部分沒有被完成。而白盒測試會發現代理方面的缺陷,指出哪些實現部分是錯誤的。[1分]（3）白盒測試比黑盒測試成本要高得多。它需要在測試可被計劃前產生源代碼,并且在確定合適的數據和決定軟件是否正確方面需要花費更多的工作量。[1分]（4）一個白盒測試的失敗會導致一次修改,這需要所有的黑盒測試被重復執行并且重新決定白盒測試路徑。[1分]測試項目中，主要的測試文檔有哪些？測試計劃、測試設計規格說明、測試用例說明、測試規程規格說明、測試執行報告、測試日志、測試缺陷報告、測試總結報告等3、談談你對“軟件測試的必要性”的理解。軟件測試的必要性主要體現在如下方面：程序代碼最終體現了軟件的質量；軟件測試力爭發現更多的缺陷盡量減少殘留的缺陷；軟件測試提高軟件的正確性；軟件測試建立對軟件的信心；軟件測試掌握軟件的質量水平；軟件測試是軟件質量保證的重要手段。4、請闡述測試用例在代碼走查中的作用。（1）代碼走查中，測試用例并不是關鍵，也并不是僅想驗證這幾個測試用例運行是否正確，人腦畢竟比計算機慢太多；（2）這里測試用例是作為懷疑程序邏輯與計算錯誤的啟發點，在隨測試實例游歷程序邏輯時，在懷疑程序的過程中發現錯誤。5、測試覆蓋準則的作用如何？1）定量地規定軟件測試需求，指導測試數據的選擇；（2）度量測試數據集，揭示軟件特定特征的能力；（3）對測試結果和軟件可靠性評估具有重要影響。專業軟件開發的SQA環境有哪些特征？遵守合同約定；服從顧客供貨商關系；需要協同工作；需要同其他開發組的合作和協調；同其它軟件系統的接口；項目組有變化時項目繼續進行；需要持續維護軟件系統若干年。請指出走查、審查這兩種同行評審方法的不同？走查和審查的區別是其正式性的等級。其中，審查是兩者之中更為正式。[2分]走查的發現限于被評審文檔的意見，而審查的發現還同改進開發方法自身的工作相結合。所以和走查相比，審查對一般的SQA做出了更大貢獻。請詳細描述軟件質量費用的經典模型？在經典軟件質量費用模型中，軟件質量費用可以劃分為控制費用、控制失效費用。其中，控制費用被進一步細化為預防費用和評價費用；控制失效費用進一步細化為內部失效費用、外部失效費用。預防費用包括建立軟件質量基礎設施、更新并改進基礎設施以及完成其運行所需的常規活動的投資。評價費用花在特定項目或軟件系統中軟件錯誤的檢測上。內部失效費用是指改正在顧客現場安裝軟件之前實施設計評審、軟件測試及驗收測試時檢測到的錯誤而產生的費用。（4）外部失效費用限定為改正由顧客或維護組在顧客現場安裝軟件系統之后檢測到的失效的費用。認證標準和評估標準的主要區別？認證標準的重點是外部的--支持供貨商顧客關系[2分]，而評估標準的重點是內部的。因為評估標準關注的是軟件過程改進[2分]。5、CCB的決策機制有哪些種類？你認為其中那種決策機制更實用？（1）最普遍的方法是投票決定。每個代表都投票，采用少數服從多數的方式。這種民主的做法能夠充分調動CCB成員的機機性；但是少數服從多數含義模糊，該決策模式也容易產生一些政見。（2）極端的做法是所有決策都交給一個人，這種安排鼓勵在決策中靈活考慮各種意見，但壓抑了CCB其他成員的積極性；（3）第三種可行的決策機制是尋求CCB成員的一致意見，同時提供合理的跳出機制。綜合考慮上述三種不同CCB決策機制，第三種策略最為實用。6、傳統質量成本和現代質量成本的主要區別有哪些？傳統的質量成本集中在與失效有關的事件和活動，如損壞、缺陷等。傳統質量成本通常以報廢、返工、返修等形式出現；[2分]現代的質量成本的目的則在于通過預防和評估活動中的適當投入，減少與失效有關的活動。[2分]Crosby,Juran,Pressman軟件質量定義的比較。（1）Crosby的定義指的是寫好的軟件符合由顧客和它的專業組編制的規格說明書的程度。這也意味著包含在規格說明中的錯誤是不予考慮的，也不降低軟件質量—顯然這是不足的。[1分]（2）Juran的定義旨在達到顧客滿意度，這就要求對檢查改正顧客的需求規格書投入大量工作。但該定義的主要缺點是免除了顧客對軟件規格書準確性、完備性的責任。[1分]（3）Pressman定義為SQA提出了要由開發者滿足的三個要求：特定功能需求，它主要是指軟件系統的輸出；在合同中提出的軟件質量標準；反映當今水平的專業方法的良好軟件工程方法的發展水平。實際上，Pressman定義提供了測試滿足需求程度的操作方向。談談你對合同評審過程的理解？合同評審是一個指導評審建議草案和合同文檔的SQA部件。其過程分為兩個階段進行：[1分]（1）第一階段—提交給可能顧客之前的建議草案評審；[1分]（2）第二階段—簽約前的合同草案評審,該階段在建議和合同談判期達成的理解基礎上評審合同草案。[1分]每個評審階段完成后，要求建議組與法律部進行必要的修改、補充和改正。[1分]請列舉典型的軟件質量基礎設施SQA部件?(不少于5個)規程與工作條例、支持性質量手段、員工培訓與認證、改正性和預防性措施、配置管理、文檔編制控制請指出軟件質量費用擴展模型對軟件質量費用經典模型的擴展。仔細考察經典軟件質量費用模型的考察，我們將發現經典軟件質量費用模型沒有能夠涵蓋管理以及管理性失效導致的軟件質量費用。[2分]軟件質量費用擴展模型拓展了經典軟件質量費用模型，以涵蓋管理人員對軟件質量總費用的‘貢獻’—軟件質量的擴展模型：相對經典軟件質量費用，軟件質量費用擴展模型添加了管理性準備與控制費用和管理性失效費用。[2分]（管理性準備與控制費用同實施的預防性管理失效或減少這些這些失效的預期出現的活動相關聯；）請描述ISO9000-3質量管理系統的基本原理（1）顧客關注。機構依靠它們的顧客，所以應當理解當前的與未來的顧客需要；（2）領導--建立并維護一個積極的內部環境中行使領導權，以實現機構的目標；（3）人們的投入。人是機構之本，他們在各機構層次的全身心投入使得他們的能力能用于為機構謀益；（4）過程方法--當把活動與資源作為過程管理的時候，就更有效地達到理想的結果；（5）管理理的系統方法--把過程作為一個系統管理；（6）持續改進--對全面性能正在進行的改進應當在機構的日程上優先；（7）決策制定的實在方法。有效決策是建立在信息分析的基礎上的；（8）相互支持的供貨商關系。一個機構和它的供貨商是互相依賴時，相互支持的供貨由關系增強雙方創造增加值的能力6、傳統質量成本和現代質量成本的主要區別有哪些？傳統的質量成本集中在與失效有關的事件和活動，如損壞、缺陷等。傳統質量成本通常以報廢、返工、返修等形式出現；現代的質量成本的目的則在于通過預防和評估活動中的適當投入，減少與失效有關的活動。在軟件產品與其他工業產品之間的區別主要有哪些？并描述這些不同？軟件產品和其他工業產品的主要區別有如下幾點：（1）產品的復雜性；產品的復雜性能夠用產品許可的操作方式的數目來度量:工業產品，即使是高級機器，也不允許由其不同的機器組合建立的幾千種以上的操作方式；一個典型的軟件，人們可以發現上百萬種軟件操作的可能。（2）產品的可見性；工業產品是可見的，而軟件產品是不可見的。工業產品的大多數缺陷可在制造過程中檢測出來；然而軟件產品的缺陷是不可見的，軟件包中的組件可能從一開始就缺失了。（3）產品開發和制造過程的特殊性。同工業產品相比，軟件產品不能在生產過程的所有三個階段檢測缺陷。能夠檢測缺陷的唯一階段是開發階段。高度螺旋模型每次迭代必需的活動包含哪些？顧客的需求規格說明、意見與更改要求；開發者的計劃制定活動；開發者的風險分析與化解；開發者設計活動；開發者關于編碼、測試、發布的構造活動；顧客的評價3、請從SQA的角度，闡述分別編寫用戶需求文檔和系統需求文檔的理由？（1）很自然人們會想到只有客戶才會有興趣透徹定義它的需求以確保他約定的軟件產品的質量。他編制的需求文檔是對低質量的基礎防護；（2）然而我們對各種軟件質量因素的分析表明，開發者可以添加代表它自身利益的需求，例如可重用性需求、可驗證性需求等；許多情況下，某些沒有包括在典型客戶需求文檔中的質量因素確是開發者感興趣的。而，諸如可移植性、可重用性、可驗證性等質量因素，客戶很少感興趣。這也就是人們為何分別編制客戶需求文檔和系統需求文檔的理由。4、主要的SQA維護基礎設施工具有哪些？主要的SQA維護基礎設施工具有軟件維護規程和工作條例、支持性軟件質量手段、維護組的培訓和認證、預防性和改正性措施、軟件配置管理、軟件維護文檔和質量記錄等5、軟件質量度量過程模型包含哪些活動？（1）軟件質量需求的定義；（2）軟件質量度量和評估的準備；（3）軟件質量度量的執行、分析和確認6、傳統質量成本和現代質量成本的主要區別有哪些？（1）[2分]傳統的質量成本集中在與失效有關的事件和活動，如損壞、缺陷等。傳統質量成本通常以報廢、返工、返修等形式出現；（2）[2分]現代的質量成本的目的則在于通過預防和評估活動中的適當投入，減少與失效有關的活動。六、應用題(每小題8分，共24分)1、某軟件需求規格說明中包含如下要求：第一列字符必須是A或B，第二列字符必須是一個數字，在此情況下進行文件修改。但是，如果第一列字符不正確，則輸出信息L；如果第二列字符不是數字，則給出信息M。請采用因果圖進行分析，并繪制出該軟件需求規格說明對應的因果圖。[4分]識別出所有原因和所有結果，并給出原因、結果元的編號如下：編號原因1第一列字符為A2第一列字符為B3第二列字符為一個數字11中間原因21修改文件22給出信息L23給出信息M（2）[4分]識別所有原因與原因之間，原因與結果之間，結果與結果之間的關系，再次接觸上繪制出因果圖如下圖所示。2、某程序模塊功能描述如下：用戶輸入分別合乎規則輸入年、月、日，程序即給出相應日期的下一天。假設限定該模塊年份在區間[1840，3000]，月份、日規定滿足公歷約束。試分別選取測試數據對年進行（1）基本邊界值測試和（2）健壯性測試。假設該模塊的輸入：年、月、日分別使用變量year,month,day表示。[4分]基本邊界值測試的測試數據year值在有效取值區間內取極值，其他變量取正常值。依據基本邊界值測試基本原理，測試數據選擇如下：組別測試數據1year=1840,month=1,day=122year=1841,month=2,day=203year=2002,month=9,day=14year=2999,month=11,day=105year=3000,month=3,day=30[4分]健壯性測試的測試數據year值在整個取值區間內取極值，其他變量取正常值。依據健壯性測試基本原理，數據選擇如下：組別測試數據1year=1840,month=1,day=122year=1841,month=2,day=203year=2002,month=9,day=14year=2999,month=11,day=105year=3000,month=3,day=306year=1839,month=4,day=197year=3001,month=8,day=223、某程序模塊如下，其中，S1,S2均為語句塊：if((A>1)AND(B==0))S1;if((A==2)OR(X>1))S2;請把上述代碼轉換成程序流程圖分別選擇測試數據使得（2）判定覆蓋、（3）條件組合覆蓋標準都能夠得到滿足。（1）[2分]程序流程圖（2）（2）[2分]判定覆蓋標準A=2,B=0,X=3；A=1,B=1,X=1（3）[4分]條件組合覆蓋A=2,B=0,X=3；A=1,B=1,X=1；A=2,B=1,X=1A=1,B=0,X=21、閱讀如下C程序：要求：請繪制出左邊代碼對應的流圖；計算所得流圖的環形復雜度要求：請繪制出左邊代碼對應的流圖；計算所得流圖的環形復雜度V(G);假設輸入的取值范圍為（1000，20001），請用基本路徑測試方法為變量year設計測試用例，使其滿足基本路徑測試的要求。 if(year%4==0){ if(year%100==0){ if(year%400!=0) leap=1; else leap=0; }elseleap=1; }else leap=0;returnleap;}[3分]流圖（2）[1分]V(G)=e-n+2=14-12+2=判定點數+1=區域數=4（3）[4分]問題3要求設計滿足基本路徑覆蓋的測試用例，而且輸入的取值范圍（1000，2001）。所選擇的測試數據只要使得獨立路徑數量得到滿足即可。典型的測試數據為：測試用例編號測試數據預期執行結果測試路徑1year=1001leap=01-2-3-11-122year=1004leap=11-2-4-5-10-11-123year=1100leap=01-2-4-6-7-9-10-11-124year=2000leap=11-2-4-6-8-10-11-122、被測程序段為：可供選擇的測試數據組合如下：可供選擇的測試數據組合如下：xyⅠ31Ⅱ-12Ⅲ03Ⅳ12找出實現（1）語句覆蓋；（2）判定覆蓋；（3）條件覆蓋至少要選擇的數據組。（1）III [2分] (2)III,IV [3分] (3)I,III [3分]3、擬對如下的軟件結構：請圖形的方式分別給出（1）深度優先的自頂向下集成測試策略、（2）自底向上集成測試策略的對上述軟件結構進行集成測試的詳細集成過程。假設集成測試過程中必須的驅動模塊、樁模塊分別編號：MX、SX，其中X為整數即驅動模塊或樁模塊編號。[4分]深度優先的自頂向下集成測試策略（2）[4分]自底向上集成測試策略1、有一段子程序：procedureexample(y,z:real;varx:real)begin if (y>1)and(z=0)thenx:=x/y; if (y=2)or（x=l）thenx:=x+l;end.該子程序接受x,y,z的值，并將計算結果x的值返回給調用程序。答題要求：(1)把上述子程序轉化成程序流程圖。(2)用白盒法設計測試用例，并使得所設計的一組或幾組測試數據能夠滿足條件組合覆蓋標準。 (1)程序流程圖（2）[4分]用白盒法中條件組合覆蓋設計測試用例：①y=2,z=0,x=4;②y=2,z=1,x=1;③y=1,z=0,x=2;④y=1,z=1,x=1.2、某程序模塊功能描述如下：用戶輸入分別合乎規則輸入年、月、日，程序即給出相應日期的下一天。假設限定該模塊年份在區間[1840，3000]，月份、日規定滿足公歷約束。試分別選取測試數據對月份進行（1）基本邊界值測試和（2）健壯性測試。、假設該模塊的輸入：年、月、日分別使用變量year,month,day表示。（1）[4分]基本邊界值測試的測試數據：在各變量取值有效區間內，month取極值，其他變量取任意正常值。按照基本邊界值測試原理，測試數據選取如下：組別測試數據1year=1840,month=1,day=122year=1841,month=2,day=203year=2002,month=9,day=14year=2999,month=11,day=105year=3000,month=12,day=30（2）[4分]健壯性測試的測試數據：month值在整個取值空間中選擇，其他變量取有效值區間中的任意值。按照健壯性測試原理，測試數據選取如下：組別測試數據1year=1840,month=1,day=122year=1841,month=2,day=203year=2002,month=9,day=14year=2999,month=11,day=105year=3000,month=12,day=306year=1839,month=0,day=197year=3001,month=13,day=223、變量的命名規則一般規定如下：變量名的長度不多于40個字符，第一個字符必須為英文字母，其他字母可以英文字母、數字以及下劃線的任意組合。請用等價分類法設計測試用例。(1)劃分等價類[4分]輸入條件合理等價類不合理等價類長度（1）小于40個字符（2）等于40個字符（5）大于40個字符第一個字符（3）英文字母（6）非英文字母其他字母（4）英文字母、數字或下劃線的任意組合空格標點符號運算符號其他可顯示字符(2)設計測試用例[4分]測試數據測試范圍期望結果s_name12等價類(1),(3),(4)有效a1b2c3d4e5f6g7h8i9j1k2l3m4n5o6p7q8r9s_tr等價類(2),(3),(4)有效a1b2c3d4e5f6g7h8i9j1k2l3m4n5o6p7q8r9s_trff等價類(5)無效234name等價類(6)無效abgh等價類(7)無效Ab!2f等價類(8)無效Fg+ghh等價類(9)無效H@gh等價類(10)無效軟件測試與質量保證一、軟件測試的定義定義：軟件測試是為了發現錯誤而執行程序的過程。或者說軟件測試是根據軟件開發各階段的規格說明和程序的內部結構而精心設計一批測試用例，并利用這些測試用例去運行程序，以發現程序錯誤的過程。二、測試的目的： 基于不同的立場，存在著兩種完全不同的測試目的。從用戶的角度出發，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可接受該產品。從軟件開發者的角度出發，則希望測試成為表明軟件產品中不存在錯誤的過程，驗證該軟件已正確地實現了用戶的要求，確立人們對軟件質量的信心。GrenfordMyers軟件測試目的(1)測試是程序的執行過程，目的在于發現錯誤；(2)一個好的測試用例在于能發現至今未發現的錯誤；(3)一個成功的測試是發現了至今未發現的錯誤的測試換言之，測試的目的是系統地找出軟件中潛在的各種錯誤和缺陷。能夠證明軟件的功能和性能與需求說明相符合。測試不能表明軟件中不存在錯誤，它只能說明軟件中存在錯誤。三、軟件測試的原則 1.應當把“盡早地和不斷地進行軟件測試”作為軟件開發者的座右銘。2.測試用例應由測試輸入數據和對應的預期輸出結果這兩部分組成。3.程序員應避免檢查自己的程序。4.在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。5.充分注意測試中的群集現象。

經驗表明，測試后程序中殘存的錯誤數目與該程序中已發現的錯誤數目成正比。6.嚴格執行測試計劃，排除測試的隨意性。7.應當對每一個測試結果做全面檢查。8.妥善保存測試計劃，測試用例，出錯統計和最終分析報告，為維護提供方便。四、軟件測試的對象 軟件測試并不等于程序測試。軟件測試應貫穿于軟件定義與開發的整個期間。需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都應成為軟件測試的對象。五、確認和驗證： 為把握軟件開發各個環節的正確性，需要進行各種確認和驗證工作。確認(Validation)，是一系列的活動和過程，目的是想證實在一個給定的外部環境中軟件的邏輯正確性。需求規格說明的確認程序的確認驗證(Verification)，試圖證明在軟件生存期各個階段，以及階段間的邏輯協調性、完備性和正確性。七、測試信息流測試信息流軟件配置：軟件需求規格說明、軟件設計規格說明、源代碼等；測試配置：測試計劃、測試用例、測試程序等；測試工具：測試數據自動生成程序、靜態分析程序、動態分析程序、測試結果分析程序、以及驅動測試的測試數據庫等等。測試結果分析：比較實測結果與預期結果，評價錯誤是否發生。排錯(調試)：對已經發現的錯誤進行錯誤定位和確定出錯性質，并改正這些錯誤，同時修改相關的文檔。修正后的文檔再測試：直到通過測試為止。通過收集和分析測試結果數據，對軟件建立可靠性模型利用可靠性分析，評價軟件質量：—軟件的質量和可靠性達到可以接受的程度；—所做的測試不足以發現嚴重的錯誤；如果測試發現不了錯誤，可以肯定，測試配置考慮得不夠細致充分，錯誤仍然潛伏在軟件中。八、測試與軟件開發各階段的關系軟件開發過程是一個自頂向下，逐步細化的過程軟件計劃階段定義軟件作用域軟件需求分析建立軟件信息域、功能和性能需求、約束等軟件設計把設計用某種程序設計語言轉換成程序代碼測試過程是依相反順序安排的自底向上，逐步集成的過程。九、軟件測試用例設計兩種常用的測試方法黑盒測試白盒測試（一）黑盒測試這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。黑盒測試又叫做功能測試或數據驅動測試。黑盒測試方法是在程序接口上進行測試，主要是為了發現以下錯誤:是否有不正確或遺漏了的功能?在接口上，輸入能否正確地接受?能否輸出正確的結果?是否有數據結構錯誤或外部信息(例如數據文件)訪問錯誤?性能上是否能夠滿足要求?是否有初始化或終止性錯誤?用黑盒測試發現程序中的錯誤，必須在所有可能的輸入條件和輸出條件中確定測試數據，來檢查程序是否都能產生正確的輸出。但這是不可能的。假設一個程序P有輸入量X和Y及輸出量Z。在字長為32位的計算機上運行。若X、Y取整數，按黑盒方法進行窮舉測試：可能采用的測試數據組：232×232＝264如果測試一組數據需要1毫秒，一年工作365×24小時，完成所有測試需5億年（二）白盒測試此方法把測試對象看做一個透明的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。軟件人員使用白盒測試方法，主要想對程序模塊進行如下的檢查：對程序模塊的所有獨立的執行路徑至少測試一次；對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次；在循環的邊界和運行界限內執行循環體；測試內部數據結構的有效性，等。對一個具有多重選擇和循環嵌套的程序，不同的路徑數目可能是天文數字。給出一個小程序的流程圖，它包括了一個執行20次的循環。包含的不同執行路徑數達5^20條，對每一條路徑進行測試需要1毫秒，假定一年工作365×24小時，要想把所有路徑測試完，需3170年白盒測試的測試用例設計十、白盒測試的測試用例設計（一）邏輯覆蓋邏輯覆蓋是以程序內部的邏輯結構為基礎的設計測試用例的技術。它屬白盒測試。語句覆蓋判定覆蓋條件覆蓋判定－條件覆蓋條件組合覆蓋路徑覆蓋。舉例：所有路徑為：L1(a->c->e),L2(a->b->d),L3(a->b->e),L4(a->c->d)依據以上推導出來的結果就可以設計滿足要求的測試用例。（二）語句覆蓋語句覆蓋就是設計若干個測試用例，運行被測程序，使得每一可執行語句至少執行一次。在圖例中，正好所有的可執行語句都在路徑L1上，所以選擇路徑L1設計測試用例，就可以覆蓋所有的可執行語句。測試用例的設計格式如下

【輸入的(A,B,X)，輸出的(A,B,X)】為圖例設計滿足語句覆蓋的測試用例是:

【(2,0,4)，(2,0,3)】覆蓋ace【L1】（三）判定覆蓋判定覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經歷一次。判定覆蓋又稱為分支覆蓋。對于圖例，如果選擇路徑L1和L2，就可得滿足要求的測試用例【(2,0,4)，(2,0,3)】覆蓋ace【L1】

【(1,1,1)，(1,1,1)】覆蓋abd【L2】如果選擇路徑L3和L4，還可得另一組可用的測試用例:

【(2,1,1)，(2,1,2)】覆蓋abe【L3】

【(3,0,3)，(3,1,1)】覆蓋acd【L4】（四）條件覆蓋條件覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的每個條件的可能取值至少執行一次。在圖例中，我們事先可對所有條件的取值加以標記。例如，對于第一個判斷：條件A＞1取真為，取假為

條件B＝0取真為，取假為對于第二個判斷：條件A＝2取真為，取假為

條件X＞1取真為，取假為測試用例覆蓋分支條件取值【(2,0,4)，(2,0,3)】L1(c,e)【(1,0,1)，(1,0,1)】L2(b,d)【(2,1,1)，(2,1,2)】L3(b,e)或測試用例 覆蓋分支 條件取值【(1,0,3)，(1,0,4)】L3(b,e)【(2,1,1)，(2,1,2)】L3(b,e) （五）判定－條件覆蓋判定－條件覆蓋就是設計足夠的測試用例，使得判斷中每個條件的所有可能取值至少執行一次，同時每個判斷中的每個條件的可能取值至少執行一次。測試用例 覆蓋分支條件取值【(2,0,4)，(2,0,3)】L1(c,e)【(1,1,1)，(1,1,1)】L2(b,d)由多個基本判斷組成的流程圖（六）條件組合覆蓋條件組合覆蓋就是設計足夠的測試用例，運行被測程序，使得每個判斷的所有可能的條件取值組合至少執行一次。記①A＞1,B＝0作

②A＞1,B≠0作

③A≯1,B＝0作④A≯1,B≠0作⑤A＝2,X＞1作

⑥A＝2,X≯1作

⑦A≠2,X＞1作

⑧A≠2,X≯1作測試用例覆蓋條件 覆蓋組合【(2,0,4),(2,0,3)】(L1) ①,⑤【(2,1,1),(2,1,2)】(L3) ②,⑥【(1,0,3),(1,0,4)】(L3) ③,⑦【(1,1,1),(1,1,1)】(L2) ④,⑧（七）路徑測試路徑測試就是設計足夠的測試用例，覆蓋程序中所有可能的路徑。測試用例通過路徑覆蓋條件【(2,0,4),(2,0,3)】ace(L1) 【(1,1,1),(1,1,1)】abd(L2)【(1,1,2),(1,1,3)】abe(L3) 【(3,0,3),(3,0,1)】acd(L3) （八）基本路徑集測試覆蓋關鍵路徑。得到程序的控制流程圖/程序圖SequenceIfWhileSequenceIfWhile計算環路復雜性的方法：-V(G)=簡單判定節點數+1V(G)=E-N+2(E是邊數，N是定點數）V(G)=封閉區域數+1V(G)=4根據環路復雜性產生基本路徑集Path1:1-2-3-8Path2:1-2-3-8-1-2-3Path3:1-2-4-5-7-8Path4:1-2-4-6-7-8準備測試用例覆蓋所有基本路徑十一。黑盒測試的測試用例設計等價類劃分邊界值分析錯誤推測法因果圖（一）等價類劃分等價類劃分是一種典型的黑盒測試方法，使用這一方法時，完全不考慮程序的內部結構，只依據程序的規格說明來設計測試用例。等價類劃分方法把所有可能的輸入數據，即程序的輸入域劃分成若干部分，然后從每一部分中選取少數有代表性的數據做為測試用例。使用這一方法設計測試用例要經歷劃分等價類（列出等價類表）和選取測試用例兩步。劃分等價類

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的。測試某等價類的代表值就等價于對這一類其它值的測試。等價類的劃分有兩種不同的情況：

①有效等價類：是指對于程序的規格說明來說，是合理的，有意義的輸入數據構成的集合。 ②無效等價類：是指對于程序的規格說明來說，是不合理的，無意義的輸入數據構成的集合。在設計測試用例時，要同時考慮有效等價類和無效等價類的設計。劃分等價類的原則。

(1)如果輸入條件規定了取值范圍，或值的個數，則可以確立一個有效等價類和兩個無效等價類。例如，在程序的規格說明中，對輸入條件有一句話：“……項數可以從1到999……”則有效等價類是“1≤項數≤999”兩個無效等價類是“項數＜1”或“項數＞999”。在數軸上表示成:(2)如果輸入條件規定了輸入值的集合，或者是規定了“必須如何”的條件，這時可確立一個有效等價類和一個無效等價類。例如，在Pascal語言中對變量標識符規定為“以字母打頭的……串”。那么所有以字母打頭的構成有效等價類，而不在此集合內（不以字母打頭）的歸于無效等價類。(3)如果輸入條件是一個布爾量，則可以確定一個有效等價類和一個無效等價類。

(4)如果規定了輸入數據的一組值，而且程序要對每個輸入值分別進行處理。這時可為每一個輸入值確立一個有效等價類，此外針對這組值確立一個無效等價類，它是所有不允許的輸入值的集合。例如，在教師上崗方案中規定對教授、副教授、講師和助教分別計算分數，做相應的處理。因此可以確定4個有效等價類為教授、副教授、講師和助教，一個無效等價類，它是所有不符合以上身分的人員的輸入值的集合。(5)如果規定了輸入數據必須遵守的規則，則可以確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。例如，Pascal語言規定“一個語句必須以分號‘;’結束”。這時，可以確定一個有效等價類“以‘;’結束”，若干個無效等價類“以‘:’結束”、“以‘,’結束”、“以‘’結束”、“以LF結束”等。確立測試用例

在確立了等價類之后，建立等價類表，列出所有劃分出的等價類。再從劃分出的等價類中按以下原則選擇測試用例：

(1)為每一個等價類規定一個唯一編號；

(2)設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止；

（3）設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。用等價類劃分法設計測試用例的實例

在某一PASCAL語言版本中規定：“標識符是由字母開頭，后跟字母或數字的任意組合構成。有效字符數為8個，最大字符數為80個。” 并且規定：“標識符必須先說明，再使用。”“在同一說明語句中，標識符至少必須有一個。”用等價類劃分的方法，建立輸入等價類表:下面選取了9個測試用例，它們覆蓋了所有的等價類。

①VARx，T1234567：REAL；BEGINx:=3.414；T1234567:=2.732；...…(1),(2),(4),(8),(9),(12),(14)

②VAR：REAL；(3)

③VARx，：REAL;(5)④VART12345678：REAL；(6)⑤VART12345......：REAL；(7)

多于80個字符⑥VART$：CHAR；(10)⑦VARGOTO：INTEGER；(11)⑧VAR2T：REAL；(13)⑨VARPAR：REAL；(15)

BEGIN......

PAP:=SIN(3.14*0.8)/6；（二）邊界值分析邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充。人們從長期的測試工作經驗得知，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。比如，在做三角形計算時，要輸入三角形的三個邊長：A、B和C。我們應注意到這三個數值應當滿足A＞0、B＞0、C＞0、A＋B＞C、A＋C＞B、B＋C＞A，才能構成三角形。但如果把六個不等式中的任何一個大于號“＞”錯寫成大于等于號“≥”，那就不能構成三角形。問題恰出現在容易被疏忽的邊界附近。這里所說的邊界是指，相當于輸入等價類和輸出等價類而言，稍高于其邊界值及稍低于其邊界值的一些特定情況。使用邊界值分析方法設計測試用例，首先應確定邊界情況。應當選取正好等于，剛剛大于，或剛剛小于邊界的值做為測試數據，而不是選取等價類中的典型值或任意值做為測試數據。（三）錯誤推測法人們也可以靠經驗和直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子。這就是錯誤推測法。錯誤推測法的基本想法是：列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例。十二。軟件測試的策略測試過程按4個步驟進行，即單元測試、組裝測試、確認測試和系統測試。開始是單元測試，集中對用源代碼實現的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現了規定的功能組裝測試把已測試過的模塊組裝起來，主要對與設計相關的軟件體系結構的構造進行測試。確認測試則是要檢查已實現的軟件是否滿足了需求規格說明中確定了的各種需求，以及軟件配置是否完全、正確。系統測試把已經經過確認的軟件納入實際運行環境中，與其它系統成份組合在一起進行測試。（一）單元測試(UnitTesting)單元測試又稱模塊測試，是針對軟件設計的最小單位─程序模塊，進行正確性檢驗的測試工作。其目的在于發現各模塊內部可能存在的各種差錯。單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。1.單元測試的內容在單元測試時，測試者需要依據詳細設計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結構，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應。(1)模塊接口測試在單元測試的開始，應對通過被測模塊的數據流進行測試。測試項目包括：調用本模塊的輸入參數是否正確；本模塊調用子模塊時輸入給子模塊的參數是否正確；全局量的定義在各模塊中是否一致在做內外存交換時要考慮：文件屬性是否正確；OPEN與CLOSE語句是否正確；緩沖區容量與記錄長度是否匹配；在進行讀寫操作之前是否打開了文件；在結束文件處理時是否關閉了文件；正文書寫／輸入錯誤，I／O錯誤是否檢查并做了處理。(2)局部數據結構測試不正確或不一致的數據類型說明使用尚未賦值或尚未初始化的變量錯誤的初始值或錯誤的缺省值變量名拼寫錯或書寫錯不一致的數據類型全局數據對模塊的影響(3)路徑測試選擇適當的測試用例，對模塊中重要的執行路徑進行測試。應當設計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。對基本執行路徑和循環進行測試可以發現大量的路徑錯誤。(4)錯誤處理測試出錯的描述是否難以理解出錯的描述是否能夠對錯誤定位顯示的錯誤與實際的錯誤是否相符對錯誤條件的處理正確與否在對錯誤進行處理之前，錯誤條件是否已經引起系統的干預等(5)邊界測試注意數據流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。2.單元測試的步驟模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯系，用一些輔助模塊去模擬與被測模塊相聯系的其它模塊。驅動模塊(driver)樁模塊(stub)──存根模塊驅動模塊(driver)──相當于所測模塊的主程序。它接收測試數據，把這些數據傳送給所測模塊，最后再輸出實測結果。樁模塊(stub)──存根模塊。用以代替所測模塊調用的子模塊。如果一個模塊要完成多種功能，可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作，對關鍵模塊還要做性能測試。對支持某些標準規程的程序，更要著手進行互聯測試。有人把這種情況特別稱為模塊測試，以區別單元測試。（二）組裝測試（IntegratedTesting）組裝測試(集成測試、聯合測試）通常，在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統。這時需要考慮的問題是：在把各個模塊連接起來的時侯，穿越模塊接口的數據是否會丟失；一個模塊的功能是否會對另一個模塊的功能產生不利的影響；各個子功能組合起來，能否達到預期要求的父功能；全局數據結構是否有問題；單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。在單元測試的同時可進行組裝測試，發現并排除在模塊連接中可能出現的問題，最終構成要求的軟件系統。子系統的組裝測試特別稱為部件測試，它所做的工作是要找出組裝后的子系統與系統需求規格說明之間的不一致。通常，把模塊組裝成為系統的方式有兩種一次性組裝方式增殖式組裝方式1.一次性組裝方式(bigbang)它是一種非增殖式組裝方式。也叫做整體拼裝。使用這種方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統。2.增殖式組裝方式這種組裝方式又稱漸增式組裝首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統在組裝的過程中邊連接邊測試，以發現連接過程中產生的問題通過增殖逐步組裝成為要求的軟件系統。(1)自頂向下的增殖方式這種組裝方式將模塊按系統程序結構，沿控制層次自頂向下進行組裝。自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。選用按深度方向組裝的方式，可以首先實現和驗證一個完整的軟件功能。(2)自底向上的增殖方式這種組裝的方式是從程序模塊結構的最底層的模塊開始組裝和測試。因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。自頂向下增殖的方式和自底向上增殖的方式各有優缺點。一般來講，一種方式的優點是另一種方式的缺點。(3)混合增殖式測試衍變的自頂向下的增殖測試首先對輸入／輸出模塊和引入新算法模塊進行測試;再自底向上組裝成為功能相當完整且相對獨立的子系統;然后由主模塊開始自頂向下進行增殖測試。自底向上-自頂向下的增殖測試首先對含讀操作的子系統自底向上直至根結點模塊進行組裝和測試;然后對含寫操作的子系統做自頂向下的組裝與測試。回歸測試這種方式采取自頂向下的方式測試被修改的模塊及其子模塊;然后將這一部分視為子系統，再自底向上測試。關鍵模塊問題在組裝測試時，應當確定關鍵模塊，對這些關鍵模塊及早進行測試。關鍵模塊的特征：

①滿足某些軟件需求；

②在程序的模塊結構中位于較高的層次（高層控制模塊）；