第一篇：軟件測試實踐之測試環(huán)境的規(guī)劃與管理

測試環(huán)境是指為了完成軟件測試工作所必需的計算機(jī)硬件、軟件、網(wǎng)絡(luò)設(shè)備、歷史數(shù)據(jù)的總稱。毫無疑問，穩(wěn)定和可控的測試環(huán)境，可以使測試人員花費較少的時間就完成測試用例的執(zhí)行，也無需為測試用例、測試過程的維護(hù)花費額外的時間，并且可以保證每一個被提交的缺陷都可以在任何時候被準(zhǔn)確的重現(xiàn)。

簡單的說，經(jīng)過良好規(guī)劃和管理的測試環(huán)境，可以盡可能的減少環(huán)境的變動對測試工作的不利影響，并可以對測試工作的效率和質(zhì)量的提高產(chǎn)生積極的作用。

一、規(guī)劃測試環(huán)境——讓環(huán)境為你服務(wù)

對于“金山詞霸”這樣的軟件，大多數(shù)測試工作都可以在一臺單獨的電腦上完成，而對于一套電信系統(tǒng)，為了執(zhí)行測試用例，你可能會需要搭建一個由多臺計算機(jī)以及其他網(wǎng)絡(luò)設(shè)備組成，采用集群和負(fù)載均衡技術(shù)，并且接駁到Internet的計算機(jī)網(wǎng)絡(luò)。

不同的行業(yè)應(yīng)用，不同的質(zhì)量目標(biāo)，都可能會影響到測試環(huán)境的規(guī)劃。但從測試工作自身的要求來看，一條應(yīng)當(dāng)遵守的原則就是“盡可能的還原軟件在用戶那里最終實際運行的環(huán)境”——雖然在很多時候這是不現(xiàn)實的。^_^

通常來說，我們所需要搭建的環(huán)境，主要是用于被測應(yīng)用的系統(tǒng)測試——單元測試和集成測試由開發(fā)人員在開發(fā)環(huán)境中進(jìn)行，而驗收測試則在用戶的最終應(yīng)用環(huán)境中進(jìn)行，因此都可以暫不考慮。

為了確定測試環(huán)境的組成，我們需要明確以下問題：

1.所需要的計算機(jī)的數(shù)量，以及對每臺計算機(jī)的硬件配置要求，包括CPU的速度、內(nèi)存和硬盤的容量、網(wǎng)卡所支持的速度、打印機(jī)的型號等；

2.部署被測應(yīng)用的服務(wù)器所必需的操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、中間件、WEB服務(wù)器以及其他必需組件的名稱、版本，以及所要用到的相關(guān)補(bǔ)丁的版本；

3.用來保存各種測試工作中生成的文檔和數(shù)據(jù)的服務(wù)器所必需的操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、中間件、WEB服務(wù)器以及其他必需組件的名稱、版本，以及所要用到的相關(guān)補(bǔ)丁的版本；

4.用來執(zhí)行測試工作的計算機(jī)所必需的操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、中間件、WEB服務(wù)器以及其他必需組件的名稱、版本，以及所要用到的相關(guān)補(bǔ)丁的版本；

5.是否需要專門的計算機(jī)用于被測應(yīng)用的服務(wù)器環(huán)境和測試管理服務(wù)器的環(huán)境的備份；

6.測試中所需要使用的網(wǎng)絡(luò)環(huán)境。例如，如果測試結(jié)果同接入Internet的線路的穩(wěn)定性有關(guān)，那么應(yīng)該考慮為測試環(huán)境租用單獨的線路；如果測試結(jié)果與局域網(wǎng)內(nèi)的網(wǎng)絡(luò)速度有關(guān)，那么應(yīng)該保證計算機(jī)的網(wǎng)卡、網(wǎng)線以及用到的集線器、交換機(jī)都不會成為瓶頸；

7.執(zhí)行測試工作所需要使用的文檔編寫工具、測試管理系統(tǒng)、性能測試工具、缺陷跟蹤管理系統(tǒng)等軟件的名稱、版本、License數(shù)量，以及所要用到的相關(guān)補(bǔ)丁的版本。對于性能測試工具，則還應(yīng)當(dāng)特別關(guān)注所選擇的工具是否支持被測應(yīng)用所使用的協(xié)議；

8.為了執(zhí)行測試用例，所需要初始化的各項數(shù)據(jù)，例如登陸被測應(yīng)用所需的用戶名和訪問權(quán)限，或其他基礎(chǔ)資料、業(yè)務(wù)資料；對于性能測試，還應(yīng)當(dāng)特別考慮執(zhí)行測試場景前應(yīng)當(dāng)滿足的歷史數(shù)據(jù)量。當(dāng)然，還有另外一個非常關(guān)鍵的問題：在測試過程中受到影響的數(shù)據(jù)如何恢復(fù)？

明確了上面的問題后，明確哪些條件是可以滿足的，哪些是需要其他部門協(xié)助調(diào)配、采購或者支援的。建議在搭建測試環(huán)境之前，把上面的問題做成一張 CheckList，并為每一項指定一個責(zé)任人，完成一項就填寫一項，最終形成的文檔則作為測試環(huán)境的配置說明文檔使用。當(dāng)然，如果時間或其他條件允許，應(yīng)當(dāng)做好應(yīng)急預(yù)案，盡量保證在環(huán)境失效時不會對正常工作產(chǎn)生太大的影響。

二、管理測試環(huán)境——把變化掌握在手中

測試環(huán)境搭建好以后不太可能永遠(yuǎn)不發(fā)生變化，至少被測應(yīng)用的每次版本發(fā)布都會對測試環(huán)境產(chǎn)生或多或少的影響。而應(yīng)對變化之道，不是禁止變化，而是“把變化掌握在手中”。下面的這些建議可以幫助你盡可能擺脫環(huán)境變化所帶來的不利影響。

1.設(shè)置專門的測試環(huán)境管理員角色

每個測試項目或測試小組都應(yīng)當(dāng)配備一名專門的測試環(huán)境管理員，其職責(zé)包括：測試環(huán)境的搭建。包括操作系統(tǒng)、數(shù)據(jù)庫、中間件、WEB服務(wù)器等必須軟件的安裝，配置，并做好各項安裝、配置手冊的編寫；

記錄組成測試環(huán)境的各臺機(jī)器的硬件配置、IP地址、端口配置、機(jī)器的具體用途，以及當(dāng)前網(wǎng)絡(luò)環(huán)境的情況；

完成被測應(yīng)用的部署，并做好發(fā)布文檔的編寫；

測試環(huán)境各項變更的執(zhí)行及記錄；

測試環(huán)境的備份及恢復(fù)；

操作系統(tǒng)、數(shù)據(jù)庫、中間件、WEB服務(wù)器以及被測應(yīng)用中所需的各用戶名、密碼以及權(quán)限的管理；

當(dāng)測試組內(nèi)多名成員需要占用服務(wù)器并且相互之間存在沖突時（例如在執(zhí)行性能測試時，在同一時刻應(yīng)當(dāng)只有一個場景在運行），負(fù)責(zé)對服務(wù)器時間進(jìn)行分配和管理。

2.明確測試環(huán)境管理所需的各種文檔

一般來說，下面的幾個文檔是必需的，當(dāng)然你也可以根據(jù)需要增加新的文檔。

組成測試環(huán)境的各臺計算機(jī)上各項軟件的安裝配置手冊，記錄各項軟件的名稱、版本、安裝過程、相關(guān)參數(shù)的配置方法等，并記錄好歷次軟件環(huán)境的變更情況；

