軟體測試 計劃 設計和執行

◾計劃和組織軟體專案中的測試

◾欣賞不同的測試方法

◾建立與包相對應的測試設計

◾為類測試建立測試工具

◾為用例測試建立功能測試用例

◾使用等價分割槽和邊界值建立樣本測試資料

◾記錄執行測試用例和整理結果的步驟

◾規劃執行測試（例如，效能，體積測試）

簡介  質量控制（QC），通常稱為測試，在任何軟體開發和維護專案中都發揮著重要作用。測試的目的是檢測錯誤。這些錯誤可能發生在需求，設計，模型和程式中。在為檢測錯誤而編寫的測試用例中也可能存在錯誤。測試的主要目的是驗證軟體程式的正確性。

本章討論在軟體專案中規劃和組織測試。此討論包括建立測試計劃和設計，瞭解測試型別，建立測試資料以及執行測試。

測試專案中的需求測試需要了解正在測試的“內容”，過程規則（即“如何”測試，包括如何對資料進行分類以進行測試），建立測試用例，識別測試工具以及採購測試技能。

◾使用UML進行軟體工程有效的測試工件包括測試策略（即，經過仔細考慮和記錄良好的方法來測試特定的軟體產品），正確記錄的測試計劃，測試用例（具有正面和負面情景） ，良好的測試架構，測試資料和測試的可追溯性。

詳細和單元級測試包括設計和建立“測試類”，它將通過檢查演算法並通過已經開發的類傳遞精心構造的資料集來測試實際的解決方案類。設計測試類並將其納入測試設計中的挑戰是本次討論的重要部分。

在大多數實際專案中，測試可以使用大約三分之一的分配專案時間。但是，在實踐中，如果專案時間不足，測試是第一個被削減的活動。這是因為測試的可見影響不會立即感覺到，但通常在系統投入生產之後。因此，重要的是將測試作為整個開發過程的一個組成部分。

各種型別的測試圖19.1顯示了在測試計劃期間要考慮的各種型別的測試。這些是：

◾單元測試 - 測試模型和系統中小單元的功能，例如用例和類。單元測試通常是程式碼的技術測試，它們需要編寫測試工具並建立測試資料。

◾元件測試 - 測試包含多個類的整個元件或子系統的功能。

◾系統測試 - 測試整個系統的功能以及系統元件之間的相互依賴性。當專案達到此係統測試級別時，它還可以進行全面性能和負載測試。

◾整合測試 - 測試整個系統及其與已在生產中的所有其他系統和資料庫的介面。整合測試受益於現有的企業體系結構，該體系結構提供有關所有現有系統及其彼此對齊的資訊。

◾驗收測試 - 系統使用者在接受系統之前獨立於開發人員進行。開發人員可以回答查詢，設定測試環境並支援使用者;但是他們沒有證明他們的工作是合理的 - 相反，專案團隊一起研究驗收測試結果，以確定改進的潛力。

◾操作測試 - 在系統執行時測試系統的功能。操作要求（也稱為非功能性要求或NFR並在第20章中討論）包括效能，數量，安全性和可擴充套件性，僅舉幾例。操作測試需要儘可能複製系統實際負載的測試資料庫和環境。

◾迴歸測試 - 在系統的任何軟體包中修復錯誤後在整個系統上執行。迴歸測試可以在開發期間以及系統執行期間進行。迴歸測試不僅可以確保系統中新固定的部分正常工作，而且系統的現有功能也不會受到新修復的影響。自動化測試工具在確保有效且高效地執行迴歸測試方面發揮著重要作用。

◾安全測試 - 雖然被視為操作測試的一部分，但安全測試與圖19.1中的其他測試正交。這是因為安全測試需要在軟體解決方案的任何和所有測試階段進行。從單元測試開始，解決方案的安全性需要在開發的所有其他階段進行測試。

滲透測試，防禦和攻擊性黑客測試以及功能安全檢查是此安全測試的一部分 - 這在本質上變得非常技術性。

向利益相關者正式報告測試結果，可以瞭解專案的狀態，系統在生產中的可靠性，以及是否需要制定任何戰略決策，特別是與系統釋出相關的決策（例如延遲釋出)。

測試策略影響因素

測試的戰略方面包括在專案中討論測試範圍，所需資源的時間和成本，從哪裡獲取資源以及其他高階複雜性。

