2．配置管理系統是專案經理的"眼睛"，是軟體測試有效實施的前提

在軟體質量體系的諸多支援活動中,配置管理系統處在支援活動的中心位置,它有機地把其它支援活動結合起來,形成一個整體,相互促 進,相互影響,有力地保證了質量體系的實施。建立公司配置管理系統很容易得到公司領導層的支援，幾乎沒人反對。更重要的是建立配置管理系統後測試人員的工作有了系統保證，測試工作的"礦藏資源"有了明確的位置，可以主動積極開展測試工作。

2.1 專案管理存在的主要問題
華友公司測試部門去年剛成立時，以建立、規範和推廣使用配置管理系統CVS為突破口，同時建立缺陷跟蹤系統Bugzilla提高測試流程的管理水平。我做為測試負責人首先分析華友公司幾個軟體專案在開發管理上的現狀,。

存在問題一、公司幾個核心專案仍然過分分依賴少數個人的作用,沒有建立起協同作戰的氛圍,沒有科學的軟體配置管理流程; 技術上只重視系統和資料庫、開發工具的選擇,而忽視配置管理工具的選擇,導致即使有些專案有配置管理的規程,也由於可操作性差而擱淺。以上種種原因導致開發過程中普遍存在如下一些問題: 調查說明華友研發成員的變動的比率達到30%，幾乎每週都有新加入的員工或者辭職人員， 一個新成員熟悉專案的最佳途徑就是通過配置管理系統閱讀專案文件，甚至閱讀同行程式碼，達到快速學習、共同提高的目的。一個辭職人員可以利用配置管理系統保留部分一段時間工作，最大程度減少對專案開發造成的損失。

存在問題二、開發管理鬆散。領導瞭解工作完成情況重視口頭交流，忽視書面文件。有些部門主管無法確切得知專案的進展情況,專案經理也不知道各開發人員的具體工作,專案進展隨意性很大,可"左"可"右"。"左"時按領導下達的"期限"進行,到期時,似乎一切已順利完成,大家一陣胡弄,交差完成,反正領導看的是介面,至於裡面是什麼,留到施工時再說。施工時的工作因此變成了無法彙報、無法理清的無休止的維護。"右"時則專案工期無休止地延期。對我們軟體工程來說,總的特點是先"左"後"右"。在領導面前表現"左",在使用者面前表現"右"。有個測試人員經常利用上班時間學習英語，過了一個多月，看她依然如此，我做為專案領導進行批評教育，這名員工並不認為自己錯了，她爭辯，公司採取彈性工作時間，考核員工是分配的任務是否完成等理由。同時、我對她批評結果遭到她的惡意報復，她給有關領導報告新來的經理如何不懂公司業務，採取不適合公司的管理方式等，由於領導無法瞭解真相，使得我的工作在一段時間開展很困難，直到過去半年，這名員工辭職出國學習領導才明白髮生了什麼。

存在問題三、專案之間溝通不夠。各個開發人員各自為政,每個專案經理都像個"地主"，編寫的程式碼不僅風格各異,而且編碼和設計脫節。每個專案組的人力資源和硬體資源成了"私有財產"，自己人員即使暫時空閒，讓他從事所謂的新技術研究，也不考慮友鄰專案需要他們幫助的現狀。本來開發中錯誤在所難免, 進展早一點的專案組或者人力資源強的專案組已經積累類似問題的解決經驗，也不願意分享給其它專案組。 開發大量重複, 留下大量難維護的程式碼。典型案例是有個簡訊專案D兩年來在這個開發人員Y 的研發支援下運轉效益很好，但是三個月之前，開發人員 Y因為待遇問題和公司領導談判失敗，提出辭職。專案D仍然在執行，但是最近移動公司規範修改、系統升級，需要修改程式，沒人能看到及時更新的文件，儘管有一堆程式碼庫，但是後來的程式設計師都沒辦法分析明白程式結構。公司領匯出面請開發人員Y來協助，因為沒有文件記錄，Y忙於新公司的工作也不能解決修改。

存在問題四、文件與程式嚴重脫節。軟體產品是公司的寶貴財富,程式碼的重用率是相當高的,如何建好知識庫,用好知識庫對公司優質高效開發產品,具有重大的影響。但開發人員的一句名口號是:"叫我幹什麼都可以,但別叫我看別人的程式"。當然,開發人員的工作態度要轉變,但客觀上有一個很重要的原因是:前人留下的程式既無像樣的文件(即使留下了文件 ,其與源程式也嚴重脫節),開發風格又不統一,就像一堆垃圾,要開發人員到垃圾中去撿破爛,從這個角度上看,開發人員的要求是合理的。

存在問題五、測試工作不規範。仍然停留在"小姑娘做測試"的底水平上，傳統的開發方式中,測試工作只是人們的一種主觀願望,根本無法提出具體的測試要求,加之開發人員的遮醜,測試工作往往是走一走過場,測試結果既無法考核又無法量化,當然就無法對以後的開發工作起指導作用。

