天天看點

Java測試工程師技術面試題庫【持續補充更新】

  1. 請你說一下設計測試用例的方法
黑盒測試:
1.等價類劃分

等價類劃分是将系統的輸入域劃分為若幹部分,然後從每個部分選取少量代表性資料進行測試。等價類可以劃分為有效等價類和無效等價類,設計測試用例的時候要考慮這兩種等價類。

2.邊界值分析法

邊界值分析法是對等價類劃分的一種補充,因為大多數錯誤都在輸入輸出的邊界上。邊界值分析就是假定大多數錯誤出現在輸入條件的邊界上,如果邊界附件取值不會導緻程式出錯,那麼其他取值出錯的可能性也就很小。

邊界值分析法是通過優先選擇不同等價類間的邊界值覆寫有效等價類和無效等價類來更有效的進行測試,是以該方法要和等價類劃分法結合使用。

3.正交試驗法

正交是從大量的試驗點中挑選出适量的、有代表性的點。正交試驗設計是研究多因素多水準的一種設計方法,他是一種基于正交表的高效率、快速、經濟的試驗設計方法。

4.狀态遷移法

狀态遷移法是對一個狀态在給定的條件内能夠産生需要的狀态變化,有沒有出現不可達的狀态和非法的狀态,狀态遷移法是設計足夠的用例達到對系統狀态的覆寫、狀态、條件組合、狀态遷移路徑的覆寫。

5.流程分析法

流程分析法主要針對測試場景類型屬于流程測試場景的測試項下的測試子項進行設計,這是從白盒測試中路徑覆寫分析法借鑒過來的一種很重要的方法。

6.輸入域測試法

輸入域測試法是針對輸入會有各種各樣的輸入值的一個測試,他主要考慮 極端測試、中間範圍測試,特殊值測試 。

7.輸出域分析法

輸出域分析法是對輸出域進行等價類和邊界值分析,确定是要覆寫的輸出域樣點,反推得到應該輸入的輸入值,進而構造出測試用例,他的目的是為了達到輸出域的等價類和邊界值覆寫。

8.判定表分析法

判定表是分析和表達多種輸入條件下系統執行不同動作的工具,他可以把複雜的邏輯關系和多種條件組合的情況表達的即具體又明确;

9.因果圖法

因果圖是用于描述系統輸入輸出之間的因果關系、限制關系。因果圖的繪制過程是對被測系統的外部特征的模組化過程,根據輸入輸出間的因果圖可以得到判定表,進而規劃出測試用例。

10.錯誤猜測法

錯誤猜測法主要是針對系統對于錯誤操作時對于操作的處理法的猜測法,進而設計測試用例

11.異常分析法

異常分析法是針對系統有可能存在的異常操作,軟硬體缺陷引起的故障進行分析,分析發生錯誤時系統對于錯誤的處理能力和恢複能力依此設計測試用例。
--------------------------------------------------------------------------------------
白盒測試:

白盒測試也稱為結構測試或邏輯驅動測試,是針對被測單元内部是如何進行工作的測試。它根據程式的控制結構設計測試用例,主要用于軟體或程式驗證。白盒測試法檢查程式内部邏輯結構,對所有的邏輯路徑進行測試,是一種窮舉路徑的測試方法,但即使每條路徑都測試過了,但仍然有可能存在錯誤。因為:窮舉路徑測試無法檢查出程式本身是否違反了設計規範,即程式是否是一個錯誤的程式;窮舉路徑測試不可能檢查出程式因為遺漏路徑而出錯;窮舉路徑測試發現不了一些與資料相關的錯誤。

白盒測試需要遵循的原則有:1. 保證一個子產品中的所有獨立路徑至少被測試一次;2. 所有邏輯值均需要測試真(true)和假(false);兩種情況;3. 檢查程式的内部資料結構,保證其結構的有效性;4. 在上下邊界及可操作範圍内運作所有循環。

常用白盒測試方法:

靜态測試:不用運作程式的測試,包括代碼檢查、靜态結構分析、代碼品質度量、文檔測試等等,它可以由人工進行,充分發揮人的邏輯思維優勢,也可以借助軟體工具(Fxcop)自動進行。

