常見(jiàn)的軟件測(cè)試面試題

時(shí)間：2024-08-27 07:46:17 面試筆試我要投稿

　　YJBYS小編為大家整理了一些常見(jiàn)的軟件測(cè)試面試題，特此推薦：

常見(jiàn)的軟件測(cè)試面試題

　　常見(jiàn)的測(cè)試用例設(shè)計(jì)方法都有哪些?請(qǐng)分別以具體的例子來(lái)說(shuō)明這些方法在測(cè)試用例設(shè)計(jì)工作中的應(yīng)用。

　　1. 等價(jià)類劃分

　　常見(jiàn)的軟件測(cè)試面試題劃分等價(jià)類: 等價(jià)類是指某個(gè)輸入域的子集合.在該子集合中,各個(gè)輸入數(shù)據(jù)對(duì)于揭露程序中的錯(cuò)誤都是等效的.并合理地假定:測(cè)試某等價(jià)類的代表值就等于對(duì)這一類其它值的測(cè)試.因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價(jià)類,在每一個(gè)等價(jià)類中取一個(gè)數(shù)據(jù)作為測(cè)試的輸入條件,就可以用少量代表性的測(cè)試數(shù)據(jù).取得較好的測(cè)試結(jié)果.等價(jià)類劃分可有兩種不同的情況:有效等價(jià)類和無(wú)效等價(jià)類.

　　2. 邊界值分析法

　　邊界值分析方法是對(duì)等價(jià)類劃分方法的補(bǔ)充。測(cè)試工作經(jīng)驗(yàn)告訴我,大量的錯(cuò)誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對(duì)各種邊界情況設(shè)計(jì)測(cè)試用例,可以查出更多的錯(cuò)誤.

　　使用邊界值分析方法設(shè)計(jì)測(cè)試用例,首先應(yīng)確定邊界情況.通常輸入和輸出等價(jià)類的邊界,就是應(yīng)著重測(cè)試的邊界情況.應(yīng)當(dāng)選取正好等于,剛剛大于或剛剛小于邊界的值作為測(cè)試數(shù)據(jù),而不是選取等價(jià)類中的典型值或任意值作為測(cè)試數(shù)據(jù).

　　3. 錯(cuò)誤推測(cè)法

　　基于經(jīng)驗(yàn)和直覺(jué)推測(cè)程序中所有可能存在的各種錯(cuò)誤, 從而有針對(duì)性的設(shè)計(jì)測(cè)試用例的方法.

　　錯(cuò)誤推測(cè)方法的基本思想: 列舉出程序中所有可能有的錯(cuò)誤和容易發(fā)生錯(cuò)誤的特殊情況,根據(jù)他們選擇測(cè)試用例. 例如, 在單元測(cè)試時(shí)曾列出的許多在模塊中常見(jiàn)的錯(cuò)誤. 以前產(chǎn)品測(cè)試中曾經(jīng)發(fā)現(xiàn)的錯(cuò)誤等, 這些就是經(jīng)驗(yàn)的總結(jié)。還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況。輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯(cuò)誤的情況。可選擇這些情況下的例子作為測(cè)試用例.

　　4. 因果圖方法

　　前面介紹的等價(jià)類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系, 相互組合等. 考慮輸入條件之間的相互組合,可能會(huì)產(chǎn)生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價(jià)類,他們之間的組合情況也相當(dāng)多. 因此必須考慮采用一種適合于描述對(duì)于多種條件的組合,相應(yīng)產(chǎn)生多個(gè)動(dòng)作的形式來(lái)考慮設(shè)計(jì)測(cè)試用例. 這就需要利用因果圖(邏輯模型). 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.

　　5. 正交表分析法

　　有時(shí)候，可能因?yàn)榇罅康膮?shù)的組合而引起測(cè)試用例數(shù)量上的激增，同時(shí)，這些測(cè)試用例并沒(méi)有明顯的優(yōu)先級(jí)上的差距，而測(cè)試人員又無(wú)法完成這么多數(shù)量的測(cè)試，就可以通過(guò)正交表來(lái)進(jìn)行縮減一些用例，從而達(dá)到盡量少的用例覆蓋盡量大的范圍的可能性。

　　6. 場(chǎng)景分析方法

　　指根據(jù)用戶場(chǎng)景來(lái)模擬用戶的操作步驟，這個(gè)比較類似因果圖，但是可能執(zhí)行的深度和可行性更好。

　　您認(rèn)為做好測(cè)試用例設(shè)計(jì)工作的關(guān)鍵是什么?

　　白盒測(cè)試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果

　　黑盒法用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測(cè)試，以最少的用例在合理的時(shí)間內(nèi)發(fā)現(xiàn)最多的問(wèn)題

　　詳細(xì)的描述一個(gè)測(cè)試活動(dòng)完整的過(guò)程：

