【正文】 使用基。因為在項目的過程中會不斷地出現(xiàn)新的風險而以前意識到的風險的可能性和嚴重性也在變化。成功的風險管理包括以下原則： 在整個項目的生命周期不斷的估計風險。 成功風險管理準則 風險管理應該是每個項目的一部分。有風險就有機會，因此風險本質(zhì)上既不是好的也不是壞的。損失可能是最終產(chǎn)品的質(zhì)量降低，費用增加，延期完成或項目失敗。 風險是機會的一個基本成分存在于每個項目中。風險管理模型用于連續(xù)地估計什么會導致錯誤，決 康佳集團呼叫中心系統(tǒng)項目 實施方案 ▲保密 第 26 頁 共 61 頁 定那些風險必須處理并實施處理它們的策略。一個小組承擔的每個項目都有風險。本節(jié)首先討論了風險管理模型，也就是項目采用的風險管理方法的理論基礎。 變更的管理工具有 Rational公司的 Clear Quest，并結合配置管理工具 Clear Case使用。 工具和技術的使用 項目經(jīng) 理在開發(fā)計劃中應指明所使用的工具和技術，在評審活動中應對項目組選用的工具和技術的合理進行評審。專家評審結果作為業(yè)務決策的入口； (4) 重大變更管理評審： 如果為重大變更， 中興華通公司 和 康佳集團 要通知變更影響的相關各方參加對變更請求的總體變更評審；通過聯(lián)席會議評審的入口條件為開發(fā)方的技術評審結論和專家組的評審結論。 (2) 中興華通公司 技術評審： 中興華通 接收到范圍變更請求后進行技術評審，審閱范圍變更的技術影響和初步的成本影響。下面針對本項目提出對變更管理的流程。因此對于項目的變更要嚴格控制 ，尤其對于重大變更必須由項目各方都參加的聯(lián)席會議評審通過，對于重大的技術變更，可考慮由專家評審通過，并通過 SCCB（軟件變更控制委員會）的審查，最后經(jīng)過項目領導小組的簽批認可。 中興華通將在變更管理方面，積極 配合 康佳集團 對項目過程中的變更進行有效的記錄、跟蹤、協(xié)調(diào)和管理。 系統(tǒng)變更控制 變更管理 項目發(fā)生變更時，如果管理不好，就會直接導致項目延期或失敗，所以變更管理在整個項目的管理中處于重要位置。所以 LoadRunner能極大的減少負載測試所需的硬件和人力資源。它先記錄下業(yè)務流程，如下訂單或機票預定，然后將其轉化為測試腳本。 使用 LoadRunner 的 VirtualUser Generator 引擎，能很簡便地創(chuàng)立起系統(tǒng)負載。 LoadRunner 是一種較高規(guī)模適應性的，自動負載測試工具，它能預測系統(tǒng)行為，優(yōu)化性能。 LoadRunner是一種預測系統(tǒng)行為和性能的負載測試工具。使用 JUnit單元測試框架，第一可以簡化測試的編寫，這種簡化包括測試框架的學習和實際測試 單元的編寫；第二可以使測試單元保持持久性；第三個則是可以利用既有的測試來編寫相關的測試。 (2) 測試工具 i. 單元測試工具： 在單元測試中我們采用測試工具 JUNIT， JUNIT 是一種開放源碼的用于面向?qū)ο蟮?JAVA程序開發(fā)的單元測試工具。使用 BVA 設計測試用例時，首先應確定邊界，然后選取正好等于、剛剛大于、或剛剛小于邊界的值作為測試數(shù)據(jù)，而不是選擇等價類的任意元素。這里所說的邊界是指，相當于輸入等價類和輸出等價類而言，稍高于其邊界值及稍低于其邊界值的一些特定情況 。 iii. 邊界值法： 由于某些未被完全知道的原因，輸入域的邊界比中間更加容易發(fā)生錯誤。 無效等價類：由那些對于程序的規(guī)格說明來說是不合理或無意義的輸入數(shù)據(jù)構成的集合。測試某等價類的代表值就等價于對這一類其它值的測試。 等價劃分的測試用例設計基于輸入條件的等價類評估，首先要對輸入條件劃分等價類，然后根據(jù)等價類選取測試用例。使用直角排列法的優(yōu)點： ? 比窮舉法、正態(tài)分布法簡單易懂； ? 是一種半自動化設計測試例的方法，大大減少了設計測試例的工作量； ? 有助于測試人員分析被測對象的屬性及屬性取值； ? 確保每個屬性值都被取到，保證了測試的全面性； ? 已最少個數(shù)的測試例，覆蓋最多的路徑和功能點。 測試技術與工具 (1) 測試 用 例設計技術 在系統(tǒng)的測試設計中，我們主要采用直角排列法，進行測試用例設計，同時在測試數(shù)據(jù)設計上兼用等價類劃分和邊界值法。通過測試發(fā)現(xiàn)的軟件問題，往往不一定是程序問題，很可能涉及到前面階段的軟件設計或需求分析工作，為此，必須在測試活動中，對各種相關的技術文檔進行再一次的核查，以體現(xiàn)測試的完整性 。 測試分析報告需要對測試范圍、測試方法、測試實例與數(shù)據(jù)、測試進度和測試結果進行綜合評價，具體指標有： ? 指出各項測試結果與預期結果之間的差異并分析差異的原因 ； ? 指出未被充分測試的特性或特性組合，并說明原因 ； ? 對致命問題和重大問題的排錯與修改情況進行綜合考察和評價 ； ? 對有關文檔資料的齊全性進行審定， 并對重要文檔（特別是用戶操作說明書）內(nèi)容的適用性進行評價 ； ? 測試小組歸納已解決和尚未解決的問題，對照測試計劃中所規(guī)定的“通過準則”確 康佳集團呼叫中心系統(tǒng)項目 實施方案 ▲保密 第 22 頁 共 61 頁 定此次測試是否通過。 測試結果分析 對于“集成測試”、“系 統(tǒng)測試”和“驗收測試”這三種測試活動所產(chǎn)生的測試結果，必須采用統(tǒng)計分析方法和技術進行處理。 測試問題跟蹤 所有測試問題通過缺陷跟蹤工具 clearquest 進行建立問題，問題分析與分配，開發(fā)修改，回歸測試直到關閉整個過程跟蹤。 實行封閉式完整測試，一次測試過程中不允 許對軟件編碼作任何修改和調(diào)整，以保證當前測試的有效性。 測試執(zhí)行 測試人員應按既定的測試步驟，選用測試實例和測試數(shù)據(jù)進行測試，根據(jù)測試情況，編寫“測試日志”。 (4) 設計和準備測試用例 康佳集團呼叫中心系統(tǒng)項目 實施方案 ▲保密 第 21 頁 共 61 頁 能否有針對性地編制實用、有效的測試用例與測試數(shù)據(jù)，取決于對業(yè)務、軟件功能、軟件產(chǎn)品，數(shù)據(jù)庫結構等方面的理解和把握程度，這是軟件測試中最難做的部分。 (3) 建立 測試環(huán)境 測試環(huán)境的建立是測試準備的重要環(huán)節(jié)。 ? 編寫“系統(tǒng)測試計劃”。 (2) 編寫測試計劃 初步確定軟件編碼階段的“單元測試”計劃含在“軟件開發(fā)小組”的工作計劃中，測試小組重點是制定以下三種測試活動的計劃。 測試組工作職責： ? 組織、實施、協(xié)助整個項目組各階段的測試活動 ； ? 在 項目組綜合計劃范圍內(nèi)，負責制定詳細的各階段軟件測試計劃 ； ? 協(xié)助項目經(jīng)理，負責對本組人員的日常管理和工作安排 ； ? 嚴格按照軟件測試規(guī)范和測試計劃來開展測試活動 ； ? 對所承擔的測試結果負責，并有責任及時將測試結果傳遞給有關人員 ； ? 了解軟件需求和設計等方面的技術文檔內(nèi)容，掌握軟件測試方法和工具的使用 ； ? 負責準備單獨的測試環(huán)境，并對測試環(huán)境實施安裝、驗收和管理 ； 康佳集團呼叫中心系統(tǒng)項目 實施方案 ▲保密 第 20 頁 共 61 頁 ? 負責設計和準備、收集和保存各種測試用例和測試數(shù)據(jù) ； ? 負責記錄與跟蹤測試中發(fā)現(xiàn)的問題和錯誤的糾正情況，統(tǒng)計和分析測試結果，并編寫測試報告 ； ? 協(xié)助用戶、開發(fā)人員、 項目經(jīng)理參與有關軟件驗收和其它測試方面的活動。 ? 制定規(guī)范和完整的測試計劃，嚴格按計劃組織測試，排除測試活動的隨意性 ； ? 預先組織和準備好各種測試用例和測試數(shù)據(jù)，以保證測試活動的順利開展 ； ? 測試輸入數(shù)據(jù)應與對應的預期輸出結果配套 ； ? 測試用例中不僅有合理的輸入條件，還要有不合理的輸入條件 ； ? 妥善保存各種測試文檔及測試用例與數(shù)據(jù)，為以后軟件重測和維護提供方便 ； ? 對每一個測試結果要做全面的分析和檢查。軟件中所有程序都必須經(jīng)過嚴格的測試和確認后，才能提交給用戶驗收。 ，對測試的組織與協(xié)調(diào)提出更高的要求，需要提前規(guī)劃，明確各方職責。 測試實施要點 ， 完成對用戶的操作培訓；使參與測試人員熟悉本系統(tǒng)實現(xiàn)功能及操作。 測試方法 同系統(tǒng)測試 測試組織 用戶主導測試， 各應用系統(tǒng)開發(fā)方參加，本軟件產(chǎn)品提供商 涉及角色 用戶測試組，各應用系統(tǒng)開發(fā)方，本軟件產(chǎn)品提供商。 測試內(nèi)容 本系統(tǒng)功能驗收測試；本系統(tǒng)性能驗收測試 。 ，及時進行修改和完善。 涉及角色 開發(fā)人員、測試人員、用戶協(xié)助人員 測試環(huán)境 獨 立于開發(fā)的系統(tǒng)測試環(huán)境 康佳集團呼叫中心系統(tǒng)項目 實施方案 ▲保密 第 18 頁 共 61 頁 測試實施要點 ，參與系統(tǒng)測試的運作。 在集成測試的基礎上，模擬實際的用戶運行環(huán)境，進一步按軟件需求分析說明書定義的全部要求，對軟件系統(tǒng)內(nèi)的所有部分、與外部系統(tǒng)及數(shù)據(jù)連接進行整體性測試。 相關文檔 概要設計、詳細設計文檔、集成測試計劃、集成測試報告 圖表 7. 集成測試 方案 系統(tǒng)測試 測試目的 對軟件的整體功能、性能、特性的有效性測試，并對軟件配置與相關技術文檔的內(nèi)容進行復查，以驗證被測軟件是否滿足需求分析說明書中的內(nèi)容，以及軟件配置及運行環(huán)境的效果確認 。使用測試用例數(shù)量不 康佳集團呼叫中心系統(tǒng)項目 實施方案 ▲保密 第 17 頁 共 61 頁 多的測試用例集來檢驗系統(tǒng)，確定是否可 以繼續(xù)后續(xù)的復雜測試。 測試內(nèi)容 的集成測試 測試方法 ，在通過建立接口 stub進行 測試組織 以軟件測試小組為主，軟件開發(fā)小組中的編碼人員協(xié)助 涉及角色 測試人員、開發(fā)人員 測試環(huán)境 獨立于開發(fā)的測試環(huán)境 測試實施要點 ，在子系統(tǒng)可以集成的時候盡早進行集成測試，因此項目組可能需要進行多個集成測試。 相關文檔 詳細設計文檔、編程規(guī)范、單元測試計劃、單元測試報告 圖表 6. 單元測試方案 集成測試 測試目的 在單元測試的基礎上，按照集成測試的計劃，依據(jù)軟件設計的要求，對系統(tǒng)各部分進行組裝測試。 涉及角色 開發(fā)人員、測試人員 測試環(huán)境 單元測試環(huán)境使用軟件開發(fā)環(huán)境 測試實 施 要點 ，如平臺建設，單元測試要求代碼覆蓋 100%，路徑覆蓋 100%。 ：運行所測模塊，并根據(jù)需要輸入相應的數(shù)據(jù)，包括實際業(yè)務數(shù)據(jù)、錯誤數(shù)據(jù)和非正常操作，檢查模塊對輸入的響應。 單元測試 測試目的 驗證程序功能模塊的輸入、輸出、處理過程和運行狀態(tài)的正確性，檢查是否符合設計要求和編程規(guī)范。 測試方案 根據(jù)測試的實施階段將整個測試工作分為單元測試，集成測試，系統(tǒng)測試與用戶驗收測試。 (2) 測試構成 測試人員由項目負責人、測試工程師、軟件編程人員、文檔管理員以及用戶組成。整個軟件系統(tǒng)的測試工作將分階段進行，并參照國家規(guī)范分別制定相應的測試計劃和測試報告，以確保軟件可靠運行。 康佳集團呼叫中心系統(tǒng)項目 實施方案 ▲保密 第 15 頁 共 61 頁 測試地點在用戶所在地，針對用戶的實際系統(tǒng)進行。 測試方法采用先進行模塊測試，然后進行系統(tǒng)統(tǒng)一測試； 每個模塊測試包括功能測試、界面測試等。 系統(tǒng)測試計劃 測試工作是軟件開發(fā)項目中的重要環(huán)節(jié)，本節(jié)將介紹我們在本項目中所采用的測試實施方案，測試管理方法，測試技術與工具等。被檢視的對象可以是即將提交正式技術評審的軟件產(chǎn)品也可以是半成品。 (5) 文檔檢視 文檔檢視是一中非正規(guī)的技術評審。避免將缺陷帶入到測試階段。 代碼走查一般由開發(fā)人員完成。 (4) 代碼走查 代碼走查是檢查程序源代碼的活動。 如果評審會議上發(fā)現(xiàn)的軟件產(chǎn)品異常相當?shù)年P鍵或數(shù)量較大，則主審 人可以建議對軟件產(chǎn)品進行修改后，再進行一次技術評審。 軟件產(chǎn)品評審結束后，必須生成相應的評審會議文檔（評審報告或評審會議紀要），在文檔中列出在軟件產(chǎn)品中發(fā)現(xiàn)的軟件異常，并明確寫出評審結論，通過還是未通過。在技術評審會議上，與會專家對軟件產(chǎn)品進行評價。這個介紹會議可以作為評審會議的一部分，也 可以采用一個獨立的評審介紹會議的形式。 ii. 評審過程的主要活動 ? 評審準備 ? 主審人必須對以下技術評審準備工作負責 ? 在適當?shù)墓芾聿块T支持下，組成技術評審小組； ? 分配評審小組成員的特定的評審角色及其職責； ? 安排評審時間表，確定地點，并發(fā)布評審會議通知； ? 分發(fā)評審資料給參與評審人員，確保他們有足夠的時間進行準備。在評審過程中的職責： ? 在評審會議上對與會專家講解被評審的產(chǎn)品； ? 解答或解釋與會專家提出的問題； ? 與評審專家討論解決方案； ? 更正評審會 議上提出的問題。評審專家職責包括： ? 事先或評審會議上詳細了解評審對象； ? 標識出評審對象存在的問題或缺陷； ? 跟與會專家及作者對發(fā)現(xiàn)的問題進行詳細的分析和探討，并爭取達成共識； ? 如果可能，對問題或缺陷的解決方案給出建議。 ? 評審專家 康佳集團呼叫中心系統(tǒng)項目 實施方案 ▲保密 第 13 頁