信息管理軟件需求說明書(20個(gè)doc)0.doc

測試的主要評測方法簡介 測試的主要評測方法包括覆蓋和質(zhì)量。測試覆蓋是對測試完全程度的評測，它建立在測試覆蓋基礎(chǔ)上，測試覆蓋是由測試需求和測試用例的覆蓋或已執(zhí)行代碼的覆蓋表示的。質(zhì)量是對測試對象（系統(tǒng)或測試的應(yīng)用程序）的可靠性、穩(wěn)定性以及性能的評測。質(zhì)量建立在對測試結(jié)果的評估和對測試過程中確定的變更請求（缺陷）的分析的基礎(chǔ)上。覆蓋評測 覆蓋指標(biāo)提供了測試的完全程度如何？這一問題的答案。最常用的覆蓋評測是基于需求的測試覆蓋和基于代碼的測試覆蓋。簡而言之，測試覆蓋是就需求（基于需求的）或代碼的設(shè)計(jì)/實(shí)施標(biāo)準(zhǔn)（基于代碼的）而言的完全程度的任意評測，如用例的核實(shí)（基于需求的）或所有代碼行的執(zhí)行（基于代碼的）。 系統(tǒng)的測試活動建立在至少一個(gè)測試覆蓋策略基礎(chǔ)上。覆蓋策略陳述測試的一般目的，指導(dǎo)測試用例的設(shè)計(jì)。覆蓋策略的陳述可以簡單到只說明核實(shí)所有性能。如果需求已經(jīng)完全分類，則基于需求的覆蓋策略可能足以生成測試完全程度的可計(jì)量評測。例如，如果已經(jīng)確定了所有性能測試需求，則可以引用測試結(jié)果來得到評測，如已經(jīng)核實(shí)了 75% 的性能測試需求。如果應(yīng)用基于代碼的覆蓋，則測試策略是根據(jù)測試已經(jīng)執(zhí)行的源代碼的多少來表示的。這種測試覆蓋策略類型對于安全至上的系統(tǒng)來說非常重要。兩種評測都可以手工得到（公式如下所示）或通過測試自動化工具計(jì)算得到?；谛枨蟮臏y試覆蓋 基于需求的測試覆蓋在測試生命周期中要評測多次，并在測試生命周期的里程碑處提供測試覆蓋的標(biāo)識（如已計(jì)劃的、已實(shí)施的、已執(zhí)行的和成功的測試覆蓋）。 在執(zhí)行測試活動中，使用兩個(gè)測試覆蓋評測，一個(gè)確定通過執(zhí)行測試獲得的測試覆蓋，另一個(gè)確定成功的測試覆蓋（即執(zhí)行時(shí)未出現(xiàn)失敗的測試，如沒有出現(xiàn)缺陷或意外結(jié)果的測試）。 這些覆蓋評測通過以下公式計(jì)算：這一關(guān)于測試覆蓋的陳述是有意義的，可以將其與已定義的成功標(biāo)準(zhǔn)進(jìn)行對比。如果不符合該標(biāo)準(zhǔn)，則此陳述將成為預(yù)測剩余測試工作量的基礎(chǔ)?；诖a的測試覆蓋 基于代碼的測試覆蓋評測測試過程中已經(jīng)執(zhí)行的代碼的多少，與之相對的是要執(zhí)行的剩余代碼的多少。代碼覆蓋可以建立在控制流（語句、分支或路徑）或數(shù)據(jù)流的基礎(chǔ)上?？刂屏鞲采w的目的是測試代碼行、分支條件、代碼中的路徑或軟件控制流的其他元素。數(shù)據(jù)流覆蓋的目的是通過軟件操作測試數(shù)據(jù)狀態(tài)是否有效，例如，數(shù)據(jù)元素在使用之前是否已作定義。基于代碼的測試覆蓋通過以下公式計(jì)算：質(zhì)量評測 測試覆蓋的評估提供對測試完全程度的評測，在測試過程中已發(fā)現(xiàn)缺陷的評估提供了最佳的軟件質(zhì)量指標(biāo)。因?yàn)橘|(zhì)量是軟件與需求相符程度的指標(biāo)，所以在這種環(huán)境中，缺陷被標(biāo)識為一種更改請求，該更改請求中的測試對象與需求不符。缺陷評估可能建立在各種方法上，這些方法種類繁多，從簡單的缺陷計(jì)數(shù)到嚴(yán)格的統(tǒng)計(jì)建模不一而足。嚴(yán)格的評估假定測試過程中缺陷達(dá)到的比率或發(fā)現(xiàn)的比率。常用模型假定該比率符合泊松分布。則有關(guān)缺陷率的實(shí)際數(shù)據(jù)可以適用于這一模型。生成的評估將評估當(dāng)前軟件的可靠性，并且預(yù)測繼續(xù)測試并排除缺陷時(shí)可靠性如何增長。該評估被描述為軟件可靠性增長建模，這是一個(gè)活躍的研究領(lǐng)域。由于該類型的評估缺乏工具支持，所以應(yīng)該慎重平衡成本與其增加價(jià)值。 缺陷分析就是分析缺陷在與缺陷關(guān)聯(lián)關(guān)系的一個(gè)或多個(gè)參數(shù)值上的分布。缺陷分析提供了一個(gè)軟件可靠性指標(biāo)。對于缺陷分析，常用的主要缺陷參數(shù)有四個(gè)： 狀態(tài)：缺陷的當(dāng)前狀態(tài)（打開的、正在修復(fù)或關(guān)閉的等）。 優(yōu)先級：必須處理和解決缺陷的相對重要性。 嚴(yán)重性：缺陷的相關(guān)影響。對最終用戶、組織或第三方的影響等等。 起源：導(dǎo)致缺陷的起源故障及其位置，或排除該缺陷需要修復(fù)的構(gòu)件。 可以將缺陷計(jì)數(shù)作為時(shí)間的函數(shù)來報(bào)告，即創(chuàng)建缺陷趨勢圖或報(bào)告；也可以將缺陷計(jì)數(shù)作為一個(gè)或多個(gè)缺陷參數(shù)的函數(shù)來報(bào)告，如作為缺陷密度報(bào)告中采用的嚴(yán)重性或狀態(tài)參數(shù)的函數(shù)。這些分析類型分別為揭示軟件可靠性的缺陷趨勢或缺陷分布提供了判斷依據(jù)。例如，預(yù)期缺陷發(fā)現(xiàn)率將隨著測試進(jìn)度和修復(fù)進(jìn)度而最終減少?？梢栽O(shè)定一個(gè)閾值，在缺陷發(fā)現(xiàn)率低于該閾值時(shí)才能部署軟件。也可根據(jù)執(zhí)行模型中的起源報(bào)告缺陷計(jì)數(shù)，以允許檢測較差的模塊、熱點(diǎn)或需要再三修復(fù)的軟件部分，從而指示一些更基本的設(shè)計(jì)缺陷。這種分析中包含的缺陷必須是已確認(rèn)的缺陷。不是所有已報(bào)告的缺陷都報(bào)告實(shí)際的缺陷，這是因?yàn)槟承┤毕菘赡苁菙U(kuò)展請求，超出了項(xiàng)目的規(guī)模，或描述的是已報(bào)告的缺陷。然而，需要查看并分析一下，為什么許多報(bào)告的缺陷不是重復(fù)的缺陷就是未經(jīng)確認(rèn)的缺陷，這樣做是有價(jià)值的。缺陷報(bào)告 Rational Unified Process 以三類形式的報(bào)告提供缺陷評估： 缺陷分布（密度）報(bào)告允許將缺陷計(jì)數(shù)作為一個(gè)或多個(gè)缺陷參數(shù)的函數(shù)來顯示。 缺陷齡期報(bào)告是一種特殊類型的缺陷分布報(bào)告。 缺陷齡期報(bào)告顯示缺陷處于特定狀態(tài)下的時(shí)間長短，如提出的。在齡期類別中，缺陷還可以按其他屬性分類，如擁有者。 缺陷趨勢報(bào)告按狀態(tài)（新的、已打開的或關(guān)閉的）將缺陷計(jì)數(shù)作為時(shí)間的函數(shù)顯示。趨勢報(bào)告可以是累計(jì)的，也可以是非累計(jì)的。 測試結(jié)果和進(jìn)度報(bào)告顯示對測試的應(yīng)用程序進(jìn)行若干次迭代和測試生命周期后的測試過程執(zhí)行結(jié)果。 許多此類報(bào)告對于評估軟件質(zhì)量具有很高的價(jià)值。一般測試標(biāo)準(zhǔn)中包括有關(guān)特定類別（如嚴(yán)重性級別）中打開的缺陷數(shù)的陳述。通過缺陷分布評估可以輕松地核對該標(biāo)準(zhǔn)。對測試需求進(jìn)行過濾或分類，該評估可以側(cè)重于不同的需求集。要有效生成此類報(bào)告，一般需要工具支持。缺陷密度報(bào)告 缺陷狀態(tài)與優(yōu)先級應(yīng)該給定所有缺陷的優(yōu)先級，通?？尚械淖龇ㄊ窃O(shè)定四種優(yōu)先級中的一種： 1. 立即解決 2. 高優(yōu)先級 3. 正常排隊(duì) 4. 低優(yōu)先級 一個(gè)成功測試的標(biāo)準(zhǔn)可以表示為缺陷在上述優(yōu)先級上所應(yīng)體現(xiàn)的分布方式。例如，對于一個(gè)成功的測試標(biāo)準(zhǔn)來說，可能不存在優(yōu)先級為 1 的打開的缺陷，而且優(yōu)先級為 2 的打開的缺陷要少于 5 個(gè)。例如下面的缺陷分布圖：很明顯該圖顯示的情況沒有達(dá)到標(biāo)準(zhǔn)。請注意，該圖需要通過過濾器才能只顯示需要的打開的缺陷。缺陷狀態(tài)與嚴(yán)重性缺陷嚴(yán)重性報(bào)告顯示每種嚴(yán)重性級別的缺陷個(gè)數(shù)，例如致命錯(cuò)誤、未執(zhí)行主要功能、次要錯(cuò)誤等嚴(yán)重性級別。缺陷狀態(tài)與在實(shí)施模型中的位置缺陷起源報(bào)告顯示缺陷在實(shí)施模型元素上的分布情況。缺陷齡期報(bào)告 缺陷齡期分析提供了有關(guān)測試有效性和缺陷排除活動的良好反饋。例如，如果大部分齡期較長的、未解決的缺陷處于有待確認(rèn)的狀態(tài)，則可能表明沒有充足的資源應(yīng)用于再次測試工作。缺陷趨勢報(bào)告 趨勢報(bào)告確定缺陷率并提供了一個(gè)出色的測試狀態(tài)視圖。在測試生命周期中，缺陷趨勢遵循著一種比較好預(yù)測的模式。在生命周期的初期，缺陷率增長很快。在達(dá)到頂峰后，就隨時(shí)間以較慢的速率下降。要發(fā)現(xiàn)問題，可以根據(jù)這一趨勢復(fù)審項(xiàng)目時(shí)間表。例如，在四個(gè)星期的生命周期中，如果缺陷率在第三個(gè)星期中仍然增長，則項(xiàng)目很明顯沒有按時(shí)間表進(jìn)行。這一簡單的趨勢分析假定：缺陷是立即關(guān)閉的，且在隨后的工作版本中對修復(fù)進(jìn)行測試，這樣關(guān)閉缺陷的速率應(yīng)該遵循與打開缺陷的速率相同的增減趨勢。如果情況并非如此，則表明缺陷解決流程發(fā)生了問題；缺陷修復(fù)所需的資源或再次測試和確認(rèn)修復(fù)所需的資源可能不足。該報(bào)告反映的趨勢顯示，在項(xiàng)目開始時(shí)，發(fā)現(xiàn)和打開新缺陷的速率很快，但隨著時(shí)間推移，該速率不斷降低。打開的缺陷的趨勢與新缺陷的趨勢相似，但稍微滯后一些。關(guān)閉的缺陷的趨勢隨著打開的缺陷的修復(fù)和核實(shí)而不斷增長。這些趨勢描述的是成功的工作。如果您的趨勢與這些趨勢差別顯著，則表明存在問題，并可以確定可能需要附加資源以應(yīng)用于開發(fā)或測試特定區(qū)域的時(shí)間。當(dāng)與測試覆蓋評測結(jié)合起來時(shí)，缺陷分析可提供出色的評估，測試完成的標(biāo)準(zhǔn)也可以建立在此評估基礎(chǔ)上。性能評測 評估測試對象的性能行為時(shí)，可以使用多種評測，這些評測側(cè)重于獲取與行為相關(guān)的數(shù)據(jù)，如響應(yīng)時(shí)間、計(jì)時(shí)配置文件、執(zhí)行流、操作可靠性和限制。這些評測主要在評估測試活動中進(jìn)行評估，但是也可以在執(zhí)行測試活動中使用性能評測評估測試進(jìn)度和狀態(tài)。主要的性能評測包括： 動態(tài)監(jiān)測 - 在測試執(zhí)行過程中，實(shí)時(shí)獲取并顯示正在執(zhí)行的各測試腳本的狀態(tài)。 響應(yīng)時(shí)間/吞吐量 - 測試對象針對特定主角和/或用例的響應(yīng)時(shí)間或吞吐量的評測。 百分位報(bào)告 - 數(shù)據(jù)已收集值的百分位評測/計(jì)算。 比較報(bào)告 - 代表不同測試執(zhí)行情況的兩個(gè)（或多個(gè)）數(shù)據(jù)集之間的差異或趨勢。 追蹤報(bào)告 -主角（測試腳本）和測試對象之間的消息/會話詳細(xì)信息。動態(tài)監(jiān)測 動態(tài)監(jiān)測通常以柱狀圖或曲線圖的形式提供實(shí)時(shí)顯示/報(bào)告。該報(bào)告用于在測試執(zhí)行過程中，通過顯示當(dāng)前的情況、狀態(tài)以及測試腳本正在執(zhí)行的進(jìn)度來監(jiān)測或評估性能測試執(zhí)行情況。例如，在以上柱狀圖中，有 80 個(gè)測試腳本正在執(zhí)行相同的用例。圖中顯示，有 14 個(gè)測試腳本處于空閑狀態(tài)，12 個(gè)處于查詢狀態(tài)，34 個(gè)處于 SQL 執(zhí)行狀態(tài)，4 個(gè)處于 SQL 連接狀態(tài)，16 個(gè)處于其他狀態(tài)。隨著測試的進(jìn)行，我們將看到各狀態(tài)腳本的數(shù)量會發(fā)生變化。顯示的輸出將是正常執(zhí)行且正在執(zhí)行中的典型測試執(zhí)行。但是，如果在測試執(zhí)行過程中，測試腳本始終保持一種狀態(tài)或沒有顯示任何變化，則表明測試執(zhí)行發(fā)生問題或者需要實(shí)施或執(zhí)行其他性能評測。響應(yīng)時(shí)間/吞吐量報(bào)告 正如其名稱的含義一樣，響應(yīng)時(shí)間/吞吐量報(bào)告評測并計(jì)算與時(shí)間和/或吞吐量（處理的事務(wù)數(shù)）相關(guān)的性能行為。這些報(bào)告通常用曲線圖顯示，響應(yīng)時(shí)間（或事務(wù)數(shù)）?quot;y軸上，而事件數(shù)在x軸上。除了顯示實(shí)際的性能行為外，它在計(jì)算并顯示統(tǒng)計(jì)信息方面也很實(shí)用，如顯示數(shù)據(jù)值的平均偏差和標(biāo)準(zhǔn)偏差。百分位報(bào)告 百分位報(bào)告通過顯示已收集數(shù)據(jù)類型的全體百分位值，提供了另一種性能統(tǒng)計(jì)計(jì)算方法。比較報(bào)告 比較不同性能測試的