華為都在用的軟件測試面試題,你會做幾道？

1、怎么來設(shè)計測試方案?

根據(jù)測試需求(包括功能需求和非功能性需求)，識別測試要點，識別測試環(huán)境要求，安排測試輪次，根據(jù)項目計劃和開發(fā)計劃做整體的測試安排。

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

不被測試的特性：由于資源、進(jìn)度等方面原因，本次測試不列入測試范圍的特性;

測試組網(wǎng)圖：進(jìn)行本次系統(tǒng)測試所需要的軟硬件設(shè)備、配置數(shù)據(jù)已及相互間的邏輯、物理連接。今后測試執(zhí)行時需要依據(jù)這個組網(wǎng)圖來進(jìn)行環(huán)境的搭建。

2、如果給你一個B/S系統(tǒng)你怎么來進(jìn)行測試?

此題答案還可用于回答測試流程，測試流程題亦可參考15題。

閱讀系統(tǒng)需求，充分理解需求，記錄問題，并與項目需求人員充分溝通。

編寫測試需求，包括系統(tǒng)功能和非功能測試要點、測試類型、測試進(jìn)度質(zhì)量要求等。

制定測試計劃，包括熟悉測試業(yè)務(wù)、設(shè)計測試用例、執(zhí)行測試用例、進(jìn)行測試小結(jié)、編寫測試報告，任務(wù)顆粒度一般應(yīng)小于5人天

編寫測試用例，根據(jù)測試方案設(shè)計用例，即便沒有明確的性能和安全測試要求，也應(yīng)識別進(jìn)行此兩項測試。

執(zhí)行軟件測試，

進(jìn)行測試小結(jié)，如果測試持續(xù)時間較長，每個版本間隙總結(jié)本輪測試。

編寫測試報告，總結(jié)測試過程，匯總度量數(shù)據(jù)。

3、怎么進(jìn)行工作流的測試?

把握需求，找準(zhǔn)結(jié)點，理清流程，畫出流轉(zhuǎn)圖，弄清節(jié)點間的數(shù)據(jù)流轉(zhuǎn)，設(shè)計測試用例的時候必須覆蓋所有可能的流程。

工作流：

如果問到有沒有做過，根據(jù)對工作流的了解情況回答，如果比較了解，可以把參與的某個項目中說上一些有工作流的，如果不是很了解就說沒有做過，但是學(xué)習(xí)過相關(guān)知識。

4、做性能測試的時候都需要關(guān)注哪些參數(shù)?

并發(fā)訪問量，服務(wù)器響應(yīng)時間(最小、平均、最大)

并發(fā)性能測試的過程是一個負(fù)載測試和壓力測試的過程，即逐漸增加負(fù)載，直到系統(tǒng)的瓶頸或者不能接收的性能點，通過綜合分析交易執(zhí)行指標(biāo)和資源監(jiān)控指標(biāo)來確定系統(tǒng)并發(fā)性能的過程。

負(fù)載測試(Load Testing)是確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測試當(dāng)負(fù)載逐漸增加時，系統(tǒng)組成部分的相應(yīng)輸出項，例如通過量、響應(yīng)時間、CPU負(fù)載、內(nèi)存使用等來決定系統(tǒng)的性能。

負(fù)載測試是一個分析軟件應(yīng)用程序和支撐架構(gòu)、模擬真實環(huán)境的使用，從而來確定能夠接收的性能過程。壓力測試(Stress Testing)是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。

疲勞測試是采用系統(tǒng)穩(wěn)定運(yùn)行情況下能夠支持的最大并發(fā)用戶數(shù)，持續(xù)執(zhí)行一段時間業(yè)務(wù)，通過綜合分析交易執(zhí)行指標(biāo)和資源監(jiān)控指標(biāo)來確定系統(tǒng)處理最大工作量強(qiáng)度性能的過程。 疲勞強(qiáng)度測試可以采用工具自動化的方式進(jìn)行測試，也可以手工編寫程序測試，其中后者占的比例較大。