動态測試:需要執行代碼,通過運作程式找到問題,包括功能确認與接口測試、覆寫率分析、性能分析、記憶體分析等。

白盒測試中的邏輯覆寫包括語句覆寫、判定覆寫、條件覆寫、判定/條件覆寫、條件組合覆寫和路徑覆寫。六種覆寫标準發現錯誤的能力呈由弱到強的變化:

1.語句覆寫每條語句至少執行一次。

2.判定覆寫每個判定的每個分支至少執行一次。

3.條件覆寫每個判定的每個條件應取到各種可能的值。

4.判定/條件覆寫同時滿足判定覆寫條件覆寫。

5.條件組合覆寫每個判定中各條件的每一種組合至少出現一次。

6.路徑覆寫使程式中每一條可能的路徑至少執行一次。      
  1. 請你說一說測試工程師的必備技能
需要的知識: 
     •    軟體測試基礎理論知識,如黑盒測試、白盒測試等;
       •    程式設計語言基礎,如C/C++、java、python等;
       •    自動化測試工具,如Selenium、Appium、Robotium等;
       •    計算機基礎知識,如資料庫、Linux、計算機網絡等;
       •    測試架構,如JUnit等。
需要具備的能力:
       •    業務分析能力,分析整體業務流程、分析被測業務資料、分析被測系統架構、分析被測業務子產品、分析測試所需資源、分析測試完成目标;
       •    缺陷洞察能力,一般缺陷的發現能力、隐性問題的發現能力、發現連帶問題的能力、發現問題隐患的能力、盡早發現問題的能力、發現問題根源的能力;
       •    團隊協作能力,合理進行人員分工、協助組員解決問題、配合完成測試任務、配合開發重制缺陷、督促項目整體進度、出現問題勇于承擔;
       •    專業技術能力,掌握測試基礎知識、掌握計算機知識、熟練運用測試工具;
       •    邏輯思考能力,判斷邏輯的正确性、對可行性邏輯分析、站在客觀角度思考;
       •    問題解決能力,技術上的問題、工作中的問題、溝通問題;
       •    溝通表達能力,和技術人員、産品人員、上下級的溝通;
       •    宏觀把控能力,有效控制測試時間、有效控制測試成本、有效制定測試計劃、有效進行風險評估、有效控制測試方向。      
  1. 請你說一下app性能測試的名額
1、記憶體:記憶體消耗測試節點的設計目标是為了讓應用不占用過多的系統資源,且及時釋放記憶體,保障整個系統的穩定性。當然關于記憶體測試,在這裡我們需要引入幾個概念:空閑狀态、中等規格、滿規格。
空閑狀态指打開應用後,點選home鍵讓應用背景運作,此時應用處于的狀态叫做空閑;中等規格和滿規格指的是對應用的操作時間的間隔長短不一,中等規格時間較長,滿規格時間較短。

記憶體測試中存在很多測試子項,清單如下:

●空閑狀态下的應用記憶體消耗;

●中等規格狀态下的應用記憶體消耗;

●滿規格狀态下的應用記憶體消耗;

●應用記憶體峰值;

●應用記憶體洩露;

●應用是否常駐記憶體;

●壓力測試後的記憶體使用。

2、CPU:

使用Android提供的view plaincopy在CODE上檢視代碼片派生到我的代碼片

adbshell dumpsys CPUinfo |grep packagename >/address/CPU.txt來擷取;

使用top指令view plaincopy在CODE上檢視代碼片派生到我的代碼片

adbshell top |grep packagename>/address/CPU.txt來擷取。

3、流量:

網絡流量測試是針對大部分應用而言的,可能還有部分應用會關注網速、弱網之類的測試。

流量測試包括以下測試項:

應用首次啟動流量提示;

應用背景連續運作2小時的流量值;

應用高負荷運作的流量峰值。

4、電量:

●測試手機安裝目标APK前後待機功耗無明顯差異;