在測試計劃中還考慮了與不測試解決方案的某些部分相關的風險以及缺陷優先順序劃分的成本。儘管測試本身具有戰術性，但在專案開始時需要採用戰略方法來為軟體解決方案提供高質量的好處。

基於UML的專案型別會影響測試計劃的建立。例如，整合專案的測試計劃側重於新開發的系統和相應的遺留應用程式之間的介面。包實施專案的測試計劃側重於測試用例的準確性和相關性。

專案的規模也會影響測試方法。對於較大的專案，更大的系統測試生命週期必須考慮測試導致的返工成本和時間。

在大型專案中，一旦開發出第一個包，測試就會開始，因此，它是迭代和增量開發生命週期的一部分。另一方面，小型專案可能專注於對整個產品的一次性測試;與大型專案相比，小型專案可能只有相對較少的演練和檢查。

專案的重要性在質量控制中也很重要。在完成系統的基本測試之後，可以縮小測試範圍以僅關注關鍵

對於具有廣泛法規遵從性，需要稽核和外部批准的專案，可以使用基於缺陷的優先​​級排序方法。

組織軟體測試組織測試功能從軟體專案的早期階段開始。測試策略定義測試型別，預期結果，測試如何完成，測試何時發生，使用的工具，角色和職責，報告和驗收標準。最終批准測試結果的關鍵角色和責任也是測試策略的一部分。

圖19.2顯示了測試計劃作為基於測試策略組織測試的關鍵文件。測試計劃包含處於包或子系統級別的測試設計。通過考慮基於用例和基於類的測試（稍後討論），測試設計受益。最後，測試用例處於詳細的單元級別。接下來討論測試組織的這三個方面。

測試計劃

測試計劃是一個基於測試策略的重要文件。測試計劃詳細說明了測試所需的資源，安排測試設計和測試用例的時間表，測試工具的採購和使用，以及記錄和重新測試錯誤以及建立和維護測試環境的方法。

一個好的測試計劃還規定了要測試的模組的預期工作量以及可用的資源。一個好的測試計劃旨在在第一個包實施後立即開始測試活動。這要求在軟體過程的初始迭代期間開發測試計劃。在建立整體測試計劃時，關注軟體功能，可靠性和可用性的客戶導向外部產品屬性（Younessi，2002）1也很重要。

測試計劃的時間表（可能在質量或專案計劃內）還應包括完成個別測試的具體日期和負責的團隊成員。基於雲的測試工具提供了一個數據庫，用於記錄和報告軟體事件，並能夠對測試結果進行分析，並對與測試相關的風險進行有根據的猜測。

測試計劃中應包含以下詳細資訊：

◾進行測試的目的或目的;雖然這通常很簡單（提高質量和減少錯誤），但測試可以採取各種形式並具有各種目標（例如，確保軟體包符合法規要求或測試效能以確定來自第三方的服務質量供應商）。

◾參與測試的人員和流程 - 這些是用於測試的資源，來源的地方（例如，內部，外部）以及他們的技能水平;更新人員技能以確保其符合測試需求是專案計劃此部分的一部分。

◾整體驗收標準 - 與整個測試過程的目標相似，驗收標準也是測試計劃檔案中的一個戰略部分。這是描述使用者在什麼條件下“接受”系統的宣告。

◾測試設計列表 - 源自用於建立整個測試環境的過程，這些測試設計通常對映到軟體模型中的軟體包。測試設計包含處理測試軟體解決方案的包和子系統的特定資訊。

◾詳細用於測試的方法和過程 - 這些是用於測試軟體解決方案的活動和任務的描述。標準（如ISTQB和ISO9001）可以為測試中使用的方法和方法提供輸入。

◾基於垂直 - 水平，黑白框等組合的測試方法（本章稍後將詳細介紹）。

◾通過可追溯性矩陣跟蹤測試到其原始要求的方法。

◾基於可用資源，開發進展情況（例如，互動，增量，並行）的測試職責和時間表將生成在整個系統開發之前準備好進行測試的模組。

◾報告錯誤和重新測試的方法 - 這是對如何進行重新測試和迴歸測試（即在錯誤/錯誤的一部分修復後對解決方案進行全面測試）的描述。為重新測試做準備是一項具有挑戰性的專案管理工作，因為很難預測在軟體開發練習的測試階段會發現什麼。