存在問題六、雖然專案施工時間不長，但軟體版本更新週期過短,幾乎每天都修改線上執行系統，且開發人員必須親自現場或遠端登陸操作，全國十幾個地點軟體內容多少都有點差別，這些差別都記錄在幾個骨幹人物的腦袋裡。 由於應用軟體的特點,各個不同的施工點有不同的要求,開發人員要手工地保持多份不同的拷貝,即使是相同的問題,但由於在不同地方提出,由不同人解決,其做法也不同,程式的可維護性越來越差。久而久之,最後連自已都分不清楚了,程式碼的相互覆蓋現象時有發生,且這苦水還無法傾訴,因為怕別人笑話,甚至別人問起,還得想法搪塞,可謂費盡苦心。

2.2 建立配置管理系統,規範專案管理流程，建立知識庫的同時節約專案費用

針對以上問題, 利用自己在Beijing Precom Inc, 普天潤匯等公司積累的經驗，建立配置管理系統CVS, CVS 的全稱是Current Version Control. CVS是一種GNU 軟體包.由Intersolv公司開發，它明確的將原始檔的儲存和使用者的工作空間獨立開來, 並使其有利與並行開發.這個工具屬於Open Source， ,CVS可以在intenet 上很方便的得到. 它的原始碼在ftp://202.113.29.4/pub1/unix/cvs 它的說明文件在ftp://202.113.29.4/doc/cvs.任何人可以很方便的下載.目前他的最新版本是2..10.8。 不需要花錢，很快建立，重點在於使用和推廣。配合專案經理共同制定相應的配置管理策略,取得了很好的成效。

2.2.1. 節約費用

(1) 縮短開發週期

利用CVS對程式資源進行版本管理和跟蹤,建立公司的程式碼知識庫,儲存開發過程中每一過程版本,這樣大大提高了程式碼的重用率,還便於同時維護多個版本和進行新版本的開發,防止系統崩潰,最大限度地共享程式碼。同時專案管理人員可以通過Version 系統檢視專案開發日誌,測試人員可以根據開發日誌和不同版本對軟體進行測試,工程人員可以從版本控制系統上得到不同的執行版本,並且可以安裝在Web Server或在Unix作業系統上命令列方式存取供外地施工人員存取最新版本,無需開發人員親臨現場。

利用CVS系統,可以大大提高開發效率,避免了程式碼覆蓋、溝通不夠、開發無序的混亂局面,如果利用了公司原有的知識庫,則更能提高工作效率,縮短開發週期。

(2) 減少施工費用

利用CVS進行軟體配置管理後,建立開發管理規範,把版本管理檔案掛接在公司內部的Web伺服器上,工程人員可以通過遠端進入內部網,獲取所需的最新版本。開發人員無需下現場,現場工程人員通過對方系統管理員收集反饋意見,書面提交到公司內部開發組專案經理,開發組內部討論決定是否修改,並作出書面答覆。這樣做,可以同時響應多個專案點,防止開發人員分配到各個專案點、分散力量、人員不夠的毛病,同時節約大量的旅差費用。

2.2.2. 有利於知識庫的建立

(1) 程式碼物件庫

軟體程式碼是軟體開發人員腦力勞動的結晶,也是軟體公司的寶貴財富,長期開發過程中形成的各種程式碼物件就像一個個零件坯一樣,是快速生成系統的組成部分。長期的一個事實是:一旦某個開發人員離開工作崗位,其原來所作的程式碼便基本成為垃圾,無人過問。究其原因,就是沒有專門對各人的有用物件進行管理,把其使用範圍擴大到公司一級,進行規範化,加以說明和普及。CVS系統為開發管理提供了一個平臺和倉庫,有利於建立公司級的程式碼物件庫。

(2) 業務及經驗庫

通過CVS的註釋,可形成完整的開發日誌及問題集合,以文字方式伴隨開發的整個過程,不依某個人的轉移而消失,有利於公司積累業務經驗,無論對版本整改或版本升級,都具有重要的指導作用。

2.2.3. 規範管理

(1) 量化工作量考核

傳統的開發管理中,工作量一直是難以估量的指標,靠開發人員自已把握,隨意性相當大;靠管理人員把握,主觀性又太強。採用CVS管理後,開發人員每天下班前對修改的檔案 Check In,其中記述當天修改細節描述,這些描述可以作為工作量的衡量指標。

(2) 規範測試

採用CVS以後,測試有了實實在在的工作,測試工作人員根據每天的修改細節描述對每一天的工作做具體的測試,對測試人員也具有可考核性,這樣環環相扣,大大減少了其工作的隨意性。

(3) 加強協調與溝通

採用CVS後,通過VSS文件共享系統和 Bugzilla缺陷跟蹤系統,大大加強了專案成員之間的溝通,做到有問題及時發現、及時修改、及時通知,但又不額外增加很多的工作量。

3．效能測試是軟體測試專業化的核心所在

