正在閱讀一本很棒的書，《軟件測試經(jīng)驗與教訓》。幾名國外的軟件測試大師，以大量的測試工作實戰(zhàn)經(jīng)驗為出發(fā)點，總結(jié)了深刻而精悍的兩百多條經(jīng)驗。作者把這些經(jīng)驗比喻成為波爾多紅酒，鼓勵讀者分散閱讀，帶入自己的工作實際情境，慢慢細品，深入思考。當然還有，不要獨攤波爾多，分享給我的朋友、同事們！

　　《軟件測試經(jīng)驗與教訓》一書，討論的第一個話題，就是關(guān)于測試人員的角色定位。我對這個話題討論的個人理解是：清晰認識自己的角色定位，能夠幫助測試人員明確對自己工作目標的預(yù)期。而清楚的認識測試人員的角色定位，對于公司、項目的其他成員來說，可以使他們對于測試工作的“期待”更加恰當，即使是“指責”，也更恰如其分。關(guān)于這個話題，以下是對于書中部分經(jīng)驗的理解或討論。

　　“測試員是前燈”

　　研發(fā)經(jīng)理和開發(fā)人員或許正開著一輛吉普，行進在盤山公路上，測試人員的職責就是做好探路的前燈，哪里是懸崖，哪里有險情，前方的路面情況如何……而產(chǎn)品或者項目的關(guān)鍵決策，都是基于這些信息的。測試人員的職責是將關(guān)于這一切的盡可能詳細的信息告知公司或項目的其他成員。

　　是這樣的角色：全面搜集、整理、報告信息

　　不是這樣的角色：決策者

　　“迅速找出重要的程序問題”

　　測試人員很重要的一條使命就是“迅速找出重要的程序問題”。如何做好這點，書中給出了幾條建議。他們看上去很簡單，很質(zhì)樸，似乎每個人都知道，但是在實際工作方法中有經(jīng)常性地提醒自己或者潛意識中就使用這幾條建議么？所謂大道至簡。

　　*首先測試經(jīng)過變更的部分，修改和更新都意味著新的風險

　　*首先測試核心功能，測試產(chǎn)品所完成的關(guān)鍵和常用功能，測試完成產(chǎn)品基本任務(wù)的功能

　　*首先測試能力，即每個基本功能是否能用，然后測試可靠性，即深入檢查每個功能在不同條件下的表現(xiàn)

　　*首先測試常見情況，使用常用的數(shù)據(jù)和使用情境。然后測試特殊情況。

　　*首先測試影響重大的問題

　　*優(yōu)先測試最需要的部分--對團隊其他成員有重要意義的任何部分的任何問題

　　*測試人員對產(chǎn)品、相關(guān)軟硬件、產(chǎn)品的最終用戶越了解，就越可能更快地找出重要問題。

　　“Follow 開發(fā)人員”

　　為開發(fā)人員提供支持，這也是測試人員的一項重要使命。盡可能建立最短、最快的反饋環(huán)路--開發(fā)人員交付產(chǎn)品時，馬上進行測試；開發(fā)人員修改變更代碼后，馬上測試變更的內(nèi)容（trunk版本的測試即是此種情況）。在書中，幾位測試大師認為，最理想的情況是，開發(fā)人員為了修改測試人員發(fā)現(xiàn)的缺陷而忙得團團轉(zhuǎn)，是開發(fā)人員，而不是測試人員，成為項目的瓶頸。當然，老板可能不會認為這個情況理想：）

　　“詢問一切，但不一定外露”

　　多提問。做測試時，遇到的情況千變?nèi)f化，不可能不遇到問題。如果真的連續(xù)地進行測試工作，而沒有任何問題可提，那么不妨暫停一下手上的測試工作，留給自己一些思考的空間，還是那個論斷，不可能沒有問題。

　　書中提到提問的方法，認為直白的提問就如一劑猛藥，會刺激到別人，所以盡量減低劑量，或與米飯同吃（結(jié)合其他溝通形式）。這個的確是個不錯的經(jīng)驗建議，在面對開發(fā)人員、產(chǎn)品需求設(shè)計人員、實施人員等同事時，可以盡量采用這樣的提問方式。當然，在面對測試部門同事、主管時，個人覺得，直接提問會更有效率。

　文檔管理，有些公司也稱為知識庫管理，本文還是以文檔作為稱呼吧。

　　1、先說說文檔管理的歷史背景和演化史吧

　　一般情況下，文檔可以包含很多方面的內(nèi)容，一個Excel表格，一個需求設(shè)計文件，一個Bug的解決方案，一個功能的描述甚至是一個有用的圖片都可以成為一個文檔。所以對文檔的標準解釋就是文檔是軟件開發(fā)，使用和維護中的必備資料。它能提高軟件開發(fā)的效率，保證軟件的質(zhì)量，而且在軟件的使用過程中有指導(dǎo)，幫助，解惑的作用，尤其在維護工作中，文檔是不可或缺的資料。