組成測試環(huán)境的各臺機(jī)器的硬件環(huán)境文檔，記錄各臺機(jī)器的硬件配置（CPU/內(nèi)存/硬盤/網(wǎng)卡）、IP地址、具體用途以及歷次的變更情況；

被測應(yīng)用的發(fā)布手冊，記錄被測應(yīng)用的發(fā)布/安裝方法，包括數(shù)據(jù)庫表的創(chuàng)建、數(shù)據(jù)的導(dǎo)入、應(yīng)用層的安裝等。另外，還需要記錄歷次被測應(yīng)用的發(fā)布情況，對版本差異進(jìn)行描述；測試環(huán)境的備份和恢復(fù)方法手冊，并記錄每次備份的時間、備份人、備份原因（與上次備份相比發(fā)生的變化）以及所形成的備份文件的文件名和獲取方式；

用戶權(quán)限管理文檔，記錄訪問操作系統(tǒng)、數(shù)據(jù)庫、中間件、WEB服務(wù)器以及被測應(yīng)用時所需的各種用戶名、密碼以及各用戶的權(quán)限，并對每次變更進(jìn)行記錄。

3.測試環(huán)境訪問權(quán)限的管理

應(yīng)當(dāng)為每個訪問測試環(huán)境的測試人員和開發(fā)人員設(shè)置單獨的用戶名，并根據(jù)不同的工作需要設(shè)置不同的訪問權(quán)限，以避免誤操作對測試環(huán)境產(chǎn)生不利的影響。下面的要求可以作為建立“測試環(huán)境訪問權(quán)限管理規(guī)范”的基礎(chǔ)。

訪問操作系統(tǒng)、數(shù)據(jù)庫、中間件、WEB服務(wù)器以及被測應(yīng)用等所需的各種用戶名、密碼、權(quán)限，由測試環(huán)境管理員統(tǒng)一管理；

測試環(huán)境管理員擁有全部的權(quán)限；

除對被測應(yīng)用的訪問權(quán)限外，一般不授予開發(fā)人員對測試環(huán)境其他部分的訪問權(quán)限。如的確有必要（例如查看系統(tǒng)日志），則只授予只讀權(quán)限；

除測試環(huán)境管理員外，其他測試組成員不授予刪除權(quán)限；

用戶及權(quán)限的各項維護(hù)、變更，需要記錄到相應(yīng)的“用戶權(quán)限管理文檔”中。

4.測試環(huán)境的變更管理

對測試環(huán)境的變更應(yīng)當(dāng)形成一個標(biāo)準(zhǔn)的流程，并保證每次變更都是可追溯的和可控的。下面的幾項要點并不是一個完整的流程，但是可以幫助你實現(xiàn)這個目標(biāo)。

測試環(huán)境的變更申請由開發(fā)人員或測試人員提出書面申請，由測試環(huán)境管理員負(fù)責(zé)執(zhí)行。測試環(huán)境管理員不應(yīng)接受非正式的變更申請（例如口頭申請）；

對測試環(huán)境的任何變更均應(yīng)記入相應(yīng)的文檔；

同每次變更相關(guān)的變更申請文檔、軟件、腳本等均應(yīng)保留原始備份，作為配置項進(jìn)行管理；

對于被測應(yīng)用的發(fā)布，開發(fā)人員應(yīng)將整個系統(tǒng)（包括數(shù)據(jù)庫、應(yīng)用層、客戶端等）打包為可直接發(fā)布的格式，由測試環(huán)境管理員負(fù)責(zé)實施。測試環(huán)境管理員不接受不完整的版本發(fā)布申請；

對測試環(huán)境做出的變更，應(yīng)該可以通過一個明確的方法返回到之前的狀態(tài)。

5.測試環(huán)境的備份和恢復(fù)

對于測試人員來說，測試環(huán)境必須是可恢復(fù)的，否則將導(dǎo)致原有的測試用例無法執(zhí)行，或者發(fā)現(xiàn)的缺陷無法重現(xiàn)，最終使測試人員已經(jīng)完成的工作失去價 值。因此，應(yīng)當(dāng)在測試環(huán)境（特別是軟件環(huán)境）發(fā)生重大變動（例如安裝操作系統(tǒng)、中間件或數(shù)據(jù)庫，為操作系統(tǒng)、中間件或數(shù)據(jù)庫打補(bǔ)丁等對系統(tǒng)產(chǎn)生重大影響并 難以通過卸載恢復(fù)）時進(jìn)行完整的備份，例如使用Ghost對硬盤或某個分區(qū)進(jìn)行鏡像備份。并由測試環(huán)境管理員在相應(yīng)的“備份記錄”文檔中記錄每次備份的時 間、備份人以及備份原因（與上次備份相比發(fā)生的變化），以便于在需要時將系統(tǒng)重新恢復(fù)到安全可用的狀態(tài)。

另外，每次發(fā)布新的被測應(yīng)用版本時，應(yīng)當(dāng)做好當(dāng)前版本的數(shù)據(jù)庫備份。而在執(zhí)行測試用例或性能測試場景之前，也應(yīng)當(dāng)做好數(shù)據(jù)備份或準(zhǔn)備數(shù)據(jù)恢復(fù)方案，例如通過運行SQL腳本來將數(shù)據(jù)恢復(fù)到測試執(zhí)行之前的狀態(tài)，以便于重復(fù)的使用原有的數(shù)據(jù)，減少因數(shù)據(jù)準(zhǔn)備和維護(hù)而占用的工作量，并保證測試用例的有效性和缺陷記錄的可重現(xiàn)。

第二篇：軟件測試（推薦）

一、簡答5*6’

1.為什么不讓時間有余的人做測試工作

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

我們沒有對軟件進(jìn)行完全測試，實際就是選擇了風(fēng)險，因為缺陷極有可能存在沒有進(jìn)行測試的部分。因此，我們要盡可能的選擇最合適的測試量，把風(fēng)險降低到最小 3.所有軟件測試缺陷都需要修復(fù)嗎

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

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

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

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

5.驗收測試的注意點有哪些 測試要注意下面的事項：

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

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

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

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

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

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

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

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

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

測試報告一般分為內(nèi)部測試報告和外部測試報告。內(nèi)部報告是我們在測試工作中的項目文檔，反映了測試工作的實施情況,一般外部測試報告要滿足下面幾個要求：

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

二、論述2*12’

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

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

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

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

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

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

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

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

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

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

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

①繪制示意圖

②闡述每個步驟是做什么 需求分析

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

概要設(shè)計

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

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

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

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

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

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

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

第三篇：軟件測試管理總結(jié)

軟件測試管理總結(jié)

軟件測試工程師管理系統(tǒng)是我接觸的測試管理項目，通過近兩個星期對軟件測試管理的學(xué)習(xí)和實踐，遇到了很多問題，覺得還是有很多經(jīng)驗需要總結(jié)。

隨著軟件開發(fā)規(guī)模的增加、復(fù)雜程度的增加，以尋找軟件中的故障為目的的測試工作就

顯得更加重要。因此，為了盡可能多的找出程序中的故障，開發(fā)出高質(zhì)量的軟件產(chǎn)品，必須

對測試工作進(jìn)行組織策劃和有效管理，采取系統(tǒng)的辦法建立起來軟件測試管理系統(tǒng)。在進(jìn)行