一般情況下以服務(wù)器能夠正常穩(wěn)定響應(yīng)請求的最大并發(fā)用戶數(shù)進(jìn)行一定時間的疲勞測試，獲取交易執(zhí)行指標(biāo)數(shù)據(jù)和系統(tǒng)資源監(jiān)控數(shù)據(jù)。如出現(xiàn)錯誤導(dǎo)致測試不能成功執(zhí)行，則及時調(diào)整測試指標(biāo)，例如降低用戶數(shù)、縮短測試周期等。還有一種情況的疲勞測試是對當(dāng)前系統(tǒng)性能的評估，用系統(tǒng)正常業(yè)務(wù)情況下并發(fā)用戶數(shù)為基礎(chǔ)，進(jìn)行一定時間的疲勞測試。

大數(shù)據(jù)量測試可以分為兩種類型：針對某些系統(tǒng)存儲、傳輸、統(tǒng)計、查詢等業(yè)務(wù)進(jìn)行大數(shù)據(jù)量的獨(dú)立數(shù)據(jù)量測試;與壓力性能測試、負(fù)載性能測試、疲勞性能測試相結(jié)合的綜合數(shù)據(jù)量測試方案。大數(shù)據(jù)量測試的關(guān)鍵是測試數(shù)據(jù)的準(zhǔn)備，可以依靠工具準(zhǔn)備測試數(shù)據(jù)。

5、客戶沒給性能指數(shù)，怎么開展性能測試?

如果客戶沒有提出明確的性能指標(biāo)，可以按照慣例和經(jīng)驗設(shè)置，需要和PM協(xié)商，一般由PM確認(rèn)，QA負(fù)責(zé)給出建議。

舉例說一個Server端程序，要求峰值時CPU和MEM消耗在75%以下，而一個頁面的訪問響應(yīng)時間一般認(rèn)為用戶的忍耐時間是3-5秒以內(nèi)，這些要參考實際的應(yīng)用來確定用戶規(guī)模、操作頻率、同時在線數(shù)等。

6、有沒有做過接口測試，是如何做的?

通過編寫測試程序， 獲得接口指針， 逐個調(diào)用接口函數(shù)驗證其正確性， 及失敗操作

7、測試過程中是如何來保證軟件質(zhì)量的?

測試用例編寫完畢后要加強(qiáng)評審的力度，確保測試用例覆蓋所有需求點

執(zhí)行測試過程中注意做小結(jié)檢查覆蓋情況、審視所提缺陷質(zhì)量，復(fù)測時應(yīng)注意相關(guān)模塊的測試

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

8、測試方案都寫什么內(nèi)容?

1概述

2被測對象分析

3應(yīng)測試的特性

4不被測試的特性

5總體設(shè)計方法

6測試模型

6.1測試組網(wǎng)圖

6.2結(jié)構(gòu)/對象關(guān)系圖

6.3測試原理

6.4操作規(guī)程

7測試需求

7.1環(huán)境需求

7.2被測對象需求

7.3測試工具需求

7.4測試代碼需求

7.5數(shù)據(jù)需求

7.6其它需求

8測試設(shè)計

8.1工具設(shè)計

8.2測試代碼設(shè)計

8.3用例設(shè)計

8.3.1設(shè)計原則

8.3.2測試項目

9.附錄

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

第1章 技術(shù)方案

1.1. 測試需求描述

1.1.1. 測試類型分析

1.1.2. 測試內(nèi)容

1.2. 缺陷分類

1.3. 缺陷級別

第2章 SOW及規(guī)格的應(yīng)答

2.1. 測試需求應(yīng)答

2.2. 交付件應(yīng)答

2.2.1. 軟件交付件應(yīng)答

2.2.2. 非軟件交付件應(yīng)答

2.3. 項目里程碑項目完成時間應(yīng)答

2.4. 質(zhì)量目標(biāo)應(yīng)答

2.5. 驗收標(biāo)準(zhǔn)應(yīng)答

2.6. 限制應(yīng)答

2.6.1. 合作供應(yīng)商人員組織應(yīng)答

2.6.2. 硬件設(shè)備應(yīng)答

2.6.3. 合作項目開發(fā)場地應(yīng)答

第3章 類似項目成功案例

第4章 項目詳細(xì)工作計劃

第5章 項目估算

9、測試方案和測試計劃的區(qū)別?

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

測試計劃主要要考慮測試的技術(shù)可行性、關(guān)鍵技術(shù)、資源投入、進(jìn)度安排、風(fēng)險管理、配置管理、輸入輸出等。