●常見使用場景中能夠正常進入待機,待機電流在正常範圍内;

●長時間連續使用應用無異常耗電現象。

5、啟動速度:

第一類:首次啟動--應用首次啟動所花費的時間;

第二類:非首次啟動--應用非首次啟動所花費的時間;

第三類:應用界面切換--應用界面内切換所花費的時間。

6、滑動速度、界面切換速度

7、與伺服器互動的網絡速度      
  1. 請你說一說web測試和app測試的不同點
系統架構方面:
web項目,一般都是b/s架構,基于浏覽器的

app項目,則是c/s的,必須要有用戶端,使用者需要安裝用戶端。

web測試隻要更新了伺服器端,用戶端就會同步會更新。App項目則需要用戶端和伺服器都更新。

性能方面:

web頁面主要會關注響應時間

而app則還需要關心流量、電量、CPU、GPU、Memory這些。

它們服務端的性能沒差別,都是一台伺服器。

相容方面:

web是基于浏覽器的,是以更傾向于浏覽器和電腦硬體,電腦系統的方向的相容

app測試則要看分辨率,螢幕尺寸,還要看裝置系統。

web測試是基于浏覽器的是以不必考慮安裝解除安裝。

而app是用戶端的,則必須測試安裝、更新、解除安裝。除了正常的安裝、更新、解除安裝還要考慮到異常場景。包括安裝時的中斷、弱網、安裝後删除安裝檔案 。

此外APP還有一些專項測試:如網絡、适配性。      
  1. 請問黑盒測試和白盒測試有哪些方法
黑盒測試方法有等價類劃分,邊界值分析,錯誤推測,因果圖法

白盒測試方法有邏輯覆寫法,程式插樁技術,基本路徑法,符号測試,錯誤驅動測試      
  1. 請你回答一下什麼是α測試和β測試,以及什麼時候用到他們
α測試:在受控的環境中進行,由使用者在開發者的場所進行,并且在開發者對使用者的指導下進行測試,開發者負責記錄發現的錯誤和使用中遇到的問題

β測試:在開發者不能控制的環境中的真實應用,由軟體的最終使用者們在一個或多個客戶場所下進行,由使用者記錄在測試中遇到的一系列問題,并定期報給開發者。      
  1. 請你分别介紹一下單元測試、內建測試、系統測試、驗收測試、回歸測試
1、單元測試:完成最小的軟體設計單元(子產品)的驗證工作,目标是確定子產品被正确的編碼,使用過程設計描述作為指南,對重要的控制路徑進行測試以發現子產品内的錯誤,通常情況下是白盒的,對代碼風格和規則、程式設計和結構、業務邏輯等進行靜态測試,及早的發現和解決不易顯現的錯誤。

2、內建測試:通過測試發現與子產品接口有關的問題。目标是把通過了單元測試的子產品拿來,構造一個在設計中所描述的程式結構,應當避免一次性的內建(除非軟體規模很小),而采用增量內建。

自頂向下內建:子產品內建的順序是首先內建主子產品,然後按照控制層次結構向下進行內建,隸屬于主子產品的子產品按照深度優先或廣度優先的方式內建到整個結構中去。

自底向上內建:從原子子產品開始來進行構造和測試,因為子產品是自底向上內建的,進行時要求所有隸屬于某個給頂層次的子產品總是存在的,也不再有使用穩定測試樁的必要。

3、系統測試:是基于系統整體需求說明書的黑盒類測試,應覆寫系統所有聯合的部件。系統測試是針對整個産品系統進行的測試,目的是驗證系統是否滿足了需求規格的定義,找出與需求規格不相符合或與之沖突的地方。系統測試的對象不僅僅包括需要測試的産品系統的軟體,還要包含軟體所依賴的硬體、外設甚至包括某些資料、某些支援軟體及其接口等。是以,必須将系統中的軟體與各種依賴的資源結合起來,在系統實際運作環境下來進行測試。

