【正文】 后，經(jīng)過乙方的開發(fā)過程得到的是最終結果，甲方對軟件開發(fā)過程沒法參與。乙方中只有具體的開發(fā)人員了解局部的軟件過程，高層管理人員沒法得到開發(fā)過程中具體的過程狀態(tài)信息，不能根據(jù)過程狀態(tài)做出決策。.. .. .. ..圖（b）表示一個對甲乙雙方可見性較好的軟件過程，在軟件開發(fā)過程的特定階段設置階段控制點（也稱為里程碑） ，甲乙雙方依據(jù)階段成果，從各自的角度提出過程改善與修改意見，控制軟件系統(tǒng)生產(chǎn)的質(zhì)量、開發(fā)過程的效率及項目資源消費。 測試測試是確保本系統(tǒng)質(zhì)量的重要手段，不經(jīng)過認真測試的系統(tǒng)是不能被用于生產(chǎn)的。雖然，對各階段的文檔的審核也可認為是測試，但本項目所指的測試是指對應用軟件的測試。做好測試是測試組的責任，測試組是與開發(fā)組相互獨立的兩組，且需要相當?shù)募夹g和經(jīng)驗，對業(yè)務的理解要十分透徹。為保證測試的效率和質(zhì)量需要主意以下幾點：1．建立高效合理的測試流程，包括：建立盡量模擬真實環(huán)境的業(yè)務數(shù)據(jù)模型（即運行業(yè)務的初始環(huán)境） ；對測試案例的設計要有深度和廣度；特別在系統(tǒng)測試和驗收測試階段，安排好項目組的全體人員的任務和責任；做好測試階段文檔和源程序的版本控制；做好測試中發(fā)現(xiàn)的 BUGS 的記錄及存檔工作；對發(fā)現(xiàn)的任何 BUGS 都要做好原因分析并記錄歸檔 ；做好回歸測試；防止對程序的修改而引起的其他問題。軟件測試是一個過程，涉及到軟件生命周期的各個階段。下圖描述了軟件.. .. .. ..測試過程模型： 測試過程是與開發(fā)過程并行的，軟件測試的實施過程是與改錯過程既是交錯的、同時又是并行進行的。在集成測試階段中，測試一般應當由獨立的軟件測試人員來實施。這種方法一方面可以有效地壓縮測試的總周期，但更重要的是可以避免開發(fā)者自身的思維局限，更加客觀全面地進行有效的測試。 項目協(xié)調(diào)與合作計劃對項目實施中的溝通是項目完成的順利與否的重要因素，所以在整個項目實施的過程中要有一套完善的溝通機制。在項目實施中，將以項目經(jīng)理為核心，實現(xiàn)全面、有效的溝通管理。其中：（1 ）項目經(jīng)理從始至終控制整 個項目的工作進展與步驟，是信息的收集.. .. .. ..者和發(fā)送者。（2 ）項目經(jīng)理要密切聯(lián)系了解各干系人信息，及時傳達給項目組其他成員。（3 ）項目經(jīng)理要每周與項 目領導小組交換項目工作進展情況，確保項目按計劃有步驟地進行，并提交全部項目管理報告給項目領導小組。（4 ）項目經(jīng)理要每周組織項 目組成員召開會議，了解項目進展情況，分派工作，了解項目實施中的問題，及時解決。（5 ）項目主管定期聯(lián)系用 戶負責人，傾聽用戶對項目的建議和意見，并采取相應的措施，最大程度保證用戶滿意度。（6 ）銷售人員和用戶保持正常通 暢的溝通渠道，及時接受用戶反饋意見。作為溝通的手段，采用如下方式進行項目的交流：（1 ）進程報告（工程簡報 ）：工程實施期間，各實施人員每天向項目經(jīng)理報告工作進展；項目經(jīng)理按照 ISO9000 質(zhì)量管理體系的要求每周向公司提交《項目進展報告》 ；同時，項目經(jīng)理每周向用戶單位提交 項目進展文件。（2 ）周例會：必要時參加由 項目管理組、用戶方在每周共同召開的周例會，會議將對一周以來的工作進展進行回顧，總結問題點，分析原因，并確定解決方案。對下一階段的工作任務進行部署。會議結果由項目管理組發(fā)布會議紀要。（3 ）工程階段總結：在實 施的每一個階段，進行工程階段總結，評估上.. .. .. ..一階段工作得失，為下階段的工作進行必要的預溝通，解決隱患問題；（4 ）多種形式的交流：項 目經(jīng)理與項目領導小組、用戶、其它廠商之間、以及項目隊伍成員之間保持通信聯(lián)絡，以傳真、電話、電子郵件等方式進行溝通。 配置管理公司采用相應的配置控制程序來管理新系統(tǒng)的各個部分，包括文檔，需求，設計，數(shù)據(jù)庫設計，編碼，文件和數(shù)據(jù)。并在項目實際實施時制定配置管理計劃，并委任一名配置管理員。配置控制的目的是控制系統(tǒng)的物理和功能特性，確保整個系統(tǒng)的完整性。配置控制既是技術活動又是管理活動，它的過程包括：配置項目發(fā)現(xiàn)和保存每個配置項目要有一個編號，用來區(qū)別有不同需求和實施要求的其它項目。它還有一個版本號，用來標明該項目所處的階段，在配置項目修改時，版本號要更新。配置系統(tǒng)要能夠容納新的配置項目，不必修改現(xiàn)存項目。配置項目要保存在軟件庫里面。為確保足夠的安全以及對所有可交付軟件項目的控制必須建立如下典型的軟件庫：名稱 狀態(tài)開發(fā)庫 動態(tài)的主庫 控制的靜態(tài)庫 靜態(tài)的.. .. .. ..開發(fā)庫是軟件作為一系列模塊進行開發(fā)和測試的動態(tài)庫。主庫是一個被控制的庫，項目的放入和取出必須按規(guī)定并以一定的控制方式進行。例如，在單元測試成功之后，模塊可以被轉(zhuǎn)入到系統(tǒng)主庫，然后供系統(tǒng)集成和系統(tǒng)測試。任何經(jīng)過以上測試需要修改模塊都要放回開發(fā)庫，以供測試。當主庫達到一定程度的穩(wěn)定后，就可以將它合成一個基準。每當基準發(fā)布以后，相關主庫都要進行拷貝產(chǎn)生靜態(tài)庫。之所以叫做靜態(tài)庫，因為以后不再更新，并且歸檔。2．配置變動控制只有當項目已經(jīng)成為基準的一部分時，軟件配置控制才能夠進行，它主要控制：評估對配置項目的變動協(xié)調(diào)批準的變動在本項目的執(zhí)行過程中，項目經(jīng)理將與用戶一起定義處理配置變動以及變動授權管理方法。作為對于已經(jīng)通過的單元，系統(tǒng)的驗收測試項目的變動，需要更高級別的授權。3．配置狀態(tài)記錄配置狀態(tài)記錄包括所有配置項目跟蹤報告，并且貫穿整個系統(tǒng)開發(fā)周期中，配置項目狀態(tài)將通過配置管理員來跟蹤和控制。為有效進行配置狀態(tài)記錄，應該詳細記錄以下信息：每個基準版的日期，版本和問題；每份問題審閱以及文檔修改的日期狀態(tài)；每份軟件問題報告、修改請求、和修改報告的日期和狀態(tài)；.. .. .. ..每個配置項目的總結描述。軟件版本公司將在版本文檔內(nèi)記錄軟件的版本，后續(xù)版本要附一個版本說明。該說明列出了版本內(nèi)的配置項目，并且說明其安裝步驟。而且，所有已經(jīng)修改的錯誤和已經(jīng)合并的新的需求都要有記錄。要在提交新版本之前重新測試修改過的軟件。對于每個版本公司保證文檔和代碼的一致性，而且保存舊版本。產(chǎn)品的完整性需要通過變更管理來維持。用戶需求的變化、系統(tǒng)需求的變化和系統(tǒng)設計的變化都被監(jiān)控和跟蹤，從而了解被批準變動的實施狀態(tài)?？刂谱兏哪康氖菫榱舜_保只有經(jīng)過批準的變更才能實施，確保變更情況傳達到了相應的有關方面，提供它們考慮和獲得它們的批準。用戶需求、系統(tǒng)需求和系統(tǒng)設計文檔在通過評審并批準后將作為基準。當一個文檔變?yōu)榛鶞室院?，就自動進入變更控制范圍。任何變動都需要提交變更請求。變更管理由以下四個部分組成：變更請求、變更評估、變更批準、變更實施和跟蹤。 文檔管理文檔必須真實地反映實際工程狀態(tài)。文檔的驗收，不能是在項目驗收時統(tǒng)一移交給用戶單位，而應當根據(jù)項目實施的不同階段，分批移交，在項目準備階段就需要制定一個文檔移交計劃，在規(guī)定的時間里移交事先規(guī)定格式、內(nèi)容的文檔。.. .. .. .. 人員管理人員的管理遵循幾條原則：本項目中的參與人員在無特殊情況且未經(jīng)用戶同意不進行調(diào)換；系統(tǒng)保障期人員均安排參加此項目建設的主要技術人員；本項目的項目管理人員安排具有同類項目豐富項目管理經(jīng)驗的人員。 保密管理考慮本系統(tǒng)的保密要求，公司承諾按照涉及國家秘密計算機系統(tǒng)要求進行系統(tǒng)建設的保密管理，并和用戶簽署保密協(xié)議，嚴格履行保密義務。.. .. .. ..3 、測試計劃 測試工作準 備為保證項目的質(zhì)量，xxxxxxxxxxx 將成立專門的項目測試小組，在項目經(jīng)理的統(tǒng)一領導之下，完成本次項目的測試工作，首先，在項目開始時，測試小組要完成測試的準備工作，測試準備工作的重點主要包括以下幾個主要方面：對整個項目情況進行調(diào)研與了解，以熟悉整個系統(tǒng)的整體架構和實現(xiàn)功能等相關情況，制定出初步的測試計劃；確定測試管理工具的實施方案，對測試管理工具根據(jù)項目的特點進行合理規(guī)劃；包括根據(jù)各個項目子系統(tǒng)的特點，制定相應的缺陷跟蹤方案、版本提交計劃等。保證測試人員的到位，并對測試人員進行測試管理工具和測試相關基礎技術的培訓，要求相關系統(tǒng)測試人員先進行相關系統(tǒng)體系結構和功能的了解，為后期的設計測試用例奠定基礎。 軟件開 發(fā)測試本項目采用的測試種類包括：模塊測試、功能測試、性能測試、分系統(tǒng)測試、全系統(tǒng)測試、容量測試、壓力測試、災難恢復測試等。在進行測試前，需要編寫詳實的測試方案，其中包括測試時間安排、測試準則、測試用例、測試范圍、測試目標、測試人員、出錯處理流程及處理結果.. .. .. ..等內(nèi)容。在測試案例中應包含對異常情況處理的測試，如數(shù)據(jù)不全、數(shù)據(jù)類別有誤、數(shù)據(jù)不合法等。各種類型的測試都是采用循環(huán)往復的“測試－改進”操作，以確保問題得到完整、充分的解決的過程。每個應用程序模塊完成后，進行模塊測試。模塊測試的目的在于通過大量、反復的測試，盡可能地捕獲程序編寫時的編碼及應用處理上的錯誤，并加以改正，使程序編寫時的錯誤在這一測試環(huán)節(jié)得到控制。功能測試是對項目實現(xiàn)的功能進行測試。功能測試可細分為：獨立測試和連續(xù)測試兩部分。獨立測試是將本項目開發(fā)實現(xiàn)的功能一一進行獨立測試。在測試過程中，將針對每一個功能制定相應的測試個案，進行嚴格的功能測試。如測試結果與實現(xiàn)要求不符，將由開發(fā)人員進行改進及完善，最終達到功能要求。測試中發(fā)生問題時，編程人員會改動程序以便解決問題。系統(tǒng)將在修改后進行重新測試。此時其進行的測試不僅針對改動部分，還應對原已通過獨立測試的部分進行重新測試。系統(tǒng)的性能是一個很重要的參數(shù)，本項目所指的系統(tǒng)性能包括系統(tǒng)的效率、響應時間及處理能力。在測試中，為每個應用設置響應時間、處理速度量度，.. .. .. ..評估系統(tǒng)的最高處理能力，在發(fā)現(xiàn)系統(tǒng)的性能不滿足要求進，需進行相應措施對系統(tǒng)的性能進行調(diào)整。針對各個分系統(tǒng)，根據(jù)不同的測試方案，按照測試方案中的測試步驟進行測試，進行測試結果分析，得出測試結論，對分系統(tǒng)的配置給出建議意見。最終對每一個分系統(tǒng)做出一個分系統(tǒng)測試報告，主要內(nèi)容為測試結果，結果分析，建議。對系統(tǒng)功能、性能、安全、可靠和擴展等每一方面都需有明確的結論和意見。在分系統(tǒng)測試完畢的基礎上，對整個硬件平臺進行測試，主要針對各分系統(tǒng)的結合部，以及總體功能。與分系統(tǒng)測試方案一樣，全系統(tǒng)測試也是根據(jù)測試方案按照測試方案中的測試步驟進行，最終做出系統(tǒng)測試報告，主要包含：系統(tǒng)功能、性能、安全、可靠和擴展等各個方面能否達到設計要求的結論，出現(xiàn)問題，建議解決問題方案。項目在投產(chǎn)前，建議進行容量測試，以找出項目投產(chǎn)后可處理的最大處理容量，確保能夠平滑地過渡或避開業(yè)務處理高峰期。與此同時，通過對業(yè)務處理高峰期時系統(tǒng)硬件資源情況的占有量的獲取，能夠有效地調(diào)配系統(tǒng)資源。通過容量測試，得知系統(tǒng)承載量，并結合業(yè)務發(fā)展增長量，可以推算出需要更換相關硬件的時間，以便用戶可以提前做好應對準備。.. .. .. ..壓力測試的目的是希望能夠通過測試，得知在極短時間內(nèi)對網(wǎng)站進行大量并發(fā)訪問，是否會對系統(tǒng)造成瞬間無法承受的壓力沖擊，致使其運行異常甚至崩潰。壓力測試可以獲知系統(tǒng)的耐壓程度，在必要時采取適當?shù)木o急防護措施，如控制、分散等措施，減低緩解系統(tǒng)瞬間壓力，防止尖峰時刻的出現(xiàn)，使系統(tǒng)得以穩(wěn)定地運行。災難恢復測試是指在模擬災難事故發(fā)生的情況下，對系統(tǒng)的恢復情況進行測試及彩排。要盡可能地找出可能發(fā)生的災難性事故，并一一進行模擬，查看系統(tǒng)的恢復情況。災難恢復測試能夠反映出系統(tǒng)備份的準確性及完整性，以及自動恢復功能的強弱，出具不同災難恢復所需的時間數(shù)據(jù)，以此可以估算出在災難發(fā)生時對用戶所造成的影響及忍受程度。 設計測試 用例和 數(shù)據(jù)測試用例和數(shù)據(jù)準備的目的是幫助用戶在不熟悉實際環(huán)境的時候，能正常的測試系統(tǒng)并對系統(tǒng)做出正確的評價。測試用例和數(shù)據(jù)的準備是一項枯燥和費時間的工作。為了提高工作效率可以從以下幾方面著手：將信息放在一個指定的位置，便于反復利用，降低變化產(chǎn)生的影響；一次完成一個步驟，避免冗余和額外的工作；