大樓弱電系統(tǒng)工程軟件開發(fā)和測試施工技術方案

大樓弱電系統(tǒng)工程軟件開發(fā)和測試施工技術方案江蘇省電力公司電網調度中心大樓弱電系統(tǒng)工程中的幾項軟件工程（IBMS系統(tǒng)、辦公自動化系統(tǒng)、一卡通系統(tǒng)），分包單位的軟件部成立須成立專門軟件開發(fā)小組，應采用開放的軟件技術，運用標準化、模塊化以及系列化的開放性設計，來完成高質量的軟件工程。軟件開發(fā)和測試應按如下程序進行。1.1.方案建議向用戶提供《系統(tǒng)解決方案建議書》，該建議書內容為就客戶所關心的問題提出可行性方案并對不同的方案進行分析比較。最后向用戶推薦最佳方案。用戶可以根據《系統(tǒng)解決方案建議書》對各種不同的實施方案進行選擇比較。1.2.需求獲取和分析5.2.1.需求獲取5.2.1.1.培訓人員參與軟件開發(fā)的用戶代表應接受為期一天左右的關于需求工程的培訓。編寫項目術語：為了解決溝通方面的問題，編一部術語匯編將項目應用領域的專用詞匯給予定義說明，既要包括那些有多種含義與用法的術語，也要包括那些在專用領域和一般使用中有不同含義的詞。5.2.1.2.獲取需求確定需求開發(fā)過程：確定如何組織需求的收集、分析、細化并核實的步驟，并將它編寫成文檔。對重要步驟要給予一定的指導。需求分類：軟件需求包括三個不同的層次——業(yè)務需求，用戶需求和功能需求，業(yè)務需求代表了需求鏈中最高層的抽象，他們?yōu)檐浖到y(tǒng)定義了項目視圖和范圍業(yè)務需求不應包括用戶需求，而所有的功能需求都應該源于用戶需求。明確不同類型的用戶：在項目中，應盡早為產品確定并描述出不同的用戶類，這樣，就能從每一個重要的用戶類代表中獲取不同的需求。作為用戶類的劃分依據，可以是：用戶使用產品的頻度，他們的應用領域和計算機系統(tǒng)知識，他們所使用的產品特性、他們所進行的業(yè)務過程、他們在地理上的布局以及他們的訪問優(yōu)先級。明確需求來源。編寫項目視圖和范圍文檔，獲取業(yè)務需求。確定非功能需求：非功能需求定義了使軟件運行良好的特性，包括產品的易用程度，執(zhí)行速度，可靠性，健壯性，也稱為質量屬性。5.2.2.需求分析需求分析包括提煉、分析和仔細審查已經收集到的需求，以確保能找出其中的錯誤、遺漏或其它不足的地方。5.2.2.1.給需求分類將需求分成以下幾種類型：業(yè)務需求使用實例或說明業(yè)務規(guī)格功能需求質量屬性外部接口需求限制數據定義解決思想5.2.2.2.繪制系統(tǒng)關聯圖關聯圖確定了通過某一接口與系統(tǒng)相連的外部實體，同時也確定了外部世界和系統(tǒng)之間的數據流和物流。5.2.2.3.創(chuàng)建用戶接口原型創(chuàng)建一個原型并且讓合適的用戶群對其評價來對需求進行分析。5.2.2.4.分析需求可行性在允許的成本，性能要求下，分析每項需求實施的可行性，明確與每需求實現相聯系的風險，包括與其它需求的沖突，對外界因素的制約和技術障礙。5.2.2.5.確定需求的優(yōu)先級別設定優(yōu)先級的一般方法是把需求分成三類：基本的：只有在這些需求上達成一致意見，軟件才會被接受。條件的：實現這些功能將增強產品的性能，如果不實現產品也可以被接受。可選的：一個功能類，實現或不實現均可。進入開發(fā)階段后，根據需求的優(yōu)先級確定開發(fā)順序。5.2.2.6.為需求建立模型為了進一步檢查需求的不一致性、模糊性、錯誤和遺漏，需要把用文本表示的需求和用模型表示的需求結合起來。這樣的模型有數據流圖、實體關系圖、狀態(tài)變換圖、對話框圖、對象圖及交互圖。5.2.2.7.建立數據字典在開發(fā)階段，數據字典定義客戶數據項以確?？蛻襞c開發(fā)小組是使用一致的定義和術語。5.2.3.編寫需求規(guī)格說明參照相關國家規(guī)范編寫《軟件功能規(guī)格說明書》。5.2.4.需求驗證5.2.4.1.審查需求文檔組織一個由不同代表（如分析人員、客戶、設計人員、測試人員）組成的小組，對SRS及相關模型進行仔細的檢查。5.2.4.2.用戶書面確認需求說明規(guī)格編寫完成并且通過需求驗證后，即可要求客戶簽字同意中止需求過程。5.2.4.3.以需求為依據編寫測試用例根據用戶需求所要求的產品特性寫出黑盒功能測試用例?？蛻敉ㄟ^使用測試用例以確認是否達到了期望的要求。還要從測試用例追溯回功能需求以確保沒有需求被疏忽，并且確保所有測試結果與測試用例相一致。同時，要使用測試用例來驗證需求模型的正確性。如對話框圖和原型等。5.2.4.4.編寫用戶手冊在需求開發(fā)早期即可起草一份用戶手冊，用它作為需求規(guī)格說明的參考并輔以需求分析，優(yōu)秀的用戶手冊要用淺顯易懂的語言描述出所有對用戶可見的功能，而輔助需求如質量屬性、性能需求及對用戶不可見的功能則在SRS中予以說明。5.2.4.5.確定合格的標準將合格的測試建立在使用情景描述或使用實例的基礎止。5.2.5.需求管理當完成需求說明后，不可避免地還會遇到項目需求的變更。有效的變更管理需要對變更帶來的潛在的影響及可能的成本費用進行評估。項目負責人與關鍵的項目風險承擔者要進行協(xié)商，以確定哪些需求可以變更，同時，無論是在開發(fā)階段還是在系統(tǒng)測試階段，還應跟蹤每項需求的狀態(tài)。這些都是需求管理的內容。1.3.項目實施按照《用戶需求說明書》、《項目開發(fā)計劃》和公司的項目開發(fā)規(guī)范，對項目進行開發(fā)，開發(fā)完畢，向用戶提交《用戶接收測試報告》、《用戶手冊》和《管理員手冊》。1.4.項目測試5.4.1.系統(tǒng)測試環(huán)境根據軟件開發(fā)項目的技術設計方案和《系統(tǒng)軟件需求規(guī)格說明書》中對系統(tǒng)環(huán)境的要求，該系統(tǒng)的測試環(huán)境將在模擬系統(tǒng)實際的運行環(huán)境的基礎上配置。對于環(huán)境測試、穩(wěn)定性測試、仿真測試和安全保密測試等測試項目，還將在系統(tǒng)交付前，在用戶的真實運行環(huán)境中進行測試。5.4.2.測試工具測試工具的使用是保證測試質量，提高測試效率的有效手段。但是對于應用系統(tǒng)，其輸入輸出及功能實現也是千差萬別，因此人工測試尤為重要，不可取代。系統(tǒng)采用測試工具及人工測試相結合的方式。使用類似于如下測試工具對系統(tǒng)進行測試工具 供應商功能性測試WinRunnerMercuryInteractive