4、回歸測試:回歸測試是指在發生修改之後重新測試先前的測試用例以保證修改的正确性。理論上,軟體産生新版本,都需要進行回歸測試,驗證以前發現和修複的錯誤是否在新軟體版本上再次出現。根據修複好了的缺陷再重新進行測試。回歸測試的目的在于驗證以前出現過但已經修複好的缺陷不再重新出現。一般指對某已知修正的缺陷再次圍繞它原來出現時的步驟重新測試。

5、驗收測試:驗收測試是指系統開發生命周期方法論的一個階段,這時相關的使用者或獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統使用者決定是否接收系統。它是一項确定産品是否能夠滿足合同或使用者所規定需求的測試。驗收測試包括Alpha測試和Beta測試。

Alpha測試:是由使用者在開發者的場所來進行的,在一個受控的環境中進行。

Beta測試:由軟體的最終使用者在一個或多個使用者場所來進行的,開發者通常不在現場,使用者記錄測試中遇到的問題并報告給開發者,開發者對系統進行最後的修改,并開始準備釋出最終的軟體。      
  1. 請說一下手動測試與自動化測試的優缺點
手工測試缺點:
1、重複的手工回歸測試,代價昂貴、容易出錯。

2、依賴于軟體測試人員的能力。

手工測試優點:

1、測試人員具有經驗和對錯誤的猜測能力。

2、測試人員具有審美能力和心理體驗。

3、測試人員具有是非判斷和邏輯推理能力。

自動化測試的優點:

1、對程式的回歸測試更友善。這可能是自動化測試最主要的任務,特别是在程式修改比較頻繁時,效果是非常明顯的。由于回歸測試的動作和用例是完全設計好的,測試期望的結果也是完全可以預料的,将回歸測試自動運作,可以極大提高測試效率,縮短回歸測試時間。

2、可以運作更多更繁瑣的測試。自動化的一個明顯的好處是可以在較少的時間内運作更多的測試。

3、可以執行一些手工測試困難或不可能進行的測試。比如,對于大量使用者的測試,不可能同時讓足夠多的測試人員同時進行測試,但是卻可以通過自動化測試模拟同時有許多使用者,進而達到測試的目的。

4、更好地利用資源。将繁瑣的任務自動化,可以提高準确性和測試人員的積極性,将測試技術人員解脫出來投入更多精力設計更好的測試用例。有些測試不适合于自動測試,僅适合于手工測試,将可自動測試的測試自動化後,可以讓測試人員專注于手工測試部分,提高手工測試的效率。

5、測試具有一緻性和可重複性。由于測試是自動執行的,每次測試的結果和執行的内容的一緻性是可以得到保障的,進而達到測試的可重複的效果。

6、測試的複用性。由于自動測試通常采用腳本技術,這樣就有可能隻需要做少量的甚至不做修改,實作在不同的測試過程中使用相同的用例。

7、增加軟體信任度。由于測試是自動執行的,是以不存在執行過程中的疏忽和錯誤,完全取決于測試的設計品質。一旦軟體通過了強有力的自動測試後,軟體的信任度自然會增加。

自動化測試的缺點:

1、不能取代手工測試

2、手工測試比自動測試發現的缺陷更多

3、對測試品質的依賴性極大

4、測試自動化不能提高有效性

5、測試自動化可能會制約軟體開發。由于自動測試比手動測試更脆弱,是以維護會受到限制,進而制約軟體的開發。

6、工具本身并無想像力      
  1. 你覺得測試和開發需要怎麼結合才能使軟體的品質得到更好的保障
測試和開發應該按照W模型的方式進行結合,測試和開發同步進行,能夠盡早發現軟體缺陷,降低軟體開發的成本。      
在V模型中,測試過程被加在開發過程的後半部分,單元測試所檢測代碼的開發是否符合詳細設計的要求。
內建測試所檢測此前測試過的各組成部分是否能完好地結合到一起。

系統測試所檢測已內建在一起的産品是否符合系統規格說明書的要求。

驗收測試則檢測産品是否符合最終使用者的需求。

