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