第一篇：測(cè)試新手應(yīng)該怎么學(xué)習(xí)軟件測(cè)試

測(cè)試新手應(yīng)該怎么學(xué)習(xí)軟件測(cè)試

對(duì)于測(cè)試新手來(lái)說(shuō)，學(xué)好測(cè)試的理論知識(shí)是必須的，因?yàn)檫@些是你測(cè)試的基礎(chǔ)，千萬(wàn)不要好高騖遠(yuǎn)，別忘了一句話“磨刀不誤砍柴工”。舉個(gè)例子，如果你沒(méi)有學(xué)習(xí)測(cè)試?yán)碚摶A(chǔ)，老板讓你做一個(gè)測(cè)試基線，你知道怎么做嗎？就算是你知道基線是什么，那么你會(huì)做好一個(gè)基線嗎？

如果基礎(chǔ)沒(méi)打好，不要急著學(xué)習(xí)測(cè)試工具，因?yàn)楣ぞ咂鋵?shí)是很好學(xué)的，無(wú)非就是點(diǎn)幾個(gè)按鈕，頂多是寫幾句腳本，進(jìn)行一下腳本什么的優(yōu)化。但是如果不會(huì)測(cè)試?yán)碚摶A(chǔ)，你用自動(dòng)化工具做出來(lái)的結(jié)果你會(huì)分析嗎？自動(dòng)化得出的結(jié)果不是最終的測(cè)試報(bào)告，這些需要測(cè)試人員再分析的，最終才能得出結(jié)果。再舉個(gè)例子，你用loadrunner測(cè)試出來(lái)了一堆數(shù)據(jù)，你能根據(jù)那些數(shù)據(jù)得出系統(tǒng)瓶頸嗎？不能，因?yàn)橄到y(tǒng)瓶頸的種類，分析方法，以及不同的系統(tǒng)要注意的瓶頸點(diǎn)不同，這些如果沒(méi)有扎實(shí)的理論基礎(chǔ)是很難分析出來(lái)的，因?yàn)樗C合各個(gè)情況才能得出系統(tǒng)瓶頸的。

還有一點(diǎn)，那就是一定要學(xué)習(xí)一些其他的東西，因?yàn)闇y(cè)試是一個(gè)多學(xué)科的科學(xué)，你必須要懂得，至少了解linux系統(tǒng)，網(wǎng)絡(luò)技術(shù)、一門開(kāi)發(fā)語(yǔ)言、CMM等內(nèi)容。因?yàn)槿绻@些你不懂，老板讓你搭建一個(gè)linux的測(cè)試環(huán)境，你會(huì)嗎？讓你搭建VPN，你會(huì)嗎？

以上就是我總結(jié)的幾點(diǎn)內(nèi)容，這些一定是不全的，后續(xù)我會(huì)繼續(xù)補(bǔ)充。但是我也就是想說(shuō)一句話，學(xué)軟件測(cè)試看似簡(jiǎn)單，其實(shí)做一名合格的軟件測(cè)試工程師很難。一定要有扎實(shí)的基礎(chǔ)、敏銳的洞察力以及廣泛的知識(shí)涵蓋面，測(cè)試軟件對(duì)我們來(lái)說(shuō)也是極其重要的。

第二篇：軟件測(cè)試學(xué)習(xí)

軟件測(cè)試學(xué)習(xí)

1． 什么是軟件測(cè)試？

答：軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而審查軟件文檔、檢查軟件數(shù)據(jù)和執(zhí)行程序代碼的過(guò)程，其目的在于在軟件交付使用前充分發(fā)現(xiàn)缺陷并協(xié)助相關(guān)部門定位、解決缺陷，最后交付一個(gè)高質(zhì)量的軟件產(chǎn)品給用戶。

2．軟件測(cè)試的分類有哪些？

答：軟件測(cè)試活動(dòng)可以分為以下幾類：

? 黑盒測(cè)試：

黑盒測(cè)試又叫功能測(cè)試，數(shù)據(jù)驅(qū)動(dòng)測(cè)試或基于需求規(guī)格說(shuō)明書(shū)的功能測(cè)試。（主要用于系統(tǒng)測(cè)試和確認(rèn)測(cè)試中）

? 白盒測(cè)試

白盒測(cè)試又稱結(jié)構(gòu)測(cè)試、邏輯驅(qū)動(dòng)測(cè)試或程序代碼內(nèi)部構(gòu)成的測(cè)試。

? 灰盒測(cè)試

灰盒測(cè)試結(jié)合黑盒和白盒測(cè)試兩種方法，一方面考慮程序代碼的功能性表現(xiàn)，另一方面，又需要考慮程序代碼的內(nèi)部結(jié)構(gòu)。（主要用于性能測(cè)試、自動(dòng)化功能測(cè)試）? 靜態(tài)測(cè)試

靜態(tài)測(cè)試就是用眼看，閱讀程序代碼、文檔資料等，與需求規(guī)格說(shuō)明書(shū)中的客戶需求進(jìn)行比較，找出程序代碼中設(shè)計(jì)不合理及文檔集料有錯(cuò)誤的地方

? 動(dòng)態(tài)測(cè)試