V模型的缺陷在于僅僅把測試過程作為在需求分析、系統設計及編碼之後的一個階段,忽視了測試對需求分析、系統設計的驗證,是以需求階段的缺陷很可能一直到後期的驗收測試才被發現,此時進行彌補将耗費大量人力物力資源。

相對于V模型,W模型增加了軟體各開發階段中應同步進行的驗證和确認活動。W模型由兩個V字型模型組成,分别代表測試與開發過程,圖中明确表示出了測試與開發的并行關系。

W模型強調:測試伴随着整個軟體開發周期,而且測試的對象不僅僅是程式,需求、設計等同樣要測試,也就是說,測試與開發是同步進行的。W模型有利于盡早地全面的發現問題。例如,需求分析完成後,測試人員就應該參與到對需求的驗證和确認活動中,以盡早地找出缺陷所在。同時,對需求的測試也有利于及時了解項目難度和測試風險,及早制定應對措施,這将顯著減少總體測試時間,加快項目進度。      
W模型中測試的活動與軟體開發同步進行,測試的對象不僅僅是程式,還包括需求和設計,是以能夠盡早發現軟體缺陷,降低軟體開發的成本。      
  1. 請你回答一下測試的相關流程是什麼
測試最規範的過程如下
需求測試->概要設計測試->詳細設計測試->單元測試->內建測試->系統測試->驗收測試

來自W模型      
  1. 給你一個字元串,你怎麼判斷是不是ip位址?手寫這段代碼,并寫出測試用例
// 基于對字元串的處理
  public static void main(String[] args){
    Scanner scanner = new Scanner(System.in);
    String ipStr = scanner.next();
    boolean isIpLegal = isIpLegal(ipStr);
    if(isIpLegal) {
      System.out.println(ipStr + " 合法");
    }else{
      System.out.println(ipStr + " 非法");
    }
  }
  public static boolean isIpLegal(String str){
  
    //檢查ip是否為空
    
    if(str == null){
      return false;  
    }
    //檢查ip長度,最短為:x.x.x.x(7位),最長為:xxx.xxx.xxx.xxx(15位)
    if(str.length() < 7 || str.length() > 15){
      return false;
    }
    //對輸入字元串的首末字元判斷,如果是"."則是非法IP  
    if(str.charAt(0) == '.' || str.charAt(str.length()-1) == '.'){  
      return false;
    }
  }
  //按"."分割字元串,并判斷分割出來的個數,如果不是4個,則是非法IP
  String[] arr = str.split("\\.");
  if(arr.length != 4){
    return false;
  }
  //對分割出來的每個字元串進行單獨判斷
  for(int i = 0; i < arr.length; i++){
    //如果每個字元串不是一位字元,且以'0'開頭,則是非法的IP,如:01.002.03.004
    if(arr[i].length() > 1 && arr[i].charAt(0) == '0'){
      return false;
    }
    //對每個字元串的每個字元進行逐一判斷,如果不是數字0-9,則是非法的IP
    for(int j = 0; j < arr[i].length(); j++){
      if (arr[i].charAt(j) < '0' || arr[i].charAt(j) > '9'){
        return false;
      }
    }
  }
  //對拆分的每一個字元串進行轉換成數字,并判斷是否在0~255
  for(int i = 0; i < arr.length; i++){
    int temp = Integer.parseInt(arr[i]);
    if(i == 0){
      if (temp < 1 || temp > 255){
        return false;
      }
    }else{
      if(temp < 0 || temp > 255){
        return false;
      }
    }
  }
    return true;
}      
  1. 請進行測試用例設計:一串數字,閏年的判别
  2. 請你說一說簡單使用者界面登陸過程都需要做哪些分析
一、功能測試
1.輸入正确的使用者名和密碼,點選送出按鈕,驗證是否能正确登入。

2.輸入錯誤的使用者名或者密碼,驗證登入會失敗,并且提示相應的錯誤資訊。

3.登入成功後能否能否跳轉到正确的頁面

4.使用者名和密碼,如果太短或者太長,應該怎麼處理

5.使用者名和密碼,中有特殊字元(比如空格),和其他非英文的情況

6.記住使用者名的功能