可追溯性矩陣

可追溯性矩陣被視為測試計劃的一部分。然而，這個矩陣非常重要，可以成為它自己的獨立檔案。 treacability矩陣由質量經理和使用者共同擁有。但是，對於較小的專案，此矩陣可以是前面提到的測試計劃的一部分。

顧名思義，可追溯性矩陣將測試用例跟蹤到正在測試的相應需求的來源 - 主要是用例。可追溯性矩陣揭示了一個需求是否可以追溯到測試用例。如果沒有，則測試用例不足或者某些要求未得到滿足。建模工具通常提供可跟蹤性工具，可用於報告此活動。可追溯性是一項持續的活動，從第一次迭代測試用例建立開始。

設計的軟體工程用例和類在軟體建模中主要有不同的焦點 - 用例關注問題空間中的需求和解決方案空間中的設計類。此外，用例和類之間的關係是多對多的，如圖19.3所示。這兩個關鍵軟體建模元素的測試設計需要考慮上述因素以及測試設計中用例和類測試之間的潛在重疊。

類，特別是在解決方案領域，由解決方案設計人員擁有。問題空間中的用例更接近使用者和業務分析師。由於這種劃分，屬於使用者和業務分析師的驗收測試用例側重於測試用例質量，而技術測試用例包括編寫測試工具。測試工具是一組類，僅用於通過自動傳遞測試資料和執行功能來測試主類。測試工具通過測試資料處理和處理能力來測試系統中的所有類。

測試設計還關注系統的單獨可執行部分 - 例如，諸如包之類的子系統。這一焦點導致了一種測試方法和一組特定於特定包的測試用例。例如，患者包的測試設計驗證並驗證建立和管理患者詳細資訊的所有方面，而資料庫包的測試設計包含驗證和驗證醫院管理系統（HMS）資料庫的效能和安全性方面的測試用例。

與每個包相對應的測試設計還考慮了要測試的類的數量及其相應的複雜性。對於每個類，有許多測試用例測試不同的功能。

測試設計進一步整合了額外的測試用例，這些測試用例涉及測試整個元件或包，而不是針對各個類。例如，測試設計中的一組測試用例測試Date類，另一組測試用例可以測試Account類。但是，一個好的測試設計可以確保有額外的測試用例來測試兩個類的工作以及它們一起提供給呼叫類的結果。

Class 1 Class 2 Class 3 Class 4 Class 5使用案例1使用案例2使用案例3使用案例4技術測試用例測試一個類的所有操作;因此，它導致對許多用例的一些功能的測試。此技術測試不同於驗收測試，其中測試單元是用例而非類。

圖19.3基於用例和基於類的測試設計。

測試方法

測試方法是測試策略的一部分。測試方法有助於確定要設計的測試型別，為測試建立的資料型別以及進行測試所需人員的技能。

專案的型別和大小以及被測試類的重要性對於使測試人員能夠開發出合理的測試方法起著重要作用。這裡討論的測試方法並不是彼此獨有的。大多數測試設計都包含了此處討論的每種測試方法的某些方面。在建立測試設計時牢記測試方法使它們更加詳盡和準確。

圖19.4突出顯示了不同的測試方法。這些方法涉及：

◾測試黑盒與白盒測試的可見性

◾自動化測試 - 進行手動測試與使用自動測試工具

◾切片測試 - 垂直（功能）或水平（技術）

◾資料等價分割槽和邊界值的分割槽

下面將進一步詳細討論這些方法。

測試的可見性 - 黑盒與白盒測試黑盒白盒測試涉及被測元素的開放性或封閉性。

黑盒測試僅涉及系統的輸入和輸出，而白盒測試則用於詳細檢查軟體的功能和過程中的邏輯。白盒方法非常適合驗證類設計的內部細節;黑盒測試用於用例的驗收測試。

測試手冊與自動手冊或自動化測試的自動化基於測試中使用的人員和工具。在手動測試中，測試人員在物理上執行測試用例並手動檢查結果。相反，在水平手動白框[可見性] [分割槽] [自動化]邊界值等效分割槽黑盒自動[切片]測試方法垂直圖19.4測試方法。