從華友實踐看，軟體測試對於產品經理、開發經理和市場經理都有所認識，他們大部分人會認為功能測試工作他們能夠很好的完成，產品經理是公司對於業務最熟悉的 一批人，他們對於測試工程師最急切的需求是你幫我實施產品的效能測試工作，他們聽說過效能測試，我們的產品投入線上執行後碰到的最大故障是大使用者量訪問業務是機器凼機，或停止正常的服務，每次故障，幾乎給公司的收入都造成很大損失。如果測試部門能有一套有效的效能測試手段，就確立了測試部門在專案開發過程中關鍵地位。

效能測試在華友軟體的質量保證中起著非常重要的作用，將效能測試概括為四個方面：Wap無線應用服務在手機使用者端效能測試、 Web/Wap應用服務在客戶端效能的測試、應用在網路上效能的測試和應用在伺服器端效能的測試。通常情況下， 四方面有效、合理的結合，可以達到對系統性能全面的分析和瓶頸的預測。

3.1 Wap無線應用服務在手機使用者端效能測試

如今人人用手機都追求時尚，時尚體現在款式, 品牌和功能。手機產品功能的日新月異，移動增值業務功能層出不窮，從最初的簡訊、彩信、鈴聲到GPRS,CDMA,K-Java, Brew手機,功能的多樣性帶來手機使用者端軟體系統測試的複雜性。眾所周知, Java手機吸引人之處是能提供智慧的, 個人化的互動服務, 例如: 動態產生個人化的股市服務, 顯示圖形, 動畫, 實時路況, 氣象報告, 數字照像, 玩遊戲等, 部分服務能直接於使用者端執行。

為了提供如此生動的服務, 移動通訊系統要能給終端使用者在無線裝置上提供接入網際網路的功能, 要能儲存、提取、管理、計算、結帳、下載軟體服務, 並使內容提供商能提供豐富的聲像多媒體內容, 形成廣大的個人化互動式服務環境。 而作為移動使用者, 可將手機視作虛擬機器, 能隨時、隨地在適當的裝置上存取應用, 享受服務。 這確是一種時尚。

當前, 對於不同品牌的手機, 它們所用的平臺(指CPU和作業系統)各不相同, 由於採用不同的設計方案, 各設計之間缺乏相容性, 作業系統和二進位制程式碼都不相容。 當手機執行需要大量記憶體時, 特別是隨著接入網際網路, 手機使用者要求能使用個性化的 互動式應用軟體, 應用程式執行在虛擬執行環境下時, 問題顯得尤為突出。 所以, 有必要建立一種標準的通用執行平臺, 達到在合適的成本下提供統一的互動式應用軟體執行環境。 但是, 除非該平臺是基於完全標準的器件, 否則是難以達到要求的。
標準的通用的執行平臺是滿足運營商, 軟體開發商, 和終端使用者三者綜合要求的解決辦法。 理想的環境必須具備以下性質:

(1)、平臺應提供二進位制相容性。 可執行軟體是二進位制目標碼, 需要在處理器和應用軟體目標碼之間建立溝通;
(2)、平臺必須包括微處理器,或一個與微處理器機器程式碼相離的通用機器碼模擬器;
(3)、平臺應包括帶有應用程式介面API及支援一致性圖形使用者介面GUI相應功能的作業系統。 API 是執行典型操作功能的軟體功能庫, 例如開啟檔案, 讀寫資料, 配置和管理記憶體, 處理事件, 顯示文件和圖形等。 為使應用軟體真正做到可移植, 裝置上必須有公共功能集, 並讓軟體開發者能通過一致性API 擴充套件功能;
(4)、平臺不應要求過多的系統資源, 可移植性裝置不應使成本上升太多;
(5)、平臺應對功率有高效率, 尤其考慮用電池供電的裝置;
(6)、由於要在網際網路上應用, 安全性也是重要因素。

以Java手機軟體測試為例潛在的測試問題和解決辦法

Java有移植性好和其它很多優勢, 但用在手機上, 速率和功耗仍是個瓶頸。 Java帶來的新問題是執行速度慢, 消耗功率大。 與PC不同的是, 手機資源有限, 一般流行的手機中CPU的速率為26MHz, 或52MHz,帶128M快閃記憶體, 8Mb, 16M 或64Mb記憶體, 沒有硬碟, 由電池供電, 體積小, 空間窄。 系統慢的原因是:

(1) 系統必須同時執行兩套軟體: Java應用和虛擬機器JVM;
(2) Java軟體需要被翻譯成自然CPU指令;
(3) Java平臺是基於棧(相對於暫存器)結構的, 導致更多的記憶體存取。

因而, 如何對執行 Java加速成為關鍵。 加速處理資料和圖形, 這對手機上網際網路和多媒體的應用具有重要意義。 要克服這些問題, 提高Java軟體效能, 可能的方法有四種:

(1) 提高微處理器速率。 然而Java軟體效能與時鐘頻率並不成線性關係, 微處理器執行一般比記憶體存取時間高2-10倍, 增加時鐘頻率只會增加等待週期。
(2) 對JVM軟體進行優化。 這可能涉及到要用匯編語言對位元組碼翻譯環路進行程式設計, 而這會導致JRE變得與微處理器類別有關。 而與可移植相抵觸;
(3) 編譯。 將軟體直接編譯到微處理器的自然機器語言。 但是這會增加記憶體的開銷, 也不節省能量的消耗。
(4) 採用基於硬體的加速器。 這可以做到提高效能, 保障能量和成本的有效性。 被手機設計廠商認為是較理想的措施。 通用型Java加速晶片於今年年初問世。

3.2 分析Web/Wap應用服務在客戶端效能的測試

Web/Wap應用服務在客戶端效能測試的目的是考察客戶端應用的效能，測試的入口是客戶端。它主要包括併發效能測試、大資料量測試和速度測試等，其中併發效能測試是重點。
併發效能測試的過程是一個負載測試和壓力測試的過程，即逐漸增加負載，直到系統的瓶頸或者不能接收的效能點，通過綜合分析交易執行指標和資源監控指標來確定系統併發效能的過程。負載測試（Load Testing）是確定在各種工作負載下系統的效能，目標是測試當負載逐漸增加時，系統組成部分的相應輸出項，例如通過量、響應時間、CPU負載、記憶體使用等來決定系統的效能。負載測試是一個分析軟體應用程式和支撐架構、模擬真實環境的使用，從而來確定能夠接收的效能過程。壓力測試（Stress Testing）是通過確定一個系統的瓶頸或者不能接收的效能點，來獲得系統能提供的最大服務級別的測試。

併發效能測試的目的主要體現在三個方面：以真實的業務為依據，選擇有代表性的、關鍵的業務操作設計測試案例，以評價系統的當前效能；當擴充套件應用程式的功能或者新的應用程式將要被部署時，負載測試會幫助確定系統是否還能夠處理期望的使用者負載，以預測系統的未來效能；通過模擬成百上千個使用者，重複執行和執行測試，可以確認效能瓶頸並優化和調整應用，目的在於尋找到瓶頸問題。

我們公司自己組織力量同時委託第三方軟體HG公司開發Hawa網站的一套應用Avatar形象系統的時候, Avatar形象在網站業務中佔有著重要的位置，網站上的很多業務都是圍繞Avatar開展。 這套系統能不能承受大量的併發使用者同時訪問? 成為這個網站能否成功的關鍵，也是這次兩個公司合做開發能否順利完成的關鍵。這類問題最常見於採用聯機事務處理(OLTP)方式資料庫應用、Web瀏覽和視訊點播等系統。這種問題的解決要藉助於科學的軟體測試手段和先進的測試工具。

Web軟體測試例項說明：哈哇網站Avatar形象系統軟體。Avatar形象系統在上線試執行三個月後，所有的功能測試順利完成，軟體功能缺陷也修改完畢。但是，效能問題越來越成為專案經理關心的焦點，我們測試部門藉助比較熟悉的壓力測試工具Web Stress 實施客戶端效能測試進行100，500，1000等併發使用者訪問。每次測試主要在基於URL：http://avatar.hawa.cn/index.jsp的基礎上，與HG公司實時互動地進行多種情況下的測試。按照HG公司要求主要針對併發數為1000和500的情況下，儘量準確的對Avatar系統的效能壓力進行模擬測試；並排除所有不是從web伺服器（即avatar.hawa.cn）上得到的URL，即只對/index.jsp等頁面進行測試。三次結果後，儘管程式優化、執行伺服器配置多次修改，仍然存在使用者量併發數達到1000，服務質量下降，頁面方面時間超過正常顯示時間。這裡有最後一次測試結果與前幾次大致相同。但是本次測試，是用多客戶端測試，按原理是應該比以前的單機測試準確度要高，但其結果是比用單機測試的時間還要長，當併發數達到1000時，其頁面的最長響應時間在80多秒（而單機測試時時59秒多）！第三次又發現ISP網路100MB頻寬實際上不到20MB，也是影響使用者服務的關鍵因素之一。

這個效能問題經過HG公司開發人員近三個月改進，/index.jsp頁面的1000個使用者併發響應時間10秒左右。對於我方採用的Web Stress效能測試工具HG公司也認同其測試結果的客觀性，公司因為該軟體效能問題推遲支付對方經費200萬圓三個月，更重要的是軟體的效能問題得到很好解決，並與HG公司的關係很好保持。另外一個更大的收穫是測試部門在Web 產品部門有個很好的形象，他們每次新軟體產品需求提出、產品上線都主動要求測試部門參與並實施嚴格測試。

如何模擬實際情況呢? 找若干臺電腦和同樣數目的操作人員在同一時刻進行操作,然後拿秒錶記錄下反應時間？ 這樣的手工作坊式的測試方法不切實際，且無法捕捉程式內部變化情況,這樣就需要壓力測試工具的輔助。

