<pre id="ff7yo"></pre>

      <form id="ff7yo"><legend id="ff7yo"></legend></form>
        <nav id="ff7yo"><listing id="ff7yo"></listing></nav><nav id="ff7yo"></nav>

        <nav id="ff7yo"><listing id="ff7yo"></listing></nav>
        <small id="ff7yo"></small><nav id="ff7yo"><dd id="ff7yo"></dd></nav>
      1. <nav id="ff7yo"></nav>
          <form id="ff7yo"></form><nav id="ff7yo"></nav>
          <nav id="ff7yo"></nav>
          <sub id="ff7yo"></sub>
          更多課程 選擇中心

          軟件測試培訓
          達內IT學院

          400-111-8989

          配置管理之持續集成系統知識?這一篇就夠了!

          • 發布:軟件測試培訓
          • 來源:軟件測試問答
          • 時間:2017-08-04 15:48

          雖然持續集成已經講了很多年了,為了保持知識的連貫性,還是總結一篇吧,文中很多內容來自網絡。

          持續集成的目的,就是讓產品可以快速迭代,同時還能保持高質量。它的核心措施是,代碼集成到主干之前,必須通過自動化測試。只要有一個測試用例失敗,就不能集成。

          Martin Fowler說過,"持續集成并不能消除Bug,而是讓它們非常容易發現和改正。"

          為什么要做持續集成

          在《Code Complete》里提到了,對于持續集成(在書中,Steve McConnell使用Incremental Integration的術語)有以下幾點好處:

          ●易于定位錯誤。也就是當你的持續集成失敗了,說明你新加的代碼或者修改的代碼引起了錯誤,這樣你很容易的就可以知道到底是誰犯了錯誤,可以找誰來討論。

          ●及早在項目里取得系統級的成果。因為代碼已經被集成起來了,所以即使整個系統還不是那么可用,但至少你和你的團隊都已經可以看到它已經在那了。

          ●改善對進度的控制。這點非常明顯,如果每天都在集成,當然每天都可以看到哪些功能可以使用,哪些功能還沒有實現。如果你是程序員,你不用在匯報任務的時候說我完成了多少百分比而煩惱,而如果你是項目經理的話,那么你也不再煩惱程序員說完成了編碼的50%到底是個什么概念。

          ●改善客戶關系。理由同上。

          ●更加充分地測試系統中的各個單元。這也是我們常講的Daily Build與Smoke Test相結合帶來的絕大好處。

          ●能在更短的時間里建造整個系統。這點恐怕要你實施以后才能得出結論。就我們而言,持續集成并沒有為每個項目都縮短時間,但卻比沒有實施時,項目更加可控,也更加有保證。

          隨著時間的推移,持續集成帶來的更多好處,也逐漸被認識到了,比如說:

          ●有助于項目的開發數據的收集。比如說,項目代碼量的變化,經常出錯的Tests,經常出錯的source code,等等。

          ●與其它工具結合的持續代碼質量改進。如與CheckStyle, PMD, FindBugs, Fxcop等等等等的結合。

          ●與測試工具或者框架結合的持續測試。如與xUnit,SilkTest, LoadRunner等等的結合。

          ●便于Code Review。在每個build里,我們都可以知道與前一個build之間有什么改動,然后針對這些改動,我們就可以實施Code Review了。

          ●便于開發流程的管理。比如說,要把一個開發的build提交給測試組作測試,測完滿意了,再提交到發布組去發布。

          持續集成實踐

          實踐的意思簡單說就是怎么做。從最初martin fowler 這老爺子的最初文章中有10個實踐,下面我們會一一來講。

          1.維護一個單一的代碼庫

          軟件項目需要大量的文件協同工作來構建出最終的產品。跟蹤所有的文件需要大量的工作,尤其是在多個開發者參與的項目中。因此,我們可以并不驚奇的看到,不同的軟件開發團隊都在開發用于管理這些文件的工具——源代碼管理工具,也叫配置管理,版本控制系統,代碼庫等。這些工具是多數軟件項目不可分的組成部分。然而,令人傷心并吃驚的是,并不是所有的項目都使用了這樣的工具。我的確見到(雖然很少)不使用這些工具的項目,它們使用本地和共享磁盤這種混亂的結合來共同工作。

          因此,做為最基本的持續集成實踐,請保證你使用一款體面的代碼管理系統。成本不是問題,有許多高質量的開源代碼管理工具存在。當前的選擇為Subversion(譯者注:現在有了更新的hg和Git)。(更老的開源工具CVS如今仍然被大量使用,雖然比沒有強,但是Subversion是更現代的選擇。)有趣的是,當我和一些開發者聊天時,我發現相比起多數商業化的代碼管理系統,他們更喜歡Subversion。據我所知,唯一值得花錢買的只有Perforce。

          當你有了代碼管理系統之后,確保每個開發者都能方便的獲得到源代碼。不應該有人還在問:“foo-whiffle 文件在哪兒?”所有東西都必須在代碼庫里。

          雖然許多團隊都在使用代碼庫,但是我經常發現,他們并不把所有東西都放在里面。如果大家需要使用一個文件,他們知道該文件放到代碼庫中,但是,構建所需的所有都應該包含在代碼庫里,包括測試腳本,屬性文件,數據庫模式文件,安裝腳本和第三方庫等。我所知道的有項目將編譯器加到代碼庫中的(對于早期脆弱的C++編譯器來說非常重要)。基本原則是:在一臺新機器上check out代碼后構建也能構建成功。新機器上的東西應該盡量的少,通常包括很大的,難于安裝的,并且穩定的軟件,比如操作系統,Java開發環境或者數據庫管理系統等。

          你需要將構建所需的所有東西都加到代碼管理系統中,同時也需要將大家經常操作的東西方進去,IDE配置便是一個很好的例子,這樣便于大家共享IDE配置。

          版本控制系統的一大功能是它允許你創建多個分支,以此來處理不同的“開發流”。這種功能很有用,但卻經常被過度使用以至給開發者帶來了不少麻煩。所以,你需要將分支的使用最小化,特別建議使用主線,即項目中只有單一的開發分支,并且每人在多數時間里都在“離線”工作。

          總之,你應該將構建所需的所有東西都放在代碼管理系統中,而不應該將構建的輸出放進去。有些朋友確實將構建輸出放在代碼管理系統中,但我認為這是一個壞味道,可能導致更深的問題——通常是你無法完成重新構建。

          1.使構建自動化

          將源代碼變成一個能運行的軟件系統通常是一個復雜的過程,包括編譯,文件搬移,加載數據庫模式等等。但其中大多數任務都是可以自動化的,并且也應該被自動化。讓人去輸入奇怪的命令或點擊對話框是非常耗時的,而且從根本上來說也是個錯誤的做法。

          構建所需的自動化環境對于軟件系統來說是一個通用功能。Unix的Make已經誕生好多年了,Java社區有Ant, .NET社區有Nant,現在又有了MSBuild。當你用這些工具構建和啟動系統時,請確保只使用一個命令完成任務。

          一個常見的錯誤是在自動化構建里并沒有完全包括構建所需的東西。構建過程中應該從代碼庫里取得數據庫模式文件并自動執行之。結合我上文所講的原則來看,任何人都應該能夠在一臺新機器上拉下代碼庫中的代碼,并只用一個命令將系統運行起來。

          構建腳本是多種多樣的,通常特定于某個平臺或社區,但情況并不必須如此。我們的多數Java項目都使用Ant,而另外有些用Ruby(Ruby世界的Rake是一個非常不錯的構建工具)。我們用Ant完成了早期的一個微軟COM工程的構建自動化,并從中大獲裨益。

          大型的構建通常需要很長的時間,而在你只做了很小的修改的情況下,你是不想運行所有的構建步驟的。因此,優秀的構建工具能夠分析出哪些地方需要做相應的修改,并將這個分析過程本身做為整個構建過程的一部分。通常的做法是檢查源代碼和目標文件的修改日期,只有當源代碼的修改日期晚于其對應的目標文件時才執行編譯。依賴關系因此變得微妙起來了:如果一個目標文件發生了修改,那些依賴于它的文件也需要重新構建。有些編譯器能夠處理這種依賴關系,而有些就不見得。

          根據自己的需要,你可以選擇不同的東西進行構建。構建中既可以包括測試,也可以不包括,甚至可以包括不同的測試板塊。有些組件可以進行單獨構建。構建腳本應該能夠允許你針對不同的情形進行不同的構建目標。

          我們大多數都使用IDE,而多數IDE都或多或少地集成了構建管理功能。但是這樣構建文件通常是特定于IDE的,而且非常脆弱。此外,它們需要依賴于IDE才能工作。雖然對于開發者個人來說,在IDE中做這樣的構建配置并無不妥,但對于持續集成服務器來說,一份能夠被其它腳本調用的主構建腳本卻是至關重要的。比如一個Java項目,各個開發者可以在自己的IDE中進行構建,但應該還有一個Ant主構建腳本來保證構建能在集成服務器上順利完成。

          1.使構建自測試

          傳統意義上的構建包括只編譯,鏈接等過程。此時程序也許能運行起來,但這并不意味著系統就能正確地運行。雖然現在的靜態語言已經能夠捕捉到許多bug,但是漏網之魚卻更多。

          一種快速并高效發現bug的方法是將自動化測試包含到構建過程中。當然,測試也不見得完美,但的確能發現很多bug——足夠多了。特別是隨著極限編程(XP)的升溫,測試驅動開發(TDD)也使自測試代碼流行起來,越來越多的人開始注意到這種技術的價值所在。

          經常讀我著作的讀者可能知道我是一個TDD和XP的大粉絲,然而我想強調的是這兩種方法和自測試并沒有必然聯系。TDD和XP都要求先寫測試代碼,再寫功能代碼使測試通過。在這種模式下,測試既用于發現bug,又用于完成系統設計。這是非常好的,但對于持續集成來說不必如此,因為此時我們自測試代碼的要求并不那么高。(然而TDD是我寫自測試代碼的首選。)

          對于自測試代碼而言,你需要一組自動化測試來檢測一大部分代碼庫中的bug。測試能通過一個簡單得命令來運行并且具備自檢功能。測試的結果應該能指出哪些測試是失敗的。對于自測試的構建來說,測試失敗應導致構建失敗。

          過去這些年里,TDD使開源的XUnit家族流行起來,成為了理想的測試工具。在ThoughtWorks,XUnit已經是非常有用的測試工具,我也經常建議人們使用。這組工具起初由Kent Beck開發,它們使自測試環境的搭建變得非常簡單。

          XUnit當之無愧地是你進行代碼自測試的起點。當然,你也應當多看看那些更側向于端到端測試的工具,包括FIT,Selenium,Sahi,Watir,FITnesse等等,我就不逐一列舉了。

          當然,別指望測試就是萬能的。常言道,測試并不代表就沒有bug。

          1.每人每天都向主線提交代碼

          集成首先在于交流,它使其他成員能夠看到你所做的修改。在這種頻繁的交流下,大家都能很快地知道開發過程中所做的修改。

          在向主線提交代碼之前,開發人員必須保證本地構建成功。這當然也包括使測試全部通過。另外,在提交之前需要更新本地代碼以匹配主線代碼,然后在本地解決主線代碼與本地代碼之間的沖突,再在本地進行構建。如果構建成功,便可以向主線提交代碼了。

          在這種頻繁提交下,開發者可以快速地發現自己代碼與他人代碼之間的沖突。快速解決問題的關鍵在于快速地發現問題。幾個小時的提交間隔使得代碼沖突也可以在幾個小時內發現,此時大家的修改都不多,沖突也不大,因此解決沖突也很簡單。對于好幾周都發現不了的沖突,通常是很難解決的。

          在更新本地代碼庫時就進行構建,這意味著我們既可以發現文本上的沖突,又可以發現編譯沖突。既然構建是自測試的,那么運行時的沖突也可以被檢測出來,而這樣的沖突往往是一些特別煩人的bug。由于提交間隔只有短短的幾個小時,bug便沒多少藏身之處了。再者,因為每次提交的修改都不多,你可以使用diff-debugging來幫你找出這些bug。

          我的基本原則是:每個開發者每天都應當向代碼庫進行提交。在實踐中,越是頻繁提交,可能導致沖突的地方就越少,因而也越容易發現。

          頻繁提交鼓勵開發人員以幾個小時為單位來分割他們的代碼,這樣便于跟蹤進度。通常,人們一開始認為在短短的幾個小時內做不了什么事情,但我們發現找個導師和多實踐可以幫助他們學習。

          1.每次提交都應在集成機上進行構建

          有了每日提交,也就又了每日測試,這應該表明主線處于健康狀態。但是在實踐中,的確有出錯的時候,原因之一在于紀律——有人并沒有在提交之前進行本地更新和構建。另外,不同開發機之間的環境不同也是一個原因。

          因此,你應該保證在集成機上進行構建,只有當集成機上構建成功后,才表明你的任務完成了。由于提交者需要對自己的提交負責,他就得盯著主線上的構建,如果失敗,馬上修改。如果下班之前你提交的修改失敗了,那么,對不起,請修改好了才回家。

          我見到過兩種方式來保證主線構建的成功:一是手動構建,二是使用持續集成服務器。

          手動構建是最簡單的,基本上與開發者在本地做的構建差不多——先到集成機上拉下主線的最新代碼,然后運行構建命令,在構建過程中你得盯著構建過程,如果構建成功,表明你的任務完成。(另見Jim Shore的描述。)

          持續集成服務器則一直監視著代碼庫,一旦檢測到有提交,便自動拉下代碼到本機,然后開始構建,并將結構通知提交者。只有當提交者收到通知后——通常是以電子郵件的方式,才表明自己的任務完成。

          在ThoughtWorks,我們是持續集成服務器的忠實粉絲,我們領導了CruiseControl和CruiseControl.NET的初期開發,此兩者均是廣為使用的CI服務器。從那時起,我們也開發了商業化的Cruise。在幾乎每個項目中,我們都使用了CI服務器,并且結果是令人愉悅的。

          不是所有人都傾向于使用CI服務器的,Jim Shore便給出了一個很好的論述,在此論述中,他解釋了為什么他更傾向于手動構建。我同意他的看法——CI不過是安裝一些軟件而已,所有的實踐都應當旨在有效地完成持續集成。但同樣,許多使用CI服務器的團隊的確發現CI服務器是很好的工具。

          有很多團隊定期的進行構建,比如每晚構建。這和持續構建并不是一回事,而且對于持續集成來說,也是不夠的。持續集成的關鍵在于盡快地發現問題。而每晚構建意味著整個白天都發現不了bug,如此,需要很長的時間發現并清楚這些bug。

          持續構建的重點在于,如果主線構建失敗,你應該馬上進行修改。在持續集成中,你一直是在一個穩定的代碼庫基礎上進行開發。主線構建失敗并不是一件壞事,但是,如果這樣的情況經常發生,那么就意味著開發人員對于本地更新并沒在意或者在提交之前并沒在本地構建。主線構建一旦失敗,必須馬上修正。為了避免主線構建失敗,也許你可以試試 pending head。

          1.快速構建

          持續集成的關鍵在于快速反饋,需要長時間構建的CI是極其糟糕的。我的多數同事都認為一個小時的構建時間對于CI來說決無道理可言。我也記得曾經有團隊夢想著他們的構建能有多么多么的快,但有時我們不得不面對很難快速構建的情況。

          對于多數項目來說,將構建時間維持在10鐘之內是合理的,這也是XP的方針之一,我們多數項目也達到了這個目標。這種做法是值得的,因為這樣省下的時間是為開發者節約的。

          如果你的構建長到了一小時,那么想使其加速便不是那么容易了。對于企業級應用來說,我們發現構建時間的瓶頸通常發生在測試上,特別是那些需要于外部交互的測試——比如數據庫。

          可能最好的解決辦法是引入階段性構建(也叫構建管道或者部署管道),因為構建事實上是分階段性的。代碼提交后首先觸發的是構建稱為提交構建,提交構建應該快速完成,而棘手的是怎么保持速度與查找bug之間的平衡。

          提交構建成功后,其他人便可自信的工作了。但是,你可能還有其它跑得比較慢的測試需要寫,這時可以用額外的機器來專門跑這些耗時的測試。

          一個簡單的例子是將構建分為兩個階段,第一個階段完成編譯,并且跑那些不需要外部交互的單元測試,數據庫交互也通過stub的方式完全消除掉。這些測試可以很快跑完,原則是將其保持在10分鐘之內。但是,對于那些需要大量外部交互——特別是涉及到真實數據庫交互時才能發現的bug,這個階段便無能為力了。第二個階段跑的測試則需要操作真實的數據庫了,同時還應包括端到端測試。這個階段可能需要幾個小時。

          在這種情況下,通常將第一階段視為提交構建,并將此做為主要的CI周期。第二階段則可在有必要時才進行,如果這個階段構建失敗,它也不需要像第一階段那樣“停下全部手頭的工作”,但也應該得到盡快的修改。第二階段的構建不見得需要保持一直通過,對于已經發現的bug來說,可以在之后幾天修改。對于這個案例來說,第二階段全是測試,因為通常情況下最慢的即是測試。

          如果第二階段構建發現了bug,通常意味著應該在第一階段中引入新的測試來予以保證。

          當然,以上的兩階段構建只是一個例子,你完全可以加入多個構建階段。提交構建之后的其它構建是可以并行完成的,如果這些階段的構建需要好幾個小時,那么可以用幾臺機器來并行完成。通過這種并行化,你可以將提交構建之外的所有測試都引入到構建過程中來,比如性能測試。

          1.在與生產環境的拷貝環境中運行測試

          測試旨在發現可能在生產環境中出現的問題,因此如果你的測試環境與生產環境不同,那么測試很有可能發現不了生產環境中的bug。

          因此,你的測試環境應該盡量與生成環境相同。使用相同的數據庫,相同的操作系統,并且版本都應該一樣。另外,將生產環境中的庫文件也放到測試環境中,即使構建時用不到這些庫。IP地址和端口號也應當相同,當然還包括硬件。

          但事實上這是有限制的。如果你開發的是桌面軟件,很難預測你的客戶在使用哪些第三方庫。再者,生產環境可能非常昂貴。即便存在這么多限制,你依然應當盡量去復制生產環境,并熟知因測試環境和生產環境的不同而可能導致的風險。

          如果你搭建的環境足夠簡單并沒有多少煩人的外部交互,那么你的提交構建便可在仿真環境中進行。但是,由于系統反應慢等原因,你可能需要test doubles。因此,通常情況是在人工環境下跑提交構建以獲取速度,而用一個生產環境的拷貝環境來跑其它測試。

          我注意到,虛擬化技術越來越引起人們的興趣。由于虛擬機可以保存構建所需的所有東西,故在虛擬機中運行構建和測試相對比較容易。另外,虛擬機技術也允許你在一臺機器上運行多個測試,或者可以模擬多臺機器同時訪問網絡的情況。隨著虛擬機性能逐漸提升,它將引起更多的注意。

          1.使任何人都能輕易獲得可執行文件

          軟件開發最困能的事情之一便是你不能保證所開發的是正確的軟件。我們發現人們往往很難預知自己究竟想要什么,而相反,對已有的東西進行評判和修改卻容易的多。敏捷開發過程則恰恰是符合人類這種行為習慣的。

          為此,項目中的所有成員都應能夠獲得最新的可執行文件并能成功的運行,目的可以包括做演示,瀏覽測試或者僅僅看看項目本周有何修改。

          這是很容易達到的:確保一個通用的地方來存放最新可執行文件。在同一個地方存放多個可執行文件也是很有用的。對于最新的可執行文件,應當保證能夠通過提交測試。

          如果你的開發過程有一個很好的迭代計劃,將每次迭代最后一次構建生成的可執行文件存放起來也是明智的做法。

          1.人人都能看到正在發生什么

          持續集成主要在于交流,因此應當保證每人都能輕易看到當前系統的狀態和已做的修改。

          主線的構建狀態是非常重要的,Cruise服務器包含一個網站,你可以在該網站上看到當前的構建狀態和最后一次主線構建的結果,許多團隊喜歡用比較顯眼的標識來反應構建狀態,比如在屏幕上放一盞燈,燈綠表示構建成功,燈紅表示失敗。尤其常見的是lava lamps——不僅表明構建狀態,還可顯示構建時間。如果紅燈中有了氣泡,則表明構建已經失敗了很長一段時間了。每個團隊都有自己的選擇,當然,適合自己的才是最好的。

          對于手工完成的持續集成過程,這種可見性也是很重要的,構建機器的顯示器應該能顯示主線構建的狀態。通常,正在做集成的人會放一個token在桌上來表明他正在做集成。人們喜歡在構建成功后播放一些簡單的聲音,比如鬧鈴之類的。

          當然,CI服務器的網站可以展示更多的信息。Cruise不但能可以顯示是誰在構建,并且能顯示最新提交的修改。另外,Cruise還可以查看提交歷史,這樣,團隊成員便可以很清楚項目的進展情況。據我所知,有些團隊的頭便是通過這種方式來了解項目成員的工作情況和整個系統的修改情況。

          使用CI網站的另一個好處是,哪怕不在一起工作的人都可以看到當前項目的狀態。再者,你也可以將不同項目的構建信息放到一起。

          并不是只有CI網站才能展示顯示構建信息。由于構建的不穩定性是一直存在的,這時我們可以將全年的日歷畫在一張墻上,每天對應一個方塊,如果構建成功,QA則在該天的方塊貼上綠色標簽,否則貼上紅色標簽。時間一久,這份日歷便可顯示出項目的穩定性進展情況。

          1.自動化部署

          做持續集成需要多種環境,不同的構建階段需要不同的環境。每天,項目的可執行文件都會在這些環境之間搬來移去,于是你希望將這些過程自動化。因此,自動化部署腳本便很重要了,不僅包括測試環境的腳本,也包括針對生產環境的部署腳本。雖然我們不是每天都向生產環境部署,但自動化部署不僅可以加速部署過程,并且能夠減少部署錯誤。

          如果你已經有了生產環境的自動化部署,那么也應該考慮一下相應的自動化回滾。由于失敗是時而會發生的事情,在這種情況下,我們希望能快速回滾到失敗之前的狀態。這樣一來,我們在部署是也不用那么畏首畏尾了,于是我們可以頻繁的發布軟件,用戶亦能盡快的享受到新的功能。(Ruby on Rails社區有一款名為Capistrano的工具即是一個典型的例子。)

          在集群環境中,我看到有每次只向一個節點部署的情況,由此在幾個小時之內逐漸完成所有節點的部署。

          對于一些面向大眾的web應用,我所了解的另外一種很有趣的部署方式是,先試驗性針對一部分用戶進行部署,再通過這些用戶的試用情況來決定是否向所有用戶部署。自動化部署,做為CI的一項原則,能夠很好的勝任這些工作。

          持續集成的難點

          持續集成有那么多好處,實踐起來的思路也很清晰,那么為啥還有那么多的團隊做得不夠好呢?做好持續集成有很多難點,下面將會分析一下。

          1.很多維護期的產品分散于很多代碼庫或者很多分支,難以統一維護

          這種情況尤其會出現在那些已經存活多年,卻依然為公司帶來利潤的軟件產品上。另外一種情況就是,公司收購來的軟件產品,因為歷史原因,也很難整合到一起。

          2.自動化測試

          這是最難的。實話實說,我們可以扭過頭看看周邊的團隊,自動化測試的程度到底如何。我覺得80%以上的項目在這一點上都做得不好。之所以很難做好自動化測試,A)有軟件產品自身架構組織的原因。比如軟件架構耦合度很高或者過于分散,難以自動化測試。 B)也有軟件產品形態的原因。比如如果軟件產品主要提供的是接口或者明確的服務,那么則比較容易自動化;如果產品主要是web界面,這自動化測試起來相對比較難。C)還有一個很重要的原因就是自動化測試的維護成本。自動化測試用例不是一蹴而就的。在寫業務代碼的同時,還要完成相應的測試用例。這是需要成本的。團隊是否有精力和時間去做這件事?一開始也許還好說,一旦業務壓力上來,就會發現很多測試用例過不去,最后也就不了了之。

          3.快速構建

          構建是需要花費時間和成本的。有硬件上的因素,也有語言上的因素,還有軟件架構的因素。

          4.

          o我們愿意花多少錢去買機器做這件事?當有的公司早已經用頂配垃圾桶編譯自己的APP了,還有的公司用那種不是SSD的mac mini 硬撐。這就是差距。

          o有些系統是php,ruby,python等解釋型語言的,有的僅僅需要壓縮、混淆打包一下就可以上線了,這速度當然快;但是還有很多系統用的是C/C++,golang等,這就相對比較耗時。這是語言上的因素。

          o軟件架構。這對構建時間影響也很大。比如一個大的C++系統,如果模塊相對比較獨立,互相依賴少,則完全可以把整個產品劃分成很多個小的模塊,進行并行編譯。那么最終整體的時間就由耗時最長的那個模塊決定了。一下子就可以把整體構建時間降下來。

          o有很多的并行分布式構建系統是收費的,這就涉及到一個許可證購買到問題。

          5.很多環境難以模擬

          雖然現在有些公司的產品就是一個網站,一個app;但是不得不說還有很多銀行的大型系統存在著。這些公司的線上系統就一套,很難找到一個預上線環境,很多都是寫好了,直接線上測試。出錯很難避免。

          6.雖然我們現在可以使用更好更強的CPU,更大的內存,更快的存儲(如SSD),并行構建、分布式構建去加速我們的構建過程,這些都是顯性的看得到的成本;而要花很多時間去做的自動化測試,則要花費很多的人力成本在上面;而對于有些特殊行業,有的時候是很難找到一個預生產環境的,這就很尷尬了。

          小結

          剛開始做持續集成容易,真的做好還是需要下一番功夫的。

          縮寫解釋:

          EE : Electrical Engineering,電子工程 俗稱EE或Double E

          CS : Computer Science, 計算機科學

          SWE : Software Engineering, 軟件工程

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:軟件測試過程中的要注意什么?
          下一篇:測試高手是如何進行測試工作的?
          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          神马影院-战旗影院-首播影院-新视觉影院-在线观看中文字幕dvd播放 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>