　　1. 項(xiàng)目經(jīng)理通過(guò)和客戶的交流，完成需求文檔，由開(kāi)發(fā)人員和測(cè)試人員共同完成需求文檔的評(píng)審，評(píng)審的內(nèi)容包括：需求描述不清楚的地方和可能有明顯沖突或者無(wú)法實(shí)現(xiàn)的功能的地方。項(xiàng)目經(jīng)理通過(guò)綜合開(kāi)發(fā)人員，測(cè)試人員以及客戶的意見(jiàn)，完成項(xiàng)目計(jì)劃。然后sqa進(jìn)入項(xiàng)目，開(kāi)始進(jìn)行統(tǒng)計(jì)和跟蹤

　　2. 開(kāi)發(fā)人員根據(jù)需求文檔完成需求分析文檔，測(cè)試人員進(jìn)行評(píng)審，評(píng)審的主要內(nèi)容包括是否有遺漏或者雙方理解不同的地方。測(cè)試人員完成測(cè)試計(jì)劃文檔，測(cè)試計(jì)劃包括的內(nèi)容上面有描述。

　　3. 測(cè)試人員根據(jù)修改好的需求分析文檔開(kāi)始寫測(cè)試用例，同時(shí)開(kāi)發(fā)人員完成概要設(shè)計(jì)文檔，詳細(xì)設(shè)計(jì)文檔。此兩份文檔成為測(cè)試人員撰寫測(cè)試用例的補(bǔ)充材料。

　　4. 測(cè)試用例完成后，測(cè)試和開(kāi)發(fā)需要進(jìn)行評(píng)審。

　　5. 測(cè)試人員搭建環(huán)境

　　6. 開(kāi)發(fā)人員提交第一個(gè)版本，可能存在未完成功能，需要說(shuō)明。測(cè)試人員進(jìn)行測(cè)試，發(fā)現(xiàn)bug后提交給bugzilla。

　　7. 開(kāi)發(fā)提交第二個(gè)版本，包括bug fix以及增加了部分功能，測(cè)試人員進(jìn)行測(cè)試。

　　8. 重復(fù)上面的工作，一般是3-4個(gè)版本后bug數(shù)量減少，達(dá)到出貨的要求。

　　9. 如果有客戶反饋的問(wèn)題，需要測(cè)試人員協(xié)助重現(xiàn)以及回歸測(cè)試。

　　以往是否曾經(jīng)從事過(guò)性能測(cè)試工作?請(qǐng)盡可能的詳細(xì)描述您以往的性能測(cè)試工作的完整過(guò)程。

　　曾經(jīng)做過(guò)一套網(wǎng)管系統(tǒng)的性能測(cè)試，主要測(cè)試該軟件在同時(shí)管理大量終端的情況下，在響應(yīng)時(shí)間，cpu/磁盤/內(nèi)存等參數(shù)是否滿足要求。

　　也曾經(jīng)做過(guò)軟交換系統(tǒng)的呼叫性能測(cè)試，主要是測(cè)試軟交換系統(tǒng)在有大量呼叫的情況下，響應(yīng)時(shí)間，呼叫成功率，cpu/磁盤/內(nèi)存等參數(shù)是否滿足設(shè)計(jì)要求。

　　您在從事性能測(cè)試工作時(shí)，是否使用過(guò)一些測(cè)試工具?如果有，請(qǐng)?jiān)囀鲈摴ぞ叩墓ぷ髟恚⒁砸粋€(gè)具體的工作中的例子描述該工具是如何在實(shí)際工作中應(yīng)用的。

　　測(cè)試網(wǎng)管系統(tǒng)中，使用的mimic來(lái)模擬終端，能夠大量的節(jié)省成本。

　　測(cè)試軟交換系統(tǒng)的時(shí)候，使用的prolab來(lái)模擬終端并發(fā)送呼叫軟交換，他完成了同時(shí)數(shù)百人才能完成的摘機(jī)撥號(hào)工作，主要工作原理是產(chǎn)生一些符合要求的ip包并發(fā)送給軟交換系統(tǒng)，同時(shí)對(duì)軟交換系統(tǒng)的回應(yīng)進(jìn)行處理，決定下一步動(dòng)作。

　　您認(rèn)為性能測(cè)試工作的目的是什么?做好性能測(cè)試工作的關(guān)鍵是什么?

　　主要是保障在大量用戶的情況下，服務(wù)能正常使用。

　　在您以往的工作中，一條軟件缺陷(或者叫bug)記錄都包含了哪些內(nèi)容?如何提交高質(zhì)量的軟件缺陷(bug)記錄?

　　1. 在傳統(tǒng)的bugzilla中，bug描述應(yīng)該包括以下的信息

　　2. 和bug產(chǎn)生對(duì)應(yīng)的軟件版本

　　3. 開(kāi)發(fā)的接口人員

　　4. bug的優(yōu)先級(jí)

　　5. bug的嚴(yán)重程度

　　6. bug可能屬于的模塊，如果不能確認(rèn)，可以用開(kāi)發(fā)人員來(lái)判斷

　　7. bug標(biāo)題，需要清晰的描述現(xiàn)象

　　8. bug描述，需要盡量給出重新bug的步驟

　　9. bug附件中能給出相關(guān)的日志和截圖。