測試計劃更多地供高層、管理者決策時做參考;同時對后續(xù)測試工作開展起指導(dǎo)作用。

在一些小項目中，可能只需要一個測試方案，測試計劃內(nèi)容相對較少，可以與測試方案合并進(jìn)行;而一些大項目中，也許要設(shè)計數(shù)十個測試方案，這就需要一個提綱挈領(lǐng)的東西了，這就是測試計劃的作用。

10、測試用例是根據(jù)什么寫的?

系統(tǒng)測試用例根據(jù)需求和設(shè)計編寫

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

11、是怎么來設(shè)計測試用例的?

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

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

12、有沒有測過手機(jī)終端的項目?

根據(jù)實際情況回答，如果沒有測試過，可以回答，公司有過類似業(yè)務(wù)。

手機(jī)終端測試

13、對測試工作的認(rèn)識是什么?

答：軟件測試是軟件開發(fā)過程的重要組成部分，是用來確認(rèn)一個程序的品質(zhì)或性能是否符合開發(fā)之前所提出的一些要求。軟件測試就是在軟件投入運(yùn)行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。

軟件測試在軟件生存期中橫跨兩個階段：通常在編寫出每一個模塊之后就對它做必要的測試(稱為單元測試)。編碼和單元測試屬于軟件生命周期中的同一個階段。在結(jié)束這個階段后對軟件系統(tǒng)還要進(jìn)行各種綜合測試，這是軟件生命周期的另一個獨(dú)立階段，即測試階段。

華為獨(dú)立外包測試一般包括ST(系統(tǒng)測試)和SDV(詳細(xì)設(shè)計驗證)兩個階段。

14、缺陷是怎么管理的?

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

測試人員執(zhí)行測試，發(fā)現(xiàn)缺陷，錄入CQ，要求填寫項目名稱、子系統(tǒng)名稱、模塊名稱、缺陷標(biāo)題、缺陷描述(描述場景、現(xiàn)象)、缺陷級別、提出人等。狀態(tài)：已提交。

項目經(jīng)理或開發(fā)組長確認(rèn)缺陷后分配給開發(fā)人員，狀態(tài)：已分配。

開發(fā)人員修復(fù)缺陷完成后，將修復(fù)缺陷所花費(fèi)的時間填寫的Schedule中，缺陷的產(chǎn)生原因填寫在備注中，因采用UCM模式，所有造成該缺陷的錯誤代碼文件，在UCM視圖中可以統(tǒng)計。狀態(tài)：已處理。

測試人員復(fù)測，如缺陷已經(jīng)修復(fù)，則關(guān)閉缺陷，狀態(tài)：已關(guān)閉。如缺陷仍然存在，則修改狀態(tài)為已分配。

當(dāng)缺陷存在爭議時，開發(fā)組長或開發(fā)人員可以申請否決，由項目經(jīng)理、技術(shù)經(jīng)理、測試負(fù)責(zé)人、相關(guān)開發(fā)人員和測試人員共同決定缺陷是否可以否決。狀態(tài)：已申請否決、已否決。

當(dāng)前不能修復(fù)，或當(dāng)前版本無法解決的缺陷可以申請延期，狀態(tài)：已申請延期、已延期。

15、介紹一下測試流程：

答：項目啟動后進(jìn)行需求培訓(xùn)，測試人員盡早的參與到項目需求的培訓(xùn)和評審，也就是測試工作應(yīng)該從需求階段開始介入。

項目經(jīng)理編寫《項目計劃》，開發(fā)人員產(chǎn)出《需求規(guī)格說明書》，這時測試組長就要根據(jù)《項目計劃》開始編寫《測試計劃》，其中包括人員，軟件硬件資源，測試點，進(jìn)度安排和風(fēng)險識別等內(nèi)容?！稖y試計劃》編寫完成后需要進(jìn)行評審，參與人員有項目經(jīng)理，測試經(jīng)理。測試組長需要根據(jù)評審意見修改《測試計劃》，并上傳到CC上，由配置管理員管理。

