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

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

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

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

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

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

　　12.有沒有測過手機(jī)終端的項(xiàng)目?

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

　　手機(jī)終端測試

　　13.對測試工作的認(rèn)識?

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

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

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

　　14.缺陷是怎么管理的?

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

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

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

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

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

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

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

　　15.介紹一下測試流程。

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

　　項(xiàng)目經(jīng)理編寫《項(xiàng)目計(jì)劃》，開發(fā)人員產(chǎn)出《需求規(guī)格說明書》，這時(shí)測試組長就要根據(jù)《項(xiàng)目計(jì)劃》開始編寫《測試計(jì)劃》，其中包括人員，軟件硬件資源，測試點(diǎn)，進(jìn)度安排和風(fēng)險(xiǎn)識別等內(nèi)容。

　　《測試計(jì)劃》編寫完成后需要進(jìn)行評審，參與人員有項(xiàng)目經(jīng)理，測試經(jīng)理。測試組長需要根據(jù)評審意見修改《測試計(jì)劃》，并上傳到CC上，由配置管理員管理。

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

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

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

　　16.一個(gè)關(guān)于測試方案評審的分歧

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

　　關(guān)于版本缺陷密度的問題：問有沒有統(tǒng)計(jì)。如果CQ中正常登記的話，是可以利用工具統(tǒng)計(jì)出來。CQ還可以根據(jù)需要定制查詢。

　　關(guān)于測試提交標(biāo)準(zhǔn)：我講了公司的標(biāo)準(zhǔn)，他說客戶也會(huì)有自己的標(biāo)準(zhǔn)。我回復(fù)說是可以依據(jù)客戶標(biāo)準(zhǔn)進(jìn)行調(diào)整，

　　17.對Unix系統(tǒng)是否熟識，是否會(huì)運(yùn)用Informix 數(shù)據(jù)庫。

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

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

　　cd 回到注冊進(jìn)入時(shí)的目錄 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) 將文件移動(dòng)至目標(biāo)，若目標(biāo)是文件名，則相當(dāng)于文件改名

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

　　cmp [-l] [-s] 文件1 文件2 比較兩個(gè)文件，

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

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

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