　　當然文檔不僅僅是在軟件開發(fā)中需要使用，其實是在任何公司中需要用到的，甚至比如在政府單位中也都是用到的，那些法律文件，行政命令，規(guī)范綱要都是文檔，前段時間經(jīng)常在說無紙化辦公，但是文檔其實還是以電子版的形式繼續(xù)存在著，所以說，文檔現(xiàn)在是無處不在，就當前社會在說，文檔是絕對不可或缺的。

　　既然文檔是不可或缺的，必然就會涉及到一個問題，那就是文檔的管理，對于文檔管理的作用，簡單來說就是保存，分類和檢索文檔。從人類發(fā)明文字以后，其實文檔的管理就已經(jīng)開始，從一開始的甲骨文時代到現(xiàn)在的電子時代，文檔的管理一直在不斷進行中，只是形式隨著時代的變化有所變化而已。

　　一開始人類社會可以能是用甲骨文的形式來保存文字，一些有意義的甲骨文就成為文檔，然后需要保存起來讓人需要的時候再去看，但是由于甲骨文是以龜殼的形式保存，你要真的去翻看，我想還是很有難度的，所以那個時候的文檔管理，純粹是實物堆放管理，挺多知道那個相關(guān)的文檔放在那個位置，要具體去找一個內(nèi)容是很麻煩的。

　　后來的呢，人類發(fā)明用竹簡開始作為文檔的記錄載體，但是竹簡其實還是一樣很笨重的，雖然比起甲骨文而言，竹簡記得內(nèi)容可以更多很規(guī)范點，但是要去查找內(nèi)容的時候還是很麻煩。

　　漢朝時，終于紙橫空出世了，世界上最偉大的發(fā)明之一在中國誕生了，大家記錄起知識開始變得很方便，而且很便宜（之前用絲綢記錄雖然也輕巧但是貴），所以文字記錄自此開始幾何級的增長了。很多紙疊在一起變成了書，人類為了方便查找內(nèi)容，還給書做了目錄，真正意義上的文檔管理就開始了。

　　但是雖然對于主要的內(nèi)容可以通過目錄查找到，不過你如果想去用通過查找?guī)讉€關(guān)鍵字的方式來查找一段具體的內(nèi)容的話，電子時代到來之前，還是沒法做的很好，所以當然我也很難在查查這個書庫里（類似少林寺藏經(jīng)樓）是否有我需要的書了，即使找也只能找到一個書名，沒法通過具體一個關(guān)鍵字來查找書了。

　　到了電子時代以后，文檔可以通過以0和1的方式保存在電腦中了，文檔管理有了翻天覆地的變化，人類可以非常便捷地把自己想要的知識找到，而且不僅僅在一本書中，可能是在一個圖書館中的所有書中，甚至是整個世界上的大部分書中，這種階段，已是咱們的先人根本無法想象到的。

　　文檔管理當然也是與時俱進的，有什么樣的條件就能創(chuàng)造什么樣的文檔管理，進入現(xiàn)代文檔管理已經(jīng)變得極其強大，除了最簡單的保存、分類和檢索以外，文檔管理還是加入的安全管理，版本控制，發(fā)布控制以及在線查看，協(xié)作編寫等新的功能。在進入21世紀以后，隨著云計算的出現(xiàn)，文檔管理甚至還加入了云元素。

　　2、DevSuite中的文檔管理

　　文檔管理在任何公司和單位中都需要，但是我想大家也清楚，文檔有些公司做的好，有些公司做的不好，當然有些公司的確不需要很好的文檔管理，比如一個小的施工隊，只要建筑圖紙保存好了就行了。但是大多數(shù)公司我覺得還是需要一個很好的文檔管理的，有些做的不好的原因，我覺得有兩方面原因，一方面原因當然是主觀重視不夠，都認為不需要怎么整理，但是一到需要的時候就急得亂找，最后可能需要重做，影響人力物力和時間；另一方面原因就是缺少一個好的文檔管理系統(tǒng)，文檔如果只在電腦上保存的話，雖然說可以查詢到，但是一旦文檔越來越多的話，文檔管理很有可能越來越混亂，文件亂放文件夾，版本沒法控制，安全性沒法保證，多人同時想來看和修改的話，很難管理，類似添加評論之類的功能就更加沒法實現(xiàn)了。

如何管理好自己的時間

　　時間管理，本身就是一門藝術(shù)。時間是最公平的，每個人的時間都是一樣的。如何在相同的時間里，做出不同的事業(yè)，這就是個人水平的體現(xiàn)。

　　一、故事

　　這里先講一個故事。故事是抄來的，我修改了其中的一部分，使其更貼近我要說的主題。

　　有兩個和尚他們分別住在相鄰的兩座山上的廟里。左邊的山上住著瘦和尚，右邊山上住著胖和尚。這兩座山之間有一條溪，于是這兩個和尚每天都會在同一時間下山去溪邊挑水，久而久之他么變成為了好朋友。兩個和尚都喜歡游泳。胖和尚經(jīng)常在挑水的時候，順便游上那么一會兒，而瘦和尚卻極少在溪水里游泳。

