後端伺服器集群測試需要注意什麼

㈠ 分布式系統的分布式系統的測試

· 在測試執行過程中，對測試結果的分析是一個需要進行深入思考的重點問題。分布式系統測試的重點在於對後端伺服器集群的測試，而判定系統中是否存在Bug則是我們需要解決的重要問題。那麼應該如何確定是否存在Bug呢？
對於測試結果的分析，我們通常觀察下面幾種情況。
觀察前端應用的返回結果。這里需要分兩種情況來考慮：第一，按照前端應用業務功能點及流程進行操作，觀察返回結果是否符合業務方的需求預期；第二，操作後端的伺服器（通常是重啟、宕機、斷網等操作），觀察前端應用的返回結果是否符合系統的設計需求。
分析伺服器日誌。在功能測試過程中，當我們在啟動伺服器的時候，需要將日誌級別定義為Debug級別（最低級別）。這樣做的主要目的是為了能便於測試工程師來分析日誌和定位問題。為了能更好地定位問題，常常需要在伺服器程序代碼中進行日誌打樁，把程序中的一些重要數據通過日誌的方式展現出來。通常情況下，我們需要對日誌的格式進行約定，在日誌行中增加一些關鍵字來進行分類，這將便於測試工程師進行日誌分析，也有利於開展分布式系統的自動化測試。另外，值得注意的是，我們盡可能地將打樁代碼放在Debug代碼中，避免影響系統代碼，引入新問題。
分析操作系統的一些重要信息。我們測試的分布式系統絕大多數是基於linux操作系統開發的，在測試的過程中，除了詳細分析程序日誌以外，還需要對操作系統的一些重要數據信息進行分析，從而來診斷伺服器程序是否存在異常。以Linux操作系統為例，我們常常會使用top命令、netstat命令及sar命令來查看操作系統的一些數據信息。例如，可以通過netstat命令檢查伺服器程序是否正確地監聽了指定的埠等。
藉助其他分析工具。例如，如何判斷伺服器程序是否產生了內存泄漏？通常需要藉助於內存檢測工具來進行分析。在Linux環境下，我們常用Valgrind來進行內存檢測。這是一款非常好用、功能強大的分析工具，可以幫助測試或者開發工程師快速發現很多隱藏的程序Bug，尤其是在內存檢測方面（同時它還具有很多其他優秀的功能，讀者可以自己查看官網中的使用手冊）。 對於分布式系統而言，壓力測試和性能測試非常重要。在進行壓力測試和性能測試的時候，可能會碰到下面一些難點。
數據准備。如何准備海量的測試數據並保證模擬數據的真實性？以一個分布式的文件系統為例，預先存入100GB的數據還是存入100TB的數據、存入的文件是大小基本一致差別不大還是各不相同甚至差異很大（例如，從幾十位元組至幾十兆位元組不等），這些因素對於分布式系統的性能影響是有很大差異的。另外，如果需要預先存入100TB的數據，若按每秒寫入100MB數據來計算，寫入100TB數據需要100×1024×1024/100=1048576秒=291.27小時=12天。我們是否能忍受這么長時間的數據准備工作？為了解決這樣的問題，我們需要對系統架構設計進行深入分析，設計好測試場景，並提前進行測試用例的設計，以盡早開始准備測試數據。
性能或壓力測試工具。通常來說，分布式系統的測試需要開發一些測試工具來滿足性能測試的需求。如果可以的話，建議這樣的測試工具最好由測試工程師自己來實現，因為測試工程師更清楚自己的測試需求。當需要自己開發測試工具的時候，有兩個關鍵問題需要重點關註：第一，一些關鍵數據的收集方式與計算將成為性能測試工具的關鍵，例如，TPS（每秒請求數）、Throughput（吞吐量）計算的准確性；第二，要保證性能測試工具的性能，如果工具本身的性能不好，將無法給予分布式系統足夠強大的壓力來進行測試。另外，當考慮到多並發（例如有10萬客戶端同時並發連接）時，如果性能測試工具在一台測試機器上只能運行50個或者更少的話，那麼需要的測試機器數量也將會很龐大（例如2000台測試機），這個成本或許是許多公司不能承受的。因此，性能測試工具本身的性能必須要足夠好才能滿足需求、降低測試成本。 自動化測試是測試行業發展的必然趨勢，對於分布式系統測試而言也不例外。在實施分布式系統自動化測試的過程中，我們可能會碰到下面兩個難點問題。
涉及平台多且硬體雜，測試流程式控制制困難。在實施自動化測試的過程中，測試腳本需要控制的操作系統和應用程序很多，而且存在跨平台的特性，同時還有可能需要控制一些網路設備。因此，選擇一個優秀的自動化測試框架成為了非常重要的工作之一。以我們的實踐經驗來看，STAF是一個不錯的選擇，它的平台（Windows及Linux各版本）支持及開發語言的支持都很全面。
測試結果驗證復雜。對於分布式系統的自動化測試來說，我們需要通過測試腳本來收集各種測試結果數據以驗證測試結果的正確性。在實施自動化測試的過程中，我們可以將測試結果數據收集部分模塊化，通過各子模塊來檢測各項數據是否正確。例如，我們會設計一個日誌分析模塊，主要負責從伺服器應用程序的日誌中收集相應數據進行對比驗證（本文前面提到的在打樁日誌中增加關鍵字部分就顯得格外重要）。
隨著互聯網的發展，大型分布式系統也越來越多、越來越復雜、越來越重要。如何有效地保證大型分布式系統7×24小時全天候持續穩定地運行也就成為了一個重要課題。