動(dòng)態(tài)測(cè)試即為實(shí)際的執(zhí)行被測(cè)對(duì)象的程序代碼，輸入事先設(shè)計(jì)好的測(cè)試用例，檢查程序運(yùn)行得到的結(jié)果與測(cè)試用例中設(shè)計(jì)的預(yù)期結(jié)果之間是否有差異，判定實(shí)際結(jié)果與預(yù)期結(jié)果是否一致，從而檢驗(yàn)程序的正確性、可靠性和有效性，并分析系統(tǒng)運(yùn)行效率和健壯性等性能狀況。

動(dòng)態(tài)測(cè)試由四個(gè)部分組成：設(shè)計(jì)測(cè)試用例、執(zhí)行測(cè)試用例、分析比較輸出結(jié)果、輸出測(cè)試報(bào)告。

動(dòng)態(tài)測(cè)試有三種方法：黑盒測(cè)試、白盒測(cè)試、灰盒測(cè)試。

? 手動(dòng)測(cè)試

手動(dòng)測(cè)試大部分的測(cè)試就是模擬用戶的業(yè)務(wù)流程，來(lái)使用軟件產(chǎn)品，從而發(fā)現(xiàn)軟件產(chǎn)品中的缺陷。手動(dòng)測(cè)試是最傳統(tǒng)的測(cè)試方法，也是現(xiàn)在大多數(shù)公司都是用的測(cè)試形式。他是測(cè)試人員設(shè)計(jì)測(cè)試用例并執(zhí)行測(cè)試用例，然后根據(jù)實(shí)際結(jié)果去和預(yù)期的結(jié)果相比較并記錄測(cè)試結(jié)果，最終輸出測(cè)試報(bào)告的測(cè)試活動(dòng)。

優(yōu)點(diǎn)：可以充分發(fā)揮測(cè)試工程師的主觀能動(dòng)性，將其智力活動(dòng)體現(xiàn)于測(cè)試活動(dòng)中，能發(fā)現(xiàn)很多的缺陷。

缺點(diǎn)：手動(dòng)測(cè)試有一定的局限性與單調(diào)枯燥性。

? 自動(dòng)測(cè)試

自動(dòng)測(cè)試就是利用一些測(cè)試工具，模擬用戶的使用流程，讓它們自動(dòng)運(yùn)行來(lái)查找缺陷。也可以編寫一些代碼，設(shè)定特定的測(cè)試場(chǎng)景，來(lái)自動(dòng)尋找缺陷

優(yōu)點(diǎn)：能夠很快、很廣泛的查找缺陷，同時(shí)可以做很多重復(fù)性的工作，大大提高了測(cè)試的效率和測(cè)試的準(zhǔn)確性，而且寫出的比較好的測(cè)試腳本，還可以在軟件生命周期的各個(gè)階段重復(fù)使用。

3．軟件測(cè)試的流程：需求測(cè)試、單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、性能測(cè)試、用戶測(cè)試、回歸測(cè)試

? 需求測(cè)試：主要從以下幾個(gè)方面考慮

①完整性：每一項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚，從而為開(kāi)發(fā)人員設(shè)計(jì)和實(shí)現(xiàn)這些功能提供所有必要的需求依據(jù)。

②正確性：每一項(xiàng)需求都必須準(zhǔn)確的陳述其要開(kāi)發(fā)的功能

③一致性：一致性是指與其它軟件需求或高層（系統(tǒng)、業(yè)務(wù)）需求不相矛盾，或者與我們的項(xiàng)目宣傳資料一致。

④可行性：每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施的。⑤無(wú)二義性：對(duì)所有需求的讀者都只能有一個(gè)明確統(tǒng)一的解釋，由于自然語(yǔ)言極易導(dǎo)致二義性，所以盡量把每項(xiàng)需求用簡(jiǎn)潔明了的用戶語(yǔ)言表達(dá)出來(lái)。

⑥健壯性：需求的說(shuō)明中是否對(duì)可能出現(xiàn)的異常進(jìn)行了分析，并且對(duì)這些異常進(jìn)行了容錯(cuò)處理。

⑦必要性：“必要性”可以理解為每項(xiàng)需求都是用來(lái)授權(quán)你編寫文檔的“根源”。要是每項(xiàng)需求都回溯至某項(xiàng)客戶的輸入，如需求用例或別的來(lái)源。

⑧可測(cè)試性：每項(xiàng)需求都能通過(guò)設(shè)計(jì)測(cè)試用例或其它驗(yàn)證方法來(lái)進(jìn)行測(cè)試。

⑨可修改性：每項(xiàng)需求只應(yīng)在SRS（軟件需求規(guī)格說(shuō)明書(shū)）中出現(xiàn)一次。這樣更改時(shí)易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說(shuō)明書(shū)更容易修改。

? 單元測(cè)試

單元測(cè)試又成為模塊測(cè)試，是對(duì)程序代碼中最小的設(shè)計(jì)模塊單元進(jìn)行測(cè)試。（可以發(fā)現(xiàn)大約80%的軟件缺陷，大多數(shù)公司中，由對(duì)應(yīng)的開(kāi)發(fā)工程師負(fù)責(zé)）單元測(cè)試方法：主要采用靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試相結(jié)合的辦法。

單元測(cè)試工具：Juint等。

單元測(cè)試優(yōu)點(diǎn)：在軟件生產(chǎn)過(guò)程中及時(shí)的開(kāi)展單元測(cè)試可以降低編碼的錯(cuò)誤率，提

高編碼質(zhì)量。

? 集成測(cè)試

集成測(cè)試又稱為組裝測(cè)試，就是將軟件產(chǎn)品中的各個(gè)模塊組裝起來(lái)，檢查其接口是否存在問(wèn)題，以及組裝后的整體性能、性能表現(xiàn)。