　　不知不覺五年過去了。有一天，瘦和尚竟然沒有帶扁擔來挑水，而是直接在溪里面游泳。胖和尚很納悶，就問瘦和尚，你今天不挑水，怎么有水喝啊。瘦和尚說，這五年來，我每天做完功課后都會抽空在廟后面挖一口井，即使有時很忙，能挖多少就算多少。如今終于讓我挖出井水，我就不用再下山挑水。現(xiàn)在我終于可以放心的游泳了。

　　于是，每天瘦和尚都可以自在的游泳，而胖和尚還是只能游一會兒就得挑水回廟里。突然有一天，兩座廟同時失火了。瘦和尚很快就用井水把火撲滅了。而胖和尚還得跑到溪里面去挑水滅火，結(jié)果火滅的時候，廟已經(jīng)燒掉了一大半了。

　　接下來，胖和尚每天除了要安排時間挑水，還得花大部分時間去修補破廟。而瘦和尚在游泳之余，還潛心書畫。故事完畢。

　　二、重要度/緊急度

　　故事說完了，我們再來重頭分析做事情的順序。

　　根據(jù)重要度和緊急度來區(qū)分事件，是一個非常常用的方法。但是，到底什么叫重要，什么叫緊急呢？

　　重要的事情：對以后的工作生活、對以后的發(fā)展等，會產(chǎn)生明顯的影響的事情，對目標的達成有顯著推動的事情。

　　緊急的事情：需要立即處理的事情。

　　我們按照以上的象限圖，來說一下事件的重要度和緊急度。

　　4：即不重要，又不緊急的事情。

　　即不對以后會產(chǎn)生重要的影響，又不是立即需要處理的事情。類似于和尚的游泳事情。此類事情，一般都是些興趣愛好，或者受人之托，或者偶然的想法。

　　3：緊急不重要的事情

　　只是立即需要處理，但是并不會對將來產(chǎn)生重要影響的事情。類似于和尚的挑水，每天必須做，不做不行，但是做了也就是解決當前問題

　　2：重要不緊急的事情

　　不是當前必須要立即處理的，但是對以后會產(chǎn)生深遠影響的事情。類似于瘦和尚的挖井，不挖也沒事，但是一旦挖成功了，后面就可以不挑水了。如果當前有明確的目標，這類事情可以是對目標達成有明顯幫助的事情。

　　1：重要緊急的事情

　　當前必須處理，不處理會立刻造成很嚴重的后果。類似于和尚們的廟失火，不立刻救火，就沒有住的地方了。

測試職業(yè)困惑案例一：不斷的學習和進步
\　　感謝小A的信任，祝你工作順利、學習進步！

　　問題描述：

　　如何組建性能測試團隊？

　　精彩答案：

　　會員 fatfish：

　　隨著軟件應(yīng)用的越來越廣泛，軟件產(chǎn)品的規(guī)模和使用群體正在呈爆發(fā)式增長，因此性能測試越來越受到軟件供應(yīng)商的重視，此外在某些領(lǐng)域中，對應(yīng)用軟件的性能表現(xiàn)有著顯著的依賴和要求，如軍工、通信、金融、商超等等，這些行業(yè)的應(yīng)用軟件往往會因為一些性能方面的表現(xiàn)不達標導(dǎo)致項目失敗或給用戶帶來災(zāi)難性的損失！所以性能測試逐漸成為了軟件質(zhì)量保障的一個重要組成部分，而相應(yīng)的，如何組建一個高效的性能測試團隊自然就成為了有效進行性能測試的關(guān)鍵。

　　由于歷史原因和現(xiàn)有條件制約，軟件供應(yīng)商可能并沒有獨立的性能測試團隊，性能測試往往揉進常規(guī)的測試部門的工作中了，但我想如有可能，還是盡量能形成一個獨立的性能測試團隊，從而可以更好的開展相關(guān)工作，下面簡單談?wù)勎艺J為比較理想的性能測試團隊的組織構(gòu)成。

　　由于項目的規(guī)模大小不一，因此下文只對理想的組織架構(gòu)作闡述，具體每個分支組織的人員數(shù)量要隨具體情況變化：

　　一）LEADER團隊領(lǐng)導(dǎo)

　　職責：

　　1.制定團隊整體的目標、策略、計劃、流程和制度等工作綱領(lǐng)。

　　2.團隊日常的經(jīng)營管理，如預(yù)算編制、費用控制、人事安排、資源協(xié)調(diào)等等方面。

　　3.對性能測試的結(jié)論以及對產(chǎn)品/項目的質(zhì)量影響作最終的報送及評判。

　　要求：為了體現(xiàn)性能測試的客觀性和重要性，此職位建議相對平行、獨立于常規(guī)的功能測試部門或小組，直接向質(zhì)量總監(jiān)或產(chǎn)品/項目經(jīng)理負責。

　　二）業(yè)務(wù)分析組

　　職責：挖掘產(chǎn)品或項目的業(yè)務(wù)需求中的對于性能表現(xiàn)方面的要求，與客戶、需求人員、顧問等一線人員溝通細節(jié)，再結(jié)合歷史用戶反饋的性能問題和要求作為經(jīng)驗積累，分析出可能涉及性能要求的相關(guān)業(yè)務(wù)場景，據(jù)以設(shè)計出各種性能測試方案以及預(yù)期達到的相關(guān)性能要素指標，盡量達到對用戶真實的、潛在的使用狀態(tài)和強度進行模擬。

