軟件測(cè)試常見問題

1、1、哪個(gè)階段引入的bug最多？哪個(gè)最少？需求分析階段引入的bug最多（大概占bug總數(shù)的55%左右）其次是設(shè)計(jì)階段（大概占bug總數(shù)的25%左右）引入bug最少的是編碼階段（大概占bug總數(shù)的15%左右）最后還有5%左右的bug是由兼容性問題或配置原因造成的。由此總結(jié)：（1）測(cè)試不能只測(cè)程序，文檔也必須要測(cè)。測(cè)試應(yīng)符合“盡早測(cè)試原則”和“不斷測(cè)試原則”。2、如何識(shí)別缺陷？1、參考需求相關(guān)文檔-與需求不符就是bug2、參考缺陷的5條定義說明：定義與順序無關(guān)，只要滿足其中任何一條就是bug。（1）需求要求的功能沒有實(shí)現(xiàn)。（2）實(shí)現(xiàn)了需求沒有要求的功能。（畫蛇添足）（3）軟件中出現(xiàn)了指明不應(yīng)該出現(xiàn)的

2、錯(cuò)誤。（4）需求雖未明確說明，但是應(yīng)該實(shí)現(xiàn)的功能沒有實(shí)現(xiàn)。（5）軟件不易使用，難以理解，運(yùn)行緩慢等，站在用戶角度上，一切不好的地方。3、參考測(cè)試用例中的預(yù)期結(jié)果-實(shí)際結(jié)果與預(yù)期結(jié)果不一致就是bug4、通過與同事、開發(fā)人員、產(chǎn)品經(jīng)理、客戶等溝通討論來確定bug。3、OS的作用？操作系統(tǒng)可以對(duì)計(jì)算機(jī)的軟件和硬件進(jìn)行統(tǒng)一管理。4、裸機(jī)中有軟件嗎？裸機(jī)中有軟件。BIOS （basic input output system基礎(chǔ)輸入輸出系統(tǒng)）程序被安裝在 計(jì)算機(jī)主板的CMOS芯片中。計(jì)算機(jī)通電后，“BIOS”程序首先獲得控制權(quán)。對(duì)計(jì)算機(jī)進(jìn)行“上電自檢”-BIOS首先獲 得計(jì)算機(jī)的控制權(quán)，檢查硬件設(shè)備的連

3、接情況是否完好，如果檢查沒有問題，就將控制 權(quán)轉(zhuǎn)交給OS;如果硬件連接有問題，就啟動(dòng)蜂鳴器，發(fā)出報(bào)警音，同時(shí)阻止OS啟動(dòng)。5、c/s和b/s的區(qū)別？c/s :客戶端需要安裝專門的客戶端程序，才能享受服務(wù)器提供的服務(wù)。例如：QQ、 滴滴打車等B/S :客戶端無需安裝專門的客戶端程序，只需要有公共的瀏覽器，在瀏覽器中輸入 不同的網(wǎng)址就可以享受不同服務(wù)器提供的服務(wù)。例如：百度網(wǎng)站等6、軟件項(xiàng)目的測(cè)試流程？步驟1：需求分析步驟2 :制定測(cè)試計(jì)劃（問題：測(cè)試計(jì)劃的主要組成）步驟3 :設(shè)計(jì)測(cè)試的過程（分析設(shè)計(jì)測(cè)試用例）步驟4：執(zhí)行測(cè)試，記錄測(cè)試的結(jié)果（通過pass，失敗failed）步驟5 :記錄缺陷，跟

4、蹤和管理缺陷（缺陷報(bào)告）步驟6 :測(cè)試總結(jié)（提交測(cè)試報(bào)告測(cè)試總結(jié)報(bào)告）要求：必須熟練掌握，并且有項(xiàng)目經(jīng)驗(yàn)后，要能夠結(jié)合項(xiàng)目說明。7、你們公司缺陷報(bào)告都包含什么？1）缺陷編號(hào)（defect ID）記錄發(fā)現(xiàn)bug的順序號(hào)在工具中缺陷編號(hào)是自動(dòng)生成的，可以唯一標(biāo)識(shí)每條缺陷。說明：在企業(yè)中項(xiàng)目的缺陷是統(tǒng)一管理的，所以編號(hào)是統(tǒng)一生成，不是只生成自己的。2）缺陷標(biāo)題（summary）簡明扼要的將缺陷描述出來（概括）說明：沒有標(biāo)準(zhǔn)答案，老師給的也只是參考。3）缺陷發(fā)現(xiàn)者/創(chuàng)建者（detected by）測(cè)試人員發(fā)現(xiàn)bug，填寫自己的工作賬號(hào)4）提交缺陷的日期（detected on date）注意：發(fā)現(xiàn)缺陷