待開發(fā)人員把《需求規(guī)格說明書》歸納好并打了基線，測試組長開始組織測試成員編寫《測試方案》，《測試方案》編寫完成后也需要進(jìn)行評審，評審人員包括項目經(jīng)理，開發(fā)人員，測試經(jīng)理，測試組長，測試成員;測試組長組織測試成員修改測試方案，直到評審?fù)ㄟ^后才進(jìn)入下個階段――編寫測試用例。

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

在我們編寫測試用例的階段，開發(fā)人員基本完成代碼的編寫，同時完成單元測試。提交測試中心后根據(jù)《測試計劃》進(jìn)度安排，測試組長組織進(jìn)行多輪次的測試，每輪測試完成后測試組長需要編寫測試報告，其中包括用例執(zhí)行通過情況，缺陷分布情況，缺陷產(chǎn)生原因，測試中的風(fēng)險等等，這時測試人員就修改增加測試用例。待到開發(fā)修改完bug并轉(zhuǎn)來新的測試版本，測試人員開始進(jìn)行第二輪的系統(tǒng)測試，首先回歸完問題單，再繼續(xù)進(jìn)行測試，編寫第二輪的測試報告，如此循環(huán)下去，直到系統(tǒng)測試結(jié)束。

16、一個關(guān)于測試方案評審的分歧?

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

關(guān)于版本缺陷密度的問題：問有沒有統(tǒng)計。如果CQ中正常登記的話，是可以利用工具統(tǒng)計出來。CQ還可以根據(jù)需要定制查詢。關(guān)于測試提交標(biāo)準(zhǔn)：我講了公司的標(biāo)準(zhǔn)，他說客戶也會有自己的標(biāo)準(zhǔn)。我回復(fù)說是可以依據(jù)客戶標(biāo)準(zhǔn)進(jìn)行調(diào)整。

17、Unix系統(tǒng)熟識，運(yùn)用Informix 數(shù)據(jù)庫。

ls 列出指定目錄下的文件，缺省目錄為當(dāng)前目錄 ./

pwd 顯示當(dāng)前的工作目錄

cd 回到注冊進(jìn)入時的目錄 cd /tmp 進(jìn)入 /tmp 目錄 cd ../ 進(jìn)入上級目錄

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

mkdir tmp 在當(dāng)前目錄下建立子目錄 tmp

mkdir -m 777 /tmp/abc 用所有用戶可讀可寫可執(zhí)行的存取模式

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

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

及/tmp/a/b 則建立之

mv [-f] [-i] 文件1 [文件2...] 目標(biāo) 將文件移動至目標(biāo)，若目標(biāo)是文件名，則相當(dāng)于文件改名

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

cmp [-l] [-s] 文件1 文件2 比較兩個文件，

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

pack 文件... 將指定文件轉(zhuǎn)儲為壓縮格式，文件名后加 .z ， 文件存取模式，訪問時間，修改時間等均不變

pcat 文件... 顯示輸出壓縮文件

unpack 文件... 將壓縮后的文件解壓后轉(zhuǎn)儲為壓縮前的格式

vi [-wn] [-R] 文件...

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

quit 退出bc

18、金融業(yè)務(wù)系統(tǒng)的測試，有哪些要點?

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

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

除了看頁面的顯示，還要連接數(shù)據(jù)庫對相應(yīng)的表進(jìn)行查詢，對數(shù)據(jù)庫表結(jié)構(gòu)不了解時，會詢問相關(guān)的開發(fā)人員。

20、對于系統(tǒng)運(yùn)行產(chǎn)生的日志文件是否關(guān)注?

答：只是適當(dāng)了解，公司對于服務(wù)器的維護(hù)安排有人負(fù)責(zé)。

21、銀行的系統(tǒng)是否在同一個頁面，用不同權(quán)限的業(yè)務(wù)員登陸會顯示不同的結(jié)果?會不會因為自己配置的不合理而產(chǎn)生錯誤?

1)有同一個頁面用不同權(quán)限的業(yè)務(wù)員顯示不同結(jié)果的情況，主要表現(xiàn)為所能執(zhí)行的操作不同，所能查詢數(shù)據(jù)的范圍不同。

2) 對于不確定的錯誤，一般不會立刻當(dāng)缺陷處理，需要跟相關(guān)人員溝通，確認(rèn)了并非自己部署得不正確的原因，才會提缺陷。這個很重要。