　　要求：

　　1、有較豐富的項目經(jīng)驗。

　　2、有很強的分析抽取和概括總結(jié)的能力。

　　3、對IT部署（軟硬件、網(wǎng)絡(luò)布局等）有一定認識。

　　4、對業(yè)務(wù)有一定理解力。

　　三）工具應(yīng)用組

　　職責：

　　1、負責工具選型，即根據(jù)業(yè)務(wù)分析出來的性能測試方案找到適應(yīng)的測試工具（如LR、RPT等）。

　　2、向性能測試具體執(zhí)行人員進行工具應(yīng)用培訓及指導(dǎo)。

　　3、條件允許的話盡可能的開發(fā)創(chuàng)新出專用性能測試工具或?qū)υ瓬y試工具進行有針對性的二次開發(fā)從而使工具更為貼近所測產(chǎn)品的實際情況。

　　4、不斷探索學習前沿、先進的性能測試工具或技術(shù)并嘗試應(yīng)用于所負責的產(chǎn)品提高工作效率。

　前言：

　　關(guān)于敏捷測試這塊內(nèi)容，本來之前一直想寫的，但是自己一直覺得還沒法歸納得很好，不過最近有個客戶到我們公司來拜訪時，也提到了他們公司要把測試這塊工作弄好的事情，談了幾個小時，相互交流了一下意見，總算雙方都有點收獲，所以接下來幾天想結(jié)合我們公司的實際情況介紹一下敏捷測試的一些相關(guān)知識，當然咱的想法也并非很權(quán)威啦，僅供參考。

　　正文：

　　談到敏捷測試，可能有些人不一定聽到過，不過很多人應(yīng)該聽到過敏捷開發(fā)吧，其實從廣義來講，測試也是屬于開發(fā)過程的一部分，測試完成以后開發(fā)過程才算真正完成，所以敏捷測試其實也可以算是敏捷開發(fā)的一部分，之所以大家不怎么關(guān)注，一方面國內(nèi)對測試行業(yè)的關(guān)注度遠遠低于開發(fā)行業(yè)，第二個方面其實也跟第一個相關(guān)，就是敏捷開發(fā)先流行起來，再加上國內(nèi)的開發(fā)、測試比例，所以敏捷測試這個概念就顯得不怎么流行了。不過，情況也在慢慢變化，從我了解到的情況看，越來越多公司已經(jīng)在關(guān)注這一塊了。

　　大家在百度上搜索一把，可以看到敏捷測試的標準定義：

　　首先敏捷測試（Agile testing）是敏捷的一種，原有測試定義中通過執(zhí)行被測系統(tǒng)發(fā)現(xiàn)問題，通過測試這種活動能夠提供對被測系統(tǒng)提供度量等概念還是適用的。

　　敏捷測試是遵循敏捷宣言的一種測試實踐：

　　1、強調(diào)從客戶的角度，即是從使用系統(tǒng)的用戶的角度，來測試系統(tǒng)。

　　2、重點關(guān)注持續(xù)迭代的測試新開發(fā)的功能，而不再強調(diào)傳統(tǒng)測試過程中嚴格的測試階段。

　　3、建議盡早開始測試，一旦系統(tǒng)某個層面可測，比如提供了模塊功能，就要開始模塊層面的單元測試，同時隨著測試深入，持續(xù)進行回歸測試保證之前測試過內(nèi)容的正確性。

　　稍微研究一把，大家就會知道，雖然加個敏捷兩字，其實測試還是原來的測試，以前大家在軟件工程里提到各種測試方法（等價類劃分法、邊界值分析法等等）、測試分類（白盒、黑盒等等）還是繼續(xù)適用的，所以放心，如果你是測試工程師，不懂敏捷測試理論也不會讓你丟了測試工作的，你只要能發(fā)現(xiàn)Bug，發(fā)現(xiàn)好Bug，發(fā)現(xiàn)很多Bug就Ok了。當然對于測試主管甚至再高層就不這么想了，呵呵，為啥原因呢，下面會慢慢為您解答。

　　那既然測試還是原來的測試，那還要敏捷測試干嘛呢，其實跟敏捷開發(fā)一樣，敏捷測試你也需要從它的發(fā)展來理解它。很久很久以前（當然，也不是太久，也就是上個世紀的事情），即使在國外也還沉醉在瀑布開發(fā)中，所以在那個時候，測試呢，就一直躲在開發(fā)過程的最后，產(chǎn)品開發(fā)完成了以后，就開始大規(guī)模測試，測試完成，軟件就發(fā)布了，就像練功夫一樣，一氣呵成，打完收工。

　　當然，后來發(fā)生的事情，我們現(xiàn)在也早已知曉，（唉，歷史啊歷史，人就像歷史長河中的一滴水，如果不能揚名，那唯一結(jié)果就是被蒸發(fā)被遺忘，悲哉！（感慨一下先！））：