7.登陸失敗後,不能記錄密碼的功能

8.使用者名和密碼前後有空格的處理

9.密碼是否非明文顯示顯示,使用星号圓點等符号代替。

10.牽扯到驗證碼的,還要考慮文字是否扭曲過度導緻辨認難度大,考慮顔色(色盲使 用者),重新整理或換一個按鈕是否好用

11.登入頁面中的注冊、忘記密碼,登出用另一帳号登陸等連結是否正确

12.輸入密碼的時候,大寫鍵盤開啟的時候要有提示資訊。

13.什麼都不輸入,點選送出按鈕,檢查提示資訊。

二、界面測試

1.布局是否合理,testbox和按鈕是否整齊。

2.testbox和按鈕的長度,高度是否複合要求。

3. 界面的設計風格是否與UI的設計風格統一。

4. 界面中的文字簡潔易懂,沒有錯别字。

三、性能測試

1.打開登入頁面,需要的時間是否在需求要求的時間内。

2.輸入正确的使用者名和密碼後,檢查登入成功跳轉到新頁面的時間是否在需求要求的時間内。

3.模拟大量使用者同時登陸,檢查一定壓力下能否正常登陸跳轉。

四、安全性測試

1.登入成功後生成的Cookie,是否是httponly (否則容易被腳本盜取)。

2.使用者名和密碼是否通過加密的方式,發送給Web伺服器。

3.使用者名和密碼的驗證,應該是用伺服器端驗證, 而不能單單是在用戶端用javascript 驗證。

4.使用者名和密碼的輸入框,應該屏蔽SQL注入攻擊。

5.使用者名和密碼的的輸入框,應該禁止輸入腳本 (防止XSS攻擊)。

6.防止暴力破解,檢測是否有錯誤登陸的次數限制。

7. 是否支援多使用者在同一機器上登入。

8. 同一使用者能否在多台機器上登入。

五、可用性測試

1. 是否可以全用鍵盤操作,是否有快捷鍵。

2. 輸入使用者名,密碼後按回車,是否可以登陸。

3. 輸入框能否可以以Tab鍵切換。

六、相容性測試

1.不同浏覽器下能否顯示正常且功能正常(IE,6,7,8,9, Firefox, Chrome, Safari,等)。

2.同種浏覽器不同版本下能否顯示正常且功能正常。

2.不同的平台是否能正常工作,比如Windows, Mac。

3.移動裝置上是否正常工作,比如Iphone, Andriod。

4.不同的分辨率下顯示是否正常。

七、本地化測試

1. 不同語言環境下,頁面的顯示是否正确。      
  1. 請對這個系統做出測試用例:一個系統,多個攝像頭,抓拍車牌,識别車牌,上傳網上,網上展示
功能:
1.每個攝像頭都能抓拍車牌;

2.每個攝像頭抓拍到的車牌能正常交給系統處理;

3.系統能夠正确識别車牌;

4.系統能夠将識别出的車牌上傳;

5.上傳至網絡的車牌能夠正常展示出來;

一、功能測試

1.使用正常的車牌,保持車牌靜止,檢查每個攝像頭是否能抓拍車牌;

2.使用類似非車牌的寫有字的紙闆,檢查每個攝像頭是否抓拍;

3.使用正常的車牌,保持車牌較高速移動,檢查每個攝像頭是否能抓拍車牌;

4.在多種情況下檢查每個攝像頭抓拍到的車牌能否正常交給系統處理,如臨時斷電、斷網後能否正常将資料交給系統;

5.使用抓拍到的正常的車牌,交由系統處理,檢查系統能否識别車牌;

6.使用非車牌的其他圖檔,交由系統處理,檢查系統能否識别;

7.在多種情況下檢查系統能否将正常識别出的車牌進行上傳,如臨時斷電、斷網後未上傳資料是否能繼續上傳;

8.構造非車牌的其他内容的資料,檢查系統能否将異常内容進行上傳;

9.檢查上傳至網絡的車牌能否正常展示出來;

10.上傳非車牌的其他内容的資料,檢查能否正常顯示出來。