測試工作識別管理的過程中，我主要做了測試計劃，測試實施，測試總結(jié)這幾部分工作。

一、測試計劃的編寫要足夠清晰合理。

測試計劃階段的整體目標(biāo)是為了確定測試范圍、測試策略和方法，以及對可能出現(xiàn)的問

題和風(fēng)險，所需要的各種資源和投入等進(jìn)行分析和估計，以指導(dǎo)測試的執(zhí)行。在計劃中要明

確測試的目的，完善對測試人員的資源分配，設(shè)置測試的標(biāo)準(zhǔn)，責(zé)任及時間都有明確的進(jìn)度

安排，指出所用工具。測試計劃編寫時要對照產(chǎn)品需求說明書，系統(tǒng)全面的對測試工作作出

籌劃。

二、準(zhǔn)確的填寫bug記錄單需進(jìn)行充分的步驟記錄。

在測試過程中，bug記錄單不清晰，產(chǎn)品錯誤便不會容易再現(xiàn)。作為測試管理人員對于

問題記錄單中必須包括的要素要了解。我曾經(jīng)有過造成填寫的問題記錄單過于簡練，只有結(jié)

果，沒有清晰的操作步驟，沒有描述產(chǎn)生錯誤的數(shù)據(jù)信息等，這些都會在測試實施過程中造

成不必要的麻煩，給開發(fā)人帶來模糊理解。認(rèn)識問題才能解決問題，我在以后的工作中正盡

可能避免這些問題。

三、測試結(jié)果的分析要全面公正。

測試結(jié)束后，對測試結(jié)果進(jìn)行分析，以確定軟件產(chǎn)品的質(zhì)量，為產(chǎn)品的改進(jìn)或發(fā)布提供

數(shù)據(jù)和支持。在管理上，應(yīng)做好測試結(jié)果的審查和分析，做好測試報告的撰寫和審查工作。

對軟件測試工程師管理系統(tǒng)的管理工作中，我覺得還可以努力地還有，明確測試流程，注意測試流程中各階段的注意事項，及正確填寫問題記錄單。及時發(fā)現(xiàn)測試實施工作中的各

種問題，加強(qiáng)與開發(fā)人員的溝通，以便及時解決問題，保證產(chǎn)品測試進(jìn)度。

第四篇：軟件測試管理常見問題及其回答

由安博測試空間技術(shù)中心http:///提供

軟件測試管理常見問題及其回答

軟件測試管理常見問題及其回答

1、測試負(fù)責(zé)人要進(jìn)行嚴(yán)格的測試進(jìn)度跟蹤嗎？

很多時候，由于人力資源的不足，測試項目負(fù)責(zé)人都是在執(zhí)行測試，這樣就使整個項目缺乏控制，一些問題（例如：有些成員的缺陷質(zhì)量不夠合格；開發(fā)人員修改不及時，系統(tǒng)某些功能發(fā)生嚴(yán)重問題導(dǎo)致部分功能無法測試。）得不到解決，耽誤了進(jìn)度。所以測試負(fù)責(zé)任必須全程監(jiān)控項目，盡可能多的掌握信息。通常，測試負(fù)責(zé)人需要完成下面這些內(nèi)容的管理工作： 測試用例執(zhí)行情況；

每個測試員提交的缺陷情況；

測試中是否發(fā)生突發(fā)問題。

2、測試也有版本控制嗎？

這里的版本主要是指測試對象的版本控制，也就是指對開發(fā)部提交的產(chǎn)品進(jìn)行版本控制。在開發(fā)小組版本管理不規(guī)范的情況下，測試小組進(jìn)行版本控制十分重要，要保證測試對象是可以控制的。建議開發(fā)和測試雙方進(jìn)行明確的約定，可以各自指定專門的測試版本負(fù)責(zé)人，制定提交原則，對提交情況進(jìn)行詳細(xì)的記錄，這樣基本避免了版本失控導(dǎo)致的測試失誤或無效。

3、如何處理測試人員的流動問題？

人員流動不僅僅是測試部門，這是IT行業(yè)的普遍現(xiàn)象。從管理者角度，主管需要多多和團(tuán)隊內(nèi)成員進(jìn)行溝通，建立一個融洽的團(tuán)隊環(huán)境，及時掌握情況，可以早些進(jìn)行相應(yīng)的調(diào)整。但是只有企業(yè)建立好的用人制度，給員工提高廣闊的發(fā)展空間和好的培訓(xùn)學(xué)習(xí)機(jī)會，才能從根本上解決這一問題。

加強(qiáng)項目管理，強(qiáng)化文檔管理并保證文檔的有效性，可以大大減少由于人員流失帶來的損失。同時，測試部門要建立培訓(xùn)機(jī)制，使新到員工接受直接或者間接的培訓(xùn)，快速適應(yīng)工作。

4、為什么開發(fā)人員經(jīng)常抱怨測試工程師提交的缺陷質(zhì)量太差？

我們經(jīng)常聽開發(fā)人員說：“這不是缺陷！”，“這個缺陷沒有，因為我的系統(tǒng)上運行正常！”。測試工程師本身就是做質(zhì)量工作的，提交的成果本身就應(yīng)該質(zhì)量高些，為什么還會有這種現(xiàn)象？

提交的缺陷引起爭議是一種正常的現(xiàn)象，例如測試人員描述不清楚就會引起爭議。減少甚至避免這種現(xiàn)象的方法是交叉測試，交叉測試是提高測試質(zhì)量的一個有效手段，當(dāng)然交叉測試會增加一定的測試成本投入。在測試任務(wù)完成后，測試工程師之間互相驗證彼此提交的缺陷，就會避免了缺陷描述不清、因運行環(huán)境而產(chǎn)生的缺陷等一系列問題，從而大大降低了回歸測試以及交流的成本，因而這種投入也是值得的，實際開發(fā)人員在單元測試階段也會進(jìn)行交叉測試，來提高開發(fā)質(zhì)量。

另外，測試人員一定要按照規(guī)范描述測試中發(fā)現(xiàn)的缺陷，一個缺陷至少描述清楚概要描述、詳細(xì)描述、重現(xiàn)步驟三方面的內(nèi)容，缺陷管理參考第八章的內(nèi)容。

5、“讓那些新手來做測試，反正他們也不會什么”正確嗎？

在實際項目開發(fā)中，我們常?？吹接行﹩挝缓鲆暅y試團(tuán)隊存在的意義，當(dāng)要實施測試時，往往臨時找?guī)讉€程序員充當(dāng)測試人員。也有些單位盡管認(rèn)識到了組建測試團(tuán)隊的重要性，但在具體落實的時候往往安排一些毫無開發(fā)經(jīng)驗的行業(yè)新手去做測試工作，這常常導(dǎo)致測試效率低下，測試人員對測試工作索然無味。

根據(jù)筆者的經(jīng)驗，測試團(tuán)隊?wèi)?yīng)首先聘請一名資深的測試領(lǐng)域?qū)＜?，他?yīng)具有極為豐富的同類項目軟件測試經(jīng)驗，對軟件開發(fā)過程中常見的缺陷或錯誤了然于胸;此外，他還具有較好的親和力和人格魅力。其次，項目測試團(tuán)隊還具有很多具備一技之長的成員，如對某些自動化測試工具運用嫻熟或能輕而易舉地編寫自動化測試腳本等。