　由于信息ERP應(yīng)用系統(tǒng)建設(shè)的特殊性，監(jiān)理單位此階段的重點并不在于對具體工作的檢查、測試，而應(yīng)該放在對承建單位的宏觀監(jiān)督方面。

　　目前國內(nèi)信息ERP應(yīng)用系統(tǒng)建設(shè)過程中，在此階段常發(fā)生承建單位不按設(shè)計階段制定的質(zhì)量保證計劃對編碼工作進行約束檢查，忽視開發(fā)過程的單元測試、集成測試工作等情況。上述情況會導(dǎo)致工程建設(shè)質(zhì)量得不到保證，最終影響到工程的質(zhì)量、進度與資金投入。

　　因此監(jiān)理單位在此階段主要監(jiān)督承建單位嚴格按照工程設(shè)計階段所制定的進度計劃、質(zhì)量保證計劃、系統(tǒng)設(shè)計進行開發(fā)工作，檢查承建單位是否按照設(shè)計中制定的規(guī)范與計劃進行編碼與測試。在此過程中，監(jiān)理單位主要通過代碼走查方式檢查編碼規(guī)范的執(zhí)行情況，檢查單元測試、集成測試和確認測試是否按計劃進行并有測試與修改記錄、集成測試是否按計劃進行并有測試與修改記錄。在此過程中需要檢查測試計劃是否得到落實、測試方案與規(guī)范是否合理、測試是否有詳細記錄并進行修改與回歸測試，必要的情況下可由監(jiān)理單位對測試結(jié)果進行抽檢。

　　對于開發(fā)過程實現(xiàn)階段的監(jiān)理，還需要注意承建單位版本控制方面的工作是否能夠正常進行，是否有專人進行版本的總體控制、開發(fā)人員是否嚴格按照質(zhì)保人員的要求進行具體版本控制，必要的情況下需要對版本控制的工作進行抽檢。但切忌由監(jiān)理單位進行具體測試而取代開發(fā)方的內(nèi)部測試，這種方法并不能保證工程的質(zhì)量。

　　系統(tǒng)測試一般由專門委托的測試機構(gòu)進行，需要對所有軟硬件進行以功能為主的測試工作（必要情況下附加性能測試），需要對測試情況進行記錄并進行錯誤的修改與回歸測試，在測試完成后要根據(jù)測試全過程的情況編寫正式的系統(tǒng)測試報告。

　　在系統(tǒng)的實施階段，承建單位在業(yè)主單位現(xiàn)有條件下進行系統(tǒng)的實施。承建單位制定詳細的實施計劃，進行現(xiàn)場跟蹤，修改實現(xiàn)環(huán)境運行工程中發(fā)現(xiàn)的問題，對用戶進行培訓，制定詳細的維護方案。

　　目前國內(nèi)信息ERP應(yīng)用系統(tǒng)建設(shè)過程中，在此階段常發(fā)生承建單位實施計劃不充分、現(xiàn)場跟蹤不到位、錯誤修改及更新不落實、出現(xiàn)異常情況無法處理、培訓工作不充分、缺少應(yīng)有的維護方案等情況。雖然在前幾個階段的工作可能已基本完成工程建設(shè)的主體工作，但此環(huán)節(jié)工作不到位仍然可能造成工程建設(shè)出現(xiàn)大的問題。

　　因此，在此過程監(jiān)理單位需要對承建單位在現(xiàn)場實施的情況及培訓情況進行監(jiān)督，檢查承建單位是否有詳細的試運行計劃、是否有詳細的現(xiàn)場跟蹤檢驗機制、是否有穩(wěn)妥可行的錯誤修改及更新方案、是否有詳細的異常情況處理辦法、是否有詳細的培訓計劃、是否有詳細的培訓方案、是否有完善的正式運行維護方案。

　　實施階段的監(jiān)理的重點是：協(xié)助業(yè)主方和承建單位處理系統(tǒng)實施期間出現(xiàn)的各項問題，并予以記錄；對于一些重復(fù)出現(xiàn)的問題，在驗收測試時給予必要的關(guān)注，督促承建單位必要的解決措施；監(jiān)督檢查承建單位試運行階段的培訓工作。

　　技術(shù)培訓監(jiān)理的重點是：監(jiān)督承建單位按照合同和業(yè)主的要求制定培訓計劃；審核培訓計劃的可操作性，要求在培訓計劃中明確：培訓對象、培訓教材、培訓時間、培訓方式和培訓師資；監(jiān)督技術(shù)培訓計劃的實施，對培訓教材和師資進行評估，將培訓計劃執(zhí)行情況和效果通報給業(yè)主。

　前言：本篇文章對于軟件管理系統(tǒng)與版本控制系統(tǒng)將作一定介紹，然后再介紹他們之間需要做的集成。

　　1、先來談?wù)劙姹究刂葡到y(tǒng)吧

　　Version Control System，簡稱VCS，屬于軟件配置管理（SCM）的一個部分。這個系統(tǒng)可能對于剛畢業(yè)的大學生來說比較陌生，幾年前甚至對一些企業(yè)來說也比較陌生，簡單來說這個系統(tǒng)主要是為了更好保存并調(diào)用文件（包括文本，代碼，圖像等）的各個版本。那為什么需要用這個系統(tǒng)來保存各個版本呢？