二、性能測試

1.同時向一個攝像頭展示多個靜止的車牌,檢查攝像頭能否抓拍到多個車牌;

2.同時向一個攝像頭展示多個較高速運動的車牌,檢查攝像頭能否抓拍到多個車牌;

3.抓拍後,檢查系統識别車牌的時間是否在需求要求的時間内;

4.模拟大量抓拍照片同時交由系統處理,檢查一定壓力下系統能否正常識别車牌;

5.模拟大量車牌同時上傳,檢查一定壓力下能否上傳成功。

三、安全性測試

1.檢查是否能夠通過給車牌加裝飾物等方法,使攝像頭無法抓拍或抓拍後系統無法正常識别車牌。      
  1. 請你對王者榮耀遊戲進行壓力測試
一.首先明确需要測試壓力的内容:
1.遊戲伺服器硬體

a.硬碟I/o

b.記憶體

c.CPU

2.網絡壓力

a.長連接配接

a1.最大連接配接數

a2.流量(内網、外網、進、出)

b.長連接配接短周期(類似Http的TCP應用,這個比較特殊的一個需求,專門針對LoginAgent)

b1.每秒建立的連接配接數

b2.實際處理能力

3.資料庫

a.每秒事務數

b.每秒鎖等待數

c.平均延時(ms)

d.CPU暫用

4.多線程的最優線程數

a.資料庫執行的多線程

b.多連接配接處理

二.Windows Server環境測試方式

1.伺服器性能監測

使用Server自帶的性能監測器設定各個程序的監測參數。Window的這個自動工具做的相當強大。大家自己摸一摸基本就會用了。每個參數都由詳細的說明。

2.案例設計注意

a.對于資料庫的性能測試上,現在由于所有的遊戲伺服器構架在DB前面都有一個實作DB緩沖功能的程序,以減少資料庫頻繁的讀寫操作。是以其實資料庫的讀是一個輕量級的數量;而資料庫的寫操作是一個周期性能過程。案例設計一定要能夠驅動這種周期性能過程。比如我們遊戲的戰鬥,導緻遊戲玩家資料的改變,或驅動所有線上玩家資料的周期性存儲。

b.選擇具有代表性,并且最頻繁的遊戲操作。用于進行最高使用者線上的各種性能名額采集。如,開槍、道具拾取、道具使用、移動、聊天

c.聊天性能測試

廣播聊天是最為考驗遊戲資訊發送能力的功能。通過進行全局廣播的壓力測試。我們可以擷取伺服器程序發送資訊到用戶端的最高承載量。進而可以對我們的各種廣播功能進行一個預估和頻率限制。

d.同屏玩家的移動測試

移動+廣播。這兩種資訊,基本是網絡遊戲流量的70-80%左右。同屏玩家數量,将會增加各種資料的廣播需求,非常影響遊戲性能。是以同屏的移動測試也是廣播測試的一個必要環節。需要根據實際結果進行适當的優化。

e.大量玩家同時登入測試

玩家登入時,有大量的資訊需要進行配置設定和初始化;同時也有大量的資料需要下傳用戶端。伺服器需要進行大量的TCP連接配接建立。是以是一個比較關鍵的過程。這個測試案例是一個比較特殊,但是營運是肯定會碰到的案例。

f.由于線程池處理事務,随着事務的時耗,存在一個最優線程數的問題。過多的線程反而會降低伺服器效率

3.細節問題

a.進行測試需要仔細思考用戶端性能影響伺服器最後表現的可能性。比如

a1.模拟用戶端的性能無法有效處理伺服器傳回資訊,可能就導緻伺服器發送的資訊緩存在伺服器系統緩存,進而表現出伺服器記憶體不斷增加。表現為伺服器發送能力不足,其實可能根本就是用戶端的性能問題

a2.用戶端性能問題,導緻發起的請求數過少,進而導緻機關時間内伺服器處理的請求過少。表現為伺服器性能不足,其實根本就是用戶端的請求能力不足。

b.網絡帶寬導緻最後表現不足