集成測(cè)試方法：一般采用非增式集成方法、增式集成方法（自底向上集成；自頂向下集成；組合方式集成）等策略進(jìn)行測(cè)試，利用以黑盒測(cè)試為主，白盒測(cè)試為輔的測(cè)試方法進(jìn)行測(cè)試。

（集成測(cè)試一般由測(cè)試工程師但當(dāng)）

集成測(cè)試的目的：主要解決的是各個(gè)軟件組成單元代碼是否符合開(kāi)發(fā)規(guī)范、接口是否存在問(wèn)題、整體功能有無(wú)錯(cuò)誤、界面是否符合設(shè)計(jì)規(guī)范、性能是否滿足用戶需求等。

? 系統(tǒng)測(cè)試

系統(tǒng)測(cè)試是將通過(guò)集成測(cè)試的軟件部署到某種較為復(fù)雜的計(jì)算機(jī)用戶環(huán)境（指一般用戶的計(jì)算機(jī)環(huán)境）進(jìn)行測(cè)試。

系統(tǒng)測(cè)試的目的：通過(guò)與系統(tǒng)的需求進(jìn)行比較，發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。主要考察被測(cè)軟件的功能和性能表現(xiàn)。

系統(tǒng)測(cè)試方法：主要采用黑盒測(cè)試方法，進(jìn)行的是安裝卸載測(cè)試、兼容性測(cè)試、功能確認(rèn)測(cè)試、安全性測(cè)試等。

系統(tǒng)測(cè)試過(guò)程其實(shí)也是一種配置檢查過(guò)程，檢查軟件在生產(chǎn)過(guò)程中是否有遺漏的地方，在此時(shí)做到查漏補(bǔ)缺，以確保交付的產(chǎn)品符合用戶的質(zhì)量要求。如果軟件可以按照用戶合理期望的方式來(lái)工作的時(shí)候，即可認(rèn)為通過(guò)系統(tǒng)測(cè)試。

? 性能測(cè)試

性能測(cè)試就是要求被測(cè)軟件在業(yè)務(wù)處理速度、處理能力和所耗用的硬件系統(tǒng)資源比率滿足用戶的需求。

對(duì)測(cè)試人員的要求：測(cè)試人員要掌握編程語(yǔ)言，精通業(yè)務(wù)流程，擁有深厚的項(xiàng)目經(jīng)驗(yàn)。所以，想順利的開(kāi)展性能測(cè)試，需要測(cè)試工程師不斷的學(xué)習(xí)，掌握相應(yīng)的知識(shí)。例子：對(duì)于某個(gè)論壇，我們需要測(cè)試論壇支持10000個(gè)用戶同時(shí)使用，并且在這種情況下，打開(kāi)帖子的速度能否控制在4秒鐘以下，論壇服務(wù)器的CPU使用率不超過(guò)80%，內(nèi)存的占用率不超過(guò)75%等，這些都是典型的性能測(cè)試指標(biāo)。

性能測(cè)試優(yōu)點(diǎn)：一方面可以驗(yàn)證被測(cè)軟件是否符合用戶需求，另一方面，可以得到相關(guān)的性能數(shù)據(jù)，為被測(cè)軟件的優(yōu)化提供參考。

性能測(cè)試工具：LoadRunner自動(dòng)化性能測(cè)試工具等。

? 用戶測(cè)試

用戶測(cè)試可以稱其為用戶確認(rèn)測(cè)試。在正式驗(yàn)收前，需要用戶對(duì)本系統(tǒng)做出一個(gè)評(píng)價(jià)，用戶可對(duì)交付的系統(tǒng)做測(cè)試，并將測(cè)試結(jié)果反饋回來(lái)，進(jìn)行修改、分析。用戶測(cè)試在整個(gè)軟件生產(chǎn)流程中非常重要，這個(gè)環(huán)節(jié)是被測(cè)軟件首次作為正式系統(tǒng)交由用戶使用，用戶會(huì)根據(jù)他們的實(shí)際使用情況進(jìn)行測(cè)試、試用，并提出實(shí)際使用過(guò)程中的問(wèn)題。

用戶測(cè)試是軟件生產(chǎn)流程中的最后質(zhì)檢關(guān)。

? 回歸測(cè)試

回歸測(cè)試就是過(guò)一段時(shí)間以后再回過(guò)頭來(lái)對(duì)以前修復(fù)過(guò)的Bug重新進(jìn)行測(cè)試，看該Bug是否會(huì)重新出現(xiàn)。

回歸測(cè)試的目的：檢查以前的測(cè)試用例能否再次通過(guò)，是否還有需要補(bǔ)充的用例等。

回歸測(cè)試工具：QTP等。

第三篇：軟件測(cè)試之新手總結(jié)

軟件測(cè)試之新手總結(jié)

在不斷發(fā)展，競(jìng)爭(zhēng)激烈的今天，大家都注重時(shí)間和效率，不節(jié)約時(shí)間，沒(méi)有效率那企業(yè)就瀕臨崩潰。企業(yè)為什么上信息化，信息化是為了什么？我們給企業(yè)上CRM、OA等，也不過(guò)是為了給他們節(jié)省時(shí)間，把一些繁重的事情交給計(jì)算機(jī)處理。計(jì)算機(jī)不是萬(wàn)能的，它是沒(méi)有智商，沒(méi)有思維的，它有的也只是固化在機(jī)器本身的一大堆代碼，并按照一定的指令去執(zhí)行，所以我們不能強(qiáng)迫它面面俱到。上企業(yè)信息化，可以提高效率，可以加強(qiáng)管理，更多的是體現(xiàn)在節(jié)約時(shí)間上，但節(jié)約出來(lái)的時(shí)間我們做了什么，這是我們要考慮的問(wèn)題。