自動化測試工具用於驗證軟體。自動化測試可以幫助進行迴歸測試 - 其中系統的所有部分都經過測試（即使它們沒有改變），以確保系統某個部分的更改不會在其他部分中產生錯誤。

切片測試 - 垂直（功能）或水平（技術）垂直或水平測試表示系統的行為與技術切片以進行測試。

系統的垂直劃分意味著將其從應用程式的角度劃分為子系統，並將這些劃分結合到測試設計中。例如，分為患者，諮詢和工作人員的醫院應用程式僅針對這些包進行測試。

測試的水平切片 基於其基礎設施而不是其功能。例如，用於測試HMS的水平切片意味著首先測試整個系統僅用於資料，然後測試業務物件以及跨所有包和程式的GUI切割。

資料等效分割槽和邊界值的劃分 等價劃分和邊界值表示如何對測試資料進行抽樣測試（Meyers，1979）.2等價劃分適用於構成資料實體的任何變數。將所有可用資料劃分為相等的分割槽，然後選擇來自每個分割槽的樣本以建立用於測試的樣本資料集。等價分割槽的邊緣是邊界值。因此，基於邊界值的測試資料由來自分割槽邊緣的資料組成。

測試架構圖19.5顯示了測試HMS時使用的測試類的技術架構。

該圖顯示了全面測試架構的一小部分，並突出了精心設計的測試架構（幾乎就像設計系統本身的一部分一樣）。圖19.5中的所有類都被定型為<< tester >>，將它們分類為負責測試的類。

圖19.5顯示了HMSbaseTester類，它是一個抽象類。該類將包含測試所需的常用功能。它們是createTestObject（），runTest（）和updateTestResults（）。這些操作由較低級別的操作過載。

第二級類也適用於系統中每個類的構造型，它們是BoundaryTester，EntityTester和TableTester。這些類被賦予了測試這些特定類的類的通用函式。例如，BoundaryTester具有處理顯示錶單，填充資料以及驗證表單上的欄位的功能。 EntityTester類具有實體類所需的最常用函式，例如get（）和set（）函式，而從EntityTester派生的類具有自己的特定函式來測試實際實體類的業務邏輯; TableTester處理在實際系統中測試資料庫類所需的常用函式，因此可能包含與載入資料庫相關的函式，然後檢查CRUD功能（建立 - 讀取 - 更新 - 刪除功能，在第13章中討論）以及檢查資料完整性。但是，這三個類位於測試體系結構的中間層。

軟體測試

319圖19.5還顯示了CustSubsystemTesterandScheduleSubsystemTester類。這些是超類，它們代表需要針對相應的患者和計劃包進行測試的基本功能。為每個包建立了這樣的超類，並賦予該包的通用測試功能。

測試設計解決方案空間中的測試設計測試設計是基於對子系統或元件級別的系統的理解而建立的。封裝為測試設計提供了一個起點。測試設計提供了所需功能的廣泛覆蓋，而不是系統中每個單元的低階測試用例。封裝圖以及MOPS中的用例文件所產生的測試設計確保了接近測試的模組化。使用者也可以參與這些測試設計，然後可以用於進行驗收測試。

測試設計格式測試設計的典型格式包含以下內容：

◾名稱 - 這標識了所考慮的測試設計，可以儲存為文件。理想情況下，該名稱應反映測試設計的性質。它可能是TestPatient中以“Test”為字首的包的名稱。

HMS的常見測試功能將由真實測試人員過載。

<< tester >> << tester >> << tester >> << tester >> << tester >> << tester >> << tester >> loadTestData（）loadTestData（）BoundaryTester EntityTester TableTester PatientFormsTest一個可選的額外圖層測試架構？是層相當於基測試儀類HMS PatientSubsystemTester ScheduleSubsystemTester loadTestData（每包）createTestObject（）loadTestData（）displayTestForm（）loadTestData（）HMSbaseTester createTestObject（）的runTest（）updateTestResult（）圖19.5的可能的測試體系結構HMS 。

◾模組 - 指示由測試設計指定的目標系統中的子系統，封裝或任何其他模組的詳細資訊。它包含要測試的軟體包型別的簡要說明，軟體包所需的準備工作（例如，建立測試資料或獲取域專家的服務），以及所需的各種型別的測試用例。