b1.确認伺服器的各個網卡,以及互相的帶寬。不然可能因為互相帶寬,導緻伺服器對于用戶端請求的處理延時。表現為伺服器卡機

b2.用戶端模拟多個玩家,比如1000個玩家。而用戶端的網卡或者用戶端與伺服器之間的中轉伺服器帶寬過小,導緻伺服器資料發送不出,記憶體不斷增加。表現為伺服器發送能力不足,其實是中間帶寬問題。

c.debug i/o導緻伺服器性能下降

c1.進行性能測試,一定要取消debug用的同步的i/o.比如我們伺服器的debuginternalLog.同步i/o是非常影響性能的,特别在壓力測試下可能導緻每秒上千上萬甚至幾十萬次的執行。一處的檔案寫入操作就可以導緻幾十萬次的處理能力變成幾千次的處理能力。

c2.用戶端避免進行阻塞操作導緻模拟多使用者性能下降,導緻伺服器表現性能下降

d.流量需要區分内網網

内、外網流量在遊戲正式運作時是完全分開的。價格也是完全不同的。一個千M的外網是一個無法想象的營運成本,而kmbps/s現在已經是一個可以接受的代價。遊戲程序需要進行不同網卡的配置和綁定。确定内外網流量。      
  1. 請你對朋友圈點贊功能進行測試
1.是否可以正常點贊和取消;

2.點贊的人是否在可見分組裡;

3.點贊狀态是否能即時更新顯示;

4.點贊狀态,共同好友是否可見;

6.性能檢測,網速快慢對其影響;

7.點贊顯示的是否正确,一行幾個;

8.點贊是否按時間進行排序,頭像對應的是否正确;

9.是否能在消息清單中顯示點贊人的昵稱、5.不同手機,系統顯示界面如何;

備注;

10.可擴充性測試,點贊後是否能發表評論;

11.是否在未登入時可檢視被點贊的資訊。      
  1. 如果做一個杯子的檢測,你如何測試
1.功能
(1)水倒水杯容量的一半

(2)水倒規定的安全線

(4)水杯容量刻度與其他水杯一緻

(5)蓋子擰緊水倒不出來

(6)燙手驗證

2.性能

(1)使用最大次數或時間

(2)掉地上不易損壞

(3)蓋子擰到什麼程度水倒不出來

(4)保溫時間長

(5)杯子的耐熱性

(6)杯子的耐寒性

(7)長時間放置水不會漏

(8)杯子上放置重物達到什麼程度杯子會被損壞

3.界面

(1)外觀完整、美觀

(2)大小與設計一樣(高、寬、容量、直徑)

(3)拿着舒服

(4)材質與設計一樣

(5)杯子上的圖案掉落

(6)圖案遇水溶解

4.安全

(1)杯子使用的材質毒或細菌的驗證

(2)高溫材質釋放毒性

(3)低溫材質釋放毒性

5.易用性

(1)倒水友善

(2)喝水友善

(3)攜帶友善

(4)使用簡單,容易操作

(5)防滑措施

6.相容性

(1)杯子能夠容納果汁、白水、酒精、汽油等。

7.震動測試

(1)杯子加包裝(有填充物),六面震動,檢查産品是否能應對鐵路/公路/航空運輸。

8.可移植性

(1)杯子在不同地方、溫度環境下都可以正常使用。      
  1. 如何對一個頁面進行測試
1、UI測試:頁面布局、頁面樣式檢查、控件長度是否夠長;顯示時,是否會被截斷;支援的快捷鍵,Tab鍵切換焦點順序正确性等。

2、功能測試:頁面上各類控件的測試範圍,測試點。結合控件的實際作用來補充檢查點: 比如, 密碼框是否*顯示, 輸入是否做trim處理等。

3、安全測試:輸入特殊字元,sql注入,腳本注入測試。背景驗證測試,對于較重要的表單 ,繞過js檢驗背景是否驗證;資料傳輸是否加密處理,比如, 直接請求轉發,位址欄直接顯示發送字元串?

4、相容性測試

5、性能測試      

繼續閱讀