華為測試面試題彙總

　　1.怎麼來設計測試方案?

根據測試需求(包括功能需求和非功能性需求)，識別測試要點，識別測試環境要求，安排測試輪次，根據專案計劃和開發計劃做整體的測試安排。

被測試的特性：通過對需求規格說明書進行分析，列出本次測試需要進行測試的各部分特性(如要測試的功能需求、效能需求、安全性需求等等);

不被測試的特性：由於資源、進度等方面原因，本次測試不列入測試範圍的特性;

測試組網圖：進行本次系統測試所需要的軟硬體裝置、配置資料已及相互間的邏輯、物理連線。今後測試執行時需要依據這個組網圖來進行環境的搭建。

　　2.如果給你一個B/S系統你怎麼來進行測試?此題答案還可用於回答測試流程，測試流程題亦可參考15題。

閱讀系統需求，充分理解需求，記錄問題，並與專案需求人員充分溝通。

編寫測試需求，包括系統功能和非功能測試要點、測試型別、測試進度質量要求等。

制定測試計劃，包括熟悉測試業務、設計測試用例、執行測試用例、進行測試小結、編寫測試報告，任務顆粒度一般應小於5人天

編寫測試用例，根據測試方案設計用例，即便沒有明確的效能和安全測試要求，也應識別進行此兩項測試。

執行軟體測試，

進行測試小結，如果測試持續時間較長，每個版本間隙總結本輪測試。

編寫測試報告，總結測試過程，彙總度量資料。

　　3.怎麼進行工作流的測試

把握需求，找準結點，理清流程，畫出流轉圖，弄清節點間的資料流轉，設計測試用例的時候必須覆蓋所有可能的流程。

工作流：

如果問到有沒有做過，根據對工作流的瞭解情況回答，如果比較瞭解，可以把參與的某個專案中說上一些有工作流的，如果不是很瞭解就說沒有做過，但是學習過相關知識。

　　4.在做效能測試的時候都需要關注哪些引數?

併發訪問量，伺服器響應時間(最小、平均、最大)

併發效能測試的過程是一個負載測試和壓力測試的過程，即逐漸增加負載，直到系統的瓶頸或者不能接收的效能點，通過綜合分析交易執行指標和資源監控指標來確定系統併發效能的過程。

負載測試(Load Testing)是確定在各種工作負載下系統的效能，目標是測試當負載逐漸增加時，系統組成部分的相應輸出項，例如通過量、響應時間、CPU負載、記憶體使用等來決定系統的效能。