當(dāng)然，在我們給企業(yè)實(shí)現(xiàn)信息化，提高工作效率，節(jié)省工作時(shí)間時(shí)，我們不妨為自己盤算一下，我們可以為我們的軟件公司實(shí)現(xiàn)什么信息化。項(xiàng)目管理我們可以用PROJECT，在測(cè)試計(jì)劃到BUG跟蹤我們可以用TD，在版本控制、代碼管理、配置管理等我們可以用VSS以及CVS，在自動(dòng)化測(cè)試時(shí)我們可以選用WR、LR、RATIONAL等等，當(dāng)然我們還可以用一些小型的比較實(shí)用的工具，比如XENU、WEB VALIDATOR、WAS、OPENSTA、SAINT等等。盲目的推崇工具并不高明，在我們沒(méi)有完全掌握工具時(shí)，我們不要完全去相信工具做出的結(jié)論，因?yàn)橛行?huì)被我們所忽略掉，我們操作的本身不正確不理解不細(xì)微可能造成結(jié)果的很大差別。工具只能作為驗(yàn)證的一種手段。

代碼管理、BUG管理工具，我認(rèn)為是必須的，也是最簡(jiǎn)單的。代碼管理如VSS，可以方便我們對(duì)程序進(jìn)行牽入牽出，能保證服務(wù)器上的程序是最高版本。當(dāng)然，VSS還可以被我們用到其它方面。BUG管理工具，我們可以通過(guò)他們統(tǒng)計(jì)工作量，也可以透過(guò)他發(fā)現(xiàn)工作中的漏洞。一個(gè)項(xiàng)目的結(jié)束，項(xiàng)目經(jīng)理學(xué)會(huì)了管理項(xiàng)目，編碼人員學(xué)會(huì)了編程，測(cè)試員得到了什么？他們得到的是很多BUG，挖掘、回顧BUG中的內(nèi)容就是一種財(cái)富，就是我們測(cè)試員可以得到的經(jīng)驗(yàn)，這些完全可以對(duì)自己的工作方式、方法進(jìn)行評(píng)價(jià)，并可以自己總結(jié)出一套測(cè)試?yán)碚摗Ｃ總€(gè)公司都可以在慢慢工作中總結(jié)和更新自己公司的BUG管理工具，這也是公司加強(qiáng)管理的一種手段。

如果有了一定的管理工具，在類似項(xiàng)目時(shí)，我們就可以參照以前的標(biāo)準(zhǔn)，參照以前的做法，這樣我們就輕車熟路了，試問(wèn)一下：我們喜歡查詢呢還是喜歡一個(gè)一個(gè)的查看呢？在工作的時(shí)候，要學(xué)會(huì)反省、挖掘、總結(jié)，成為一個(gè)有思想的人。有思想的人遠(yuǎn)遠(yuǎn)比一個(gè)只愛(ài)勞動(dòng)的人受重用。加強(qiáng)工具化管理勢(shì)在必行，今天你為自己花費(fèi)了一分鐘，明天也許你會(huì)節(jié)約出一個(gè)小時(shí)

沒(méi)有什么固定的模式，也沒(méi)有什么固定的套路，這就是軟件行業(yè)。軟件行業(yè)更依賴于人的因素，這就告訴我們環(huán)境的不同，變化是不同的，在原來(lái)的基礎(chǔ)上總結(jié)出自己的開(kāi)發(fā)模式，才是我們應(yīng)該要做的。就像XP開(kāi)發(fā)模式也有前提一樣。取人之長(zhǎng)，補(bǔ)己之短是我們最好的做事方式。

面對(duì)著五花八門的工具，我很迷茫，也許其他新手也和我一樣。但我認(rèn)為，學(xué)工具是必然的，但不是必須的。測(cè)試?yán)碚摽梢灾笇?dǎo)我們的工作，但測(cè)試更多是要靠自己的總結(jié)，在實(shí)踐中慢慢的積累。

第四篇：軟件測(cè)試（推薦）

一、簡(jiǎn)答5*6’

1.為什么不讓時(shí)間有余的人做測(cè)試工作

表面上看這體現(xiàn)了管理的效率和靈活性，但實(shí)際上也體現(xiàn)了管理者對(duì)測(cè)試的輕視。測(cè)試和測(cè)試的人有很大關(guān)系。測(cè)試工作人員應(yīng)該是勤奮并富有耐心，善于學(xué)習(xí)、思考和發(fā)現(xiàn)問(wèn)題，細(xì)心有條理，總結(jié)問(wèn)題，如果具備這樣的優(yōu)點(diǎn)，做其它工作同樣也會(huì)很出色，因此這里還有一個(gè)要求，就是要喜歡測(cè)試這項(xiàng)工作。2.軟件測(cè)試風(fēng)險(xiǎn)主要體現(xiàn)在哪里