測試的基本策略是自動負載測試，通過在一臺或幾臺PC機上模擬成百或上千的虛擬使用者同時執行業務的情景，對應用程式進行測試，同時記錄下每一事務處理的時間、中介軟體伺服器峰值資料、資料庫狀態等。通過可重複的、真實的測試能夠徹底地度量應用的可擴充套件性和效能，確定問題所在以及優化系統性能。預先知道了系統的承受力,就為終端使用者規劃整個執行環境的配置提供了有力的依據。

併發效能測試前的準備工作
　　
測試環境：配置測試環境是測試實施的一個重要階段，測試環境的適合與否會嚴重影響測試結果的真實性和正確性。測試環境包括硬體環境和軟體環境，硬體環境指測試必需的伺服器、客戶端、網路連線裝置以及印表機/掃描器等輔助硬體裝置所構成的環境；軟體環境指被測軟體執行時的作業系統、資料庫及其他應用軟體構成的環境。
　　
一個充分準備好的測試環境有三個優點：一個穩定、可重複的測試環境，能夠保證測試結果的正確；保證達到測試執行的技術需求；保證得到正確的、可重複的以及易理解的測試結果。
　　
測試工具：成熟的併發效能測試工具有很多，選擇的依據主要是測試需求和效能價格比。著名的併發效能測試工具有QALoad、LoadRunner、Benchmark Factory、 Webstress和AB-Apache等。這些測試工具都是自動化負載測試工具，通過可重複的、真實的測試，能夠徹底地度量應用的可擴充套件性和效能，可以在整個開發生命週期、跨越多種平臺、自動執行測試任務，可以模擬成百上千的使用者併發執行關鍵業務而完成對應用程式的測試。
　　
測試資料：在初始的測試環境中需要輸入一些適當的測試資料，目的是識別資料狀態並且驗證用於測試的測試案例，在正式的測試開始以前對測試案例進行除錯，將正式測試開始時的錯誤降到最低。在測試進行到關鍵過程環節時，非常有必要進行資料狀態的備份。製造初始資料意味著將合適的資料儲存下來，需要的時候恢復它，初始資料提供了一個基線用來評估測試執行的結果。
　　
在測試正式執行時，還需要準備業務測試資料，比如測試併發查詢業務，那麼要求對應的資料庫和表中有相當的資料量以及資料的種類應能覆蓋全部業務。

模擬真實環境測試，有些軟體，特別是面向大眾的商品化軟體，在測試時常常需要考察在真實環境中的表現。如測試防毒軟體的掃描速度時，硬碟上佈置的不同型別檔案的比例要儘量接近真實環境，這樣測試出來的資料才有實際意義。
　　
併發效能測試的關鍵的是測試過程中對監控物件的靈活應用，例如目前三層結構的執行模式廣泛使用，對中介軟體的併發效能測試作為問題被提到議事日程上來，許多系統都採用了國產中介軟體，選擇Java Script監控物件，手工編寫指令碼，可以達到測試目的。
　　
採用自動化負載測試工具執行的併發效能測試，基本遵循的測試過程有：測試需求與測試內容，測試案例制定，測試環境準備，測試指令碼錄製、編寫與除錯，指令碼分配、回放配置與載入策略，測試執行跟蹤，結果分析與定位問題所在，測試報告與測試評估。
　　
3.3 應用在網路上效能的測試

應用在網路上效能的測試重點是利用成熟先進的自動化技術進行網路應用效能監控、網路應用效能分析和網路預測。
　　
網路應用效能分析
　　
網路應用效能分析的目的是準確展示網路頻寬、延遲、負載和TCP埠的變化是如何影響使用者的響應時間的。利用網路應用效能分析工具，例如Application Expert，能夠發現應用的瓶頸，我們可知應用在網路上執行時在每個階段發生的應用行為，在應用執行緒級分析應用的問題。可以解決多種問題：客戶端是否對資料庫伺服器運行了不必要的請求？當伺服器從客戶端接受了一個查詢，應用伺服器是否花費了不可接受的時間聯絡資料庫伺服器？在投產前預測應用的響應時間；利用Application Expert調整應用在廣域網上的效能；Application Expert能夠讓你快速、容易地模擬應用效能，根據終端使用者在不同網路配置環境下的響應時間，使用者可以根據自己的條件決定應用投產的網路環境。
　　
網路應用效能監控
　　
在系統試執行之後，需要及時準確地瞭解網路上正在發生什麼事情；什麼應用在執行，如何執行；多少PC正在訪問LAN或WAN；哪些應用程式導致系統瓶頸或資源競爭，這時網路應用效能監控以及網路資源管理對系統的正常穩定執行是非常關鍵的。利用網路應用效能監控工具，可以達到事半功倍的效果，在這方面我們可以提供的工具是Network Vantage。通俗地講，它主要用來分析關鍵應用程式的效能，定位問題的根源是在客戶端、伺服器、應用程式還是網路。在大多數情況下使用者較關心的問題還有哪些應用程式佔用大量頻寬，哪些使用者產生了最大的網路流量，這個工具同樣能滿足要求。
　　
網路預測
　　
考慮到系統未來發展的擴充套件性，預測網路流量的變化、網路結構的變化對使用者系統的影響非常重要。根據規劃資料進行預測並及時提供網路效能預測資料。我們利用網路預測分析容量規劃工具PREDICTOR可以作到：設定服務水平、完成日網路容量規劃、離線測試網路、網路失效和容量極限分析、完成日常故障診斷、預測網路裝置遷移和網路裝置升級對整個網路的影響。
　　
從網路管理軟體獲取網路拓撲結構、從現有的流量監控軟體獲取流量資訊（若沒有這類軟體可人工生成流量資料），這樣可以得到現有網路的基本結構。在基本結構的基礎上，可根據網路結構的變化、網路流量的變化生成報告和圖表，說明這些變化是如何影響網路效能的。 PREDICTOR提供如下資訊：根據預測的結果幫助使用者及時升級網路，避免因關鍵裝置超過利用閥值導致系統性能下降；哪個網路裝置需要升級，這樣可減少網路延遲、避免網路瓶頸；根據預測的結果避免不必要的網路升級。