版本7.0公司MercuryInteractive鏈接測試

LoadRunner

7.0公司MercuryInteractiveWeb測試

LoadRunner

7.0公司5.4.3.測試標準《信息產業(yè)部軟件產品測試標準》《GB/T17544－1998》國際標準ISO／IEC12119：1994《信息技術軟件包質量要求和測試》5.4.4.測試類型5.4.4.1.數據和數據庫完整性測試測試目標：

確保數據庫訪問方法和進程正常運行，數據不會遭到損壞。技術：

調用各個數據庫訪問方法和進程，并在其中填充有效的和無效的數據（或對數據的請求）。檢查數據庫，確保數據已按預期的方式填充，并且所有的數據庫事件都已正常發(fā)生；或者檢查所返回的數據，確保為正當的理由檢索到了正確的數據完成標準： 所有的數據庫訪問方法和進程都按照設計的方式運行，數據沒有遭到損壞。需考慮的特測試可能需要DBMS開發(fā)環(huán)境或驅動程殊事項：序在數據庫中直接輸入或修改數據。進程應該以手工方式調用。應使用小型或最小的數據庫（記錄的數量有限）來使所有無法接受的事件具有更大的可視度。功能測試測試目標：

確保測試對象的功能正常，其中包括導航、數據輸入、處理和檢索等功能。技術：