我們沒(méi)有對(duì)軟件進(jìn)行完全測(cè)試，實(shí)際就是選擇了風(fēng)險(xiǎn)，因?yàn)槿毕輼O有可能存在沒(méi)有進(jìn)行測(cè)試的部分。因此，我們要盡可能的選擇最合適的測(cè)試量，把風(fēng)險(xiǎn)降低到最小 3.所有軟件測(cè)試缺陷都需要修復(fù)嗎

從技術(shù)上講，所有的軟件缺陷都是能夠修復(fù)的，但是沒(méi)有必要修復(fù)所有的軟件缺陷。測(cè)試人員要做的是能夠正確判斷什么時(shí)候不能追求軟件的完美。對(duì)于整個(gè)項(xiàng)目團(tuán)隊(duì)，要做的是對(duì)每一個(gè)軟件缺陷進(jìn)行取舍，根據(jù)風(fēng)險(xiǎn)決定那些缺陷要修復(fù)。發(fā)生這種現(xiàn)象的主要原因如下：-沒(méi)有足夠的時(shí)間資源。在任何一個(gè)項(xiàng)目中，通常情況下開(kāi)發(fā)人員和測(cè)試人員都是不夠用的，而且在項(xiàng)目中沒(méi)有預(yù)算足夠的回歸測(cè)試時(shí)間，修改缺陷可能引入新的缺陷。

-有些缺陷只是特殊情況下出現(xiàn)，這種缺陷處于商業(yè)利益考慮，可以在以后升級(jí)中進(jìn)行修復(fù)。-不是缺陷的缺陷。我們經(jīng)常會(huì)碰到某些功能方面的問(wèn)題被當(dāng)成缺陷來(lái)處理，這類問(wèn)題可以以后有時(shí)間時(shí)考慮再處理。缺陷是否修改要由軟件測(cè)試人員、項(xiàng)目經(jīng)理、程序員共同討論來(lái)決定是否修復(fù)，不同角色的人員從不同的角度來(lái)思考，以做出正確的決定。4.如何減少測(cè)試人員跳槽帶來(lái)的損失 建議我們從以下兩個(gè)方面做起：

-加強(qiáng)部門內(nèi)員工之間的互相學(xué)習(xí)，互相學(xué)習(xí)是建立學(xué)習(xí)型組織的基本要求，是知識(shí)互相轉(zhuǎn)移的過(guò)程。在此基礎(chǔ)上，可以把個(gè)人擁有的技術(shù)以知識(shí)的形式沉積下來(lái)，也就完成了隱性知識(shí)到顯性知識(shí)的轉(zhuǎn)化。

-管理者就應(yīng)該把員工的個(gè)人成長(zhǎng)和企業(yè)的發(fā)展聯(lián)系起來(lái)，為員工設(shè)定合理發(fā)展規(guī)劃并付諸實(shí)現(xiàn)。

5.驗(yàn)收測(cè)試的注意點(diǎn)有哪些 測(cè)試要注意下面的事項(xiàng)：

（1）用戶現(xiàn)場(chǎng)測(cè)試不可能測(cè)試全部功能，因此要測(cè)試核心功能。這需要提前做好準(zhǔn)備，這些核心功能一定要預(yù)先經(jīng)過(guò)測(cè)試，證明沒(méi)有問(wèn)題才可以和用戶共同進(jìn)行測(cè)試。測(cè)試核心模塊的目的是建立用戶對(duì)軟件的信心。當(dāng)然如果這些模塊如果問(wèn)題較多，不應(yīng)該進(jìn)行演示。（2）如果某些模塊確實(shí)有問(wèn)題，我們可以演示其它重要的業(yè)務(wù)功能模塊，必要時(shí)要向用戶做成合理的解釋。爭(zhēng)得時(shí)間后，及時(shí)修改缺陷來(lái)彌補(bǔ)。（3）永遠(yuǎn)不能欺騙用戶，蒙混過(guò)關(guān)。6.完全測(cè)試程序是可能的嗎

實(shí)際上完全測(cè)試是不可能的。主要有以下原因：-完全測(cè)試比較耗時(shí)，時(shí)間上不允許；

-完全測(cè)試通常意味著較多資源投入，這在現(xiàn)實(shí)中往往是行不通的；-輸入量太大，不能一一進(jìn)行測(cè)試；-輸出結(jié)果太多，只能分類進(jìn)行驗(yàn)證；-軟件實(shí)現(xiàn)途徑太多；

-軟件產(chǎn)品說(shuō)明書(shū)沒(méi)有客觀標(biāo)準(zhǔn)，從不同的角度看，軟件缺陷的標(biāo)準(zhǔn)不同；因此測(cè)試的程度要根據(jù)實(shí)際情況確定 7.是不是發(fā)現(xiàn)的缺陷越多就說(shuō)明軟件缺陷越多 其中的原因主要如下：

-代碼復(fù)用、拷貝代碼導(dǎo)致程序員容易犯相同的錯(cuò)誤。類的繼承導(dǎo)致所有的子類會(huì)包含基類的錯(cuò)誤，反復(fù)拷貝同一代碼意味可能也復(fù)制了缺陷。-程序員比較勞累是可以導(dǎo)致某些連續(xù)編寫的功能缺陷較多。

“缺陷一個(gè)連著一個(gè)”不是一個(gè)客觀規(guī)律，只是一個(gè)常見(jiàn)的現(xiàn)象。如果軟件編寫的比較好，這種現(xiàn)象就不常見(jiàn)了。測(cè)試人員只要嚴(yán)肅認(rèn)真的測(cè)試程序就可以了。8.軟件測(cè)試就是QA嗎