5、后應(yīng)及時(shí)提交缺陷。說明：1、發(fā)現(xiàn)缺陷應(yīng)確認(rèn)審核，盡量避免提交“假bug2.缺陷“審核”后，不要人為 延誤應(yīng)及時(shí)提交。5）指派給誰（assigned to）指派過程：首先：測(cè)試人員一開發(fā)方負(fù)責(zé)人接下來：開發(fā)方負(fù)責(zé)人一具體負(fù)責(zé)的開發(fā)人員6）功能模塊（subject）定位在哪個(gè)模塊中發(fā)現(xiàn)的該bug說明：開發(fā)方負(fù)責(zé)人可以通過功能模塊，明確解決該bug的對(duì)應(yīng)開發(fā)人員。7）版本（detected in release）說明：在軟件研發(fā)過程中出現(xiàn)的若干臨時(shí)版本，和軟件最終發(fā)布的版本都是版本， 都需要測(cè)試。8）狀態(tài)（status）表明該缺陷處于怎樣的處理情況。缺陷的狀態(tài)：新的（new）激活的（open）已解決

6、的（fixed）關(guān)閉的（closed）被拒絕的（rejected）重新激活的（reopen）9）缺陷的嚴(yán)重程度（severity）表明缺陷有多糟糕，對(duì)程序的影響有多壞。嚴(yán)重級(jí)別：（1,2,3,4）致命的（urgent）嚴(yán)重的（high）中等的（medium）-最多建議性的小問題（low）發(fā)現(xiàn)問題：嚴(yán)重級(jí)別的定義過于籠統(tǒng)，容易在實(shí)際工作中引起爭議，所以公司通常會(huì)編 寫級(jí)別的詳細(xì)說明，進(jìn)一步規(guī)范級(jí)別的劃分。注意：嚴(yán)重級(jí)別定義應(yīng)專業(yè)、準(zhǔn)確，不應(yīng)為了引起開發(fā)方重視而故意夸大。不同公司、項(xiàng)目組嚴(yán)重級(jí)別詳細(xì)說明可能不同，工作中要注意參考。10）缺陷的優(yōu)先級(jí)（priority）表明的是希望或者建議開發(fā)方在什

7、么時(shí)候，什么版本解決該bug。優(yōu)先級(jí)的級(jí)別：立即解決（urgent）下一個(gè)版本解決（high）-常用軟件產(chǎn)品發(fā)布之前解決（medium）盡量在軟件發(fā)布之前解決（low）注意：對(duì)于優(yōu)先級(jí)不同公司的詳細(xì)說明可能不同，要注意參考。11）缺陷描述（description）通過將發(fā)現(xiàn)的過程和數(shù)據(jù)記錄下來，使開發(fā)人員能夠重現(xiàn)該bug。（開發(fā)人員能看明 白）要求：邏輯要清晰，用語應(yīng)專業(yè)、準(zhǔn)確，描述應(yīng)易讀、易懂，在描述中不要出現(xiàn)任何 評(píng)價(jià)性的語言。如實(shí)記錄缺陷。8、什么是回歸測(cè)試？為什么要進(jìn)行回歸測(cè)試？回歸測(cè)試就是在當(dāng)前版本中，對(duì)上一個(gè)版本中測(cè)過的所有功能點(diǎn)，再重新測(cè)試一遍?；貧w測(cè)試的必要性：通過回歸測(cè)試驗(yàn)證