另外，測試團(tuán)隊還應(yīng)聘請一些兼職成員，如驗證測試實施過程中，同行評審是最常使用的一種形式，這些同行專家就屬于兼職測試團(tuán)隊成員的范疇。至于測試團(tuán)隊里里的測試新手，這部分人可以安排去從事交付驗證或黑盒測試之類的6、測試同化現(xiàn)象是什么？

同化現(xiàn)象是指隨著時間的推移，開發(fā)人員會逐漸影響測試人員的思維和對缺陷的判斷能力，尤其是針對同一產(chǎn)品，同一組開發(fā)人員和同一組測試人員共同配合了很長時間，很多本來是缺陷的問題，由于測試人員對軟件“習(xí)慣成自然”的使用，會不被當(dāng)成缺陷，尤其是在開發(fā)人員的解釋和說服下。同化現(xiàn)象發(fā)生可能意味著“惡性循環(huán)”的開始：測試人員會幫著開發(fā)人員解釋一個個缺陷的合理性，一輪有一輪的測試都不會發(fā)現(xiàn)問題。

招聘新的人員，不同的測試項目組輪換去測試不同的產(chǎn)品，就可以避免。同時建議產(chǎn)品可以發(fā)布測試版，更多的人對其進(jìn)行測試，就可以發(fā)現(xiàn)更多的問題。

7、測試工程師如何避免定位效應(yīng)？

社會心理學(xué)家曾作過一個試驗：在召集會議時先讓人們自由選擇位子，之后到室外休息片刻再進(jìn)入室內(nèi)入座，如此五至六次，發(fā)現(xiàn)大多數(shù)人都選擇他們第一次坐過的位子。這種現(xiàn)象稱為定位效應(yīng)，說明人們習(xí)慣上凡是自己認(rèn)定的，人們大都不想輕易改變它。

定位效應(yīng)在開發(fā)人員和測試人員身上都有體現(xiàn)。例如開發(fā)工程師針對某一自己寫的功能，經(jīng)常進(jìn)行代碼移植，這種復(fù)制的“功能”，由于上一次經(jīng)過調(diào)試，在新的地方往往不會認(rèn)真調(diào)試，這些代碼往往會帶來共享變量沖突等許多種類型的缺陷。

定位效應(yīng)體現(xiàn)在測試人員身上就是測試過的功能不再進(jìn)行認(rèn)真測試：在回歸測試時，之前由于進(jìn)行過認(rèn)真的測試，往往會認(rèn)為某些功能是可靠，只要驗證一些以前發(fā)現(xiàn)的缺陷是否修改完成就可以了。這種現(xiàn)象在反復(fù)多次回歸時表現(xiàn)的更加突出，因為回歸測試中很多功能都會進(jìn)行多次反復(fù)測試。眾所周知，開發(fā)人員在修改缺陷時往往會引入新的缺陷，測試人員的疏于防范就會把這些缺陷帶到用戶這里。

解決這種問題的方案一般有兩個：

(1)完整的執(zhí)行測試用例：這種方法投入較大，但是在開發(fā)產(chǎn)品時最好在最后一次回歸測試時測試的執(zhí)行一次全部的測試用例。

(2)交叉測試：測試人員交叉測試，就可以很大程度的避免定位效應(yīng)。測試工程師在回歸測試時互相交換任務(wù)，反復(fù)測試某一功能的機(jī)會大大減少，從而也就不會“主觀的”人員某些功能沒有缺陷。

通常上面的兩個方法都是結(jié)合使用的，既要進(jìn)行交叉測試，又要全面執(zhí)行測試用例，測試覆

蓋面要盡可能的廣泛。

8、測試人員忽然辭職怎么辦？

目前IT行業(yè)人員流動較大已經(jīng)成為一種不爭的事實，員工的辭職大多數(shù)都會給組織帶來一定的影響，而這種影響基本是不可能避免的。在測試領(lǐng)域，員工忽然辭職也會帶來很大的負(fù)面影響，尤其測試隊伍規(guī)模較小時。面對這種情況，我們所能做的，就是如何最大限度的降低這種影響。

根據(jù)作者的經(jīng)驗，主要有兩種方法：第一種是在測試人員內(nèi)部建立一個良好的學(xué)習(xí)環(huán)境，大家互相學(xué)習(xí)，這樣某些特有技術(shù)不會被某一個人所掌握，而互相學(xué)習(xí)和提高自身，也是大多數(shù)成員愿意做的；第二種就是在組織中進(jìn)行知識管理，把技術(shù)作為知識沉淀下來，這樣新的員工在接手工作時容易上手，通過學(xué)習(xí)快速適應(yīng)環(huán)境。

此外，日常還要注意工作規(guī)范化，例如形成盡可能多的文檔，都可以降低員工離職帶來的損失。

9、測試人員工作發(fā)生問題測試經(jīng)理應(yīng)該如何做？

測試人員工作發(fā)生問題是測試經(jīng)理經(jīng)常要面對的問題，作為測試部門的領(lǐng)導(dǎo)，首先要做的是指出測試人員所犯的錯誤，使其盡快改正錯誤。

唯一不能做的就是盯著下屬的錯誤不放。總盯著下屬的失誤，是一個領(lǐng)導(dǎo)者的最大失誤。英國行為學(xué)家波特說：當(dāng)遭受許多批評時，下級往往只記住開頭的一些，其余就不聽了，因為他們忙于思索論據(jù)來反駁開頭的批評。身為測試經(jīng)理要根據(jù)測試人員的心理來進(jìn)行指導(dǎo)，最大限度的調(diào)動每個人員的積極性來參加工作。

10、不深入到具體測試工作時，測試經(jīng)理如何考核員工？

這種現(xiàn)象在測試規(guī)模較大的組織中很常見。測試經(jīng)理應(yīng)該盡可能的安排每周與每個成員在不被打擾的環(huán)境下進(jìn)行談話，這樣可以盡早發(fā)現(xiàn)和解決很多問題。

最為一個測試經(jīng)理，主要工作之一就是定期的評定組織做了些什么并且是怎樣做的。同時還要為員工做一個報告——關(guān)于充分了解測試人員正在做什么和怎樣做的報告，以此來給測試人員做做工作成績考核。這份報告要了解到每個人的動態(tài)。

測試經(jīng)理和每個員工重點是談?wù)勀壳暗墓ぷ鳎绱蠹以诠ぷ髦械膯栴}或意見；是否需要幫助等。許多管理者經(jīng)常抱怨沒有時間在一周會見每一個員工來談他們的工作。但是根據(jù)作者的經(jīng)驗，如果不能安排時間和員工進(jìn)行每周的談話，員工會來打擾測試經(jīng)理的工作，因為員工很多問題還要要來找測試經(jīng)理商議。

同時對待員工要用他們能接受的方式，而不是我們自己可以接受的方式。“己之不予，勿施于人”，這條黃金法則可能會對許多生活中的純粹的社交因素有效，但是并不是總對工作有用。有效率的管理者知道應(yīng)該逐漸了解每一個員工需要怎樣的對待方式。

總之，只有盡可能多的和員工接觸，才能更精確的進(jìn)行考核。

11、測試經(jīng)理如何面對加班問題？

大多數(shù)情況下，作者是不主張加班的。當(dāng)員工每周工作超過40個小時的時候，他們開始在工作的時候關(guān)心自己的事。他們花錢，會給很久沒有聯(lián)系的人打電話，因為員工們一直都在工作。員工不能在太疲勞的狀態(tài)下完成工作，這是因為他們在工作時不能關(guān)心自己，這種情況下通常效率很低。