3.4 應用在伺服器上效能的測試
　　
首先分析伺服器的型別，伺服器的劃分起碼可以依據四大部分進行。一是根據整個架構，可分為IA伺服器和RISC伺服器；二是按照硬體配置的差別可分為工作組級、部門級、企業級；三是按照具體安裝的應用軟體可分為Web伺服器、檔案伺服器、FTP伺服器、E-mail伺服器、資料庫伺服器等等；四是根據作業系統分為WINDOWS陣營、UNIX陣營。這四大分類有所關聯，但其中按應用分類是最能給使用者清晰概念的。因為使用者在採購選型時，總是先想好了拿它做什麼用的。Intel最近所提出的前端（用於接入等）、中端（用於各種應用和中介軟體）和後端（用於資料庫、線上分析等）的分類辦法，這也是從應用角度考慮的。

分析伺服器效能指標莫不聚焦於三大指標：CPU、I/O及Web。如果大家還記得圖靈機的話，應該對計算單元和輸入輸出的重要不會抱什麼懷疑的態度。至於選擇Web作為衡量伺服器效能的要點，只能說是網路的力量。Internet的大行其道讓我們很難想象有伺服器孤島出現。工程師往往通過給與被測伺服器不斷增加的併發式檔案讀寫、資料庫操作以及HTTP訪問來取得其最大的潛值。

以Web測試為例，衡量Web效能一般有下列幾個重要指標：HTTP 每秒交易數（Transaction Per Second）；每秒會話數（Sessions Per Second）；當前使用者數（Concurrent users）；吞吐量（Throughput）。HTTP TPS通常也叫做每秒的點選數；每秒會話數是每秒到達Web伺服器的使用者數；當前使用者數是特定時間在Web 站點上的使用者數；吞吐量是在特定時間由Web站點發出的資料流量頻寬，它與伺服器提供服務的內容和交易數相關。以上將是我們對測試結果進行評述與點評的重要技術基礎。

4.專案管理開發環節的測試任務

當公司構架了合理的組織結構並制定了縝密的計劃後，就進入了產品的開發階段。 下面以已經實施完成的CYB專案一期為例，分析華友公司在專案管理上的正在推廣的具體 專案管理細節的優缺點和測試工作改進探討：

CYB專案一期需求：由於華友各類業務（SMS和WAP等）在不同運營商（中國聯通、中國移動、中國電信等）的不同平臺和在網站www.hawa.cn 的WEB門戶中向用戶提供服務，各類業務的相互獨立，為了統一管理使用者資訊、業務和計費等資訊，並彙總進行統計分析處理，同時也為了整合各類業務系統的資源，建立公司的業務運營支撐系統。

4.1 開發階段和專案週期

開發階段比較明顯，注重各階段應完成的功能，對本階段應完成的工作不能留到下一階段。明確專案經理為D，專案組開發程式設計師六人，專案第一階段週期3個月，專案需要完成的功能：
1)實現使用者資訊的統一管理，包括：使用者基本資訊，使用者使用業務的積分，使用者的定製/退定資訊的管理
2)實現各類業務資訊的集中管理，包括：簡訊業務、WAP1.2、WAP2.0、JAVA、彩鈴等各種業務
3)實現計費資訊的統一管理
4)提供客服功能
5)提供統計分析功能
6)提供統一的標準介面，分別與各業務子系統及運營商的系統相連線
7)提供網路管理、監控等功能

在這個階段，測試經理需要負責詳細瞭解專案開發需要的需求、設計文件等，制訂初步的測試方案，根據測試任務的特點決定測試開發任務。實際結果表明開發階段的最大兩個問題：重視設計、不重視測試和軟體質量，設計會議開了至少五次，參加會議有公司很有經驗的設計人員，測試有關人員沒有被邀請參加，忽視產品的效能需求，更多的關注基本功能實現；忽視需求是客服和運維人員，自以為很理解市場部提出的需求，忽視程式開發人員實現的難度和開發人員之間理解需求的差別，專案組成員之間重視口頭交流，忽視文件價值。