◾依賴性 - 指示此測試設計所依賴的其他測試設計。這在建立測試周期時很有用，或者可以根據測試周期建立測試設計本身。例如，TestPatient測試設計的依賴關係是TestConsultation，理想情況下，在測試整個系統的使用者程式碼和密碼之後，應該測試客戶端的建立和維護。

◾測試用例列表 - 這是構成測試設計的測試用例列表。屬於此測試設計的所有測試用例都與簡短的單行描述一起列出。測試用例可以根據測試設計的需要進行編號和分組（例如，所有介面測試用例可以在測試設計文件中分組，與所有資料庫訪問測試用例分開）。

測試設計專注於解決方案領域的包裝。一旦實現，包（或子系統）被認為是系統的單獨可執行部分。這要求測試設計考慮測試包的方法，所需的資料型別，包與其他包的依賴性以及包的操作要求。這導致列出並理解包中每個構造型的類的數量。測試設計還可能導致在每個包中建立單獨的測試包或在系統中建立單獨的測試包。

元件的測試設計由於元件是包中的可執行程式碼單元，因此測試設計也用於單個元件。此外，測試設計包含元件內各個類的測試用例。因此，必須測試元件內的元件和類之間的依賴性，並且需要將其合併到測試設計中。此外，有時兩個或多個類之間的操作也可能彼此依賴（通常通過序列圖指定），需要仔細建立處理此依賴關係的測試用例。

測試整個元件需要額外的測試用例 - 而不是單個類。例如，測試設計中的一組測試用例可以測試Date類，另一組測試用例可以測試Schedule類。良好的測試設計可確保第三組測試用例根據Date類中輸入的有效和無效資料測試計劃的工作情況。

因此，較早的測試用例被認為是類的單元測試，而後面描述的測試用例是基於系統中某些功能的測試用例，該功能超出了類的單獨操作，即排程程式接受有效日期和一定範圍。這種相互依賴性的概念在測試設計中得到了擴充套件，包括相互依賴的多種型別的元件，元件和包。

測試設計中的可重用性測試體系結構和設計中的可重用性意味著基類增強了測試設計人員提供一套良好的測試類的能力，這些測試類不僅可以確保全面有效的測試，還可以確保建立測試設計和執行的效率。測試用例。

測試設計有助於測試設計人員從過去的專案中學習，並逐步增加他們的測試用例。在軟體專案的初始迭代中使用的測試線束和測試用例可以重複用於測試以後的迭代。

注意重用有助於從現有測試臺建立測試資料。最後，在測試結果的整理中使用的測試類也有助於重用，因此應該結合到測試架構和設計中。

但是，在考慮重用測試時，重要的是要注意將要重用的類（第15章中討論的“重用”）需要進行全面測試，不僅要考慮它們當前的功能，還需要通過潛在的重用進行徹底的重用。後續專案中的繼承和關聯將使用它們（“with reuse”）。

除了詳細測試可重用的類之外​​，還必須為這些類的使用者（使用者）提供擴充套件測試類以建立自己的測試類的機會。因此，對於可重用的類庫，還應提供一套適合重用的測試類。

解決方案空間中的測試用例測試用例構成了測試工作的基礎，特別是在解決方案空間中。編寫好的測試用例與編寫好的用例一樣重要。因此，重新討論第5章是很重要的，其中討論了編寫好的用例。有人提到好的用例是良好測試用例的起點。這是因為驗收測試用例要求測試人員逐步完成用例。

編寫測試用例以進行類和元件的技術測試。這些測試用例是基於一小段測試程式碼的技術測試的基本單元。測試用例還測試正在開發的軟體的基本單元。因此，測試用例將記錄為進行一類測試所採取的步驟。

測試用例格式記錄測試用例的格式取決於測試的內容。例如，測試GUI的測試用例的測試格式與測試資料庫的測試用例不同。以下是可以擴充套件並用於設計的通用測試用例格式：

◾標識 - 用於標識測試用例的名稱和編號

◾目的 - 測試的原因（例如，驗證業務邏輯或檢查螢幕上欄位的有效性）。這個目的可能決定了測試者類的型別。

◾先決條件 - 可以在執行測試之前必需的元素。這些先決條件與特定測試用例有關。模組的整個測試設計的先決條件單獨記錄。

◾輸入 - 輸入系統的資料，由有效和無效的測試資料組成。