利用有效的和無效的數據來執(zhí)行各個用例、用例流或功能，以核實以下內容：在使用有效數據時得到預期的結果。在使用無效數據時顯示相應的錯誤消息或警告消息。各業(yè)務規(guī)則都得到了正確的應用。完成標準：所計劃的測試已全部執(zhí)行。所發(fā)現的缺陷已全部解決。需考慮的特確定或說明那些將對功能測試的實施和殊事項：執(zhí)行造成影響的事項或因素（內部的或外部的）業(yè)務周期測試測試目標

確保測試對象及背景的進程都按照所要求的業(yè)務模型和時間表正確運行。技術：

通過執(zhí)行以下活動，測試將模擬若干個業(yè)務周期：將修改或改進對測試對象進行的功能測試，以增加每項功能的執(zhí)行次數，從而在指定的時間段內模擬若干個不同的用戶。將使用有效的和無效的數據或時間段來執(zhí)行所有與時間或數據相關的功能。將在適當的時間執(zhí)行或啟用所有周期性出現的功能。在測試中還將使用有效的和無效的數據，以核實以下內容：在使用有效數據時得到預期的結果。在使用無效數據時顯示相應的錯誤消息或警告消息。各業(yè)務規(guī)則都得到了正確的應用。完成標準： 所計劃的測試已全部執(zhí)行。所發(fā)現的缺陷已全部解決。需考慮的特殊系統(tǒng)日期和事件可能需要特殊的支持活動事項：需要通過業(yè)務模型來確定相應的測試需求和測試過程。用戶界面測試測試目標： 核實以下內容：通過測試對象進行的瀏覽可正確反映業(yè)務的功能和需求，這種瀏覽包括窗口與窗口之間、字段與字段之間的瀏覽，以及各種訪問方法（Tab健、鼠標移動、和快捷鍵）的使用窗口的對象和特征（例如，菜單、大小、位置、狀態(tài)和中心）都符合標準。技術：為每個窗口創(chuàng)建或修改測試，以核實各個應用程序窗口和對象都可正確地進行瀏覽，并處于正常的對象狀態(tài)。完成標準： 成功地核實出各個窗口都與基準版本保持一致，或符合可接受標準需考慮的特殊并不是所有定制或第三方對象的特征都可訪事項：問。性能評測測試目標： 核實所指定的事務或業(yè)務功能在以下情況下的性能行為：正常的預期工作量預期的最繁重工作量技術： 使用為功能或業(yè)務周期測試制定的測試過程。通過修改數據文件來增加事務數量，或通過修改腳本來增加每項事務的迭代數量。腳本應該在一臺計算機上運行（最好是以單個用戶、單個事務為基準），并在多個客戶機（虛擬的或實際的客戶機，請參見下面的“需要考慮的特殊事項”）上重復。完成標準： 單個事務或單個用戶：在每個事務所預期或要求的時間范圍內成功地完成測試腳本，沒有發(fā)生任何故障。][多個事務或多個用戶：在可接受的時間范圍內成功地完成測試腳本，沒有發(fā)生任何故障。需考慮的特殊綜合的性能測試還包括在服務器上添加后臺事項：工作量?？刹捎枚喾N方法來執(zhí)行此操作，其中包括：直接將“事務強行分配到”服務器上，這通常以“結構化查詢語言”(SQL)調用的形式來實現。通過創(chuàng)建“虛擬的”用戶負載來模擬許多個（通常為數百個）客戶機。此負載可通過“遠程終端仿真”(RemoteTerminalEmulation)工具來實現。此技術還可用于在網絡中加載“流量”。使用多臺實際客戶機（每臺客戶機都運行測試腳本）在系統(tǒng)上添加負載。性能測試應該在專用的計算機上或在專用的機時內執(zhí)行，以便實現完全的控制和精確的評測。性能測試所用的數據庫應該是實際大小或相同縮放比例的數據庫。負載測試測試目標： 核實所指定的事務或商業(yè)理由在不同的工作量條件下的性能行為時間。技術： 使用為功能或業(yè)務周期測試制定的測試。通過修改數據文件來增加事務數量，或通過修改測試來增加每項事務發(fā)生的次數。完成標準： 多個事務或多個用戶：在可接受的時間范圍內成功地完成測試，沒有發(fā)生任何故障。需考慮的特殊負載測試應該在專用的計算機上或在專用的事項：

機時內執(zhí)行，以便實現完全的控制和精確的評測。負載測試所用的數據庫應該是實際大小或相同縮放比例的數據庫。強度測試測試目標：核實測試對象能夠在以下強度條件下正常運行，不會出現任何錯誤：服務器上幾乎沒有或根本沒有可用的內存（RAM和DASD）連接或模擬了最大實際（實際允許）數量的客戶機多個用戶對相同的數據或賬戶執(zhí)行相同的事務最繁重的事務量或最差的事務組合（請參見上面的“性能測試”）。注：強度測試的目標可表述為確定和記錄那些使系統(tǒng)無法繼續(xù)正常運行的的情況或條件。客戶機的強度測試在“配置測試”的第3.1.11節(jié)中進行了說明。技術： 使用為性能評測或負載測試制定的測試。要對有限的資源進行測試，就應該在一臺計算機上運行測試，而且應該減少或限制服務器上的RAM和DASD（直接訪問存儲設備）對于其他強度測試，應該使用多臺客戶機來運行相同的測試或互補的測試，以產生最繁重的事務量或最差的事務組合。完成標準： 所計劃的測試已全部執(zhí)行，并且在達到或超出指定的系統(tǒng)限制時沒有出現任何軟件故障，或者導致系統(tǒng)出現故障的條件并不在指定的條件范圍之內。需考慮的特如果要增加網絡工作強度，可能會需要使殊事項：用網絡工具來給網絡加載消息或信息包。應該暫時減少用于系統(tǒng)的DASD，以限制數據庫可用空間的增長。使多個客戶機對相同的記錄或數據賬戶同時進行的訪問達到同步。容量測試測試目標： 核實測試對象在以下高容量條件下能否正常運行：連接或模擬了最大（實際或實際允許）數量的客戶機，所有客戶機在長時間內執(zhí)行相同的、且情況（性能）最壞的業(yè)務功能。已達到最大的數據庫大?。▽嶋H的或按比例縮放的），而且同時執(zhí)行了多個查詢或報表事務。技術： 使用為性能評測或負載測試制定的測試。應該使用多臺客戶機來運行相同的測試或互補的測試，以便在長時間內產生最繁重的事務量或最差的事務組合（請參見上面的“強度測試”）。創(chuàng)建最大的數據庫大?。▽嶋H的、按比例縮放的、或填充了代表性數據的數據庫），并使用多臺客戶機在長時間內同時運行查詢和報表事務。完成標準： 所計劃的測試已全部執(zhí)行，而且在達到或超出指定的系統(tǒng)限制時沒有出現任何軟件故障。需考慮的特殊對于上述的高容量條件，哪個時間段是可以事項：接受的時間？安全性和訪問控制測試測試目標：

應用程序級別的安全性：核實主角只能訪問其所屬用戶類型已被授權訪問的那些功能或數據。系統(tǒng)級別的安全性：核實只有具備系統(tǒng)和應用程序訪問權限的主角才能訪問系統(tǒng)和應用程序。技術：

應用程序級別的安全性：確定并列出各用戶類型及其被授權訪問的功能或數據。為各用戶類型創(chuàng)建測試，并通過創(chuàng)建各用戶類型所特有的事務來核實其權限。修改用戶類型并為相同的用戶重新運行測試。對于每種用戶類型，確保正確地提供或拒絕了這些附加的功能或數據。系統(tǒng)級別的訪問：請參見以下的“需考慮的特殊事項”完成標準：

各種已知的主角類型都可訪問相應的功能或數據，而且所有事務都按照預期的方式運行，并在先前的應用程序功能測試中運行了所有的事務。需考慮的特殊事項：

必須與相應的網絡或系統(tǒng)管理員一起對系統(tǒng)訪問權進行檢查和討論。由于此測試可能是網絡管理或系統(tǒng)管理的職能，可能會不需要執(zhí)行此測試。故障轉移和恢復測試測試目標： 確保恢復進程（手工或自動）將數據庫、應用程序和系統(tǒng)正確地恢復到了預期的已知狀態(tài)。測試中將包括以下各種情況：客戶機斷電服務器斷電通過網絡服務器產生的通信中斷技術：

DASD或DASD控制器斷電或DASD與DASD控制器的通信中斷周期未完成（數據過濾進程被中斷，數據同步進程被中斷）。數據庫指針或關鍵字無效數據庫中的數據元素無效或遭到破壞應該使用為功能和業(yè)務周期測試創(chuàng)建的測試來創(chuàng)建一系列的事務。一旦達到預期的測試起點，就應該分別執(zhí)行或模擬以下操作：客戶機斷電：關閉PC機的電源。服務器斷電：模擬或啟動服務器的斷電過程。通過網絡服務器產生的中斷：模擬或啟動網絡的通信中斷（實際斷開通信線路的連接或關閉網絡服務器或路由器的電源）。DASD和DASD控制器被中斷、斷電或與DASD和DASD控制器的通信中斷：模擬與一個或多個DASD控制器或設備的通信，或實際取消這種通信。一旦實現了上述情況（或模擬情況），就應該執(zhí)行其他事務。而且一旦達到第二個測試點狀態(tài)，就應調用恢復過程。在測試不完整的周期時，所使用的技術與上述技術相同，只不過應異常終止或提前終止數據庫進程本身。對以下情況的測試需要達到一個已知的數據庫狀態(tài)。當破壞若干個數據庫字段、指針和關鍵字時，應該以手工方式在數據庫中（通過數據庫工具）直接進行。其他事務應該通過使用“應用程序功能測試”和“業(yè)務周期測試”中的測試來執(zhí)行，并且應執(zhí)行完整的周期。]完成標準： 在所有上述情況中，應用程序、數據庫和系統(tǒng)應該在恢復過程完成時立即返回到一個已知的預期狀態(tài)。此狀態(tài)包括僅限于已知損壞的字段、指針或關鍵字范圍內的數據損壞，以及表明進程或事務因中斷而未被完成的報表。需考慮的特 恢復測試會給其他操作帶來許殊事項：多的麻煩。斷開纜線連接的方法（模擬斷電或通信中斷）可能并不可取或不可行。所以，可能會需要采用其他方法，例如診斷性軟件工具。需要系統(tǒng)（或計算機操作）、數據庫和網絡組中的資源。這些測試應該在工作時間之外或在一臺獨立的計算機上運行。配置測試測試目標：技術：

