一、選擇題
1.分析：對程式的測試最好由第三方測試機構來做，對程式的除錯最好由程式設計師來做，故B不對。由測試用例的原則：程式設計師應避免測試自己的程式得C說法錯誤。又由測試的目的是找錯而不是證明程式正確，故D不正確。
2.分析：軟體測試的目的是發現軟體中的錯誤，而非證明軟體的正確性。
3.分析：軟體缺陷可按軟體缺陷型別或嚴重性進行統計，而軟體缺陷型別或嚴重性可以分為軟體系統崩潰、功能失效和容錯性問題、使用者友好性、效能、文字錯誤和增強需求等型別。
4.分析：軟體測試不僅僅限於程式編碼之後，而應該貫穿於軟體開發的全過程。軟體測試並不等於程式測試，因此，需求分析、概要設計、詳細設計以及程式編碼等各個階段所得到的文件資料，包括需求規格說明、軟體概要設計規格說明、軟體詳細設計規格說明以及源程式，都應做為軟體測試的物件。
5.分析：軟體的外部設計是從使用者的角度對產品進行描述的，外部設計規格說明是在外部設計期間產生的文件，使用者手冊是另一種文件，與外部設計規格說明不同的是，它是在需求獲取與定義階段就開始建立，以後要不斷細化和完善的文件。
6.分析：桌上檢查(Desk Checking)是一種傳統的檢查方法，由程式設計師自己檢查自己編寫的程式。程式設計師在程式通過編譯之後，進行單元測試設計之前，對源程式程式碼進行分析，對照錯誤列表進行檢查，對程式推演測試資料，並補充相關的文件。桌上檢查的目的就是發現程式中的錯誤。
7.分析：同行評審的方法很多，基於正式化程度可以分為臨時評審、桌上檢查、結對評審、走查、小組評審、正式評審六種，其中走查是一種非正式的評審，但在軟體企業中被廣泛使用。走查的方法有兩種：一種是使用一些樣品資料作為測試用例，一步步的執行模組，極為參與評審的一起檢查以確保正確的邏輯和行為。另一種走查是按照指令碼執行，通過指令碼描述一個具體的任務或場景，用以說明系統如何在互動中完成預定的功能。
8.分析：條件覆蓋就是指設計若干測試用例，執行被測程式，使得每個判定的每個條件的可能取值至少評價一次。本題可以取(A=8，B=6)和(A=9，B=9)這兩組測試用例，這樣A<=8及B>7都能夠把真假各取一次，達到100%的條件覆蓋率。
9.分析：對於一個軟體，其可能的輸入資料數量一般是非常驚人的，所以要想全部將其作為測試用例是不現實的，應當選擇發現錯誤可能性大的資料作為測試用例，不能隨機選取測試用例，故A正確，B、C錯誤。軟體測試貫穿於軟體開發的各個階段，D項錯誤。
10.分析：在進行資料流測試時，弄清楚各型別結點的含義非常重要。輸出語句、賦值語句、迴圈控制語句、條件語句和過程呼叫，都是定義語句的例子。如果執行對應這種語句的結點，就會改變該變數的儲存單元的內容。輸出語句、賦值語句、條件語句、迴圈控制語句和過程呼叫，都是使用語句的例子。如果執行對應這種語句的結點，不會改變該變數的儲存單元內容。
11.分析：一般測試過程中使用的黑盒測試是基於功能的測試，可以看作是窮舉輸入測試，只有把所有可能的輸入都作為測試用例使用，才能查出程式中所有的錯誤。黑盒測試的覆蓋率取決於測試用例設計的完備性。
12.分析：軟體單元測試的物件是可獨立編譯或彙編的程式模組或軟體構件或面向物件設計中的類。而完整的、整合的計算機系統是系統測試和驗收測試的測試物件。
13.分析：效能測試的目標是為了提高軟體效能。對效能測試要判斷出哪些模組執行得最多或者佔用的機器時間最多，這些模組就將被重新檢查、重新編寫以便執行的更快。效能測試可以通過白盒或黑盒測試方法來測試，但在大多數實際情況下，人們都是使用黑盒測試方法來實現效能測試。
14.分析：對於效能測試來說，分析效能下降曲線往往可以從中獲得很多重要資訊，所謂效能下降曲線，就是指效能指標(比如響應時間和吞吐量)隨使用者數的增加而變化的曲線。通常分析效能下降曲線時，會首先將其分為幾個區間：效能平坦區、效能輕微下降區、效能急劇下降區。其中效能平坦區是軟體執行的正常狀態，因此人們往往希望該區間越長越好;效能輕微下降區是軟體承受高負載的緩衝區，該區間也是越長越好;效能急劇下降區不是軟體的正常執行區間，這一階段響應時間會急劇增加至使用者不能忍受，吞吐量會急劇下降甚至低於單使用者時的吞吐量，但該區間對於分析效能瓶頸卻有很大作用，通常說來，效能急劇下降區的起始點(也稱效能拐點)就是效能瓶頸出現的地方，此時進一步分析資源利用率就可以找到效能瓶頸的原因。
15.分析：對系統測試分析時，通常從使用者層、應用層、子系統層、協議等幾個層次入手。因為使用者層面向的最終使用者是使用者，因此使用者層的測試主要圍繞著使用者介面的規範性、友好性、可操作性、系統對使用者的支援，以及資料的安全性等方面展開。另外，使用者層的測試通常還應注意可維護性測試和安全性測試。選項C併發效能測試屬於應用層測試所關注的。
16.分析：由於系統測試的主要目標是測試開發出來的軟體是否是問題空間的一個合理解，因此對於系統測試而言，面向物件軟體與傳統結構化軟體並沒有本質區別。
17.分析：面向物件設計與面向物件分析有很多的區別，不能將它們混淆。
18.分析：表示層的測試主要集中在客戶端。包括四個方面：排版結構的測試、連結結構的測試、客戶端程式的測試、瀏覽器相容性測試。
19.分析：Web應用軟體的安全性不僅僅與Web應用軟體本身的開發相關。系統的安全漏洞其實也算是系統的缺陷，所以安全漏洞的檢測也屬於測試的範疇。對於黑客來說，攻擊更主要是利用系統的已知漏洞進行，而不是黑客本身發現的新漏洞。狹義的入侵是指黑客進入或試圖進入一個系統，而廣義的入侵是指以任何違反安全規定的方式使用一個系統
20.分析：軟體易用性測試主要包括三個方面：易安裝性測試、功能易用性測試和使用者介面測試，其中使用者介面是使用者與軟體打交道的唯一渠道，使用者介面是否友好在很大程度上決定了軟體的`易用性，因此使用者介面測試是軟體易用性測試最重要的一項內容，選項A說法正確。對軟體功能的關聯包括靜態關聯和動態關聯兩方面，其中對於靜態關聯的測試可以通過檢查選單完成，而對於動態關聯的測試需要針對各項任務設計測試用例，以檢查軟體能否合理引導使用者使用下一步的功能，故選項B說法不正確。使用軟體的目的就是能夠減少重複輸入，保證資料的一致性，減輕人工勞動，提高工作效率，故選項C說法正確。軟體的安裝通常需要在安裝手冊的指導下完成，因此檢查和評估軟體安裝手冊的正確性和易用性是安裝性測試的重要內容，選項D說法正確。
21.分析：測試總結是測試過程的最後一個活動，在測試報告中的內容包括：①測試專案概述，②測試用例執行情況總結，③軟體缺陷報告總結，④ 被測軟體評價。
22.分析：測試計劃的要點有：①目標和範圍：包括產品特性、質量目標、各個階段的測試物件、目標範圍和限制，②專案估算：根據歷史資料和採用恰當的評估技術，對測試工作量、所需資源作出合理估算，③風險計劃：測試可能存在的風險分析、識別以及風險的迴避監控和管理，④日程：專案工作分解結構，並採用時限圖、甘特圖等方法制定時間和資源表，⑤專案資源：人員、硬體和軟體等資源的組織和分配，人力資源是重點，⑥跟蹤和控制機制：質量保證和控制、變更管理和控制。
23.分析：自動化測試不是萬能的，它所能夠完成的功能也是有限的，不可能也不要期望將所有的測試活動自動化。根據經驗，自動測試只能發現20%的缺陷，而手工測試可以發現80%，A項說法錯誤。很多情況下，例如軟體不穩定、測試結果易於人工驗證但難於自動化、涉及物理互動的測試，不適合用自動化測試，C項說法錯誤。軟體測試的目的是發現缺陷，D錯誤。
24.分析：為獨立的配置管理而設計的並且能滿足終端使用者功能的一組軟體稱為是軟體配置項。軟體配置項測試的測試工作要求被測軟體已通過單元測試和整合測試，對需要固化執行的軟體提供韌體。
25.分析：軟體配置項測試是由軟體的供方組織，由獨立於軟體開發人員實施，而系統測試是由軟體的需方組織，由獨立於軟體開發人員實施。二者都可以委託國家認可的第三方測試機構來實施。在二者的測試工作中都滿足對需要固化的軟體提供韌體。
二、論述題
1.分析：首先分析程式的規則說明和被測程式的功能，將其輸入情況劃分為有效等價類和無效等價類，然後按照等價類設計測試用例的方法設計有效的測試用例和無效的測試用例。
2.分析：軟體測試過程是一種抽象的模型，用於定義軟體測試的流程和方法。軟體開發過程質量決定軟體的質量，軟體測試過程質量直接影響測試結果的準確性和有效性。
3.分析：首先根據程式的原始碼，畫出控制流圖。然後通過控制流圖可以計算出該程式的複雜度，找出所有的獨立路徑，根據基本路徑測試法設計測試用例。