負載測試是一個分析軟體應用程式和支撐架構、模擬真實環境的使用，從而來確定能夠接收的效能過程。壓力測試(Stress Testing)是通過確定一個系統的`瓶頸或者不能接收的效能點，來獲得系統能提供的最大服務級別的測試。

疲勞測試是採用系統穩定執行情況下能夠支援的最大併發使用者數，持續執行一段時間業務，通過綜合分析交易執行指標和資源監控指標來確定系統處理最大工作量強度效能的過程。 疲勞強度測試可以採用工具自動化的方式進行測試，也可以手工編寫程式測試，其中後者佔的比例較大。

一般情況下以伺服器能夠正常穩定響應請求的最大併發使用者數進行一定時間的疲勞測試，獲取交易執行指標資料和系統資源監控資料。如出現錯誤導致測試不能成功執行，則及時調整測試指標，例如降低使用者數、縮短測試周期等。還有一種情況的疲勞測試是對當前系統性能的評估，用系統正常業務情況下併發使用者數為基礎，進行一定時間的疲勞測試。

大資料量測試可以分為兩種型別：針對某些系統儲存、傳輸、統計、查詢等業務進行大資料量的獨立資料量測試;與壓力效能測試、負載效能測試、疲勞效能測試相結合的綜合資料量測試方案。大資料量測試的關鍵是測試資料的準備，可以依靠工具準備測試資料。

　　5.如果客戶沒有給你效能指數時，你怎麼來開展效能測試工作?

如果客戶沒有提出明確的效能指標，可以按照慣例和經驗設定，需要和PM協商，一般由PM確認，QA負責給出建議。

舉例說一個Server端程式，要求峰值時CPU和MEM消耗在75%以下，而一個頁面的訪問響應時間一般認為使用者的忍耐時間是3-5秒以內，這些要參考實際的應用來確定使用者規模、操作頻率、同時線上數等。

　　6.有沒有做過介面測試，是如何做的?

通過編寫測試程式， 獲得介面指標， 逐個呼叫介面函式驗證其正確性， 及失敗操作

　　7.測試過程中是如何來保證軟體質量的?

測試用例編寫完畢後要加強評審的力度，確保測試用例覆蓋所有需求點

執行測試過程中注意做小結檢查覆蓋情況、審視所提缺陷質量，複測時應注意相關模組的測試

測試時間寬裕的話可以做交叉測試，用以確保測試質量。

　　8.測試方案都寫什麼內容?

1概述

2被測物件分析

3應測試的特性

4不被測試的特性

5總體設計方法

6測試模型

6.1測試組網圖

6.2結構/物件關係圖

6.3測試原理

6.4操作規程

7測試需求

7.1環境需求

7.2被測物件需求

7.3測試工具需求

7.4測試程式碼需求

7.5資料需求

7.6其它需求

8測試設計

8.1工具設計

8.2測試程式碼設計

8.3用例設計

8.3.1設計原則

8.3.2測試專案

　　9.附錄

(測試方案要求根據《SRS》上的每個需求點設計出包括需求點簡介，測試思路和詳細測試方法三部分的方案) 以往華為測試方案　　目錄如下：

第1章 技術方案

1.1. 測試需求描述

1.1.1. 測試型別分析

1.1.2. 測試內容

1.2. 缺陷分類

1.3. 缺陷級別

第2章 SOW及規格的應答

2.1. 測試需求應答

2.2. 交付件應答

2.2.1. 軟體交付件應答

2.2.2. 非軟體交付件應答

2.3. 專案里程碑專案完成時間應答

2.4. 質量目標應答

2.5. 驗收標準應答

2.6. 限制應答

2.6.1. 合作供應商人員組織應答

2.6.2. 硬體裝置應答

2.6.3. 合作專案開發場地應答

第3章 類似專案成功案例

第4章 專案詳細工作計劃

第5章 專案估算

　　9.測試方案和測試計劃的區別

測試方案是技術性的;測試計劃更多是管理性的。

測試計劃主要要考慮測試的技術可行性、關鍵技術、資源投入、進度安排、風險管理、配置管理、輸入輸出等。測試計劃更多地供高層　　管理者決策時做參考;同時對後續測試工作開展起指導作用。

在一些小專案中，可能只需要一個測試方案，測試計劃內容相對較少，可以與測試方案合併進行;而一些大專案中，也許要設計數十個測試方案，這就需要一個提綱挈領的東西了，這就是測試計劃的作用。

　　10.測試用例是根據什麼寫的?

系統測試用例根據需求和設計編寫

(華為的SDV測試用例是根據《測試方案》和測試策略來編寫的)

　　11.是怎麼來設計測試用例的?

答：先熟悉系統需求，把握測試要點，設計用例的原則首先是要覆蓋每個需求點，可以通過填寫需求跟蹤矩陣來保證覆蓋。

黑盒測試的測試用例設計方法：等價類劃分法、 邊界值分析法、錯誤推測法、因果圖。

　　12.有沒有測過手機終端的專案?

根據實際情況回答，如果沒有測試過，可以回答，公司有過類似業務。

手機終端測試

　　13.對測試工作的認識?

答：軟體測試是軟體開發過程的重要組成部分，是用來確認一個程式的品質或效能是否符合開發之前所提出的一些要求。軟體測試就是在軟體投入執行前，對軟體需求分析、設計規格說明和編碼的最終複審，是軟體質量保證的關鍵步驟。軟體測試是為了發現錯誤而執行程式的過程。

軟體測試在軟體生存期中橫跨兩個階段：通常在編寫出每一個模組之後就對它做必要的測試(稱為單元測試)。編碼和單元測試屬於軟體生命週期中的同一個階段。在結束這個階段後對軟體系統還要進行各種綜合測試，這是軟體生命週期的另一個獨立階段，即測試階段。

華為獨立外包測試一般包括ST(系統測試)和SDV(詳細設計驗證)兩個階段。

　　14.缺陷是怎麼管理的?

答：我們採用了Rational ClearQuest來管理缺陷。

測試人員執行測試，發現缺陷，錄入CQ，要求填寫專案名稱、子系統名稱、模組名稱、缺陷標題、缺陷描述(描述場景、現象)、缺陷級別、提出人等。狀態：已提交。

專案經理或開發組長確認缺陷後分配給開發人員，狀態：已分配。

開發人員修復缺陷完成後，將修復缺陷所花費的時間填寫的Schedule中，缺陷的產生原因填寫在備註中，因採用UCM模式，所有造成該缺陷的錯誤程式碼檔案，在UCM檢視中可以統計。狀態：已處理。

測試人員複測，如缺陷已經修復，則關閉缺陷，狀態：已關閉。如缺陷仍然存在，則修改狀態為已分配。

當缺陷存在爭議時，開發組長或開發人員可以申請否決，由專案經理、技術經理、測試負責人、相關開發人員和測試人員共同決定缺陷是否可以否決。狀態：已申請否決、已否決。

當前不能修復，或當前版本無法解決的缺陷可以申請延期，狀態：已申請延期、已延期。

　　15.介紹一下測試流程。

答：專案啟動後進行需求培訓，測試人員儘早的參與到專案需求的培訓和評審，也就是測試工作應該從需求階段開始介入。

專案經理編寫《專案計劃》，開發人員產出《需求規格說明書》，這時測試組長就要根據《專案計劃》開始編寫《測試計劃》，其中包括人員，軟體硬體資源，測試點，進度安排和風險識別等內容。

《測試計劃》編寫完成後需要進行評審，參與人員有專案經理，測試經理。測試組長需要根據評審意見修改《測試計劃》，並上傳到CC上，由配置管理員管理。

待開發人員把《需求規格說明書》歸納好並打了基線，測試組長開始組織測試成員編寫《測試方案》，《測試方案》編寫完成後也需要進行評審，評審人員包括專案經理，開發人員，測試經理，測試組長，測試成員;測試組長組織測試成員修改測試方案，直到評審通過後才進入下個階段――編寫測試用例。

測試用例是根據《測試方案》來編寫的，通過《測試方案》階段，測試人員對整個系統需求有了詳細的理解。這時開始編寫用例才能保證用例的可執行和對需求的覆蓋。測試用例需要包括測試項，用例級別，預置條件，操作步驟和預期結果。其中操作步驟和預期結果需要編寫詳細和明確。測試用例應該覆蓋測試方案，而測試方案又覆蓋了測試需求點，這樣才能保證客戶需求不遺漏。同樣，測試用例也需要通過開發人員，測試人員的評審，測試組長也需要組織測試人員對測試用例進行修改，直到評審通過。

在我們編寫測試用例的階段，開發人員基本完成程式碼的編寫，同時完成單元測試。提交測試中心後根據《測試計劃》進度安排，測試組長組織進行多輪次的測試，每輪測試完成後測試組長需要編寫測試報告，其中包括用例執行通過情況，缺陷分佈情況，缺陷產生原因，測試中的風險等等，這時測試人員就修改增加測試用例。待到開發修改完bug並轉來新的測試版本，測試人員開始進行第二輪的系統測試，首先回歸完問題單，再繼續進行測試，編寫第二輪的測試報告，如此迴圈下去，直到系統測試結束。

　　16.一個關於測試方案評審的分歧

我們原本的流程是完成方案包括用例後進行評審，華為的建議是，在測試方案(即測試人員總結出測試重點等)之後，即進行評審，不能等全部用例完成。

關於版本缺陷密度的問題：問有沒有統計。如果CQ中正常登記的話，是可以利用工具統計出來。CQ還可以根據需要定製查詢。

關於測試提交標準：我講了公司的標準，他說客戶也會有自己的標準。我回復說是可以依據客戶標準進行調整，

　　17.對Unix系統是否熟識，是否會運用Informix 資料庫。

ls 列出指定目錄下的檔案，預設目錄為當前目錄 ./

pwd 顯示當前的工作目錄

cd 回到註冊進入時的目錄 cd /tmp 進入 /tmp 目錄 cd ../ 進入上級目錄

mkdir [-m 模式] [-p] 目錄名 建立目錄

mkdir tmp 在當前目錄下建立子目錄 tmp

mkdir -m 777 /tmp/abc 用所有使用者可讀可寫可執行的存取模式

建立目錄 /tmp/aaa ，存取模式參看命令 chmod

mkdir -p /tmp/a/b/c 建立目錄 /tmp/a/b/c ，若不存在目錄 /tmp/a

及/tmp/a/b 則建立之

mv [-f] [-i] 檔案1 [檔案2...] 目標 將檔案移動至目標，若目標是檔名，則相當於檔案改名

rm [-f] [-i] 檔案...或 rm -r [-f] [-i] 目錄名... [檔案] 用來刪除檔案或目錄

cmp [-l] [-s] 檔案1 檔案2 比較兩個檔案，

diff [-be] 檔案1 檔案2 比較兩個文字檔案，將不同的行列出來

pack 檔案... 將指定檔案轉儲為壓縮格式，檔名後加 .z ， 檔案存取模式，訪問時間，修改時間等均不變

pcat 檔案... 顯示輸出壓縮檔案

unpack 檔案... 將壓縮後的檔案解壓後轉儲為壓縮前的格式

vi [-wn] [-R] 檔案...

vi 是一個基於行編輯器 ex 上的全螢幕編輯器，可以在vi 中使用 ex，ed的全部命令，vi選項中 -wn 指將編輯視窗大小置為n行，-R 為將編輯的檔案置為只讀模式， vi 工作模式分為命令模式和輸入模式，一般情況下在命令模式下，可敲入vi命令，進入輸入模式下時可以編輯要編輯的文字，命令 a A i I o O c C s S R 可進入輸入模式，在輸入模式下按 ESC 鍵可推出輸入模式，回到命令模式，在命令模式中敲入： 命令，則可進入ex方式，在螢幕底部出現提示符 ： ，此時可使用任意ex命令，螢幕底行也用來作/ ? ! 命令的提示行，大多數命令可以在其前面加數字，表示命令執行的重複次數，下面簡單介紹一下vi 的命令集，^ 表示(CTRL)鍵

quit 退出bc

　　18.對於金融業務系統的測試，有哪些要點?

首先要根據客戶的需求文件，保證業務邏輯正確、符合要求。舉例授信審批流程來說，主要測試前面崗位錄入的數值資料傳遞到流程最後一個崗位後能正確顯示;以及操作員的許可權控制嚴格按照需求要求，不同的許可權除了在流程中的作用不同，所能執行的功能也不同

　　19.平時測試時怎麼保證頁面間傳值正確?

除了看頁面的顯示，還要連線資料庫對相應的表進行查詢，對資料庫表結構不瞭解時，會詢問相關的開發人員。

　　20.對於系統執行產生的日誌檔案是否關注?

答：只是適當瞭解，公司對於伺服器的維護安排有人負責。

　　21.銀行的系統是否在同一個頁面，用不同許可權的業務員登陸會顯示不同的結果?會不會因為自己配置的不合理而產生錯誤?

1)有同一個頁面用不同許可權的業務員顯示不同結果的情況，主要表現為所能執行的操作不同，所能查詢資料的範圍不同。

2) 對於不確定的錯誤，一般不會立刻當缺陷處理，需要跟相關人員溝通，確認了並非自己部署得不正確的原因，才會提缺陷。這個很重要。