8、當(dāng)前版本中:新增加的功能對(duì)原有功能是否有 影響，帶來bug ；修復(fù)的bug是否同時(shí)帶來了新的問題?；貧w測(cè)試存在重復(fù)，建議使用自動(dòng)化的方式進(jìn)行，可以大大提高回歸測(cè)試效率。Rejected |9、缺陷的跟蹤管理過程（生命周期、一生、流程、步驟）？1、渺試人員提交缺路New5、測(cè)試人員返測(cè)映陷 通過開發(fā)人員和測(cè) 善人炭共同淡 不是Rejected |9、缺陷的跟蹤管理過程（生命周期、一生、流程、步驟）？1、渺試人員提交缺路New5、測(cè)試人員返測(cè)映陷 通過開發(fā)人員和測(cè) 善人炭共同淡 不是3、開發(fā)人員修改此缺陷4、抵陷修改完畢2、開苴統(tǒng)理瞼還此缺陷Closed步驟1：測(cè)試人員提交新的bug給開發(fā)方負(fù)責(zé)人

9、。步驟2 :開發(fā)方負(fù)責(zé)人審核bug，情況1 : bug審核通過，開發(fā)方負(fù)責(zé)人將會(huì)激活bug，并指派給相應(yīng)的開發(fā)人員。情況2 : bug審核未通過，開發(fā)方將拒絕bug。步驟3：開發(fā)人員解決bug，解決后將缺陷設(shè)置為“已解決”狀態(tài)。（待返測(cè)的bug）步驟4 :測(cè)試人員對(duì)已解決的bug進(jìn)行返測(cè)，情況1：返測(cè)通過，測(cè)試人員將bug關(guān)閉。情況2：返測(cè)未通過，測(cè)試人員將缺陷重新激活，并指派回開發(fā)人員繼續(xù)解決，直 到返測(cè)通過，bug關(guān)閉為止。10、關(guān)于嚴(yán)重程度和優(yōu)先級(jí)的面試題。Q1:影響優(yōu)先級(jí)的因素有哪些？（1）缺陷的嚴(yán)重程度，一般越嚴(yán)重，優(yōu)先級(jí)越高。（2）開發(fā)人員的開發(fā)壓力，開發(fā)壓力越小，解決bug的優(yōu)先

10、級(jí)越高。（3）缺陷的影響范圍，影響范圍越大，bug的優(yōu)先級(jí)越高。（4）解決bug的成本（時(shí)間），成本越小，優(yōu)先級(jí)越高。Q2 :缺陷的嚴(yán)重程度和優(yōu)先級(jí)一定是嚴(yán)格成正比關(guān)系嗎？缺陷的嚴(yán)重程度和優(yōu)先級(jí)不是嚴(yán)格成正比的，例如：界面的錯(cuò)別字，就是嚴(yán)重級(jí)別低, 但是優(yōu)先級(jí)高的情況。Q3 :優(yōu)先級(jí)和嚴(yán)重程度一旦確定后能改嗎？嚴(yán)重程度一旦確定不能修改；優(yōu)先級(jí)一般能改，而且經(jīng)常延后處理。Q4 :是否存在發(fā)布的軟件中，有bug是發(fā)現(xiàn)了但是沒有解決的情況？在發(fā)布的軟件中可能存在發(fā)現(xiàn)但是沒有解決的bug。此類bug應(yīng)通過“bug討論”，在 權(quán)衡解決的成本，和不解決是否給用戶帶來嚴(yán)重后果，以及是否會(huì)造成法律糾紛后才能

11、決定。關(guān)于此類bug，軟件企業(yè)通常通過后期升級(jí)版本或者打補(bǔ)丁的方式給予解決。11、隨機(jī)缺陷（隨機(jī)bug或不可重現(xiàn)bug）概念：隨機(jī)缺陷就是按照相同的操作過程操作，時(shí)有時(shí)無的bug。（always 一直/sometime 有時(shí)）12、測(cè)試人員如何處理隨機(jī)bug ?（1）隨機(jī)bug也必須要報(bào)告（2）測(cè)試人員在提交隨機(jī)bug時(shí)應(yīng)該說明該bug為隨機(jī)缺陷。測(cè)試人員應(yīng)盡量詳細(xì)的記錄發(fā)現(xiàn)隨機(jī)bug的過程（步驟，數(shù)據(jù)），并且盡量能夠 提供證跡（截圖或視頻）。測(cè)試人員應(yīng)盡量配合開發(fā)人員對(duì)隨機(jī)bug進(jìn)行缺陷調(diào)查，例如：配合保留測(cè)試環(huán) 境；配合提供隨機(jī)bug的出現(xiàn)頻率等?？梢约尤氚缀袦y(cè)試，參與到測(cè)試調(diào)查中。13、