測試管理工作的重要任務(wù)之一就是要創(chuàng)造一個環(huán)境，讓員工在工作時間內(nèi)完成工作，同時還要鼓勵他們每周不要超過40小時，甚至可以基于他們在40個小時能夠完成的工作量給他們酬勞。通常情況下這樣做能夠提升創(chuàng)造力，從而會逐漸提高效率。

測試工作本身的一個突出特點就是不斷重復(fù)枯燥、冗長的測試，如果在疲勞狀態(tài)下，很有可能精力不集中，略過一些重要的測試環(huán)節(jié)。而且有的時候測試需要編寫測試驅(qū)動程序，這種情況更需要較好的狀態(tài)來工作。

12、測試管理者如何面對自己的錯誤？

每個人都會犯錯。我們可能會因為忘記開會而使客戶發(fā)怒，承認(rèn)自己犯錯是一件尷尬的事情，尤其是管理人員認(rèn)為對自己負(fù)責(zé)的項目小組承認(rèn)犯錯可能會失去尊嚴(yán)。如果我們不是經(jīng)常犯錯，承認(rèn)錯誤的時候其實能夠贏得尊敬。例如我們忘記一次會議，然后為此向同事或者客戶道歉，其他的人會理解我們的。

不管做了什么，不要否認(rèn)或故意忽略自己的失誤。故意忽略不會讓錯誤消失，這只會讓錯誤成長為怪物。

13、為什么計劃定期的培訓(xùn)?

測試工作和開發(fā)工作一樣，不但要面對日新月異的新技術(shù)，還要學(xué)習(xí)相關(guān)系統(tǒng)的領(lǐng)域知識。只有在不斷的學(xué)習(xí)中，才能做好工作，跟上行業(yè)的發(fā)展。如果測試管理者沒有基于不斷的變化而培訓(xùn)員工，就會給組織帶來一定的損失。日常培訓(xùn)可以是關(guān)于特定項目或者是技術(shù)，通常采用下面幾種方法：

（1）測試部門內(nèi)自由交流方式的培訓(xùn)。這種培訓(xùn)的交流比較隨意，可以在周五的例會上進(jìn)行交流，也可以大家一起坐在茶館里進(jìn)行交流。方法可以采用“頭腦風(fēng)暴法”，讓每個組員討論一個特定的領(lǐng)域，這種交流方法特別對同時要做很多不同項目的小組比較有益處。當(dāng)每個人做不同的項目，這會有助于每個人了解你小組所有的工程。

（2）跨部門的互相學(xué)習(xí)。測試工作需要很多領(lǐng)域以及技術(shù)知識，這些知識單靠自學(xué)是遠(yuǎn)遠(yuǎn)不夠的。和其它部門的同事進(jìn)行交流是一個相當(dāng)好的辦法，大家在工作中可以在技術(shù)等各個方面互相得到提高。

（3）外部培訓(xùn)。外部培訓(xùn)盡管投入較高，但也是值得的。這些專家一般在自己的領(lǐng)域非常精通，可以快速提高整個測試團(tuán)隊的水平。也可以通過測試小組介紹一些朋友來進(jìn)行培訓(xùn)，這種方式可以降低成本。

培訓(xùn)是構(gòu)造學(xué)習(xí)型組織的基本條件，也是提高員工水平的重要方法。經(jīng)常的定期培訓(xùn)，可以增強(qiáng)組織凝聚力，使員工更加愿意長期留在組織中發(fā)展。做為測試負(fù)責(zé)人，定期的進(jìn)行培訓(xùn)是十分必要的。

14、時間上不允許進(jìn)行全部測試，測試負(fù)責(zé)人應(yīng)該如何做？

這個問題也許十分可笑，可是現(xiàn)實中我們的測試經(jīng)理們卻不得不面對這個問題。這里的全部測試不是指對軟件進(jìn)行遍歷測試，而是指測試負(fù)責(zé)人制定的測試計劃包含的全部測試內(nèi)容。通常，不管是開發(fā)產(chǎn)品還是做具體的項目，都會發(fā)生耽誤進(jìn)度的情況。一旦整體進(jìn)度不能向后延遲，項目相關(guān)人員習(xí)慣上的做法就是縮減測試時間。尤其在功能還沒有開發(fā)完成的情況

下，這種現(xiàn)象更為突出。

擔(dān)負(fù)著質(zhì)量重任的測試經(jīng)理，如何來解決這個問題呢？比較好的做法是按照下面的步驟逐步來完成和改進(jìn)工作：

（1）按照測試任務(wù)的輕重緩急，盡最大努力完成測試任務(wù)。在時間不足的情況下，我們應(yīng)該對測試任務(wù)按照優(yōu)先級來劃分，重要緊急的任務(wù)先完成。這個時候的測試任務(wù)是一種輔助性工作，其目的就是盡最大努力來提高質(zhì)量。因此，面對這種情況，測試負(fù)責(zé)人要做的就是帶領(lǐng)測試小組充分利用所有資源來保證質(zhì)量。

（2）在實際工作中和開發(fā)人員共同配合，逐步改進(jìn)工作。只有整個團(tuán)隊的軟件開發(fā)能力提高了，才能從根源上解決問題。因此，測試負(fù)責(zé)人要帶領(lǐng)團(tuán)隊和開發(fā)小組共同尋找適合自己的開發(fā)模式，從而使項目規(guī)劃的更加合理，進(jìn)而按照預(yù)定計劃來開展測試工作。

總之，在任何情況下，測試負(fù)責(zé)人都不應(yīng)該抱怨。只有積極的面對問題，才能更好的解決問題。

15、公司不重視測試，測試負(fù)責(zé)人如何開展測試工作？

目前國內(nèi)的軟件公司不重視測試仍然是一種普遍現(xiàn)象。盡管很多公司在意識上已經(jīng)開始重視測試，但是在具體工作中，往往由于追趕進(jìn)度、節(jié)省資源等方面原因而忽略測試工作。在這種情況下，測試負(fù)責(zé)人仍要對軟件質(zhì)量負(fù)主要責(zé)任。在這種環(huán)境下，測試負(fù)責(zé)人應(yīng)該如何開展工作呢？

首先，要主動去配合開發(fā)人員完成工作。尤其是不能抱怨環(huán)境，在任何情況下抱怨是不能解決問題的，只能加重矛盾的激化。在此基礎(chǔ)上，逐漸顯出測試工作的重要性，然后再逐步健全測試體系。

其次，用實際行動來證明測試工作的重要性。只有測試工作的業(yè)績逐步表現(xiàn)出來，人們才會真正的注意到測試的重要性。因此，測試負(fù)責(zé)人從點滴開始做起，才能逐步做好測試工作。要想做好軟件，把開發(fā)的軟件產(chǎn)品形成商品，測試工作必須和開發(fā)一樣重視。否則，質(zhì)量不好的產(chǎn)品，很快會被市場淘汰的?，F(xiàn)代的軟件規(guī)模越來越大，測試工作也會越來越重要，因此測試負(fù)責(zé)人只要堅持做好工作，可發(fā)揮作用的空間會越來越大。

最后要說的是，如果真的是在一個沒有希望的團(tuán)隊里，測試負(fù)責(zé)人可以考慮辭職。辭職也是一個不錯的選擇，到新的環(huán)境去發(fā)揮自己的能力，要比長時間的懷著“郁悶”的心情去工作好的多。

16、測試管理者需要是技術(shù)專家嗎？