軟件測(cè)試人員的職責(zé)是盡可能早的找出軟件缺陷，確保得以修復(fù)。而質(zhì)量保證人員（QA）主要職責(zé)是創(chuàng)建或者制定標(biāo)準(zhǔn)和方法，提高促進(jìn)軟件開(kāi)發(fā)能力和減少軟件缺陷。測(cè)試人員的主要工作是測(cè)試，質(zhì)量保證人員日常工作重要內(nèi)容是檢查與評(píng)審，測(cè)試工作也是測(cè)試保證人員的工作對(duì)象。軟件測(cè)試和質(zhì)量是相輔相成的關(guān)系，都是為了提高軟件質(zhì)量而工作。9.測(cè)試產(chǎn)品和測(cè)試項(xiàng)目區(qū)別

習(xí)慣上把開(kāi)發(fā)完成后進(jìn)行商業(yè)化、幾乎不進(jìn)行代碼修改就可以售給用戶使用的軟件成為軟件產(chǎn)品，也就是可以買“賣拷貝”的軟件，軟件項(xiàng)目是一種個(gè)性化的產(chǎn)品，可以是按照用戶要求全部重新開(kāi)發(fā)，也可以修改已有的軟件產(chǎn)品來(lái)滿足特定的用戶需求。項(xiàng)目和產(chǎn)品的不同特點(diǎn)，決定我們測(cè)試產(chǎn)品和測(cè)試項(xiàng)目仍然會(huì)有很多不同的地方：

-質(zhì)量要求不同。通常產(chǎn)品的質(zhì)量要高一些，修復(fù)發(fā)布后產(chǎn)品的缺陷成本較高，甚至?xí)?lái)很多負(fù)面的影響。而做項(xiàng)目通常面向某一用戶，雖然質(zhì)量越高越好，但是一般只要滿足用戶要求就可以了。測(cè)試資源投入多少不同。做軟件產(chǎn)品通常是研發(fā)中心來(lái)開(kāi)發(fā)，進(jìn)度壓力要小些。同時(shí)由于質(zhì)量要求高，因此會(huì)投入較多的人力、物力資源。項(xiàng)目最后要和用戶共同驗(yàn)收測(cè)試，這是產(chǎn)品測(cè)試不具有的特點(diǎn)。此外，測(cè)試產(chǎn)品與測(cè)試項(xiàng)目在缺陷管理方面、測(cè)試策略制定都會(huì)有很大不同，測(cè)試管理者應(yīng)該結(jié)合具體的環(huán)境，恰如其分的完成工作 10.如何編寫提交給用戶的測(cè)試報(bào)告

測(cè)試報(bào)告一般分為內(nèi)部測(cè)試報(bào)告和外部測(cè)試報(bào)告。內(nèi)部報(bào)告是我們?cè)跍y(cè)試工作中的項(xiàng)目文檔，反映了測(cè)試工作的實(shí)施情況,一般外部測(cè)試報(bào)告要滿足下面幾個(gè)要求：

根據(jù)內(nèi)部測(cè)試報(bào)告進(jìn)行編寫，一般可以摘錄；不可以向客戶報(bào)告嚴(yán)重缺陷，即使是已經(jīng)修改的缺陷，開(kāi)發(fā)中的缺陷也沒(méi)有必要讓客戶知道；報(bào)告上可以列出一些缺陷，但必須是中級(jí)的缺陷，而且這些缺陷必須是修復(fù)的；報(bào)告上面的內(nèi)容盡量要真實(shí)可靠；整個(gè)測(cè)試報(bào)告要仔細(xì)審閱，力爭(zhēng)不給項(xiàng)目帶來(lái)負(fù)面作用，尤其是性能測(cè)試報(bào)告。總之，外部測(cè)試報(bào)告要小心謹(jǐn)慎的編寫。

二、論述2*12’

1.請(qǐng)論述為什么要進(jìn)行軟件測(cè)試，并列舉歷史上2~3個(gè)著名軟件測(cè)試（缺陷）案例，說(shuō)明測(cè)試重要性

軟件測(cè)試的目的,第一是確認(rèn)軟件的質(zhì)量，其一方面是確認(rèn)軟件做了你所期望做的事情（，另一方面是確認(rèn)軟件以正確的方式來(lái)做了這個(gè)事情。第二是提供信息，比如提供給開(kāi)發(fā)人員或程序經(jīng)理的回饋信息，為風(fēng)險(xiǎn)評(píng)估所準(zhǔn)備的信息。第三軟件測(cè)試不僅是在測(cè)試軟件軟件產(chǎn)品本身，而且還包括軟件開(kāi)發(fā)的過(guò)程。如果一個(gè)軟件產(chǎn)品開(kāi)發(fā)完成之后發(fā)現(xiàn)了很多問(wèn)題，這說(shuō)明此軟件開(kāi)發(fā)過(guò)程很可能是有缺陷的。因此，軟件測(cè)試的第三個(gè)目的是保證整個(gè)軟件開(kāi)發(fā)過(guò)程是高質(zhì)量的。

愛(ài)國(guó)者導(dǎo)彈防御系統(tǒng)把“槍口”對(duì)準(zhǔn)了自己人 美國(guó)迪斯尼公司的獅子王游戲軟件的兼容性問(wèn)題 售票系統(tǒng)性能問(wèn)題