　　這個就需要追述到?jīng)]有版本控制系統(tǒng)之前的歷史了，那個時候也有程序員，也要寫代碼，一開始大家寫了代碼就直接保存，后來發(fā)現(xiàn)一個問題，有一天代碼改錯了，其實前一天的代碼是沒問題的，但是已經(jīng)保存了，沒辦法恢復(fù)到前一天了。怎么辦呢？大家想出一個辦法，你每次做了修改，就必須保存一個副本，以便以后需要。

　　就這樣，那個問題是解決了，但是后續(xù)問題又出來了，每天至少保存一個副本，副本是越來越多，但是一旦有一次我改錯了，想去找原來正確的代碼，我卻沒法一下子找到，因為副本太多了，我怎么知道那個副本里我是主要改了什么東西呢？辦法又出來了，大家每次弄副本的時候，必須再用一個Excel文檔記錄那個副本改了什么，而且每個副本的名字必須統(tǒng)一，是XXX-1，XXX-2這樣子，后綴是版本號。

　　這個問題又解決了，但是新的問題還是不斷出來，我發(fā)現(xiàn)之前代碼沒這個問題，但是現(xiàn)在代碼有這個問題，但是代碼好像沒改啥，我想最好能比較一下，但是一看代碼有幾千行，讓我怎么去比較這2個版本之間的差別啊（后來經(jīng)過千辛萬苦終于找到原因，原來是一個變量初值賦錯了，可能是當初的筆誤），好像很難解決啊！

　　問題繼續(xù)出來，同一個文件可能我在改，別人也在改，最后出了大問題，到底是誰改壞的呢，大家都不承認，因為是同一個源文件，放在同一個地方，大家誰需要的時候就去改，最后就不了了之了，因為根本查不出來的。

　　問題還在出來，我在改這個文件，剛改完覆蓋了服務(wù)器上的那個文件，孰不知有另外一個人也拿了這個文件改其他一個東西，我剛覆蓋完，他也傳上去把我的覆蓋了，最后出問題了說是我的責任，媽的，我明明傳上去了，誰叫他覆蓋了。

　　問題......問題還有很多，怎么解決呢？解決方案就是咱們說的版本控制系統(tǒng)，它的功能主要也就是我上面需要解決的各個問題，當然遠遠不止這些功能啦，以后再慢慢詳說。

　　目前流行的版本控制管理工具有Subversion，Clearcase，Perforce，AccuRev，VSS等等，其中Subversion是免費的，Perforce在美國硅谷那塊用得比較多。

　　2、再來說說軟件開發(fā)過程管理系統(tǒng)吧

　　所謂的軟件開發(fā)過程管理系統(tǒng)，從廣義上來說，需要包括整個軟件工程的所有部分，包括需求分析，概要設(shè)計，編碼，測試和部署與維護，不過今天我們說這個僅僅只包括開發(fā)與測試的階段，也其實就是代碼會一直改動的那段時間（做功能與修Bug）。

　　還是按照上面介紹版本控制管理系統(tǒng)的方法來介紹軟件開發(fā)管理系統(tǒng)。

　　在沒有這個系統(tǒng)之前，我們是怎樣管理咱們的開發(fā)過程（包括修Bug）的呢？一般情況下，領(lǐng)導(dǎo)發(fā)給Email給你說，某某某，今天你把這個功能做了，這就完了，然后出來的問題就是，你有沒有做完，他不來問他就不知道，即使你跟他說了，由于功能太多，他也忘記了。所以呢，大家就想出辦法，分配任務(wù)的時候，需要用Excel文檔來記錄，做什么事情，負責人是誰，什么時候做好的，代碼放在哪里都得記上。

　　這個辦法的確是很好，大家都很興奮，以為一切都控制之中了，但是漸漸地問題又來了，功能很多，Bug又很多，都記錄在Excel文檔上，今天發(fā)我一份，明天發(fā)我一份，我太忙了，都來不及去更新這些內(nèi)容，但是每天還是有新的發(fā)過來，到最后，不知道哪一份Excel文檔是最新的，這個Feature有沒有做，這個Bug有沒有修，我自己都忘記了。

　　三個臭皮匠頂個諸葛亮，大家一合計，有了解決方法，不要這么多Excel文檔了，就一個吧，所有的都記在一個上面，放在一個地方，大家自己上去更新，雖然辦法是好，但是有時候還是忘記去更新。不過經(jīng)常有人提醒我去更新，基本上也沒落下啥。

　　但是不久以后問題還是再次出現(xiàn)了，經(jīng)理想看看某段時間，小張修了多少Bug，做了多少功能，算了好久愣是沒算出來，一看原來是，每個開發(fā)和測試記錄的時間方式都不一樣，有些人喜歡用年月日，有些人喜歡再加具體時間，有些人只用月日，縱是Excel有再強的功能也沒法找出來。

　1、“云測試”簡介

　　云測試是基于云計算的一種新型測試方案，云計算通過網(wǎng)絡(luò)以按需、易擴展的方式向用戶交付所需的資源，包括基礎(chǔ)設(shè)施、應(yīng)用平臺、軟件功能等服務(wù)。