㈡ web測試中對客戶端和伺服器的性能測試都涉及到什麼

這種就類似於雲計算等後端基礎服務的測試，對於一些大的公司，會有一個專門的團隊來開發這種後端基礎服務，這種服務當然也需要測試人員來保證質量。

這類服務一般都是通過HTTP介面的方式提供給剛才講的WEB／APP的後端使用，所以，第一個要做的也就是介面測試，也就是用Postman等工具做手工測試、用TestNG＋HttpClient或者Python的Nose框架做自動化測試。

不過，對於這類後端服務來說，介面只是暴露給外用的部分，內部邏輯通常是非常復雜的，所以，除了針對介面做測試之外，測試人員還需要細致地了解這些服務端產品的技術框架及技術實現，需要了解到模塊的級別，對於系統框架圖、時序圖等都有很好的理解。針對這些理解去設計用例，再跟開發一起討論如何實現用例。

如果這種基礎服務用了某一個開源軟體，那通常也需要測試人員能關注社區的進展，並把我們發現的Bug及解決方案等推到社區，為社區做貢獻。

除了介面測試之外，在我們公司，異常測試、穩定性測試、性能測試也是服務端測試必備的測試類型。
異常測試會模擬各種異常情況，比如硬體異常－機器掛掉的情況下能否啟動備機、硬碟掛掉的情況下是否會丟失數據；網路異常－網路忽然斷掉、或者網路流量變小的情況；系統異常－操作系統忽然掛掉的情況。這些極端的情況出現的時候，我們需要驗證數據有沒有丟、能不能盡快啟動備機對外提供服務、系統狀態有沒有異常等。我們會採用各種方式或者工具來模擬這些異常，比如用TrafficControl工具來控制網路流量。

穩定性測試，就是模擬系統在7*24的運行下會不會出問題，一般會用介面測試或者性能測試用例不斷地跑，在運行期間，我們會模擬各種情況，比如說負載的變化、系統的各種干擾等。可以用ChaosMonkey等工具來進行這類測試。

性能測試，其實細分起來會有各種類型，比如負載測試、壓力測試、配置測試、甚至還有線上壓測、容量規劃等。最常規的性能測試，一般是先規定一個系統需要承受的壓力，比如說，某一個系統，1個小時之內會有1W單的單子，那基於這個需求我們分析伺服器後端需要承受的壓力，分析出來以後，就寫性能測試腳本，然後逐漸增加壓測的力度，直到超過這個預定的壓力。通常在這個測試過程中會發現各種問題，比如資料庫索引沒有建、線程池太小、系統異常等。需要解決了之後再加大壓力測試。也是用Grinder／JMeter等工具來進行性能測試，不過難的不是這些工具的使用，而是發現問題以後的定位。