2.論述軟件測(cè)試科學(xué)的發(fā)展歷程 1957年之前－調(diào)試為主 20世紀(jì)50年代，計(jì)算機(jī)剛誕生不久，只有科學(xué)家級(jí)別的人才會(huì)去編程，需求和程序本身也遠(yuǎn)遠(yuǎn)沒(méi)有現(xiàn)在這么復(fù)雜多變，相當(dāng)于開(kāi)發(fā)人員一人承擔(dān)需求分析，設(shè)計(jì)，開(kāi)發(fā)，測(cè)試等所有工作，當(dāng)然也不會(huì)有人去區(qū)分調(diào)試和測(cè)試。

1957–1978－證明為主 當(dāng)時(shí)計(jì)算機(jī)應(yīng)用的數(shù)量，成本和復(fù)雜性都大幅度提升，隨之而來(lái)的經(jīng)濟(jì)風(fēng)險(xiǎn)也大大增加，測(cè)試就顯得很有必要了，這個(gè)時(shí)期測(cè)試的主要目就是確認(rèn)軟件是滿足需求的，也就是我們常說(shuō)的“做了該做的事情”。

1979–1982－破壞為主 我們不僅要證明軟件做了該做的事情，也要保證它沒(méi)做不該做的事情，這會(huì)使測(cè)試更加全面，更容易發(fā)現(xiàn)問(wèn)題。

1983–1987－評(píng)估為主 人們提出了在軟件生命周期中使用分析，評(píng)審，測(cè)試來(lái)評(píng)估產(chǎn)品的理論。軟件測(cè)試工程在這個(gè)時(shí)期得到了快速的發(fā)展.1988–至今－預(yù)防為主 預(yù)防為主是當(dāng)下軟件測(cè)試的主流思想之一。測(cè)試不是在編碼完成后才開(kāi)始介入，而是貫穿于整個(gè)軟件生命周期。3.論述軟件缺陷的由來(lái)

軟件缺陷的產(chǎn)生主要是由軟件產(chǎn)品的特點(diǎn)和開(kāi)發(fā)過(guò)程決定的。

軟件本身：①需求不清晰，導(dǎo)致設(shè)計(jì)目標(biāo)偏離客戶的需求，從而引起功能或產(chǎn)品特征上的缺陷。②系統(tǒng)結(jié)構(gòu)非常復(fù)雜，而又無(wú)法設(shè)計(jì)成一個(gè)很好的層次結(jié)構(gòu)或組件結(jié)構(gòu)，結(jié)果導(dǎo)致意想不到的問(wèn)題或系統(tǒng)維護(hù)、擴(kuò)充上的困難；即使設(shè)計(jì)成良好的面向?qū)ο蟮南到y(tǒng)，由于對(duì)象、類太多，很難完成對(duì)各種對(duì)象、類相互作用的組合測(cè)試，而隱藏著一些參數(shù)傳遞、方法調(diào)用、對(duì)象狀態(tài)變化等方面問(wèn)題。③對(duì)程序邏輯路徑或數(shù)據(jù)范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯(cuò)誤。④對(duì)一些實(shí)時(shí)應(yīng)用，要進(jìn)行精心設(shè)計(jì)和技術(shù)處理，保證精確的時(shí)間同步，否則容易引起時(shí)間上不協(xié)調(diào)，不一致性帶來(lái)的問(wèn)題。⑤沒(méi)有考慮系統(tǒng)崩潰后的自我恢復(fù)或數(shù)據(jù)的異地備份、災(zāi)難性恢復(fù)等問(wèn)題，從而存在系統(tǒng)安全性、可靠性的隱患。⑥系統(tǒng)運(yùn)行環(huán)境的復(fù)雜，不僅用戶使用的計(jì)算機(jī)環(huán)境千變?nèi)f化，包括用戶的各種操作方式或各種不同的輸入數(shù)據(jù)，容易引起一些特定用戶環(huán)境下的問(wèn)題；在系統(tǒng)實(shí)際應(yīng)用中，數(shù)據(jù)量很大。從而會(huì)引起強(qiáng)度或負(fù)載問(wèn)題。⑦由于通信端口多、存取和加密手段的矛盾性等，會(huì)造成系統(tǒng)的安全性或適用性等問(wèn)題。⑧新技術(shù)的采用，可能涉及技術(shù)或系統(tǒng)兼容的問(wèn)題，事先沒(méi)有考慮到。

團(tuán)隊(duì)工作：系統(tǒng)需求分析時(shí)對(duì)客戶的需求理解不清楚，或者和用戶的溝通存在一些困難。不同階段的開(kāi)發(fā)人員相互理解不一致。對(duì)于設(shè)計(jì)或編程上的一些假定或依賴性，相關(guān)人員沒(méi)有充分溝通。項(xiàng)目組成員技術(shù)水平參差不齊技術(shù)問(wèn)題。算法錯(cuò)誤：在給定條件下沒(méi)能給出正確或準(zhǔn)確的結(jié)果。語(yǔ)法錯(cuò)誤：對(duì)于編譯性語(yǔ)言程序，編譯器可以發(fā)現(xiàn)這類問(wèn)題；但對(duì)于解釋性語(yǔ)言程序，只能在測(cè)試運(yùn)行時(shí)發(fā)現(xiàn)。計(jì)算和精度問(wèn)題：計(jì)算的結(jié)果沒(méi)有滿足所需要的精度。系統(tǒng)結(jié)構(gòu)不合理、算法選擇不科學(xué)，造成系統(tǒng)性能低下。接口參數(shù)傳遞不匹配，導(dǎo)致模塊集成出現(xiàn)問(wèn)題。