　　云計算包含三種不同服務(wù)類型：SaaS、PaaS和IaaS。SaaS（Software as a Service，軟件即服務(wù)）指的是通過瀏覽器，以服務(wù)形式提供給用戶應(yīng)用程序；PaaS （Platform as a Service，平臺即服務(wù)）指的是以服務(wù)形式提供給開發(fā)人員應(yīng)用程序開發(fā)及部署平臺，讓其利用此平臺來開發(fā)、部署和管理SaaS應(yīng)用程序。平臺一般包含數(shù)據(jù)庫、中間件及開發(fā)工具，所有都以服務(wù)形式通過互聯(lián)網(wǎng)提供；IaaS （Infrastructure as a Service，基礎(chǔ)架構(gòu)即服務(wù)）指的是以服務(wù)形式提供服務(wù)器、存儲和網(wǎng)絡(luò)硬件。這類基礎(chǔ)架構(gòu)一般是利用網(wǎng)格計算架構(gòu)建立虛擬化的環(huán)境，因此虛擬化、集群和動態(tài)配置軟件也被涵蓋在IaaS之中。

　　從云計算的服務(wù)類型來區(qū)分，基于云計算技術(shù)的云測試屬于PaaS層。它是軟件測試工具（包括功能測試工具、性能測試工具等）服務(wù)商提供一個測試平臺，軟件開發(fā)企業(yè)在其平臺上進行相關(guān)自動化測試、不再在本地計算機上安裝和使用這些工具。這種無須本地安裝和配置測試環(huán)境，在遠程測試平臺上進行測試的方式就叫云測試。

　　2、“云測試”的必要性

　　在企業(yè)的信息化建設(shè)過程中，通常需要對軟件全生命周期進行系統(tǒng)化的測試，確定系統(tǒng)過程度量和質(zhì)量度量，保證企業(yè)信息系統(tǒng)有序可控的設(shè)計、開發(fā)和運行，并實現(xiàn)對軟件全生命周期的質(zhì)量控制和過程管理。同時許多應(yīng)用系統(tǒng)的上線運行、升級改造、運行維護都需要進行大量且頻繁的系統(tǒng)測試。在日常的測試工作中，出現(xiàn)因測試資源不足而推遲測試時間、環(huán)境工具配置復(fù)雜而延長測試周期的情況。測試任務(wù)重、成本高、時間緊、人員和軟硬件資源缺乏成為當前需首要解決的問題。

　　針對當前存在的問題，利用云計算技術(shù)可以實現(xiàn)企業(yè)內(nèi)多個團隊的測試平臺共享。在建設(shè)測試基礎(chǔ)設(shè)施方面，云測試可實現(xiàn)巨大節(jié)省，將前期的高額投入分攤到多個測試用戶上，無需擔心大量的硬件、軟件和人力資源成本。

　　云測試提供一整套測試環(huán)境，測試人員登錄到該測試環(huán)境，就可以立即展開測試。這將軟硬件安裝、環(huán)境配置、環(huán)境維護的代價轉(zhuǎn)移給云測試提供者，極大地減少了測試環(huán)境搭建時間，如機器和網(wǎng)絡(luò)準備、操作系統(tǒng)安裝、各種測試工具軟件安裝等，提高了測試效率；在云測試平臺上進行性能測試，可以開啟更多的客戶端，獲得更加強大的運算能力，能夠盡早發(fā)現(xiàn)和應(yīng)對意料之外的流量高峰，讓測試軟件獲得巨大的性能改善。

　　云測試不但可以提供完整的測試環(huán)境，還可以提供許多附加服務(wù)，如提供測試用例、測試數(shù)據(jù)、自動測試服務(wù)等。相比提供虛擬化的測試環(huán)境，此類服務(wù)更專注于特定的業(yè)務(wù)領(lǐng)域，提供了稀缺的專業(yè)技能，附加值更高。

　　3、大型企業(yè)信息系統(tǒng)中的“云測試”應(yīng)用

　　（1）選擇云配置

　　國家標準與技術(shù)研究院（NIST）提出一套關(guān)于云的定義，該定義提出了4種不同的云配置：

　　公共云：公共云的云服務(wù)通常遍布整個因特網(wǎng)，能夠服務(wù)于幾乎不限數(shù)量的、擁有相同基本架構(gòu)的客戶。如Cloud Testing企業(yè)能提供多種瀏覽器的平臺，一般的用戶在本地用Selenium把自動化測試腳本編寫好，然后上傳到企業(yè)網(wǎng)站，就可以在其平臺上運行Selenium腳本。

　　私有云：這種類型的云針對單個機構(gòu)特別定制，例如一些金融機構(gòu)或政府機構(gòu)。私有云都會采用一些虛擬化操作系統(tǒng)和網(wǎng)絡(luò)技術(shù)，因此能夠降低使用服務(wù)器和網(wǎng)絡(luò)設(shè)備的數(shù)量，或者使這些設(shè)備的管理更為明晰。