12、測(cè)試用例/案例？主要組成：用例編號(hào)、測(cè)試目的、測(cè)試步驟（過程、數(shù)據(jù)）、預(yù)期結(jié)果等 編寫用例的注意事項(xiàng):（1 ）在編寫用例之前，應(yīng)明確用例編號(hào)的格式要求，還有如果用例帶有附件，附件的 命名，提交位置等。（2）用例必須要評(píng)審互評(píng)互審、測(cè)試評(píng)審會(huì)（小組）、甲方參與的評(píng)審會(huì)（3）編寫測(cè)試用例的要求基本要求：就是先能寫好一條用例。其他測(cè)試人員能夠順利執(zhí)行你寫的用例。高級(jí)要求：測(cè)試人員要能夠獨(dú)立完成測(cè)試的分析和設(shè)計(jì)，形成較為完善的測(cè)試方案 （思路）。標(biāo)準(zhǔn)：測(cè)試的覆蓋率高，遺漏bug少，效率高。14、測(cè)試用例的參考資料有？（如何沒有需求文檔應(yīng)該怎么測(cè)試？）1、用戶的需求（需求相關(guān)文檔）2、核心的技術(shù)文檔（測(cè)

13、試方不一定拿到，例如：開發(fā)與測(cè)試不是同一家公司）3、已開發(fā)的被測(cè)系統(tǒng)（工作中經(jīng)常參考被測(cè)系統(tǒng)測(cè)試，只參考需求大概只能完成20%-40%的測(cè)試設(shè)計(jì)）4、測(cè)試人員要與開發(fā)、產(chǎn)品經(jīng)理、客戶等淘通討論。另外要利用好網(wǎng)絡(luò)資源，查找資料，參考同類軟件產(chǎn)品等（說明：參考資源可能不齊全，測(cè)試人員應(yīng)利用一切可利用資源，盡自己所能測(cè)試）15、測(cè)試用例的作用？（理解）（1）編寫用例會(huì)提高測(cè)試的覆蓋率（測(cè)的更全）。（2）測(cè)試用例可以提高測(cè)試效率。（3）面對(duì)重復(fù)性的測(cè)試工作時(shí)，測(cè)試用例可以重復(fù)執(zhí)行。（例如：回歸測(cè)試）（4）利用測(cè)試用例可以監(jiān)督測(cè)試過程，評(píng)估測(cè)試質(zhì)量。（5）利用測(cè)試用例，可以縮短測(cè)試周期-如果項(xiàng)目升級(jí)或二

14、次開發(fā)時(shí)，保留原有 用例，只需對(duì)修改部分設(shè)計(jì)測(cè)試即可，大大縮短測(cè)試周期。16、黑盒/功能測(cè)試的方法有？1、等價(jià)類劃分法場合：軟件中有數(shù)據(jù)輸入的地方名詞：有效等價(jià)類（正向測(cè)試:對(duì)程序來說，正確的、合理的輸入數(shù)據(jù)集合。-驗(yàn)證功能是否正確實(shí)現(xiàn)無效等價(jià)類（反向測(cè)試）：對(duì)程序來說，錯(cuò)誤的、不合理的輸入數(shù)據(jù)集合。-驗(yàn)證 軟件的異常處理能力（健壯性）方法：將大量數(shù)據(jù)劃分成若干范虱 再從每個(gè)范圍中挑選少量代表數(shù)據(jù)進(jìn)行測(cè)試。（抽樣測(cè)，效率高）*數(shù)軸*2、邊界值法場合：有數(shù)據(jù)輸入的地方；多個(gè)選項(xiàng)的下拉列表名詞:最大值，最小值，次邊界（臨近邊界值）方法：和等價(jià)類邊界值一塊使用 侑效，無效，最大，最?。ㄅR近）例子：（