測試管理者在測試項目中的主要任務(wù)是制定測試策略，管理測試計劃的落實情況，并且還要為測試項目的進(jìn)行創(chuàng)造良好的執(zhí)行環(huán)境。同時還要調(diào)動員工的創(chuàng)造性，對員工的工作作出評估。這些工作不一定要求測試管理者達(dá)到專家的水平。

但是在實際工作中，由于測試人員的短缺，測試管理者常常做為測試員來執(zhí)行具體的測試任務(wù)。尤其在規(guī)模較小的測試團(tuán)隊，測試管理者的日常工作通常以具體的測試執(zhí)行工作為主，這個時候更需要測試管理者有較好的背景知識。

總體說來，技術(shù)方面的背景知識對測試管理者是十分有益的。例如：分配工作任務(wù)、做進(jìn)度預(yù)算，以及一些具體的執(zhí)行工作，都需要一定的背景知識。當(dāng)然，做為一個測試管理者，沒有必要精通所有的技術(shù)，那也是辦不到的。測試管理者做到正確的幫助員工最好地完成工作，并且提供最好的完成工作的環(huán)境就可以了。

第五篇：軟件測試復(fù)習(xí)資料

1． 黑盒測試法是通過分析程序的功能來設(shè)計測試用例的方法。

2． 黑盒測試除了測試程序外，它還適用于對需求分析階段的軟件文檔進(jìn)行測試。3． 白盒測試除了測試程序外，它也適用于對軟件具體設(shè)計階段的軟件文檔進(jìn)行測試。4． 單元測試一般以白盒測試法為主，測試的依據(jù)是模塊功能規(guī)格說明。5． 軟件測試中常用的靜態(tài)分析方法是引用分析和接口分析。

6． 測試人員的基本素質(zhì)為計算機(jī)專業(yè)技能、測試專業(yè)技能、行業(yè)知識

7． 軟件危機(jī)的體現(xiàn)為：A、開發(fā)成本和進(jìn)度估計不正確B、用戶對完成的軟件不滿足C、軟件經(jīng)常不可維護(hù)；

8． 軟件測試按照開發(fā)階段劃分：A、單元測試

B、集成測試；系統(tǒng)測試C、確認(rèn)測試；驗收測試

9． 軟件測試按照測試技術(shù)劃分：A、性能測試、負(fù)載測試、壓力測試B、恢復(fù)測試、安全測試、兼容測試

10． 軟件測試項目周期是指：A、需求階段、測試計劃B、階段測試、設(shè)計階段測試、執(zhí)行階段 11． 軟件測試原則有：A、制定嚴(yán)格的測試計劃 B、保留所有的測試文檔C、功能測試中的缺陷確認(rèn) 12． 制定測試計劃的步驟：確定測試范圍、確定測試策略、確定測試標(biāo)準(zhǔn)、確定測試構(gòu)架、確定項目管理機(jī)制、預(yù)計測試工作量、測試計劃評審 13． 對于軟件的β測試，β測試就是在軟件公司外部展開的測試，由非專業(yè)的測試人員執(zhí)行的測試。14． 正式的技術(shù)評審FTR（Formal Technical Review）是軟件質(zhì)量保證活動，其相關(guān)的描述為： A.FTR是評審產(chǎn)品而不是評審生產(chǎn)者的能力B.FTR要有嚴(yán)格的評審計劃并遵守日程安排C.FTR限制參與者人數(shù)并要求評審會之前做好預(yù)備 15． 在進(jìn)行單元測試時，常用的方法是采用白盒測試，輔之以黑盒測試

16． 側(cè)重于觀察資源耗盡情況下的軟件表現(xiàn)的系統(tǒng)測試被稱為壓力測試 17． 必須要求用戶參與的測試階段是驗收測試 18． 系統(tǒng)測試的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。

19． 測試通?？煞譃榘缀袦y試和黑盒測試。白盒測試是根據(jù)程序的內(nèi)部邏輯來設(shè)計測試用例,黑盒測試是根據(jù)軟件的規(guī)格說明來設(shè)計測試用例。20． 一個程序中所含有的路徑數(shù)與程序的復(fù)雜程度有著直接的關(guān)系。

1． 測試階段的根本目標(biāo)是盡可能多地發(fā)現(xiàn)并排除軟件中潛藏的錯誤，最終把一個高質(zhì)量的軟件系統(tǒng)交給用戶使用。2． 功能測試時系統(tǒng)測試的主要內(nèi)容，檢查系統(tǒng)的功能、性能是否與需求規(guī)格說明相同。3． 軟件測試主要分為單元測試、集成測試、確認(rèn)測試和系統(tǒng)測試四類測試。4． 漸增方式把模塊結(jié)合到程序中去時，有自頂向下和自底向上兩種集成策略。5． 編寫測試用例的依據(jù)是單元測試計劃和詳細(xì)設(shè)計說明書。6． 系統(tǒng)測試時在集成測試完成后，確認(rèn)測試之前進(jìn)行的測試。

7． 設(shè)計系統(tǒng)測試計劃需要參考的項目文檔有軟件測試計劃、軟件需求工件、和迭代計劃。

8． 測試設(shè)計員的職責(zé)有設(shè)計測試用例、設(shè)計測試過程、腳本。

9． 軟件驗收測試包括正式驗收測試、alpha測試、beta測試三種類型。10． 軟件測試按照開發(fā)階段劃分單元測試、集成測試、系統(tǒng)測試、確認(rèn)測試、驗收測試。11． 軟件測試按照測試技術(shù)劃分性能測試、負(fù)載測試、壓力測試、恢復(fù)測試、安全測試、兼容測試

12． 靜態(tài)測試基本特征是在對軟件進(jìn)行分析、檢查和審閱，不實際運行被測試的軟件 13． 軟件測試項目周期是指需求階段、測試計劃、階段測試、設(shè)計階段測試、執(zhí)行階段 14． 軟件測試的角色分析人員、設(shè)計人員、開發(fā)人員、執(zhí)行人員 15． 軟件測試原則有制定嚴(yán)格的測試計劃、、保留所有的測試文檔、功能測試中的缺陷確認(rèn)

16． 測試工作的文檔主要有：測試計劃、測試模型和用例設(shè)計或規(guī)格說明、測試分析報告等

17． 測試計劃的制定必須要注重測試策略、測試范圍、測試方法、測試安排、測試風(fēng)險、測試治理

18． 缺陷的分類為：需求文檔的缺陷、軟件配置引起的缺陷、分析、設(shè)計的缺陷、靜態(tài)文檔的缺陷、軟件開發(fā)引起的缺陷、短視將來的缺陷 19． 測試用例工作主要是如何添加測試用例、如何編寫測試用例、將測試用例和需求關(guān)聯(lián)

20． 自動化測試工具有：ratinal Robot、winrunner、quicktest 21． 軟件性能測試工具有： loadRunner、Ratinaol Visual Qantify、PureLoad 22． BUG的種類有：需求階段的BUG、分析設(shè)計階段的BUG、實現(xiàn)階段的BUG、配置階段的BUG、靜態(tài)文檔的BUG。23． 測試項目主要包括以下幾個階段：計劃階段、初始階段、執(zhí)行階段、總結(jié)評估階段、設(shè)計階段。

1． 缺陷報告

是描述軟件缺陷現(xiàn)象和重現(xiàn)步驟地集合。軟件缺陷報告Software Bug Report（SBR）或軟件問題報告Software Problem Report（SPR）

2． 回歸測試