對於這種後端服務的測試人員來說，技術上的要求是挺高的，需要有較好的編程能力，需要對資料庫、操作系統等機制有很好的了解才行。

㈢ 什麼是伺服器集群伺服器集群的缺點和優點是什麼

出現任何故障，如：硬碟、內存、CPU、主板、I/O板以及電源故障，運行在這台伺服器上的應用就會切換到其它的伺服器上。

二、集群系統可解決軟體系統問題，我們知道，在計算機系統中，用戶所使用的是應用程序和數據，而應用系統運行在操作系統之上，操作系統又運行在伺服器上。這樣，只要應用系統、操作系統、伺服器三者中的任何一個出現故障，系統實際上就停止了向客戶端提供服務，比如我們常見的軟體死機，就是這種情況之一，盡管伺服器硬體完好，但伺服器仍舊不能向客戶端提供服務。而集群的最大優勢在於對故障伺服器的監控是基於應用的，也就是說，只要伺服器的應用停止運行，其它的相關伺服器就會接管這個應用，而不必理會應用停止運行的原因是什麼。

三、集群系統可以解決人為失誤造成的應用系統停止工作的情況，例如，當管理員對某台伺服器操作不當導致該伺服器停機，因此運行在這台伺服器上的應用系統也就停止了運行。由於集群是對應用進行監控，因此其它的相關伺服器就會接管這個應用。

集群系統的不足之處在於：

我們知道集群中的應用只在一台伺服器上運行，如果這個應用出現故障，其它的某台伺服器會重新啟動這個應用，接管位於共享磁碟櫃上的數據區，進而使應用重新正常運轉。我們知道整個應用的接管過程大體需要三個步驟：偵測並確認故障、後備伺服器重新啟動該應用、接管共享的數據區。因此在切換的過程中需要花費一定的時間，原則上根據應用的大小不同切換的時間也會不同，越大的應用切換的時間越長。

㈣ 伺服器配置選擇需要注意哪些方面

伺服器配置選擇需要注意的有：

1、可擴展性

伺服器必須具有一定的「可擴展性」，這是因為企業網路不可能長久不變，特別是在當今信息時代。如果伺服器沒有一定的可擴展性，當用戶一增多就不能勝任的話，一台價值幾萬，甚至幾十萬的伺服器在短時間內就要遭到淘汰，這是任何企業都無法承受的。為了保持可擴展性，通常需要在伺服器上具備一定的可擴展空間和冗餘件（如磁碟陣列架位、PCI和內存條插槽位等）。

可擴展性具體體現在硬碟是否可擴充，CPU是否可升級或擴展，系統是否支持WindowsNT、Linux或UNIX等多種可選主流操作系統等方面，只有這樣才能保持前期投資為後期充分利用。

2、易使用性

伺服器的功能相對於PC機來說復雜許多，不僅指其硬體配置，更多的是指其軟體系統配置。伺服器要實現如此多的功能，沒有全面的軟體支持是無法想像的。但是軟體系統一多，又可能造成伺服器的使用性能下降，管理人員無法有效操縱。所以許多伺服器廠商在進行伺服器的設計時，除了在伺服器的可用性、穩定性等方面要充分考慮外，還必須在伺服器的易使用性方面下足功夫。

伺服器的易使用性主要體現在伺服器是不是容易操作，用戶導航系統是不是完善，機箱設計是不是人性化，有沒有關鍵恢復功能，是否有操作系統備份，以及有沒有足夠的培訓支持等方面。

3、可用性

對於一台伺服器而言，一個非常重要的方面就是它的「可用性」，即所選伺服器能滿足長期穩定工作的要求，不能經常出問題。其實就等同於Sun所提出的可靠性（Reliability）。

因為伺服器所面對的是整個網路的用戶，而不是單個用戶，在大中型企業中，通常要求伺服器是永不中斷的。在一些特殊應用領域，即使沒有用戶使用，有些伺服器也得不間斷地工作，因為它必須持續地為用戶提供連接服務，而不管是在上班，還是下班，也不管是工作日，還是休息、節假日。這就是要求伺服器必須具備極高的穩定性的根本原因。

4、易管理性

