問題集
1.軟件測(cè)試分哪兩種方法?分別適合什么情況?
2.一套完整的測(cè)試應(yīng)該由哪些階段組成?分別闡述一下各個(gè)階段。
3.軟件測(cè)試的類型有那些?分別比較這些不同的測(cè)試類型的區(qū)別與聯(lián)系。
4.測(cè)試用例通常包括那些內(nèi)容?著重闡述編制測(cè)試用例的具體做法
5.在分別測(cè)試winform的C/S結(jié)構(gòu)與測(cè)試WEB結(jié)構(gòu)的軟件是，應(yīng)該采取什么樣的方法分別測(cè)試?他們存在什么樣的區(qū)別與聯(lián)系?
6.在測(cè)試winform的C/S結(jié)構(gòu)軟件時(shí)，發(fā)現(xiàn)這個(gè)軟件的運(yùn)行速度很慢，您會(huì)認(rèn)為是什么原因?您會(huì)采取哪些方法去檢查這個(gè)原因?
7.描述使用bugzilla缺陷管理工具對(duì)軟件缺陷(BUG)跟蹤的管理的流程8.如果您是測(cè)試組長(zhǎng)，您會(huì)采取什么樣的方式管理團(tuán)隊(duì)?在測(cè)試人員同開發(fā)人員的溝通過程中，如何提高溝通的效率和改善溝通的效果?維持測(cè)試人員同開發(fā)團(tuán)隊(duì)中其他成員良好的人際關(guān)系的關(guān)鍵是什么?
問題解答：
1.軟件測(cè)試分哪兩種方法?分別適合什么情況?
軟件測(cè)試方法一般分為兩種：白盒測(cè)試與黑盒測(cè)試。白盒測(cè)試又稱為結(jié)構(gòu)測(cè)試、邏輯驅(qū)動(dòng)測(cè)試或基于程序本身的測(cè)試，它著重于程序的內(nèi)部結(jié)構(gòu)及算法，通常不關(guān)心功能與性能指標(biāo);黑盒測(cè)試又被稱為功能測(cè)試、數(shù)據(jù)驅(qū)動(dòng)測(cè)試或基于規(guī)格說明的測(cè)試，它實(shí)際上是站在最終用戶的立場(chǎng)，檢驗(yàn)輸入輸出信息及系統(tǒng)性能指標(biāo)是否符合規(guī)格說明書中有關(guān)功能需求及性能需求的規(guī)定。
2.一套完整的測(cè)試應(yīng)該由哪些階段組成?分別闡述一下各個(gè)階段。
計(jì)劃階段、設(shè)計(jì)階段、白盒單元、白盒集成、黑盒單元、黑盒集成、系統(tǒng)測(cè)試、回歸測(cè)試、驗(yàn)收測(cè)試一套完整的測(cè)試應(yīng)該由五個(gè)階段組成：1)。測(cè)試計(jì)劃首先，根據(jù)用戶需求報(bào)告中關(guān)于功能要求和性能指標(biāo)的規(guī)格說明書，定義相應(yīng)的測(cè)試需求報(bào)告，即制訂黑盒測(cè)試的最高標(biāo)準(zhǔn)。以后所有的測(cè)試工作都將圍繞著測(cè)試需求來進(jìn)行，符合測(cè)試需求的應(yīng)用程序即是合格的，反之即是不合格的;同時(shí)，還要適當(dāng)選擇測(cè)試內(nèi)容，合理安排測(cè)試人員、測(cè)試時(shí)間及測(cè)試資源等。
2)測(cè)試設(shè)計(jì)將測(cè)試計(jì)劃階段制訂的測(cè)試需求分解、細(xì)化為若干個(gè)可執(zhí)行的測(cè)試過程，并為每個(gè)測(cè)試過程選擇適當(dāng)?shù)臏y(cè)試用例(測(cè)試用例選擇的好壞將直接影響測(cè)試結(jié)果的有效性)。
3)測(cè)試開發(fā)建立可重復(fù)使用的自動(dòng)測(cè)試過程。
4)測(cè)試執(zhí)行執(zhí)行測(cè)試開發(fā)階段建立的自動(dòng)測(cè)試過程，并對(duì)所發(fā)現(xiàn)的缺陷進(jìn)行跟蹤管理，測(cè)試執(zhí)行一般由單元測(cè)試、組合測(cè)試、集成測(cè)試、系統(tǒng)聯(lián)調(diào)及回歸測(cè)試等步驟組成，測(cè)試人員應(yīng)本著科學(xué)負(fù)責(zé)的態(tài)度，一步一個(gè)腳印地進(jìn)行測(cè)試。
5)測(cè)試評(píng)估結(jié)合量化的測(cè)試覆蓋域及缺陷跟蹤報(bào)告，對(duì)于應(yīng)用軟件的質(zhì)量和開發(fā)團(tuán)隊(duì)的工作進(jìn)度及工作效率進(jìn)行綜合評(píng)價(jià)。
3.軟件測(cè)試的類型有那些?分別比較這些不同的測(cè)試類型的區(qū)別與聯(lián)系。
BVT (Build Verification Test)，主要目的是驗(yàn)證最新生成的軟件版本在功能上是否完整，主要的軟件特性是否正確Scenario Tests(基于用戶實(shí)際應(yīng)用場(chǎng)景的測(cè)試)，Scenario Tests優(yōu)點(diǎn)是關(guān)注了用戶的需求，缺點(diǎn)是有時(shí)候難以真正模仿用戶真實(shí)的使用情況Smoke Test，修復(fù)Bug后，針對(duì)此次修復(fù)是否會(huì)對(duì)其他模塊造成影響而進(jìn)行的專門測(cè)試。Smoke Test優(yōu)點(diǎn)是節(jié)省測(cè)試時(shí)間，防止build失敗。缺點(diǎn)是覆蓋率還是比較低此外，還有Application Compatibility Test(兼容性測(cè)試)，主要目的是為了兼容第三方軟件，確保第三方軟件能正常運(yùn)行，用戶不受影響。Accessibility Test(軟件適用性測(cè)試)，是確保軟件對(duì)于某些有殘疾的人士也能正常的使用，但優(yōu)先級(jí)比較低。其它的測(cè)試還有Functional Test(功能測(cè)試)、Security Test(安全性測(cè)試)、Stress Test(壓力測(cè)試)、Performance Test(性能測(cè)試)、Regression Test(回歸測(cè)試)、Setup/Upgrade Test(安裝升級(jí)測(cè)試)等
4. 測(cè)試用例通常包括那些內(nèi)容?著重闡述編制測(cè)試用例的具體做法不同結(jié)構(gòu)的用例包括的不一樣。(版本、編號(hào)、項(xiàng)目、設(shè)計(jì)人員、設(shè)計(jì)日期、輸入、預(yù)期輸出……)
軟件測(cè)試用例的基本要素包括測(cè)試用例編號(hào)、測(cè)試標(biāo)題、重要級(jí)別、測(cè)試輸入、操作步驟、預(yù)期結(jié)果。
用例編號(hào)： 測(cè)試用例的編號(hào)有一定的規(guī)則，比如系統(tǒng)測(cè)試用例的編號(hào)這樣定義規(guī)則： PROJECT1-ST-001 ，命名規(guī)則是項(xiàng)目名稱+測(cè)試階段類型(系統(tǒng)測(cè)試階段)+編號(hào)。定義測(cè)試用例編號(hào)，便于查找測(cè)試用例，便于測(cè)試用例的跟蹤。
測(cè)試標(biāo)題： 對(duì)測(cè)試用例的描述，測(cè)試用例標(biāo)題應(yīng)該清楚表達(dá)測(cè)試用例的用途。比如 “ 測(cè)試用戶登錄時(shí)輸入錯(cuò)誤密碼時(shí)，軟件的響應(yīng)情況 ” .重要級(jí)別： 定義測(cè)試用例的優(yōu)先級(jí)別，可以籠統(tǒng)的分為 “ 高 ” 和 “ 低 ” 兩個(gè)級(jí)別。一般來說，如果軟件需求的優(yōu)先級(jí)為 “ 高 ” ，那么針對(duì)該需求的測(cè)試用例優(yōu)先級(jí)也為 “ 高 ” ;反之亦然，測(cè)試輸入： 提供測(cè)試執(zhí)行中的各種輸入條件。根據(jù)需求中的輸入條件，確定測(cè)試用例的輸入。測(cè)試用例的輸入對(duì)軟件需求當(dāng)中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那么測(cè)試用例設(shè)計(jì)中會(huì)遇到很大的障礙。
操作步驟： 提供測(cè)試執(zhí)行過程的步驟。對(duì)于復(fù)雜的測(cè)試用例，測(cè)試用例的輸入需要分為幾個(gè)步驟完成，這部分內(nèi)容在操作步驟中詳細(xì)列出。
預(yù)期結(jié)果： 提供測(cè)試執(zhí)行的預(yù)期結(jié)果，預(yù)期結(jié)果應(yīng)該根據(jù)軟件需求中的輸出得出。如果在實(shí)際測(cè)試過程中，得到的實(shí)際測(cè)試結(jié)果與預(yù)期結(jié)果不符，那么測(cè)試不通過;反之則測(cè)試通過。
5.描述使用bugzilla缺陷管理工具對(duì)軟件缺陷(BUG)跟蹤的管理的流程1、測(cè)試人員或開發(fā)人員發(fā)現(xiàn)bug后，判斷屬于哪個(gè)模塊的問題，填寫bug報(bào)告后，系統(tǒng)會(huì)自動(dòng)通過Email通知項(xiàng)目組長(zhǎng)或直接通知開發(fā)者。
1) 經(jīng)驗(yàn)證無誤后，修改狀態(tài)為VERIFIED.待整個(gè)產(chǎn)品發(fā)布后，修改為CLOSED. 2) 還有問題，REOPENED，狀態(tài)重新變?yōu)?ldquo;New"，并發(fā)郵件通知。
2)項(xiàng)目組長(zhǎng)根據(jù)具體情況，重新reassigned分配給bug所屬的開發(fā)者。
3) 若是，進(jìn)行處理，resolved并給出解決方法。(可創(chuàng)建補(bǔ)丁附件及補(bǔ)充說明)
4)開發(fā)者收到Email信息后，判斷是否為自己的修改范圍。
5) 若不是，重新reassigned分配給項(xiàng)目組長(zhǎng)或應(yīng)該分配的開發(fā)者。
6)測(cè)試人員查詢開發(fā)者已修改的bug，進(jìn)行重新測(cè)試。(可創(chuàng)建test case附件)
相關(guān)文章導(dǎo)讀：