是指重新執(zhí)行已經(jīng)做過的測試的某個子集，以保證修改變化沒有帶來非預(yù)期的副作用。

3． 動態(tài)測試 通過運行軟件來檢驗軟件的動態(tài)行為和運行結(jié)果的正確性。動態(tài)測試的兩個基本要素： 被測試程序、測試數(shù)據(jù)（測試用例）

4． 白盒測試又稱為結(jié)構(gòu)測試和邏輯驅(qū)動測試，允許測試人員對程序內(nèi)部邏輯結(jié)構(gòu)及有關(guān)信息來設(shè)計和選擇測試用例，對程序的邏輯路徑進(jìn)行測試。白盒測試是把測試對象看作一個打開的盒子，測試人員須了解程序的內(nèi)部結(jié)構(gòu)和處理過程，由于白盒測試是一種結(jié)構(gòu)測試，所以被測對象基本上是源程序，以程序的內(nèi)部邏輯和指定的覆蓋標(biāo)準(zhǔn)確定測試數(shù)據(jù)。

5． 黑盒測試又稱為功能測試或數(shù)據(jù)驅(qū)動測試，把系統(tǒng)看成一個黑盒子，不考慮程序的內(nèi)在邏輯，只根據(jù)需求規(guī)格說明書的要求來檢查程序的功能是否符合它的功能說明。

6． 路徑覆蓋的含義是，選取足夠多的測試數(shù)據(jù)，使程序的每條可能路徑都至少執(zhí)行一次(如果程序圖中有環(huán)，則要求每個環(huán)至少經(jīng)過一次)。

7． 軟件測試 ：在軟件投入運行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。8． 單元測試（模塊測試）：針對每個模塊進(jìn)行的測試，可從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例，多個模塊可以平行地對立地測試。通常在編碼階段進(jìn)行，必要的時候要制作驅(qū)動模塊和樁模塊。9． 集成測試：在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計要求組裝成為系統(tǒng)，應(yīng)提交集成測試計劃、集成測試規(guī)格說明和集成測試分析報告。

10． 確認(rèn)測試：驗證軟件的功能和性能及其它特性是否與用戶的要求一致。

11． 系統(tǒng)測試：將軟件放在整個計算機(jī)環(huán)境下，包括軟硬件平臺、某些支持軟件、數(shù)據(jù)和人員等，在實際運行環(huán)境下進(jìn)行一系列的測試。

1． 測試過程中會產(chǎn)生哪些基本文檔？

（1）測試計劃（通常包括單元測試和集成測試）：確定測試范圍、方法和需要的資源

（2）測試過程：詳細(xì)描述和每個測試方案有關(guān)的測試步驟和數(shù)據(jù)（包括測試數(shù)據(jù)及預(yù)期的結(jié)果）；

（3）測試結(jié)果：把每次測試運行的結(jié)果歸入文檔，如果運行出錯，則應(yīng)產(chǎn)生 問題報告，并且必須通過調(diào)試解決所發(fā)現(xiàn)的問題。

（4）

2.大型軟件系統(tǒng)的測試過程基本上由幾個步驟組成? 1）.模塊測試

在設(shè)計得好的軟件系統(tǒng)中，每個模塊完成一個清晰定義的子功能，而且這個子功能和同級其他模塊的功能之間沒有相互依賴關(guān)系。因此，有可能把每個模塊作為一個單獨的實體來測試，而且通常比較容易設(shè)計檢驗?zāi)K正確性的測試方案。模塊測試的目的是保證每個模塊作為一個單元能正確運行，所以模塊測試通常又稱為單元測試。在這個測試步驟中所發(fā)現(xiàn)的往往是編碼和詳細(xì)設(shè)計的錯誤。2）.子系統(tǒng)測試

子系統(tǒng)測試是把經(jīng)過單元測試的模塊放在一起形成一個子系統(tǒng)來測試。模塊相互間的協(xié)調(diào)和通信是這個測試過程中的主要問題，因此，這個步驟著重測試模塊的接口。3）.系統(tǒng)測試

系統(tǒng)測試是把經(jīng)過測試的子系統(tǒng)裝配成一個完整的系統(tǒng)來測試。在這個過程中不僅應(yīng)該發(fā)現(xiàn)設(shè)計和編碼的錯誤，還應(yīng)該驗證系統(tǒng)確實能提供需求說明書中指定的功能，而且系統(tǒng)的動態(tài)特性也符合預(yù)定要求。在這個測試步驟中發(fā)現(xiàn)的往往是軟件設(shè)計中的錯誤，也可能發(fā)現(xiàn)需求說明中的錯誤。不論是子系統(tǒng)測試還是系統(tǒng)測試，都兼有檢測和組裝兩重含義，通常稱為集成測試。4）.驗收測試

驗收測試把軟件系統(tǒng)作為單一的實體進(jìn)行測試，測試內(nèi)容與系統(tǒng)測試基本類似，但是它是在用戶積極參與下進(jìn)行的，而且可能主要使用實際數(shù)據(jù)(系統(tǒng)將來要處理的信息)進(jìn)行測試。驗收測試的目的是驗證系統(tǒng)確實能夠滿足用戶的需要，在這個測試步驟中發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯誤。驗收測試也稱為確認(rèn)測試。5）.平行運行

關(guān)系重大的軟件產(chǎn)品在驗收之后往往并不立即投入生產(chǎn)性運行，而是要再經(jīng)過一段平行運行時間的考驗。所謂平行運行就是同時運行新開發(fā)出來的系統(tǒng)和將被它取代的舊系統(tǒng)，以便比較新舊兩個系統(tǒng)的處理結(jié)果。這樣做的具體目的有如下幾點：(1)可以在準(zhǔn)生產(chǎn)環(huán)境中運行新系統(tǒng)而又不冒風(fēng)險；(2)用戶能有一段熟悉新系統(tǒng)的時間；

(3)可以驗證用戶指南和使用手冊之類的文檔；

(4)能夠以準(zhǔn)生產(chǎn)模式對新系統(tǒng)進(jìn)行全負(fù)荷測試，可以用測試結(jié)果驗證性能指標(biāo)。3.一套完整的測試應(yīng)該由哪些階段組成？分別闡述一下各個階段。

計劃階段、設(shè)計階段、白盒單元、白盒集成、黑盒單元、黑盒集成、系統(tǒng)測試、回歸測試、驗收測試一套完整的測試應(yīng)該由五個階段組成：

1）測試計劃首先，根據(jù)用戶需求報告中關(guān)于功能要求和性能指標(biāo)的規(guī)格說明書，定義相應(yīng)的測試需求報告，即制訂黑盒測試的最高標(biāo)準(zhǔn)。以后所有的測試工作都將圍繞著測試需求來進(jìn)行，符合測試需求的應(yīng)用程序即是合格的，反之即是不合格的；同時，還要適當(dāng)選擇測試內(nèi)容，合理安排測試人員、測試時間及測試資源等。2）測試設(shè)計將測試計劃階段制訂的測試需求分解、細(xì)化為若干個可執(zhí)行的測試過程，并為每個測試過程選擇適當(dāng)?shù)臏y試用例（測試用例選擇的好壞將直接影響測試結(jié)果的有效性）。

3）測試開發(fā)建立可重復(fù)使用的自動測試過程。