在伺服器的主要特性中，還有一個重要特性，那就是伺服器的「易管理性」。伺服器雖然在穩定性方面有足夠保障，但也應有必要的避免出錯的措施，以及時發現問題，而且出了故障也能及時得到維護。這不僅可減少伺服器出錯的機會，同時還可大大提高伺服器維護的效率。其實也就是Sun提出的可服務性（Serviceability）。

伺服器的易管理性還體現在伺服器有沒有智能管理系統，有沒有自動報警功能，是不是有獨立與系統的管理系統，有沒有液晶監視器等方面。只有這樣，管理員才能輕松管理，高效工作。

(4)後端伺服器集群測試需要注意什麼擴展閱讀：

伺服器維護保養：

1、注重機房環境的建設

機房環境對伺服器的正常運轉有著重要的影響作用。因此，伺服器維護和保養的首要環節就是做好機房環境建設。機房要保證充足的空間，用以安裝和配置伺服器的相關設備，機房的隔斷，地板等要組好防靜電等細節處理。機房的防火工作也很關鍵，要做好牆面和電纜等的防火處理。一旦遇到火情等，如何保障設備的安全，如何保障人員的有序撤離等都是機房建設中需要考慮的因素。機房的溫度和濕度也應當操持在一定的范圍，溫度和濕度對於電子產品的正常工作有著非常大的影響作用。

2、做好硬體維護工作

伺服器的硬體組成較為復雜，對於伺服器硬體的維護應由專業人員進行。在維護和保養存儲設備時，我們首先應當對其容量進行測試，看是否需要進行擴容等操作。存儲容量一定要能滿足任務的需求，並留有一定的冗餘量。在拆卸和更新伺服器設備時，務必讓設備處於斷電狀態並進行接地處理。即便是更換最簡單的部件，這些環節也不能省略。對於一些不熟悉的部件，要反復仔細的閱讀說明書和參照文件，在沒有十足把握的前提下切忌盲目拆解。要定期對伺服器進行除塵處理。

3、維護好伺服器軟體

軟體是伺服器的重要組成部分，伺服器的穩定高效運行離不開相應的軟體。我們要定期對伺服器的軟體系統進行巡檢，及時發現漏洞，及時安裝官方給定的補丁程序。在擴展伺服器資料庫時，在條件允許的情況下，最好對原有數據進行備份，以免造成不必要的損失。

4、做好電力控制

沒有穩定的電力保證，伺服器就沒有辦法正常工作。電子控制是一個非常關鍵，但又非常容易被忽視的問題。在機房建設之初，我們就應當充分考慮到伺服器的電力保障。要為機房設計和配置一套穩定，可靠的電力供應系統。這套系統還要有處置和應對突發事件的能力，例如，不可預知的停電、雷電等。

5、密碼管理

伺服器的密碼管理是伺服器防禦能力的最關鍵組成部分。密碼的管理和更換應當形成一套長效機制。我們要定期對伺服器的密碼進行更換，密碼應有專人管理。選用的密碼要有一定的專業性，一定的復雜度，最好是將數字和字母等結合起來，大小寫也要融合進去。在日常的檢查中，我們要做好登統計，關閉一些不太使用的埠。

㈤ 想做程序員做後端都需要掌握哪些知識

目前掌握的僅能：
1，研發（基本吧，產品總得有人來做）
2，調優（主要是Mysql調優，在符合業務需求的情況下盡可能提高TPS）
3，運維（小公司不會像大公司一樣還標配運維，通常後端兼任運維職能）

擴展下：
研發：php入行，選個好框架（推薦Yaf），然後研發過程中多注意下性能，多用php本身的函數來解決需求，php本身函數豐富，而且都是C擴展，性能非常可靠。

調優：這個我實在不知道該放到研發還是運維，所以就單獨拿出來說。因為其實對於伺服器性能的調優本身兩邊都需要進行，一是研發時注意，二是各個軟體（主要是DB）的配置項。我的調優很粗暴，用阿里雲的壓力測試（耗費了公司一些錢財，罪過罪過）每次壓一分到5分鍾，然後看看瓶頸在哪裡，把配置項全部列出來，肉眼+自行判斷調整哪個參數看看能不能提升性能（233），我也會在代碼中把每個核心部分的消耗時間打入日誌，來判斷到底該進行哪裡的優化。