問題解決方法：開始階段請測試和質量保證工程師參加討論，就會提出軟體實現的效能需求；重視文件交流的價值，建立軟體文件模版和版本控制機制，每次交流落實在成員理解和書面文件。

4.2 軟體開發流程

華友公司原來是重視專案管理，忽視流程，一味誇大個別人努力在專案成功中的作用。經過一年痛苦的實踐，開始探討流程管理，已經啟動公司的SW-CMM質量體系認證工作，希望建立非常規範化和系統化的軟體開發流程，其流程的有很高的可執行性，並且能在實踐過程中不斷改進。華友公司的流程管理改進從一個專案研發的所有方面開始摸索，包括從最開始的意向、市場策劃到最後軟體的版本釋出(release)上線投入商業運營，都設計有相應的流程規定，基本上已由測試部門負責推廣一種能夠達到規範、高效的軟體開發流程。
CYB專案經理D重視口頭交流溝通，忽視文件交流，同時缺少與專案組成員知識共享意識；經理D重視與領導的交流，忽視與開發人員交流，專案實施中開發人員碰到具體問題沒人協助解決，開發效率降低。雖然流程沒錯，但是流程涉及到開發人員出現問題也是需要重視的。流程管理的關鍵，以"人"為本。

目前的組織框架下，經過一年多的工作實踐，深深體會到人和流程是保證專案成功的兩個最關鍵因素。由具備專案實施基本素質的人按規範的合理化流程進行專案開發，才能最大限度地保證專案的成功。一個好的流程可以保證差一點的人做出來的東西不至於太差，但不能確保做出精品。通過流程可以實現一種規範化、流水線化、工業化的軟體開發。通過流程我們部門間的配合才節省寶貴時間，為專案早期完成，贏得市場主動權。

4.3 專案計劃的階段性

1) 努力做到專案計劃詳細、周到。CYB專案計劃從開始有三個月計劃，到修改三次以上，計劃完成時間從三個月、延長到六個月、直到現在的八個月。計劃已經形同虛設。實踐證明不合理的計劃不如沒有計劃，不合理的計劃給領導造成錯誤的認識。合理的計劃應該是先明確本週工作計劃，對於難以預測的任務或者困難給出一個近期工作的方向，然後根據實際進展情況進行細化調整。

2) 流程中明確定義開發階段、測試階段。開發階段任務沒有完成，佔用測試階段計劃時間，測試工作效率降低。正確的處理方式建議不要減少測試工作時間，專案開發完成時間根據實際需要順延。

3) 每個階段都列出了該階段的各項活動，並詳細描述每項活動的屬性:

進入條件，輸入;
驗證方法;
結束條件，輸出。

4) 每個階段結束都要召開階段結束會議。前一個階段結束（以本階段開發任務測試完成為標誌）才能進入下一階段。專案經理需要在每個階段測試任務完成情況進行分析，存在的問題要充分暴露出來，以便於早點解決。 CYB專案經理D採取報喜不報優的做法，在會議上常得到領導的表揚，其他專案經理常愁眉苦臉擺出人員問題、可能的技術問題、測試人員和時間問題等。實際結果最後笑的專案經理也是專案完成比較順利。

5) 理想計劃中每個活動都比較具體，每個活動的時間以天為單位。計劃包括了開展質量控制活動的時間，推廣說明版本控制系統和缺陷跟蹤系統的使用的時間。

典型案例是公司研發用於使用者資訊管理的代號CYB專案，CYB專案開始時副總裁牽頭，由於測試人員少沒有參與，開發經理們討論設計實施方案後幾乎大家一片讚美。隨後專案經理D負責開發，他認為時間緊，省去了許多必須的文件工作。經理D採取報喜不報優的做法，專案文件差，過分強調計劃，而忽視計劃任務達到的質量，大部分專案測試沒有完成就宣佈開發完成，結果前三個月每次經理會上總裁都會表揚他們取得的階段成果，我做為測試經理沒有說話的機會，有一次剛講幾句，總裁馬上提醒希望大家克服困難，每個組的任務都可能需要加班等。結果原計劃三個月完成專案，已經過了半年發現要實現商用還需要做很多工作，具體完成時間也不確定， 可是現在每天總是強調專人測試，問文件沒有，只能通過問了一次又一次的溝通方式實施測試工作， 有個不錯的測試人員實在無法忍耐，辭職了，我只好安排新的測試人員應對完成任務。這個CYB專案遭到了整個公司的一片噓聲，雖然沒有放棄，但沒有商業價值了。快9個月的研發成本老本最清楚去那兒了。
總結教訓，專案經理對計劃和測試工作的高度重視、周密制定、嚴格執行是能夠實現專案有效商業價值的基本保障。

4.4 重視Review的作用