4）測試執(zhí)行執(zhí)行測試開發(fā)階段建立的自動測試過程，并對所發(fā)現(xiàn)的缺陷進(jìn)行跟蹤管理，測試執(zhí)行一般由單元測試、組合測試、集成測試、系統(tǒng)聯(lián)調(diào)及回歸測試等步驟組成，測試人員應(yīng)本著科學(xué)負(fù)責(zé)的態(tài)度，一步一個腳印地進(jìn)行測試。

5）測試評估結(jié)合量化的測試覆蓋域及缺陷跟蹤報告，對于應(yīng)用軟件的質(zhì)量和開發(fā)團(tuán)隊的工作進(jìn)度及工作效率進(jìn)行綜合評價。4.軟件測試的流程

制訂測試計劃、設(shè)計測試用例、實施測試、提交缺陷報告、編寫測試總結(jié)。5.測試計劃的內(nèi)容都包括什么？其中哪些是最重要的？

1)測試計劃的內(nèi)容：測試目的和測試項目簡介、測試參考文檔和測試提交文檔、術(shù)語和定義、測試策略、確定測試內(nèi)容、資源、測試進(jìn)度、測試員的職責(zé)與任務(wù)分配、項目通過或失敗的標(biāo)準(zhǔn)、暫停和重新啟動測試的標(biāo)準(zhǔn)、風(fēng)險和問題等。2)最重要的：測試策略、確定測試內(nèi)容、資源、測試進(jìn)度、測試員的職責(zé)與任務(wù)分配、項目通過或失敗的標(biāo)準(zhǔn) 6.測試計劃的目的是什么？

測試計劃的目的：編寫軟件測試計劃的目的是指導(dǎo)測試組成員進(jìn)行工作和讓測試組以外的項目成員了解測試工作的。7.簡述靜態(tài)測試和動態(tài)測試的區(qū)別？

a)靜態(tài)測試： 基本特征是在對軟件進(jìn)行分析、檢查和審閱，不實際運行被測試的軟件。靜態(tài)測試約可找出30～70%的邏輯設(shè)計錯誤。對需求規(guī)格說明書、軟件設(shè)計說明書、源程序做檢查和審閱。包括：是否符合標(biāo)準(zhǔn)和規(guī)范；通過結(jié)構(gòu)分析、流圖分析、符號執(zhí)行指出軟件缺陷。b)動態(tài)測試：通過運行軟件來檢驗軟件的動態(tài)行為和運行結(jié)果的正確性。動態(tài)測試的兩個基本要素：被測試程序和測試數(shù)據(jù)（測試用例）。動態(tài)測試方法：(1)選取定義域有效值,或定義域外無效值；(2)對已選取值決定預(yù)期的結(jié)果；(3)用選取值執(zhí)行程序；(4)執(zhí)行結(jié)果與預(yù)期的結(jié)果相比,不吻和程序有錯。8.白盒測試有哪幾種方法？

語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。9.壓力測試和性能測試的區(qū)別？

1)廣義上說壓力測試是包括在性能測試之中的，是性能測試項內(nèi)的一種。

2)性能測試：顧名思義就是測試軟件的運行性能。驗證SRS中的性能需求，是否實現(xiàn)。

3)壓力測試：測試軟件在超負(fù)荷下的工作情況，也是一種軟件的性能。因此是屬于性能測試范圍的。

10.測試結(jié)束的標(biāo)準(zhǔn)是什么？

測試計劃中所有規(guī)定的測試內(nèi)容和回歸測試都已經(jīng)運行完成或根據(jù)上級主管對測試結(jié)果的意見，就可以結(jié)束本次測試。11.黑盒測試的測試用例設(shè)計方法包括哪些？：

a)等價類劃分：劃分等價類--確立測試用例--設(shè)計用例。b)邊界值分析：通過分析，考慮如何確立邊界情況 c)錯誤推測法：靠經(jīng)驗和直覺來推測程序中可能存在的各種錯誤，從而有針對性地編寫用例。可以列舉出可能的錯誤和可能發(fā)生錯誤的地方，然后選擇用例。d)因果圖：通過畫因果圖，在圖上標(biāo)明約束和限制，轉(zhuǎn)換成判定表，然后設(shè)計測試用例。這適合于檢查程序輸入條件的各種組合情況。

12.缺陷報告的作用

缺陷報告是軟件測試人員的工作成果之一，體現(xiàn)軟件測試的價值缺陷報告可以把軟件存在的缺陷準(zhǔn)確的描述出來，便于開發(fā)人員修正缺陷報告可以反映項目、產(chǎn)品當(dāng)前的質(zhì)量狀態(tài)，便于項目整體進(jìn)度和質(zhì)量控制。軟件測試缺陷報告是軟件測試的輸出成果之一，可以衡量測試人員的工作能力。13.等價分類法的基本思想是什么？

根據(jù)程序的輸入特性，將程序的定義域劃分為有限個等價區(qū)段“等價類”，從等價類中選擇出的用例具有“代表性”，即測試某個等價類的代表值就等于對這一類其他值的測試。如果某個等價類的一個輸入數(shù)據(jù)（代表值）測試中查出了錯誤，說明該類中其他測試用例也會有錯誤。14.簡單闡述一下軟件測試的目標(biāo)

(1)測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；

(2)好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；(3)成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。15.軟件測試準(zhǔn)則有哪些？

(1)所有測試都應(yīng)該能追溯到用戶需求。

(2)應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測試” 作為軟件開發(fā)者的座右銘。(3)pareto原則：測試發(fā)現(xiàn)的錯誤中的80%很可能是由程序中20%的模塊造成的。

（4）應(yīng)該從“小規(guī)?！睖y試開始，并逐步進(jìn)行“大規(guī)?！睖y試。

（5）測試用例應(yīng)由輸入數(shù)據(jù)和預(yù)期的輸出結(jié)果兩部分組成，并兼顧合理的輸入和不合理的輸入數(shù)據(jù)

（6）窮舉測試是不可能的。

（7）為了達(dá)到最佳的測試效果，應(yīng)該由獨立的第三方從事測試工作。

（8）程序修改后要回歸測試。

（9）應(yīng)長期保留測試用例，直至系統(tǒng)廢棄。16.您認(rèn)為做好測試用例設(shè)計工作的關(guān)鍵是什么？

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

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

1． 根據(jù)下面給出的規(guī)格說明，利用等價類劃分的方法，給出足夠的測試用例。

“一個程序讀入三個整數(shù)。把此三個數(shù)值看成是一個三角形的三個邊。這個程序要打印出信息，說明這個三角形是三邊不等的、是等腰的、還是等邊的?！?/p>

2． 某報表處理系統(tǒng)要求用戶輸入處理報表的日期，日期限制在2003年1月至2008年12月，即系統(tǒng)只能對該段期間內(nèi)的報表進(jìn)行處理，如日期不在此范圍內(nèi)，則顯示輸入錯誤信息。系統(tǒng)日期規(guī)定由年、月的6位數(shù)字字符組成，前四位代表年，后兩位代表月。請用等價類劃分法和邊界值劃分法設(shè)計測試用例來測試程序的日期檢查功能。

3． 設(shè)要對一個自動飲料售貨機(jī)軟件進(jìn)行黑盒測試。該軟件的規(guī)格說明如下：

“有一個處理單價為1元5角錢的盒裝飲料的自動售貨機(jī)軟件。若投入1元5角硬幣，按下“可樂”、“雪碧”或“紅茶”按鈕，相應(yīng)的飲料就送出來。若投入的是2元硬幣，在送出飲料的同時退還5角硬幣?！?/p>

利用等價類劃分的方法，設(shè)計測試該軟件的全部測試用例。