項(xiàng)目管理的問(wèn)題：缺乏質(zhì)量文化，不重視質(zhì)量計(jì)劃，對(duì)質(zhì)量、資源、任務(wù)、成本等的平衡性把握不好，容易擠掉需求分析、評(píng)審、測(cè)試、等時(shí)間，遺留的缺陷會(huì)比較多。系統(tǒng)分析時(shí)對(duì)客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。開(kāi)發(fā)周期短，需求分析、設(shè)計(jì)、編程、測(cè)試等各項(xiàng)工作不能完全按照定義好的流程來(lái)進(jìn)行，工作不夠充分，結(jié)果也就不完整、不準(zhǔn)確，錯(cuò)誤較多；周期短，還給各類開(kāi)發(fā)人員造成太大的壓力，引起一些人為的錯(cuò)誤。開(kāi)發(fā)流程不夠完善，存在太多的隨機(jī)性和缺乏嚴(yán)謹(jǐn)?shù)膬?nèi)審或評(píng)審機(jī)制，容易產(chǎn)生問(wèn)題。文檔不完善，風(fēng)險(xiǎn)估計(jì)不足等。4.軟件測(cè)試V模型

①繪制示意圖

②闡述每個(gè)步驟是做什么 需求分析

即首先要明確客戶需要的是什么，需要軟件作成什么樣子，需要有那幾項(xiàng)功能

概要設(shè)計(jì)

主要是架構(gòu)的實(shí)現(xiàn)，指搭建架構(gòu)、表述各模塊功能、模塊接口連接和數(shù)據(jù)傳遞的實(shí)現(xiàn)等項(xiàng)事務(wù)。詳細(xì)設(shè)計(jì)

對(duì)概要設(shè)計(jì)中表述的各模塊進(jìn)行深入分析，對(duì)各模塊組合進(jìn)行分析等。軟件編碼

按照詳細(xì)設(shè)計(jì)好的模塊功能表，編程人員編寫出實(shí)際的代碼。單元測(cè)試

按照設(shè)定好的最小測(cè)試單元進(jìn)行按單元測(cè)試，主要是測(cè)試程序代碼，為的是確保各單元模塊被正確的編譯，單元的具體劃分按不同的單位與不同的軟件有不同。集成測(cè)試

經(jīng)過(guò)了單元測(cè)試后，將各單元組合成完整的體系，主要測(cè)試各模塊間組合后的功能實(shí)現(xiàn)情況，以及模塊接口連接的成功與否，數(shù)據(jù)傳遞的正確性等，其主要目的是檢查軟件單位之間的接口是否正確。根據(jù)集成測(cè)試計(jì)劃，一邊將模塊或其他軟件單位組合成系統(tǒng)，一邊運(yùn)行該系統(tǒng)，以分析所組成的系統(tǒng)是否正確，各組成部分是否合拍。系統(tǒng)測(cè)試

經(jīng)過(guò)了單元測(cè)試和集成測(cè)試以后，我們要把軟件系統(tǒng)搭建起來(lái)，按照軟件規(guī)格說(shuō)明書(shū)中所要求，測(cè)試軟件其性能功能等是否和用戶需求相符合，在系統(tǒng)中運(yùn)行是否存在漏洞，等。驗(yàn)收測(cè)試

主要就是用戶在拿到軟件的時(shí)候，在使用現(xiàn)場(chǎng)，會(huì)根據(jù)前邊所提到的需求，以及規(guī)格說(shuō)明書(shū)來(lái)做相應(yīng)測(cè)試，以確定軟件達(dá)到符合效果的。

第五篇：軟件測(cè)試學(xué)習(xí)綱要

《軟件測(cè)試》學(xué)習(xí)綱要

一、2013年春季學(xué)期期末考試題型如下：

1、選擇題：15題、每題2分；共30分

2、填空題：15空、每空1分；共15分

3、論述題：6題、每題5分；共30分

4、軟件測(cè)試實(shí)踐題：4題、共25分

學(xué)習(xí)要點(diǎn)：

1)軟件測(cè)試目的、原則、誤區(qū)、對(duì)象、分類

2)軟件缺陷

3)軟件測(cè)試V模型

4)測(cè)試用例概念、設(shè)計(jì)原則、設(shè)計(jì)步驟

5)黑盒、白盒測(cè)試

6)邊界值、等價(jià)類測(cè)試用例設(shè)計(jì)

7)因果圖法

8)場(chǎng)景法

9)邏輯覆蓋測(cè)試分類、關(guān)系

10)環(huán)路復(fù)雜度

11)單元測(cè)試概念

12)單元測(cè)試的策略

13)集成測(cè)試概念

14)集成測(cè)試策略10個(gè)字

15)系統(tǒng)測(cè)試的概念

16)回歸測(cè)試概念

17)驗(yàn)收測(cè)試概念、過(guò)程

18)動(dòng)態(tài)測(cè)試與靜態(tài)測(cè)試

19)系統(tǒng)性能參數(shù)

20)性能測(cè)試分類

21)測(cè)試計(jì)劃、測(cè)試報(bào)告文檔內(nèi)容

22)白盒測(cè)試用例設(shè)計(jì)

23)黑盒測(cè)試用例設(shè)計(jì)

24)Junit單元測(cè)試用例設(shè)計(jì)及編程