◾行動 - 測試人員進行測試所需的活動或步驟。對於技術測試用例，可能不需要詳細操作，因為這些操作是測試工具的一部分。

◾預期輸出 - 確定測試是成功還是失敗。

◾實際輸出 - 或佔位符，用於在測試用例執行時記錄結果。

◾例如，執行測試的測試人員的管理細節。

在成功測試中，建立良好的測試資料樣本非常重要。每個測試用例和測試設計都應該能夠從廣泛的資料中提取，以建立樣本測試資料。每個測試設計還應該能夠將實際輸出與預期輸出相匹配，尤其是在自動測試中。

測試資料是一個輸入檔案，包含由有效和無效輸入組成的大量資料記錄。表19.1提供了這兩個重要資料類別的示例。

這些是Patient類的輸入資料，測試其“Patient Medicare Insurance Number” - 一個六位INTEGER欄位。有效輸入確保類能夠接受並處理它要接受的輸入。無效輸入測試類拒絕不接受的輸入的能力。

這兩組資料輸入到輸入檔案中，相應的一組預期結果輸入另一個檔案中。然後可以將實際輸出與該預期結果檔案進行匹配，以確保驗證測試結果。測試工具使用這種方法不僅可以進行常規測試，還可以進行迴歸測試，這需要進行大量不需要人工干預的常規測試。

遮蔽和混合測試資料對於某些測試，資料洩漏和隱私等問題值得關注。誰可以測試以及他們可以測試什麼是重要的。因此，在執行測試之前，需要遮蔽帳號，名稱和其他標識源等詳細資訊。例如，信用卡號1234 1234 1234 1234將被遮蔽為xxxx xxxx xxxx xx34。同樣，只提供護照號碼的最後一位數字。與掩蔽相關的是資料的混合。這合併了資料和替換，例如真實姓名和假名。遮蔽和混合的程式碼本身已經過測試，以確保結果正確並且不會導致錯誤的測試結果。

醫院管理系統的驗收測試用例以下部分包含HMS的驗收測試用例。這些測試用例歸使用者和業務分析師所有。它們基於相應的用例（在第5章中討論）。

解決方案空間中基於類的測試用例方法本節討論解決方案空間中的測試用例。這裡的重點是設計級別的技術測試。因此，所有技術測試用例及其相應的測試工具都側重於測試作為測試單元的類（與上一節中討論的驗收測試中的用例相對）。但是，由於用例和類之間的多對多關係，類的每個測試用例還測試了許多用例的一些功能。基於類的測試對用例的影響如圖19.3所示。

測試工具在面向物件的設計中，其他類會為其提供的功能呼叫類。

此呼叫由其他類呼叫該類的操作或方法。類不是自己執行，而是由其他類呼叫。因此，要啟動系統，需要一個起始類。

此起始類取決於操作環境（例如，在Java中，此起點是Java虛擬機器中的類載入器，或由語言提供的JVM）。

每次使用JVM並測試整個系統可能既不實際也不必要。

另一方面，可能有必要以最小的級別測試類，因為它是由程式設計師編寫的。在系統的最小單元進行的常規和增量測試要求在類本身中編碼一些測試方法。

通過編寫測試類來專門呼叫正在測試的類及其所有操作來實現此要求。這樣的測試類稱為測試工具。例如，在Java環境中，為了測試Patient類，首先在Patient中建立一個main（）函式。

通常，Java應用程式只需要一個類，其主要方法是起點輸入操作預期輸出實際輸出患者登入：P2003付款型別：現金/支票患者登入並顯示帳單。在檢查細節後，患者將選擇支付型別的現金/支票。 （例如PayPal）客戶列印的賬單作為要結算的發票。

發票編號200303支付金額：$ 3333.00日期：22/11/2004支付方式：現金患者登入：123432患者嘗試登入但由於登入不正確而失敗。

提示說登入錯誤。

顯示訊息：登入無效。

請再試一次。

但是，在“起始類”之外的類中使用main方法允許測試程式碼駐留在類中，因此類可以獨立於其他類進行“單元”測試。