運維：主要分三部分，
快速部署：雖然是小公司，但是老闆有些資源，所以可以預計上線第一波的壓力不小，如果產品良好的情況下壓力只能會越來越大，所以要求如果感覺到系統有壓力後，需要快速進行橫向擴展系統，這里我選用的Puppet，理由很簡單：老牌，使用廣泛，社區強大。
監控報警：這是運維的眼睛，我選用的zabbix，理由跟上面一樣：老牌，使用廣泛，社區強大。
日誌採集：因為是集群的原因，看日誌不方便，最開始是用nfs來收集，後來隨著日誌越來越分散，日誌越來越大，沒用多久就被我拋棄了，然後在朋友的推薦下使用ELK進行日誌採集和查看。理由只是因為沒有別的更好選擇（朋友強烈推薦這個，其他的都是沒有啥強大社區，這個看著更靠譜點）

㈥ 什麼是集群測試干什麼用的有什麼功能（請用通俗的語言說明）

比如我開發了一個軟體，在正式發行前要檢測其功能或可預測到的缺點。集群就是讓更多的人來用好發現更多的問題。

㈦ 對linux下的一個分布式系統進行測試，報告問題時需要哪些信息

· 在測試執行過程中，對測試結果的分析是一個需要進行深入思考的重點問題。分布式系統測試的重點在於對後端伺服器集群的測試，而判定系統中是否存在Bug則是我們需要解決的重要問題。那麼應該如何確定是否存在Bug呢？對於測試結果的分析，我們通常觀察下面幾種情況。
觀察前端應用的返回結果。這里需要分兩種情況來考慮：第一，按照前端應用業務功能點及流程進行操作，觀察返回結果是否符合業務方的需求預期；第二，操作後端的伺服器（通常是重啟、宕機、斷網等操作），觀察前端應用的返回結果是否符合系統的設計需求。

㈧ 負載均衡 伺服器集群 的一些基礎問題

負載均衡有多種方式：對應tcp/ip協議的不同層

可以在應用層做，也可以在網路層或者鏈路層做

負載均衡主要作用是為了系統的擴展性和高可用性

主要目的並不是為了升級單機的配置

數據一般採取硬體存儲，即多個伺服器訪問同一個存儲設備

㈨ 伺服器如何實現集群和負載均衡