　　社區(qū)云：社區(qū)云專為一系列互不相連的、嚴格界定的機構(gòu)而設(shè)立，如供應(yīng)鏈或是多個政府機構(gòu)的聯(lián)合體等使用實例。

　　混合云：這種云表現(xiàn)為以上多種云配置的組合，數(shù)個云以某種方式整合在一起，為一些商業(yè)計劃提供支持。有時用戶可能需要用一套單獨的證書訪問多個云，有時數(shù)據(jù)可能需要在多個云之間流動，或者某個私有云的應(yīng)用可能需要臨時使用公共云的資源。

　　結(jié)合大多數(shù)企業(yè)信息系統(tǒng)建設(shè)的現(xiàn)狀，從成本、應(yīng)用、管理、安全性等多方面考慮。私有云在安全性、可擴展性上優(yōu)于公共云，且易于管理，更加適合于企業(yè)的云配置。

　　（2）云測試內(nèi)容

　　目前企業(yè)云測試的測試內(nèi)容主要包括：

　　隨著企業(yè)業(yè)務(wù)和云計算技術(shù)的發(fā)展，為軟件測試服務(wù)的各種應(yīng)用亦將得到發(fā)展，云測試的測試內(nèi)容也應(yīng)即時得到整理和更新。

（3）構(gòu)建云測試平臺

　　依據(jù)云配置，構(gòu)建適用于企業(yè)的云測試平臺應(yīng)分為以下四層：資源層、資源管理層、服務(wù)管理層、訪問管理層。

　　底層是資源層，資源層是構(gòu)建云測試平臺的基礎(chǔ)，它包括服務(wù)器、存儲和網(wǎng)絡(luò)設(shè)施等。資源層由資源管理層管理，負責高并發(fā)量的用戶請求處理、大運算量計算處理、及云數(shù)據(jù)的存儲等。

　　資源管理層監(jiān)控和管理平臺資源的使用情況，迅速反應(yīng)，完成節(jié)點同步配置、負載均衡配置和資源監(jiān)控等工作，確保資源能順利分配給合適的用戶，動態(tài)地部署、配置和回收資源。

　　服務(wù)管理層提供管理和服務(wù)，對云用戶和用戶選擇的云測試服務(wù)進行管理。云測試服務(wù)部署在服務(wù)管理層，是平臺的核心內(nèi)容。

　　最上面一層是訪問管理層，提供云用戶請求服務(wù)的交互界面，根據(jù)用戶請求并轉(zhuǎn)發(fā)到相應(yīng)的程序，是用戶使用云測試平臺的入口。

　　這四層包括硬件和軟件，共同構(gòu)成了云測試平臺。企業(yè)可以將應(yīng)用程序、測試工具部署在平臺中，提高測試的效率。

　　（4）擴展云測試應(yīng)用

　　除利用云測試平臺進行大規(guī)模的用戶模擬外，結(jié)合企業(yè)測試業(yè)務(wù)，還可開展大量的測試應(yīng)用。

　　企業(yè)測試工具集

　　通過將企業(yè)現(xiàn)有的測試工具整合到云測試平臺，可以解決工具資源不足、配置復(fù)雜等問題。若需使用企業(yè)未購買且不經(jīng)常使用的測試工具，還可通過公共云進行一次性的付費測試，降低測試成本。

　　基于企業(yè)的測試知識庫

　　通過測試案例、業(yè)務(wù)知識、測試技術(shù)的積累，形成具有對象性的系統(tǒng)化的測試知識庫。此類服務(wù)更專注于企業(yè)的業(yè)務(wù)領(lǐng)域，可以快速提升測試人員的專業(yè)能力。

　　4、可能存在的問題

　　使用云測試平臺進行測試在很大程度上可以節(jié)約企業(yè)的測試成本、提高人員的測試效率，但是云測試固有的模式?jīng)Q定其在以下幾個方面存在著不足和缺陷，需要靠相應(yīng)的技術(shù)手段來完善和規(guī)避。

　　安全問題（企業(yè)信息安全和網(wǎng)絡(luò)安全）

　　在進行功能測試或性能測試的過程中，軟件如何實現(xiàn)相關(guān)功能的邏輯信息和技術(shù)手段都會部分體現(xiàn)在測試腳本中，軟件的漏洞及性能狀況也將會體現(xiàn)在日志中，若沒有足夠的防護措施造成這些信息的泄漏則對企業(yè)產(chǎn)生不良影響。

　　同時云測試基于網(wǎng)絡(luò)，對網(wǎng)絡(luò)傳輸速率和穩(wěn)定性有較高的要求，網(wǎng)絡(luò)中斷、網(wǎng)速過慢、病毒攻擊等問題都會限制云測試的應(yīng)用。

　　適應(yīng)范圍限制

　　與C/S結(jié)構(gòu)軟件相比，B/S應(yīng)用的軟件更加適用于云測試應(yīng)用。C/S結(jié)構(gòu)軟件仍需在云測試平臺中安裝被測試軟件，實現(xiàn)手段上較為復(fù)雜。

　　對于因保密等原因限制網(wǎng)絡(luò)訪問的軟件，也不適應(yīng)于云測試，需要搭建專有的測試環(huán)境進行軟件測試。