上一課顯示了Patient類的所有功能將如何進行測試。建立測試工具，傳送測試訊息，以及可選地自動記錄結果，如圖19.6中的序列圖所示。如圖所示，測試線束確保測試類的每個操作。但是，測試工具應該集中精力徹底測試其實現可能隨時間變化的功能，以允許功能的可擴充套件性，從而實現系統的可擴充套件性。這是因為函式的可變性很可能在系統中產生錯誤而不是標準函式。

驗證測試用例一旦以指定的格式設計和建立測試用例，就必須驗證測試用例是否正確。如果計算和其他輸出沒有改變，可以根據現有系統的結果對它們進行交叉檢查，或者可以根據樣本手動輸出和系統專家使用者執行的其他計算來驗證輸出。

研討會中測試用例的演練對於驗證測試用例和測試工具是否正確也非常有用。

示例程式碼19.1 class Patient {// private：int PatientID;字串名稱;地址;日期出生日期; // operations // public：<< business >> getPatientName（）：BOOL; getSerialNumber（）：BOOL; changeAddress（）：BOOL; << maths >> calculateAge（）：AGE; - << database >> saveDetails（Sno，Details）：Void; - // test operations static void main（String args []）aPatient = New Patient; aPatient.getPatientName（）; aPatient.getSerialNumber（）; aPatient.changeAddress（）; aPatient.calculateAge（）; aPatient.saveDetails（）;軟體測試

◾329執行（NFR）測試執行測試是技術測試中的一項單獨的專用活動。如前所述，操作測試的設計，編寫和執行與類的測試用例非常相似。

操作測試需要單獨的方法和設計。因此，整個操作測試分別放在測試包中。第20章討論的操作（非功能）規範提供了這些測試成功或失敗的標準。

一些操作測試一些操作測試包括以下內容：

◾效能測試 - 在各種條件下測試系統的效能。測試工具是測試元件或系統響應時間的有用輔助工具。但是，應在不同的負載條件下計算響應時間。在系統上以最小負載測試響應可能會給出測試成功的錯誤印象。

◾卷測試 - 系統在執行條件下處理特定交易量的能力。卷測試的示例包括系統在其資料庫中插入/更新大量資料的能力以及在系統操作期間將資料儲存在其實體物件中的能力。

JVM：PatientSubsystemTester createTestObject createPatient（）aPatient：Patient runTest（）getPatientName（）getSerialNumber（）changeAddress（）calculateAge（）saveDetails（）collat​​eResults（）updateResults（）HMStestResult結果類負責儲存測試結果測試工具物件測試Patient類的所有操作

圖19.6描述測試工具行為的序列圖。

with UML軟體工程

◾安全測試 - 系統通過適當的身份驗證和其他安全機制允許或阻止資料的能力。雖然登入和密碼是系統功能的常規部分，但安全測試涉及測試可能已在系統中使用的特定安全類和第三方安全元件。

◾可擴充套件性測試 - 系統在可能使用系統的其他功能時處理越來越多的負載的能力。 例如，如果系統今天可以處理500個Patient物件的例項，它可以在一年的時間內容納50,000個Patient物件的例項嗎？ 可擴充套件性測試的另一個例子是測試系統儲存越來越多的資料和越來越多的系統使用者的能力。

常見錯誤	糾正錯誤	例項
在沒有測試“安全帶”的情況下測試技術類	編寫測試工具以對應技術類。	參見示例程式碼19.1和關於測試線束的討論。
忘記測試元件	確保測試設計包括除了類之外的元件測試。	請參閱前面關於測試設計的討論。
不計劃進行運營測試	在測試計劃開始時包括操作（NFR）測試。 一旦開發出第一個模組（包），就開始進行操作測試。	請參閱本章中有關操作（NFR）測試的討論。
不基於用例的驗收測試	驗收測試由使用者在接受系統之前執行。 由於需求是在用例中指定的，因此驗收測試必須基於用例。	請參閱本章中HMS驗收測試案例。
建立的測試資料不足	確保提供涵蓋主要要求的廣泛測試資料。	通過從等價分割槽和邊界值中抽樣，檢視測試資料建立章節中的討論。
假設所有測試都是手動或自動化的	實際測試是手動和自動測試的平衡。	有關測試方法，請參見圖19.4。
不瞭解正面和負面測試之間的區別	積極測試是班級接受“好”資料的地方; 而負面測試是指班級拒絕“壞”資料的地方	重新討論有效和無效資料以進行測試。