15、等價(jià)類邊界值）最小值min最大值mwx3場景法（基于業(yè)務(wù)的測(cè)試方法）場合：界面填寫項(xiàng)較少，業(yè)務(wù)邏輯較復(fù)雜名詞：基本流（正確流）備選流（錯(cuò)誤流）步驟：根據(jù)業(yè)務(wù)列出場景（測(cè)試點(diǎn)、測(cè)試需求點(diǎn)）根據(jù)場景編寫用例4、因果圖法判定表場合：（梳理關(guān)系比較復(fù)雜場景和業(yè)務(wù)）控件組合（組合數(shù)量少于20種）。名詞：因：輸入條件果：輸出結(jié)果因果圖：用畫圖的方式表示輸入條件和輸出結(jié)果之間的關(guān)系。（1）基本圖形符號(hào)表示因-果之間的關(guān)系真：1或true假：0 或 false1）恒等如果a=1，那么b=1如果a=0，那么如果a=0，那么b=01SW2）與全1為1，有0為03）或（了解）含義：全0為0,有1為14）非（了解）取

16、反如果a = 1那么b=0如果a=0那么b=1（2）限制圖形符號(hào)表示的是要么因之間，要么果之間相互的制約限制（單方面的限制）1）互斥（E-Exclude）可以不選，但是如果選只能選1個(gè)。互斥2）唯一（O-only）只能選1個(gè)（不能不選，不能多選，只能選擇1個(gè)）問題：唯一和互斥有什么區(qū)別？唯一必須要選1個(gè)，而互斥可以不選。3）包含（I-include）了解要求至少選1個(gè)（允許多選，但是不能不選）包舍4）要求（R-require）如果a=1，要求b必須=1如果a=0, b無所謂因5）屏蔽（M-masked）了解如果a=1，那么b必須二0如果a=0,那么b可能是1也可能是0 （無所謂，1或0都有可能