核實測試對象可在所需的硬件和軟件配置中正常運行。使用功能測試腳本。在測試過程中或在測試開始之前，打開各種與非測試對象相關的完成標準：需考慮的特殊事項：

軟件（例如Microsoft應用程序：Excel和Word），然后將其關閉。執(zhí)行所選的事務，以模擬主角與測試對象軟件和非測試對象軟件之間的交互。重復上述步驟，盡量減少客戶機工作站上的常規(guī)可用內存對于測試對象軟件和非測試對象軟件的各種組合，所有事務都成功完成，沒有出現任何故障。需要、可以使用并可以通過桌面訪問哪種非測試對象軟件？通常使用的是哪些應用程序？應用程序正在運行什么數據？例如，在Excel中打開的大型電子表格，或是在Word中打開的100頁文檔。作為此測試的一部分，應將整個系統(tǒng)、Netware、網絡服務器、數據庫等都記錄下來。安裝測試測試目標：技術：完成標準：需考慮的特殊事項：

核實在以下情況下，測試對象可正確地安裝到各種所需的硬件配置中：首次安裝。以前從未安裝過<項目名稱>的新計算機更新。以前安裝過相同版本的<項目名稱>的計算機更新。以前安裝過<項目名稱>的較早版本的計算機手工開發(fā)腳本或開發(fā)自動腳本，以驗證目標計算機的狀況（首次安裝-<項目名稱>從未安裝過；<項目名稱>安裝過相同或較早的版本）。啟動或執(zhí)行安裝。使用預先確定的功能測試腳本子集來運行事務。<項目名稱>事務成功執(zhí)行，沒有出現任何故障。應該選擇<項目名稱>的哪些事務才能準確地測試出<項目名稱>應用程序已經成功安裝，而且沒有遺漏主要的軟件構件？5.4.5.測試資源人力資源人力資源角色

所推薦的最少資源

具體職責或注釋（所分配的專職角色數量）測試經進行管理監(jiān)督。理，職責：測試項目?提供技術指導經理?獲取適當的