談項目管理和軟件測試過程

領測軟件測試網 1. 軟件測試在公司的組織保障是基礎

1.1 研發部組織結構介紹 

以華友公司研發部的組織結構為例，測試部門屬于研發部副總裁直接管理，見如下結構圖

公司研發部的組織結構圖 





對于從事軟件研發的組織來說，工作類型至少包括項目管理、產品設計、編碼、測試、質量保證和軟件配置管理，以及其它人員，如文檔編制人員和美工人員/系統硬件管理人員等。根據職能需要，可以以半獨立方式進行部門和項目的矩陣管理，即職員要對項目經理/組長負責，也要對部門經理/總監負責，工作考核由雙方共同完成，標準的組織應包括技術開發部/組（主要是編碼和設計人員），產品開發部/組（產品需求和項目管理），測試部/組，配置管理部/組（因為配置管理人員基本上是按20個技術人員配一個配置管理人員，所以一般部門規模較小，或者只是配置管理組），軟件質量保障部/組，其它部/組（如系統/文檔/美工等）。華友公司組織結構中，研發部是公司軟件研發的核心部門

產品研發Ⅰ部、Ⅱ部、和應用研發部主要負責：



與軟件產品部或內容產品部配合，協助完成內容產品的可行性、合理性分析；

平臺、網關、應用產品的研發項目的立項和方案評審；

研發項目的概要設計、詳細設計工作；

研發項目的編碼、單元測試工作；

組織公司相關部門進行研發產品的培訓；

協助相關部門做好產品的售前技術支持工作；

協助相關部門進行軟件的安裝與調試；

根據相關部門的要求做好產品的售后服務工作，保障軟件的運行正常。 

測試部隸屬研發部，主要職責如下： 

與內容產品部和軟件產品部配合完成軟件需求分析討論，并根據需求說明書制訂《項目測試方案》，編寫《測試用例》，建立測試環境；

負責完成研發部各開發組研發的軟件產品開發過程和投入運營之前的新增軟件和修改升級軟件的模塊測試和系統測試；

建立、推廣并維護實施軟件版本管理系統CVS和VSS；

使用并維護軟件缺陷管理系統Bugzilla，負責軟件問題解決過程跟蹤記錄；

負責推廣實施軟件開發文檔規范化工作，管理研發產品相關文檔；

負責配合軟件運維部門等對于新業務軟件或修改升級業務軟件的上線測試工作，并提供上線測試報告；

負責監督軟件開發流程的執行，并負責提出軟件開發過程改進建議，提高軟件產品質量。 

1.2 軟件產品研發各部門的組織結構分解 

1)華友公司從2003年10月開始，對項目組制訂明確指標的獨立考核，各開發部門是技術總監帶隊，再細分各項目經理具體負責項目計劃和執行，對項目具體開發成員進行分工。對于測試部門制訂年度測試部門任務計劃/考核表，如SMS業務銷售額指標完成：目標1：9900萬（獎金提取比例為0.01％）；目標2：16800萬（獎金提取比例為0.02％）；目標3：23200萬（獎金提取比例為0.03％）

詳細給出財務目標和業務運營目標。 

在每周的開發經理工作會議上交流報告任務進展情況，并提出最近測試需求，測試部門經理負責制訂測試計劃、測試用例和測試實施方案，安排測試工程師與對應的開發人員交流完成測試執行工作。測試部經理負責開發流程管理和人力資源、測試用軟硬件資源調配，需要與研發之外的部門定期交流掌握下周或近期可能測試任務，所有其他外部接口都由測試部經理負責完成，與其他項目組和產品部門協調項目進度。 

2) 工作匯報關系為: 

開發部門：Team Member->Team Leader->研發總監->研發部副總裁->總裁。

測試部門：測試工程師->測試小組經理->測試部經理/總監->研發部副總裁->總裁。 

3）項目成員結構： 

公司通常的開發項目組為6到8個開發人員，最多不超過10人。 

華友公司的經過三次改造后的組織結構和項目組結構，各個業務部門分類非常細，任務明確，軟件開發的每一個步驟都有專門的部門、專門的人員負責，從最基礎的開發人員到負責統領全局的總監和副總裁，層層管理，溝通渠道暢通。而在軟件測試上，由于有限的測試資源，首先體現在公司的組織結構上，集中表現為測試部門不得不面對公司級管理部門的缺失和管理的交叉上，沒有質量管理部門，部門質量管理工作測試部門兼做。公司從成本角度考慮，測試部門規模較小，測試人員總數不超過10人，幾乎每個測試人員接收處理10個開發人員的測試任務需求。從實際情況出發，首先明確測試部門和軟件開發部門相對獨立的組織關系，保證測試人員的工作不受開發小組的控制，實現測試客觀、公證。華友公司要想有效地保障產品質量，首先就要在構架合理的組織結構和測試流程上下功夫，這就如同蓋高樓首先要打好地基一樣，地基不打牢，結構和流程不合理，其他方面再下功夫也是徒勞。 

從實踐經驗看，一年前首先成立測試部，把屬于開發部門的測試工程師歸口到獨立的測試部門管理，其次建立規范的測試流程，與開發部門交流，要求每周提出測試需求，再根據現有的資源制訂每周測試計劃，同時向人力資源部門提出招聘計劃，隨著測試工作的成績不斷被開發部門和上級領導認可，再推廣實施軟件開發過程規范化的管理，通過測試實踐的優良成績來確立測試部門在公司的地位和作用，經過一年的奮斗測試部門從無到有，從最初兩人到現在十人，軟件配置管理和缺陷跟蹤系統已經被60%的開發人員自愿使用和接收。 總結本人在華友一年多測試工作經驗，深深體會到在國內從事軟件項目開發難、從事軟件測試和質量保證工作更難，需要具備扎實的技術功底同時，不斷提高測試項目管理能力，尋找工作的突破口。世上無難事，只怕有心人，但是只要你努力獻身于軟件測試工作，打出一片天地是有可能的。

 


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，能夠發現應用的瓶頸，我們可知應用在網絡上運行時在每個階段發生的應用行為，在應用線程級分析應用的問題�？梢越鉀Q多種問題：客戶端是否對數據庫服務器運行了不必要的請求？當服務器從客戶端接受了一個查詢，應用服務器是否花費了不可接受的時間聯系數據庫服務器？在投產前預測應用的響應時間；利用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)記錄比較準確、比較客觀。

以上是華友公司在項目管理中所涉及到的一些主要環節，很值得國內的軟件企業在制定項目管理規劃時借鑒。

5.1 項目管理存在問題 

總結軟件企業管理中易出現的如下問題，結合我公司在產品開發管理的過程中出現問題總結如下：

1)需求說明差─需求不清楚、不完整、太概括、 或者不可測試，都會造成問題。

2)不切實際的時間表─如果在很短的時間里要求做許多事，出現錯誤是不可避免的。

3)不重視測試─只能根據客戶意見或系統崩潰來判斷系統的質量，整個公司沒有質量管理部門。有些經理認為測試工作是服務工作，只有編寫代碼工作才是生產工作，編程人員待遇高、地位高。

4)不斷增加功能─在開發正在進行過程中要求增加許多新的功能，這是常見的問題。

5)交流問題─如果開發人員對客戶的要求不了解，或者客戶由不恰當的期望，必然會導致錯誤。

6）編寫文檔意識太差─90%的開發人員不愿意花時間寫文檔，項目經理缺少這方面的管理考核要求，喜歡采取多次對話開會等輕松的溝通方式。

5.2 解決措施

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 軟件測試 項目管理