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