【文章內容簡介】 法、軟件性能測試工具 LoadRunner。 5. 對功能測試與性能測試方法進行總結，并結合在實習單位測試功能中總結經驗教訓 2 功能 性 測試基本理論 軟 件功能測試的定義 早期的測試理論通常使用黑盒測試的概念定義功能性測試，但經過測試技術的不斷發(fā)展，僅以功能性測試作為黑盒測試的全部過程已經不能滿足軟件質量的要求，因此功能性測試的內容被更加細化，目標及其定義也變得更加明確。 恰當的功能性測試被定義為：根據軟件產品的特征、操作、描述和用戶方案對軟件系統(tǒng)特性和可操作行為進行測試，以確定它們滿足需求中預期功能性的行為 稱為軟件的功能性測試。 [5] 3 功能測試通常在已知軟件應當具有哪些功能后，以用戶角度來進行程序功能的使用，參照需求分析和規(guī)格說明書作為評定標準，以確保 軟件中各個可以功能滿足用戶需求，并且功能可以有效運行。 功能測試在測試階段中得定位 一般來講，對軟件產品進行的測試統(tǒng)稱為軟件測試，軟件測試大致可分為單元測試、集成測試、功能測試、性能測試、兼容性測試、可靠性測試、驗收測試 [6]等 7 個階段，軟件的功能性測試屬于軟件測試中黑盒測試的一部分。 軟件的功能性測試是在單元測試與集成測試完成后進行的一項檢驗軟件功能是否符合預期要求及功能正確性的測試過程 [7]。 軟件性能的指標 為 了能夠客觀地度量軟件的性能，人們定義了一系列性能指標，比便于在不同情況下度量軟件的性能。合理的性能指標應該記能夠以客觀的方式進行度量，也能夠基本與人對軟件性能的主觀感受比較一致。之所以人們在性能測試中使用多種性能指標，是因為不同人員對軟件性能的視角不同，關注點也不同。 圖 21 顯示了功能測試 與性能測試 在軟件測試過程中的定位，及測試進行的順序。 圖 21 軟件測試中的功能測試 因此，功能性測試 與性能性測試 的開展是有前提條件的。在軟件未實現功能的集成前進行的單一功能測試都含有風險，無法保證后續(xù)集成進的模塊不會對之前正確的功能帶來負面影響。 基于軟件模型的功能測試策略 軟件測試工作是有組織有計劃的對某個軟件進行的缺陷暴露工作。因此為了做到有計劃有針對性，在不同軟件開發(fā)模式下都應當有相對應的軟件開發(fā)模型，使得測試工作能夠滿足整個軟件制造流程的風格要求，并且能與各階段順暢銜接。 原型模型 原型模型是指在軟件開發(fā)過程中，開發(fā)方通過制作形象化的模型展示最終軟件系統(tǒng)的外觀（原型體現軟件的功能外觀，并輔以功能機制說明來掩飾工作流程與處理邏輯，并非實際的軟件程序），來響應客戶需求的方法。在基于原型模型進行的開發(fā)中，開發(fā)方和客戶在項目初始階段不斷審評該原型，以最終確定的軟件 原型生成系統(tǒng)需求、規(guī)格說明書，并以此作為項目開發(fā)的基礎。 4 因此，在測試以原型模型進行的項目的功能時，評判功能是否完備、以及功能是否正確的標準來自最終的系統(tǒng)需求、規(guī)格說明書，并且功能測試應當在根據需求、規(guī)格研發(fā)出軟件實體之后進行。 根據以上分析，基于原型模型的功能測試應如圖 22 所示。 圖 22 基于原型模型的功能測試 原型模型是比較簡單的軟件工程模型，依照此模型進行的功能測試只能測試出軟件產品針對于需求、規(guī)格說明文檔中不符的缺陷。對于軟件需求中存在的錯 [8]誤，通過基于此模型進行的 功能測試是很難發(fā)現其缺陷所在的。 V 模型 V 模型是在古老的瀑布模型基礎上演變而來的軟件工程模型，由于將軟件開發(fā)與測試構造成一個 V 字形而得名。 V 模型中的功能測試被定義在了整個軟件開發(fā)過程的后半部分，它強調了測試活動與軟件設計間的關系，將軟件實現和驗證有機的結合起來，以確保較高的軟件質量。在 V 模型中各個測試階段的測試標準都參考相對應的設計文檔， 若測試出缺陷則通過相對應的文檔入手返回開發(fā)階段按照模型一次修改 。 因此，在測試以 V 模型進行的項目時，功能測試的依據主要來自于軟件的概 要設計、規(guī)格說明書，以驗證集成在一起的軟件系統(tǒng)是否符合概要設計、規(guī)格說明書內的要求。 根據以上分析，基于 V 模型的功能測試應如圖 23 所示 。 圖 23 基于 V 模型的功能測試 V 模型是標準的軟件開發(fā)模型，具備完善的各類設計與文檔，功能測試階段具有自己獨立的測試參考標準 —— 概要設計，因此在進行功能測試的時候只需要分析概要設計中對軟件功能的描述，即可對系統(tǒng)進行測試 [6]。但使用 V 只有在后期的功能測試中才可發(fā)現前期設計上面的問題，發(fā)現缺陷 后需要較多的工序來進行修改。雖可保證軟件產品的質量，但是整個周期較長。 PTGM 測試過程模型 5 與 功能性測試相比，性能測試的復雜性更高，測試執(zhí)行的困難更大，對測試工具的依賴也更強，更需要過程模型的指導。圖 24 給出一個性能測試的過程模型 —— 性能測試通用模型（ Performance Testing General Model,PTGM） ,該模型的實質是將針對功能測試的自動化測試模型進行適當調整，以適應性能測試的需要，在第四章中進行詳細介紹 [9] 圖 24 PTGM 模型示意圖 3. 功能性 測試方法 功能性測試流程 功能性測試按步驟可劃分為 7 個部分，即獲取測試系統(tǒng)、測試方法選定、進行測試需求分析、功能點分解、建立測試用例、測試執(zhí)行、 BUG 管理。 圖 31 展示了功能性測試經歷的 7 個步驟。 圖 31 功能性測試流程 每一步按照箭頭所示方向向下進行，最終完成功能性測試過程。 測試需求分析 測試需求分析階段是研究用戶需求，完全理解用戶對軟件所需求的完功能，并確認用戶對軟件功能的需求，建立可評判的、可驗證的基本依據的的過程 。 6 因此，測試需求分析階段就 是對用戶需求的理解過程，通過研究需求分析文檔把用戶想要哪些功能摸清，把用戶對于每個功能想要達到的目標摸清，就完成了測試需求的分析。 功能點分解 軟件的功能繁多而復雜，即使是單一的文本輸入框在功能測試時也不只是測試能否輸入文本這么簡單，能輸入的最大字符長度、可輸入的字符類型、輸入超過超過規(guī)格限定的數據時的系統(tǒng)反饋等都是需要進行測試的項目。 功能測試的功能點分解階段即是將軟件中所有功能的測試點分解出來，建立一個可視化的、有規(guī)律的、全面性的文檔指導之后的測試用例建立，以及測試執(zhí)行時覆蓋這些功能點的依據 。 建立測試用例 建立測試用例階段在功能分解之后進行，此階段主要進行的是根據測試需求分析階段獲得的功能正確性評判依據對分解出的每個功能點進行測試執(zhí)行時具體操作的規(guī)劃。建立出的測試用例集可 以作為執(zhí)行測試時每一步操作的依據，并記錄測試執(zhí)行的結果以備分析缺陷情況使用。 測試執(zhí)行 測試執(zhí)行階段是在之前的準備工作完成后具體實施測試操作的環(huán)節(jié)，在此環(huán)節(jié)中通過已建立的評判體系對系統(tǒng)各個功能點進行驗證，以求暴露出所有存在的缺陷。通過實習期間的親身體會，在測試執(zhí)行時，一昧的按照測試用例去執(zhí)行，以期單 純的使用這樣的方法來發(fā)現軟件缺陷往往是不夠的。更多時候，需要測試操作者通過自己已有的知識、經驗和靈感增加隨機的測試用例，豐富按照固定模式生成的測試用例集的覆蓋的場景，才可更多的暴露出軟件潛藏的缺陷與不足。 BUG 管理 BUG 管理階段是對已發(fā)現的軟件缺陷進行確認、上報、跟蹤、回歸的過程 [10]。在測試