17、）因a屏蔽b判定表組成L*觀則加規(guī)則2，規(guī)則3 規(guī)則4 1規(guī)則54規(guī)則aL1TTuT 口F 口FPFtC21TzAFpTpTpFe至口 -王口 -l食謎。(矛I 必11X】X !A2 11X】條件樁動(dòng)作機(jī)-一37條件項(xiàng)動(dòng)作項(xiàng)判定表特點(diǎn)（了解）1）輸入條件的順序無關(guān)緊要2）輸出結(jié)果的順序也無關(guān)緊要3）先測(cè)哪個(gè)組合后測(cè)哪個(gè)組合無關(guān)緊要4）每個(gè)組合都是相互獨(dú)立的，所以先測(cè)哪個(gè)組合，后測(cè)哪個(gè)組合無所謂。方法：（因果圖與判定表）根據(jù)業(yè)務(wù)的之前的因果關(guān)系進(jìn)行畫圖，然后用進(jìn)行判定表進(jìn)行情況和結(jié)果表達(dá)。例子：被測(cè)系統(tǒng)：交通一卡通充值分析需求，列出輸入條件（因）投幣：50元、100元充值金額：50元、100元分

18、析，列出輸出結(jié)果（果1）充值成功和退卡2）找零3）錯(cuò)誤提示和退卡12345678輸 入 條 件1、投幣50元1112,投幣100元3,充值50元14,充值1001日、充值成功和退卡1b、找零11c.錯(cuò)誤提示和退卡11限制1 + 23+41 2. 3. 限制1 + 23+41 2. 3. 45、測(cè)試大綱法場合：程序中有多個(gè)界面（例如安裝、卸載測(cè)試）步驟：列大綱（窗口和操作）寫用例正交排列法場合：控件組合（組合數(shù)量大）步驟：列出控件和控件的取值選擇合適的正交表Ln（mk ）n:行數(shù)in:展中每列最大值-由控件取值個(gè)數(shù)確定k:列數(shù)-控件個(gè)數(shù)確定映射：控件名稱和取值填到正交表中根據(jù)正交表填寫測(cè)試用例1

19、7、正交排列法和判定表的異同？1、都可以用來測(cè)試控件之間的組合情況。2、判定表常用來測(cè)試組合少的情況。-測(cè)的全，但是效率低。3、正交排列法適合測(cè)試組合數(shù)量多的情況。-抽樣測(cè)，效率高4、判定表法測(cè)試時(shí)考慮控件之間的組合和限制情況，而正交排列法只是考慮控件 之間的組合。18、場景法的測(cè)試思路在接到一個(gè)測(cè)試任務(wù)時(shí)，通常先使用場景法將整體業(yè)務(wù)流程、邏輯進(jìn)行測(cè)試，當(dāng)整 體流程，核心業(yè)務(wù)沒有問題時(shí)，再通過等價(jià)類、邊界值、判定表等方法對(duì)細(xì)節(jié)進(jìn)行測(cè)試。（思路：先整體后細(xì)節(jié)）V模型用需求驗(yàn)收測(cè)試需求分析系統(tǒng)刪試概要設(shè)計(jì)集成洲試 .,I詳細(xì)設(shè)訃爪元.測(cè)試編碼A:優(yōu)點(diǎn)：開發(fā)階段和測(cè)試階段劃分清晰，對(duì)應(yīng)關(guān)系清晰B：缺

20、點(diǎn)：容易理解成測(cè)試是在開發(fā)完成后才開始的；也沒有體現(xiàn)出文檔測(cè)試C :深入理解：開發(fā)每個(gè)階段產(chǎn)生了相關(guān)的文檔，測(cè)試人員應(yīng)該參與文檔測(cè)試；根據(jù)相 關(guān)的開發(fā)文檔，應(yīng)該編寫測(cè)試對(duì)應(yīng)階段的測(cè)試計(jì)劃和測(cè)試用例-測(cè)試和開發(fā)是并行展 開工作的模型展開：一、軟件開發(fā)階段需求分析（1）需求分析師或產(chǎn)品經(jīng)理，了解客戶需求（2）編寫需求設(shè)計(jì)說明書概要設(shè)計(jì) （1）系統(tǒng)架構(gòu)師/系統(tǒng)分析師（2）編寫概要設(shè)計(jì)手冊(cè)詳細(xì)設(shè)計(jì)（1）系統(tǒng)架構(gòu)師（2）編寫詳細(xì)設(shè)計(jì)手冊(cè)4編碼（1）程序員（2）程序 二、軟件測(cè)試階段劃分單元測(cè)試（unit testing ）（1）是最小的測(cè)試單位，一般是一個(gè)子模塊、函數(shù)（方法、類等（2）依據(jù)是詳細(xì)設(shè)計(jì)說明

21、書（3）主要使用黑盒（功能）測(cè)試方法，核心模塊結(jié)合白盒測(cè)試方法（看代碼）（4）目前實(shí)際工作中，單元測(cè)試工作主要由開發(fā)人員自己完成-節(jié)約成本，但不嚴(yán)格（5）可能需要測(cè)試人員編寫驅(qū)動(dòng)模塊或樁模塊驅(qū)動(dòng)模塊：模擬被測(cè)模塊的上一級(jí)模塊（調(diào)用被測(cè)模塊的當(dāng)前模塊）樁模塊：模擬被測(cè)模塊的下一級(jí)模塊（被被測(cè)模塊調(diào)用的模塊）集成測(cè)試（integrated testing）（1）也叫組裝測(cè)試，把開發(fā)好的新功能逐步向主程序添加后，進(jìn)行測(cè)試的過程（2）會(huì)形成很多臨時(shí)版本（內(nèi)部版本）（3）測(cè)試以黑盒為主，核心功能結(jié)合白盒測(cè)試，更關(guān)注模塊之間的調(diào)用關(guān)系是否正確（4）主要參考概要設(shè)計(jì)說明書（5）拿到新版本先做冒煙測(cè)試：用較少

22、人員（1-5人，經(jīng)驗(yàn)豐富），較少時(shí)間（0.5-2天）對(duì)軟件核心的功能模塊 進(jìn)行大致測(cè)試，主要驗(yàn)證該軟件是否可以進(jìn)行全面測(cè)試（一般不會(huì)逐條執(zhí)行用例，而是有選擇性）（6）軟件集成的方式人:自頂向下深度優(yōu)先：把相關(guān)功能的所有子模塊集成起來，便于測(cè)試一個(gè)完整的業(yè)務(wù)功能廣度優(yōu)先：把同一級(jí)的模塊同時(shí)優(yōu)先進(jìn)行集成，不便于看到軟件的完整子功能B：自底向上。：混合系統(tǒng)測(cè)試（system testing）（1）整個(gè)軟件系統(tǒng)集成完畢，形成安裝文檔或部署文檔，在較為真實(shí)的軟硬件環(huán)境中（盡量是實(shí)際生產(chǎn)環(huán)境），進(jìn) 行全面測(cè)試的過程（2 ）系統(tǒng)測(cè)試的依據(jù)是需求規(guī)格說明書（3）全面的黑盒測(cè)試方法，再結(jié)合兼容性測(cè)試、性能測(cè)試、

23、安裝測(cè)試等（4）在系統(tǒng)測(cè)試之前，一般做一個(gè)確認(rèn)測(cè)試”，主要確認(rèn)：A:確認(rèn)開發(fā)組發(fā)布的版本，可以進(jìn)行全面的系統(tǒng)測(cè)試（冒煙測(cè)試）B:確認(rèn)相關(guān)的文檔齊全、正確（尤其給用戶的文檔）說明：確認(rèn)測(cè)試一般時(shí)間較短，不要把它單獨(dú)當(dāng)做體格測(cè)試階段驗(yàn)收測(cè)試（user acceptance testing，UAT用戶接受度測(cè)試）（1）主要由用戶參與的測(cè)試（2）一般分為alpha測(cè)試和beta測(cè)試Alpha測(cè)試：開發(fā)方完成整個(gè)系統(tǒng)后，經(jīng)過了系統(tǒng)測(cè)試后，再組織用戶（一般也是開發(fā)方充當(dāng)）在開發(fā)方的環(huán)境 中，對(duì)軟件進(jìn)行檢查Beta測(cè)試：在用戶的實(shí)際使用環(huán)境中，由最終用戶完成對(duì)軟件的檢查對(duì)于公共類的軟件（操作系統(tǒng)、辦公軟件、

24、游戲.），一般發(fā)布公測(cè)版，讓用戶下載使用，收集問題反饋（3）驗(yàn)收測(cè)試不需要寫測(cè)試用例，完全站在用戶使用角度、體驗(yàn)度角度20.W模型（雙V模型）（1）第一個(gè)V表示開發(fā)階段（2）第二個(gè)V表示測(cè)試階段（3）體現(xiàn)出了文檔測(cè)試（4）但沒有體現(xiàn)出測(cè)試計(jì)劃和測(cè)試用例 其他模型：X模型、H模型21、軟件測(cè)試的分類（軟件測(cè)試方法、測(cè)試策略）按測(cè)試技術(shù)分類（1）黑盒測(cè)試（功能測(cè)試）也叫功能測(cè)試，是不考慮程序的內(nèi)部結(jié)構(gòu)，只知道程序的輸入和輸出的情況下， 進(jìn)行的功能驗(yàn)證的測(cè)試方式。單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試必須采用的方法（2）白盒測(cè)試（結(jié)構(gòu)測(cè)試、邏輯結(jié)構(gòu)測(cè)試）也叫結(jié)構(gòu)測(cè)試，是只考慮程序的內(nèi)部結(jié)構(gòu)， 而不考慮外部功能的測(cè)試方式。A :通過檢查程序代碼發(fā)現(xiàn)bugB:要求測(cè)試人員懂得代碼C:白盒測(cè)試是降低軟件風(fēng)險(xiǎn)的補(bǔ)充測(cè)試，是在黑盒測(cè)試基礎(chǔ)上補(bǔ)充的，一個(gè)模 塊不能只做白盒測(cè)試而不做黑盒測(cè)試D :白盒測(cè)試的成本較高（時(shí)間成本、人力成本）E：白盒測(cè)試有專門的方法，需要寫白盒測(cè)試用例F：單元測(cè)試用的最多，集成測(cè)試也可能會(huì)用，系統(tǒng)測(cè)試完全不用（3）灰盒測(cè)試=黑盒+白盒在集成測(cè)試中經(jīng)常采用，以黑盒測(cè)試為主，對(duì)于模塊之間的調(diào)用關(guān)系或者出現(xiàn) 錯(cuò)誤的情況下，檢查代碼按是否需要運(yùn)行代碼分類（1）靜態(tài)測(cè)試A:不運(yùn)行程序的測(cè)試過程B :主要包括：代碼測(cè)試，界面測(cè)試，文檔測(cè)試C：靜態(tài)測(cè)試中的代碼測(cè)試主要檢