很多組織機構慢慢的在不同的伺服器和地點部署sql
server資料庫——為各種應用和目的——開始考慮通過sql
server集群的方式來合並。
將sql
server實例和資料庫合並到一個中心的地點可以減低成本，尤其是維護和軟硬體許可證。此外，在合並之後，可以減低所需機器的數量，這些機器就可以用於備用。
當尋找一個備用，比如高可用性的環境，企業常常決定部署microsoft的集群架構。我常常被問到小的集群(由較少的節點組成)sql
server實例和作為中心解決方案的大的集群哪一種更好。在我們比較了這兩個集群架構之後，我讓你們自己做決定。
什麼是microsoft集群伺服器
mscs是一個windows
server企業版中的內建功能。這個軟體支持兩個或者更多伺服器節點連接起來形成一個「集群」，來獲得更高的可用性和對數據和應用更簡便的管理。mscs可以自動的檢查到伺服器或者應用的失效，並從中恢復。你也可以使用它來(手動)移動伺服器之間的負載來平衡利用率以及無需停機時間來調度計劃中的維護任務。
這種集群設計使用軟體「心跳」來檢測應用或者伺服器的失效。在伺服器失效的事件中，它會自動將資源(比如磁碟和ip地址)的所有權從失效的伺服器轉移到活動的伺服器。注意還有方法可以保持心跳連接的更高的可用性，比如站點全面失效的情況下。
mscs不要求在客戶計算機上安裝任何特殊軟體，因此用戶在災難恢復的經歷依賴於客戶-伺服器應用中客戶一方的本質。客戶的重新連接常常是透明的，因為mscs在相同的ip地址上重啟應用、文件共享等等。進一步，為了災難恢復，集群的節點可以處於分離的、遙遠的地點。
在集群伺服器上的sql
server
sql
server
2000可以配置為最多4個節點的集群，而sql
server
2005可以配置為最多8個節點的集群。當一個sql
server實例被配置為集群之後，它的磁碟資源、ip地址和服務就形成了集群組來實現災難恢復。
sql
server
2000允許在一個集群上安裝16個實例。根據在線幫助，「sql
server
2005在一個伺服器或者處理器上可以支持最多50個sql
server實例，」但是，「只能使用25個硬碟驅動器符，因此如果你需要更多的實例，那麼需要預先規劃。」
注意sql
server實例的災難恢復階段是指sql
server服務開始所需要的時間，這可能從幾秒鍾到幾分鍾。如果你需要更高的可用性，考慮使用其他的方法，比如log
shipping和資料庫鏡像。
單個的大的sql
server集群還是小的集群
下面是大的、由更多的節點組成的集群的優點：
◆更高的可用新(更多的節點來災難恢復)。
◆更多的負載均衡選擇(更多的節點)。
◆更低廉的維護成本。
◆增長的敏捷性。多達4個或者8個節點，依賴於sql版本。
◆增強的管理性和簡化環境(需要管理的少了)。
◆更少的停機時間(災難恢復更多的選擇)。
◆災難恢復性能不受集群中的節點數目影響。
下面是單個大的集群的缺點：
◆集群節點數目有限(如果需要第9個節點怎麼辦)。
◆在集群中sql實例數目有限。
◆沒有對失效的防護——如果磁碟陣列失效了，就不會發生災難恢復。
◆使用災難恢復集群，無法在資料庫級別或者資料庫對象級別，比如表，創建災難恢復集群。
虛擬化和集群
虛擬機也可以參與到集群中，虛擬和物理機器可以集群在一起，不會發生問題。sql
server實例可以在虛擬機上，但是性能可能會受用影響，這依賴於實例所消耗的資源。在虛擬機上安裝sql
server實例之前，你需要進行壓力測試來驗證它是否可以承受必要的負載。
在這種靈活的架構中，如果虛擬機和物理機器集群在一起，你可以在虛擬機和物理機器之間對sql
server進行負載均衡。比如，使用虛擬機上的sql
server實例開發應用。然後在你需要對開發實例進行壓力測試的時候，將它災難恢復到集群中更強的物理機器上。
集群伺服器可以用於sql
server的高可用性、災難恢復、可擴展性和負載均衡。單個更大的、由更多的節點組成的集群往往比小的、只有少數節點的集群更好。大個集群允許更靈活環境，為了負載均衡和維護，實例可以從一個節點移動到另外的節點。

㈩ 軟體測試，測試環境搭建需要考慮哪些方面

構建測試環境是軟體測試實現的重要階段，測試環境是否合適將嚴重影響測試結果的真實性和正確性。測試環境包括硬體環境和軟體環境。

硬體環境是指由必要的伺服器、客戶端、網路連接設備和輔助硬體設備（如列印機／掃描儀）組成的環境。軟體環境是指被測軟體在運行過程中，由操作系統、資料庫等應用軟體組成的環境。

(10)後端伺服器集群測試需要注意什麼擴展閱讀：

測試環境的組成部分：

1．需要的計算機數量，以及每台計算機的硬體配置要求，包括CPU的速度、內存和硬碟的容量、網卡支持的速度、列印機的類型等。

2．操作系統、資料庫管理系統、中間件、WEB伺服器以及部署被測應用伺服器所需的其他必要組件的名稱和版本，以及使用的相關補丁的版本；

3．操作系統、資料庫管理系統、中間件、WEB伺服器和伺服器存儲各種測試活動中生成的文檔和數據所需的其他必要組件的名稱和版本，以及要使用的相關補丁的版本；

4．操作系統、資料庫管理系統、中間件、WEB伺服器和其他計算機執行測試所需的必要組件的名稱和版本，以及要使用的相關補丁的版本；

5．被測應用程序的伺服器環境是否需要專用計算機，測試管理伺服器環境是否需要備份；

6．網路環境要在測試中使用。例如，如果測試結果與連接到Internet的線路的穩定性有關，則應考慮為測試環境租用單獨的線路；如果測試結果與區域網內的網速有關，則應保證計算機的網卡、網線以及所使用的集線器和交換機不會成為瓶頸。