按軟體工程規範化流程，一般把Review和測試作為保證軟體質量兩個主要手段。測試的重要性已經成為各專案經理認識，並貫穿於開發的全過程，形成了專案組成員人人重視測試工作的氛圍。Review則是一個非常簡單有效並能儘早發現軟體中錯誤的有效方法，專案經理在每週必須根據進展情況制訂Review計劃，可以說，任何交付物都要經技術總監參加的Review後才能進行基線化。目前華友公司正在建立比較詳細全面、可執行性高的由Review流程和各種交付物的Review Checklist。

我們正在彌補這方面的工作流程缺陷，提出：凡事有計劃，凡事必review。首先在開發組內部推廣程式碼規範化工作，定期進行員工Code Review的工作， Code Review 是工作的重要環節。

4.5 質量管理和測試（QA）

公司目前沒有獨立的質量管理部門，暫時由測試部門測試經理作為質量保證部門的代表，監督和保證專案的進展的各項流程和模板，並且收集專案中發現的一些問題和解決方法以優化流程。由於公司對測試人才有著迫切的需要，因此，只好自己組建培養測試人才隊伍。從現實出發，我們不可能想IBM和微軟等大公司有雄厚的才力支援質量保障和測試工作開展，我們的工作重點放在軟體測試方面。從起步三人開始的實施測試工作，首先測試工程師的工作讓專案經理和上級領導發現並肯定他們的工作成果。通過對比測試人員實施測試後的模組和未實施測試的模組投入商業運營帶來的很大差異，看到軟體修補的高昂費用，提高了領導和專案經理對測試部門的重視程度。逐步擴大測試人員數量，增加測試隊伍的規模，提高測試人員的的福利待遇成為可能。

招聘測試人員時，要把好質量關，國內聯想、華為等公司一般對於測試人員待遇底，重視不夠，我們需要測試認為改變這種錯誤認識，讓優秀的人加入測試隊伍。目前測試部門工程師10個人中有2個留學回國計算機方面碩士，其餘幾人都是計算機或相關學科本科生。儘管經驗方面不夠，但測試人員的素質和專業技能是國內一流的，一段時間測試團隊的努力，這個部門已經成為公司業務開發的至關重要的部門。要不斷提高軟體測試的自動化程度，測試工作不能僅靠手工勞動來完成，更多的情況是要使用工具軟體和編寫測試程式來完成，培養全面的測試專業人才是項任重道遠的工作。

4.6 度量資料

公司最近開始CMM的質量管理體系工作，CMM中比較強呼叫資料說話，對專案過程中基本上所有的資料都會有記錄，最後把收集的資料提交質量保證部門進行分析，以改進流程。但是公司的專案管理定量化工作實施有一定難度，配合華友公司的績效考核，測試部門要求專案經理重視專案中的資料收集，主要包括各種Review資料、測試資料以及專案組員每天的活動資料等。要求專案經理也要維護一個專案檔案，在這個專案檔案中可以說包含了專案開發過程中所有的產出、開發活動、管理活動等的記錄。測試部門提供能夠進行團隊專案開發的CVS或VSS等團隊開發系統，可以這麼說，有了這個專案團隊開發系統，測試經理和專案經理就可以方便了解這個專案的開發過程。

4.7 團隊精神

團隊精神就好比人身體的每個部位，一起合作去完成一個動作。對公司來講，團隊精神就是每個人各就各位，通力合作。我們公司的每一個獎勵活動或者我們的業績評估，都是把個人能力和團隊精神作為兩個最主要的評估標準。如果一個人的能力非常好，而他卻不具備團隊精神，那麼我們寧可選擇後者。公司強調團隊精神、合作精神，應該說，其流程本質上就要求員工之間的互相協調和理解。公司不定期的對經理級別人員進行團隊管理培訓，在對員工不斷進行相關培訓，使員工的合作精神和協調精神都比剛進入公司時有較大提高。

4.8 培訓

公司有專門的培訓人員和培訓費用計劃，每半年會徵集員工培訓需求和建議，然後安排有關主題的培訓活動。在新員工進入公司後都會有公司流程和其他一些公司普遍章程的培訓，以保證員工對流程的理解和執行。對於具體專案，專案經理在制定專案計劃時就會在專案計劃中提出所有的培訓需求，包括技術上的培訓和其他所需的培訓。

4.9 配置管理

在專案正式開展前，專案經理就要制定配置管理計劃，並且指定配置管理員建立起配置管理庫，按配置流程嚴格進行配置管理。在配置流程中也詳細提供了對更改的控制，沒有經過批准的更改請求是絕對不能進行的。

4.10 記錄

記錄及時、充分、比較準確。這些記錄包括:重要的郵件、會議紀要、稽核記錄、缺陷報告、測試報告。

1)提倡與客戶和其他專案組的所有往來必須郵件記錄。
2)對所有的活動都有一個跟蹤落實的過程，比如對所有的Review記錄和更改請求都會有一個狀態標識，標識其當前狀態，通過跟蹤其狀態來監督其落實。
3)對所有的活動，包括對文件和程式碼的更改都會有一個歷史記錄。
4)記錄比較準確、比較客觀。
以上是華友公司在專案管理中所涉及到的一些主要環節，很值得國內的軟體企業在制定專案管理規劃時借鑑。